qadesk.ru / Платформы и стек / Android
Мобильные приложения

Android — отчёт с эмулятора и устройства, прогон по матрице

Gradle пишет JUnit XML для каждого инструментального теста — QA Деск принимает его как есть и кладёт в покрытие рядом с ручными кейсами; конфигурации прогона превращают план в матрицу «устройство × версия ОС».

Что особенного в мобильном тестировании

Веб-продукт живёт в одной среде — браузере. Мобильное приложение живёт в сотнях: производитель, версия Android, размер экрана, состояние сети, ограничения батареи. Поэтому в тест-менеджменте для Android важны две вещи, которых веб-командам обычно хватает «по умолчанию»: матрица конфигураций у прогона и дефект с точным указанием устройства и номера сборки.

QA Деск ничего не запускает на устройствах и не заменяет ферму. Он собирает результаты — автотестов из Gradle и ручных проверок с телефона — в одно покрытие и заводит дефект там, где разработка его увидит.

Отчёты Espresso и UIAutomator

Инструментальные тесты Android пишут JUnit XML без дополнительных плагинов. После ./gradlew connectedDebugAndroidTest файлы лежат в app/build/outputs/androidTest-results/connected/; для управляемых устройств Gradle (gradle-managed-devices) — в app/build/outputs/androidTest-results/managedDevice/. Юнит-тесты на JVM — в app/build/test-results/.

Загрузка тем же CLI, что и для веб-проектов:

android-tests:
  stage: test
  when: always
  script:
    - ./gradlew connectedDebugAndroidTest
    - curl -fsSL https://qadesk.ru/cli/qadesk-cli-linux-amd64 -o qadesk-cli && chmod +x qadesk-cli
    - ./qadesk-cli upload --run "$CI_PROJECT_NAME android" --env stage --platform android
        --build "$(./gradlew -q printVersionCode)" app/build/outputs/androidTest-results/connected

--platform android и --build ложатся в поля прогона: по ним потом фильтруется история и сравниваются сборки. Приём идемпотентен по паре «прогон CI + попытка» — повтор упавшего задания не создаёт второй прогон.

Ключ кейса в имени теста

Строка покрытия связывается с автотестом через ключ кейса вида QAD-C42. В Kotlin его удобно держать в имени метода или в @DisplayName:

@Test
fun `QAD-C42 вход с верным паролем открывает главный экран`() {
    onView(withId(R.id.login)).perform(typeText("user"))
    // …
}

Приём ищет ключ сначала в property с именем qadesk.case, затем в имени теста, затем в classname. Тесты без ключа не записываются и возвращаются поимённо — это осознанно: тихо принятый отчёт с половиной несматченных результатов хуже честного отказа.

Ручные прогоны по устройствам

У плана в QA Деск есть конфигурации — именованный набор значений вроде {device: Pixel 8, os: Android 14}. Из одного плана стартует несколько прогонов, по одному на конфигурацию, и каждая проверка выполняется отдельно на каждом устройстве. Время исполнения считается по строкам, поэтому руководитель видит, во что обходится регресс на трёх устройствах против одного.

Практичный минимум для Android — три конфигурации: актуальная версия ОС на «референсном» устройстве, минимальная поддерживаемая версия и один аппарат с агрессивным энергосбережением (Xiaomi, Huawei), где чаще всего ломаются фоновые задачи и пуши.

Дефект с телефона

Из упавшей строки прогона дефект заводится одним действием: среда, платформа, сборка и конфигурация переносятся в поля, ссылка на прогон прикладывается. Скриншоты и видео из adb screenrecord прикладываются к дефекту вложениями. Дальше — воркфлоу с проверкой переходов на сервере и задача разработчику в Битрикс24 или SourceCraft.

Если в приложении стоит Sentry, краш становится дефектом без участия тестировщика — см. Sentry.

Чего в продукте нет

  • нет запуска тестов и фермы устройств — результаты приезжают из вашего CI или с рук;
  • нет больших видео во вложении дефекта: сегодня не больше 8 МБ на файл, длинные записи экрана стоит резать;
  • нет готовых пресетов устройств — конфигурации создаются в проекте вручную, пресеты в планах.

С чего начать

  1. Добавьте выгрузку androidTest-results в пайплайн с when: always.
  2. Проставьте ключи кейсов у сценариев входа, оплаты и пушей — там, где ручной регресс дороже всего.
  3. Заведите три конфигурации устройств и запустите план по ним.
  4. Возьмите из каталога чек-лист публикации приложения — проверки разрешений, обновления с предыдущей версии и работы без сети.

Попробуйте на своём проекте

Заведите проект, загрузите первый отчёт или заведите первый дефект — бесплатный тариф без карты. Нужно демо на ваших сценариях — напишите на hello@qadesk.ru.

Создать проект

Рядом по теме

Мобильные приложения

iOS

Xcode складывает результаты в бандл xcresult, а QA Деск принимает JUnit XML — между ними один шаг конвертации в пайплайне; после него автотесты и ручные проверки на устройствах живут в одном покрытии.

iOS — результаты XCTest в покрытие, ручной регресс по версиям Мобильные приложения

Flutter

У кроссплатформенного приложения один набор кейсов и две платформы исполнения — конфигурации прогона в QA Деск позволяют не заводить кейсы дважды, а отчёты flutter test приезжают тем же CLI после конвертации в JUnit.

Flutter — один код, два прогона и одно покрытие Мобильные приложения

Appium

Appium — самый частый выбор для мобильных автотестов вне кода приложения; отчёт даёт тот раннер, из которого вы его запускаете, а QA Деск принимает JUnit или Allure и кладёт результат в прогон нужной платформы.

Appium — один драйвер, два прогона, честный отчёт