Настройка тестирования на реальных устройствах через Firebase Test Lab

Настройка тестирования на реальных устройствах через Firebase Test Lab

Эмулятор врёт. Не злобно, но систематически: GPU-рендеринг другой, Bluetooth недоступен, камера симулированная, поведение памяти отличается от реального устройства. Мы в TrueTech за 5+ лет опыта с мобильными проектами сталкивались с этим десятки раз. Firebase Test Lab даёт доступ к физическим устройствам — Pixel 8, Samsung Galaxy S24, планшетам, старым Xiaomi с кастомными прошивками. Тест, который прошёл на эмуляторе, может упасть на Samsung One UI из-за кастомного WebView или изменённой системы разрешений. Закажите настройку под ключ — мы подготовим матрицу, Robo Script и CI-интеграцию за 2–3 дня.

Почему эмуляторы подводят, а реальные устройства — нет?

Эмулятор не воспроизводит аппаратные особенности: разное поведение памяти, отсутствие реальных датчиков (акселерометр, гироскоп), эмулированная камера. На реальном устройстве выявляются проблемы с push-уведомлениями (APNs/FCM), работой в фоне (Background fetch) и глубокими ссылками (Universal Links / App Links). По нашим данным, около 30% крэшей, обнаруженных на физических устройствах, не воспроизводятся на эмуляторе. Использование Firebase Test Lab гарантирует, что ваше приложение готово к реальным пользователям.

Что умеет Firebase Test Lab

Два режима тестирования:

Instrumentation Tests — запускает ваши Espresso / XCUITest тесты на выбранных устройствах. Полный контроль над тем, что проверяется.

Robo Test — автоматический краулер. Запускаете APK без единого написанного теста, Robo самостоятельно обходит интерфейс по Accessibility-дереву, нажимает кнопки, заполняет поля случайными данными, ищет крэши. Полезен для быстрой проверки новых сборок перед релизом.

Поддержка платформ: Android (Espresso, UI Automator, Appium) и iOS (XCUITest). Firebase Test Lab для iOS — отдельная история с меньшим парком устройств, но реальные iPhone и iPad всё равно ценнее симулятора.

Настройка: от загрузки билда до результатов

Android

Сборка APK и тест-APK:

./gradlew assembleDebug assembleAndroidTest

Загрузка и запуск через gcloud:

gcloud firebase test android run \
  --type instrumentation \
  --app app/build/outputs/apk/debug/app-debug.apk \
  --test app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk \
  --device model=Pixel8,version=34,locale=ru,orientation=portrait \
  --device model=a54xnsxx,version=13,locale=ru,orientation=portrait \
  --results-bucket gs://my-project-test-results \
  --results-dir "run_$(date +%Y%m%d_%H%M%S)"

model=a54xnsxx — это Samsung Galaxy A54. Список доступных моделей: gcloud firebase test android models list.

Матрица устройств

Выбор матрицы — отдельная аналитическая задача. Нет смысла гонять тесты на 50 устройствах. Принцип:

Реалистичная матрица для большинства проектов: 3–5 устройств. Больше — дороже и дольше, но не обязательно информативнее.

iOS

Для iOS нужен .ipa с development-подписью (не distribution). Загрузка:

gcloud firebase test ios run \
  --test MyAppTests.zip \
  --device model=iphone15pro,version=17.4,locale=ru_RU,orientation=portrait

MyAppTests.zip — архив с .xctestrun файлом и тест-продуктами. Собирается через xcodebuild build-for-testing.

Robo Test с кастомным скриптом

Чистый Robo-краулер иногда застревает на экране логина — не знает учётные данные. Robo Script позволяет задать начальные действия:

[
  {
    "eventType": "VIEW_TEXT_CHANGED",
    "replacementText": "[email protected]",
    "elementDescriptors": [{"resourceName": "com.example.app:id/email_input"}]
  },
  {
    "eventType": "VIEW_CLICKED",
    "elementDescriptors": [{"resourceName": "com.example.app:id/login_button"}]
  }
]

