Тестирование нативных мобильных приложений¶
Требования применяются к iOS и Android. Уровни обязательности определены в
корневом README.md.
Выбор достаточного способа проверки и назначение CI-gates регулируются
DEV-VER; этот документ задаёт только mobile-специфичные свойства тестов.
MOB-TST-001. Уровни тестирования¶
Уровень: SHOULD
Применяется к: изменению поведения с риском регрессии
Изменение следует проверять на самом низком уровне, который подтверждает изменённое наблюдаемое поведение. Несколько уровней тестирования нужны только для независимо значимых рисков на границе бизнес-логики, UI, платформы или интеграции. Критичный пользовательский сценарий следует проверять e2e UI-тестом.
Обоснование¶
Выбор уровня по риску сохраняет полезное покрытие без обязательного дублирования одного поведения несколькими тестами.
Проверка¶
- сопоставление рисков изменения и тестов;
- review негативных сценариев;
- запуск набора в CI.
Исключения¶
Низкорисковое изменение MAY проверяться существующим автоматизированным набором или ограниченной ручной проверкой с фиксацией результата в merge request.
MOB-TST-002. Матрица устройств¶
Уровень: MUST
Применяется к: проверке release candidate
Для каждой поддерживаемой платформы release pipeline должен выполнять smoke- и integration-тесты на минимальной объявленной версии ОС и хотя бы на одной основной версии, используемой проектом. Merge request MAY использовать более узкую матрицу, если затронутый риск проверяется до release. Разные размеры экрана, ориентации и accessibility text sizes могут проверяться component-, screenshot- или параметризованными UI-тестами без полного перемножения с версиями ОС.
Обоснование¶
Минимальная и новая ОС имеют разные API и системное поведение.
Проверка¶
- review CI matrix;
- test report по выбранным версиям и отдельным UI-вариантам;
- контролируемый platform-specific defect.
Исключения¶
Ориентация, запрещённая продуктовым контрактом, не включается.
MOB-TST-003. Реальные платформенные сборки¶
Уровень: MUST
Применяется к: обязательным CI jobs
Тесты каждой поддерживаемой платформы должны компилироваться и выполняться в её реальной среде сборки: iOS — на macOS Runner с iOS Simulator, Android — в Linux container с emulator. Подписанный artifact должен пройти smoke test на физическом устройстве, если изменение затрагивает аппаратную, signing- или permission-границу, которую simulator или emulator не воспроизводит.
Обоснование¶
Simulator не подтверждает подпись, permissions и часть аппаратных функций, но для изменений, не затрагивающих эти границы, физический прогон не добавляет соразмерной уверенности.
Проверка¶
- CI logs и device reports;
- установка подписанного artifact;
- тест permissions и deep links.
Исключения¶
Для критичной аппаратной или permission-функции физический device test обязателен на каждой затронутой платформе.
MOB-TST-004. Сеть, lifecycle и ресурсы¶
Уровень: MUST
Применяется к: integration- и e2e-тестам поведения, зависящего от сети, lifecycle или исчерпаемого локального ресурса
Набор должен проверять те из следующих условий, которые могут изменить наблюдаемый результат тестируемого сценария: offline, медленную или меняющуюся сеть, background/foreground, process death, low memory, storage full, отмену и повтор операции. Assertions должны проверять сохранённый результат и отсутствие дубликата, когда сценарий создаёт сохраняемый результат.
Обоснование¶
Мобильная ОС регулярно приостанавливает и уничтожает процесс.
Проверка¶
- fault-injection scenarios;
- relaunch без сохранённого process memory;
- проверка идемпотентности.
Исключения¶
Условия, не способные повлиять на результат сценария, не требуют отдельного теста или обоснования.
MOB-TST-005. Store upgrade и миграция¶
Уровень: MUST
Применяется к: каждому release candidate
Должны проверяться clean install, upgrade с каждой поддерживаемой схемы локальных данных, сохранение сессии по контракту и logout после несовместимого изменения credentials. Тест должен использовать store-equivalent подписанный artifact.
Обоснование¶
Пользователь обновляет приложение поверх произвольного поддерживаемого состояния.
Проверка¶
- upgrade matrix;
- проверка migrations и Keychain/Keystore;
- тест отката, если магазин и schema его допускают.
Исключения¶
Downgrade не требуется, если он запрещён store и контрактом данных.