Deeplink позволяет открыть определённый экран приложения по ссылке: товар, заказ, приглашение или результат поиска. Для пользователя это короткий путь к нужному действию. Для QA — сценарий, в котором одновременно участвуют ОС, браузер, конфигурация домена, навигация приложения и контроль доступа.
Проверка не заканчивается появлением приложения на экране. Важно, какой объект открылся, под каким аккаунтом, что произойдёт после входа и куда пользователь попадёт по кнопке назад.
Какие ссылки нужно различать
Custom scheme выглядит как qahub://article/123. Такую схему обрабатывает установленное приложение, но сама схема не подтверждает владение веб-доменом и может конфликтовать с другими обработчиками.
Android App Links и iOS Universal Links используют обычные веб-ссылки и подтверждённую связь сайта с приложением. На Android проверяется Digital Asset Links, на iOS — associated domains и apple-app-site-association. Это разные платформенные механизмы с разной диагностикой.
Что входит в контракт ссылки
До тестирования опиши допустимые домены, пути, параметры и ожидаемые экраны. Например, https://example.com/orders/1042 означает просмотр заказа, а не подтверждение покупки. Действия с последствиями обычно требуют явного подтверждения и повторной проверки прав.
Нужно договориться о неизвестном объекте, отсутствующем параметре, старом формате ссылки и приложении, которое ещё не установлено. Без такого контракта одинаковое поведение разные участники команды будут считать то багом, то допустимым fallback.
Проверка связи с доменом
На Android файл assetlinks.json должен соответствовать приложению и сертификату подписи. Проверка debug-сборки не доказывает работоспособность магазинной: подписи могут отличаться. Состояние верификации проверяют на целевом устройстве, учитывая асинхронное выполнение и версию ОС.
На iOS нужны согласованные entitlement и AASA-файл. Учитывай доставку конфигурации через инфраструктуру Apple и кэширование: исправление файла на сервере не обязательно мгновенно меняет поведение уже установленного приложения.
Откуда пользователь открывает ссылку
Проверь реальный источник: письмо, мессенджер, заметки, веб-страницу, QR-код. Встроенный браузер и перенаправления могут менять путь открытия. Ввод URL в адресную строку браузера не является эквивалентом нажатия на Universal Link.
Apple также описывает ситуацию, когда переход между страницами одного домена в Safari остаётся в браузере. Поэтому баг-репорт должен содержать источник и способ открытия, а не только адрес ссылки.
Практический пример: заказ после входа
Представь ссылку на заказ 1042, которая пришла пользователю по почте. Проверяй не только аккаунт владельца, но и другого пользователя с обычными правами.
- 1.Заверши сессию в приложении и нажми ссылку из письма. Ожидается согласованный экран входа с сохранением целевого маршрута.
- 2.Войди владельцем заказа. Приложение должно открыть именно заказ 1042 без лишнего повторного входа и без случайной покупки.
- 3.Вернись назад. История переходов должна быть понятной и не создавать бесконечный цикл между входом и заказом.
- 4.Повтори переход после выхода, войдя другим пользователем. Ожидается отказ в доступе, без раскрытия деталей чужого заказа.
- 5.Удали тестовый заказ разрешённым способом и открой ссылку снова. Приложение должно показать предусмотренное состояние недоступного объекта.
Проверку прав подтверждай ответом API или серверными данными: скрытый экран сам по себе ещё не доказывает защиту ресурса.
Состояния приложения и повторные переходы
Проверь запуск, когда процесс ещё не существует, возврат из фона и открытие поверх другого экрана. Повторная ссылка на тот же объект не должна создавать неконтролируемую стопку одинаковых экранов.
Отдельный случай — два разных перехода подряд во время запуска. Например, пользователь нажал заказ 1042, затем 1043 до окончания входа. Требование должно определять, какой маршрут останется актуальным и не выполнится ли устаревшее действие.
Параметры и безопасность
Считай все параметры внешними данными. Проверь неизвестные идентификаторы, пустые значения, URL-кодирование, лишние параметры и неожиданные вложенные адреса. Приложение не должно доверять роли, цене или владельцу только потому, что они указаны в ссылке.
- →Целевой домен проверяется полностью, без совпадения по случайной подстроке.
- →Возвратный URL ограничен допустимыми направлениями.
- →Секреты и персональные данные не попадают в URL и диагностические вложения.
- →Для изменения данных действуют обычные серверные проверки доступа.
Fallback и отсутствие приложения
Если приложение не установлено, веб-ссылка должна приводить к доступному веб-сценарию или согласованной странице. Custom scheme без обработчика не обеспечивает такой результат автоматически. Проверь также старую установленную версию, которая ещё не знает нового маршрута.
Сохранение контекста после установки — отдельный механизм deferred deep linking. Его нельзя считать встроенным свойством любой App Link или Universal Link: продукт должен явно поддерживать и тестировать этот путь.
Как диагностировать сбой
Разделяй три вопроса: ОС выбрала приложение, приложение разобрало адрес, backend разрешил доступ. Если открывается браузер, начни с домена, подписи и верификации. Если приложение открывается на главной, изучай обработку маршрута и восстановление после входа.
Не подменяй проверку системной маршрутизации прямым вызовом конкретной activity с указанием package. Такой запуск полезен для диагностики обработчика, но может обойти выбор приложения операционной системой.
Что должен вынести QA
Хороший deeplink доставляет пользователя к нужному контексту, сохраняет правильную навигацию и не расширяет права доступа. Проверяй доменную ассоциацию, источник перехода, состояние приложения, авторизацию и fallback как части одного маршрута. Для воспроизведения сохраняй полный адрес с безопасно заменёнными секретами и точный способ открытия.