После авторизации Robo продолжает обход уже авторизованной части приложения. Это быстрый способ проверить регрессии без написания тестов.

Интеграция в CI

GitHub Actions:

- name: Set up gcloud
  uses: google-github-actions/setup-gcloud@v2
  with:
    service_account_key: ${{ secrets.GCLOUD_SERVICE_ACCOUNT_KEY }}
    project_id: my-firebase-project

- name: Run tests on Firebase Test Lab
  run: |
    gcloud firebase test android run \
      --app app-debug.apk \
      --test app-debug-androidTest.apk \
      --device model=Pixel8,version=34 \
      --timeout 10m

Service account нужен с ролью Firebase Test Lab Admin. Результаты автоматически сохраняются в Cloud Storage — скриншоты, видео, логкаты, XML-отчёт.

Анализ результатов

В консоли Firebase Test Lab для каждого запуска доступны:

• Видеозапись прохождения теста
• Logcat с фильтром по тегам
• Скриншоты в ключевых точках
• Отчёт о покрытии (если включён jacoco)
• XML-результаты в формате JUnit (для Allure / Jenkins)

Что входит в настройку под ключ

Мы предлагаем полный цикл:

• Анализ вашего парка устройств по данным аналитики
• Конфигурация матрицы из 3–5 устройств
• Написание Robo Script для авторизации (если требуется)
• Интеграция в CI (GitHub Actions, GitLab CI, Bitrise)
• Обучение команды работе с результатами
• Гарантия корректной работы в течение 5 дней после сдачи

Опыт наших инженеров — 30+ проектов с Firebase Test Lab. Свяжитесь с нами для оценки вашего проекта — мы подберём оптимальную конфигурацию.

Сроки

2–3 дня — настройка Firebase Test Lab, конфигурация матрицы устройств, интеграция в CI, настройка Robo Script для авторизации. Плюс время на первый анализ результатов и устранение устройство-специфичных проблем. Стоимость рассчитывается индивидуально.

Как Firebase Test Lab экономит время на регрессиях?

Robo-тесты без единой строки кода находят крэши и ANR на реальных устройствах быстрее, чем ручное тестирование. По нашим данным, это экономит до 40% времени QA-цикла. В сочетании с Instrumentation-тестами вы получаете полное покрытие за считанные часы.

Тестирование мобильных приложений: XCTest, Espresso, Detox и Appium

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

Почему flaky-тесты опасны?

Одна нестабильная проверка может завалить пайплайн, заблокировав релиз. Разработчики тратят 15-20% рабочего времени на перезапуск и анализ ложнонегативных сбоев. Автоматизация без стабильности — не экономия, а потеря эффективности. Мы решаем эту проблему на уровне архитектуры: Gray Box-фреймворки (Detox, Patrol) синхронизируются с состоянием приложения, а native инструменты (XCUITest, Espresso) получают правильные IdlingResource и accessibilityIdentifier. Результат: стабильность >99% на CI.

Unit-тесты: что тестировать, а что нет

На iOS XCTest — основа. Бизнес-логика в ViewModel, Interactor, UseCase — тестируется без проблем, если она не тянет UIKit. Типичная ошибка: логика в UIViewController напрямую — тогда unit-тест требует создания view-иерархии, что медленно и нестабильно. Выход — выносить логику в сервисы с @testable import.

Для асинхронного кода в Swift: XCTestExpectation для старого стиля, await + XCTest async для современного. С Combine — XCTestExpectation + sink, но удобнее использовать библиотеки типа CombineExpectations. На Android JUnit 4/5 + Mockito для unit-тестов, Coroutines Test для suspend-функций. runTest {} из kotlinx-coroutines-test — стандарт для ViewModel с StateFlow. Покрытие кода unit-тестами на уровне 80% сокращает время регрессии на 60% (данные наших проектов).

UI-тесты: стабильность важнее покрытия

