Покрытие мобильного приложения автотестами

Источник: документация проекта мобильных автотестов.

Актуализировано: 2026-08-27.

Назначение отчёта

Это функциональная оценка UI-покрытия Android-приложения BP2, а не code coverage. Источники: ручной regression checklist из Regression checklist, детальная связь сценариев с автотестами из матрицы покрытия, фактическая Pytest-коллекция и регулярный состав запуска из main.py.

Итог по функциональным сценариям

Полностью покрыто 68% сценариев — 90 из 133.

Статус	Сценариев
Покрыто	90
Частично	21
Не покрыто	21
Требует решения	1
Всего	133

Полностью или частично автотестами затронуто 83% сценариев — 111 из 133. Статус каждого REG-MOB сценария и ссылка на конкретный автотест приведены в матрице покрытия.

Автоматизированный UI-набор

Проверено командами collection на 27 августа 2026 года:

Метрика	Значение
UI-вариантов с параметризацией	170
Smoke	35
Regression	135
Регулярных UI-модулей в main.py	12
Unit-тестов инфраструктуры и page objects	332

Модуль	UI-вариантов	Основная область
tests/test_login.py	13	авторизация, восстановление пароля, негативные проверки, logout
tests/test_menu.py	4	нижняя навигация
tests/test_else.py	7	профиль и сотрудники
tests/test_appearance.py	5	темы, основные экраны и Android System UI
tests/test_accounts.py	7	мультиаккаунт и сессии
tests/test_process.py	29	процессы, сделки, документы, этапы
tests/test_deal_fields.py	27	поля и переменные сделки
tests/test_tasks.py	33	CRUD, lifecycle формы, документы с сетевой ошибкой, календарь, комментарии и сеть
tests/test_financial_operations.py	16	степпер, товарная ФО и действия с финансовой операцией
tests/test_notifications.py	11	лента и переходы в задачу/экземпляр процесса
tests/test_push_notifications.py	1	настоящий FCM push и deeplink
tests/test_chat.py	17	личные/групповые чаты, вложения и offline/retry

Все перечисленные модули входят в REGULAR_TEST_MODULES. Чат запускается с отдельными CHAT_* настройками и dev APK/package, когда используется dev backend.

Сильные зоны покрытия

• авторизация, безопасный recover password и основные негативные проверки формы;
• корневая навигация приложения;
• процессы, сделки, документы и базовые переходы этапов;
• поля сделки: сохранение, отмена, границы и обязательность;
• задачи: CRUD, жизненный цикл статуса, сортировка, фильтры по ответственному и участнику, связь со сделкой, права, календарь, документы и комментарии;
• API-assisted матрица степпера, полный товарный E2E и действия с финансовой операцией;
• лента уведомлений, переходы в задачу/экземпляр процесса и настоящий FCM push;
• мультиаккаунт, профиль и сотрудники;
• светлая, тёмная и системная темы, сохранение выбора и видимость ключевого UI;
• личная/групповая переписка, reply, вложения и offline/retry чата;
• управляемая ошибка скачивания с retry и сохранение черновика задачи после background/foreground.

Основные пробелы

• QR login: отсутствуют fixture выпуска одноразового token и источник QR для камеры эмулятора;
• дополнительные фильтры процессов и оставшиеся параметры фильтра задач;
• CRUD комментариев сделки;
• медленная сеть и управляемая ошибка upload документа;
• read/read-all уведомлений и deeplink в компанию/бизнес-процесс;
• расширенные lifecycle-сценарии: orientation, другие формы и cold start без сети;
• app update и часть дополнительных вкладок карточки сделки;
• push/deeplink чата и ошибки вложений.

Состояние последнего полного UI-прогона

Последний сохранённый полный запуск завершился 31 июля 2026 года. Runner зафиксировал 136 passed, 6 failed, 4 xfailed, 1 xpassed. Allure показывает те же 147 вариантов как 137 passed, 5 broken, 1 failed, 4 skipped: xpass входит в passed, а пять UI timeout классифицированы как broken.

Все шесть финальных падений относились к tests/test_tasks.py:

• четыре календарных сценария не находили дату после однонаправленного scroll;
• редактирование комментария начиналось до подтверждённого сохранения;
• offline-refresh очищал ранее загруженный список.

После этого прогона исправлены навигация календаря, восстановление корневого экрана задач, ожидание сохранённого комментария и подготовка API-задачи. Фокусные проверки на видимом эмуляторе прошли: 4/4 календарных сценария и 3/3 сценария CRUD комментариев. Полный suite после этих исправлений ещё не повторялся.

Offline-refresh намеренно не ослаблен: приложение завершает loader и после возврата сети получает новые данные, но при неуспешном refresh скрывает ранее загруженную задачу. Это расхождение с ожидаемым продуктовым поведением, а не ошибка локатора автотеста.

Новый модуль оформления проверен 3 августа 2026 года отдельным полным запуском на видимом Android Emulator: 5 passed. Проверены все пять сценариев подряд, включая восстановление темы приложения и исходного Android night mode. После добавления проверки формы задачи расширенный сценарий основных экранов повторно прошёл фокусный запуск: 1 passed.

Пять P0-сценариев задач, добавленные 12 августа 2026 года, прошли collection и контрактные API/unit-проверки. Фокусный Appium-прогон не стартовал: видимый AVD bp2_api_35 дважды не зарегистрировался в ADB после запуска emulator 36.6.11 (swiftshader_indirect и host); headless-режим не использовался.

После разбора полного прогона P2-набор повторно проверен 14 августа 2026 года: успешно завершены 342 unit-теста, collection подтвердил 170 UI-вариантов и 512 тестов суммарно, проведены фокусные Appium-прогоны на видимом emulator-5554. Сценарии комментария к API-созданной задаче и offline/retry чата прошли. Сценарий восстановления пароля зафиксировал отсутствие входа в форму в текущей сборке. Переход из уведомления по сделке воспроизводит уход с ленты без карточки сделки; товарная вычисляемая ФО доходит до финиша, но API оставляет price и priceWithTax пустыми. Корректировка суммы и разделение ФО сохраняются сервером, но соответствующие формы не закрываются после успеха. Управление сетью чата блокирует REST и оба WebSocket-хоста, а сценарий скачивания документа дополнительно блокирует S3/CDN-хост фактического remotePath.

Правила актуализации

• После изменения tests/ сверять collection, main.py, соответствующий docs/test_*_cases.md и docs/tests_structure.md.
• После изменения ручного regression checklist пересчитывать статусы только по строкам docs/mobile_coverage_matrix.md.
• Execution-метрики обновлять только после полного запуска; фокусные прогоны указывать отдельно и не выдавать за зелёный suite.
• API-assisted сценарии должны явно описывать создание и безусловную очистку тестовых данных.