XCUITest (iOS) и Espresso (Android) — нативные UI-тесты. Работают быстро, интегрированы с IDE, но тестируют одну платформу. Главная проблема XCUITest — хрупкость селекторов. app.buttons["Войти"] падает при смене локализации или рефакторинге accessibility label. Правильный подход: accessibilityIdentifier для тестируемых элементов, никогда не текстовые метки. Идентификаторы из shared enum — чтобы они не расходились между приложением и тестами. Опыт показывает: такая практика снижает flakiness на 90%.

Espresso на Android стабильнее из-за IdlingResource механизма — тест автоматически ждёт завершения background операций. Но кастомные async операции (OkHttp, кастомные Executors) нужно регистрировать в IdlingRegistry вручную, иначе тест не синхронизируется с сетевыми запросами. Мы гарантируем правильную настройку IdlingResource на этапе аудита.

Detox и Patrol: end-to-end для React Native и Flutter

Detox — E2E фреймворк для React Native, разработанный Wix. Работает на реальных устройствах и симуляторах через Gray Box подход: знает о состоянии JS thread и синхронизируется с ним. Это решает главный flakiness-источник — тест не нажимает кнопку, пока приложение занято. Настройка Detox нетривиальна. Требует специальный debug-билд с DetoxInstrumentsServer, конфигурации в package.json и отдельного Appium-сервера не нужно. Типичная проблема: тест стабилен на симуляторе, падает на реальном устройстве из-за анимаций. Решение — animations: disabled в Detox конфигурации для E2E билда.

Patrol — аналог для Flutter. Расширяет встроенный integration_test пакет и добавляет возможность взаимодействовать с нативными системными диалогами (permission prompts, notifications) — то, что flutter_driver и базовый integration_test не умеют. Для CI используется через patrol test --target integration_test/app_test.dart.

Appium: кроссплатформа с ценой

Appium — когда нужно покрыть iOS и Android одними тестами. Использует WebDriver протокол, поверх XCUITest и UiAutomator2 драйверов. Скорость ниже нативных фреймворков, но для команд без ресурсов на две тестовые кодовые базы — компромисс. Appium 2.x с плагинной архитектурой заметно удобнее первой версии. appium-doctor диагностирует окружение — полезен при настройке CI.

CI и параллелизация

Для параллельного запуска XCUITest используем Xcode Cloud или xcodebuild test-without-building с несколькими симуляторами через parallel-testing-enabled. Время прогона 200 UI-тестов с параллелизацией на 4 симулятора — с 40 минут до 12. На Android аналогично используем Firebase Test Lab с шардингом.

Типичные ошибки при настройке (и как их избежать)

Как мы это делаем: процесс работы

1. Аудит текущего кода и CI — оцениваем flakiness, покрытие, узкие места.
2. Проектирование тестовой архитектуры — выбираем фреймворк, селекторы, моки.
3. Настройка инфраструктуры — CI пайплайн, parallel execution, отчёты (Allure, Xcode Report).
4. Написание тестов — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Интеграция и стабилизация — прогон 200+ тестов, отлов flaky-кейсов.
6. Передача документации — архитектура, запуск, troubleshooting.

Что входит в работу (deliverables)

• Архитектурная документация тестового покрытия
• Настроенный CI-пайплайн с параллелизацией и отчётами
• Код тестов (unit, UI, E2E) с styleguide
• Обучение команды (2 часа воркшопа)
• Доступ к тестовым билдам и CI-логам
• Поддержка в течение месяца после сдачи (фикс flakiness, обновление под новые версии)

Сроки ориентировочно

Настройка инфраструктуры с нуля (CI, unit + UI тесты, отчёты) — 2-3 недели. Написание покрытия для существующего приложения — от 2 недель до месяца в зависимости от объёма. Оценим ваш проект за 2 дня — свяжитесь с нами. 5+ лет опыта в автоматизации, 50+ успешных проектов, сертифицированные специалисты по iOS/Android. Гарантируем стабильность тестов >98% на CI после внедрения.