AWS Device Farm: настройка тестирования на реальных устройствах

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
AWS Device Farm: настройка тестирования на реальных устройствах
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Регрессионное тестирование мобильного приложения на десятке устройств — головная боль без облачной фермы. Разные производители, версии ОС, разрешения экранов — каждый тест приходится запускать локально или на реальных устройствах в офисе. AWS Device Farm решает эту проблему, используя экосистему AWS: те же IAM-роли, CLI, политики доступа. Наш опыт показывает, что 80% проблем при первом запуске — неправильная упаковка тестов или конфигурация пула устройств. Избежать этих ошибок поможет эта статья. Мы настроили Device Farm для 30+ проектов, и среднее сокращение времени регрессионного тестирования составило 70% — это позволило клиентам отказаться от покупки физических устройств и сосредоточиться на качестве кода.

Как настроить тестирование на AWS Device Farm?

Почему AWS Device Farm, а не BrowserStack или Sauce Labs?

Если ваш проект уже на AWS (CodePipeline, CodeBuild, S3), Device Farm встраивается органично: не нужен отдельный логин, биллинг через AWS, IAM-политики централизованы. Для компаний с требованиями к data residency это плюс — устройства находятся в тех же регионах, что и остальная инфраструктура. Device Farm поддерживает APK/IPA и Instrumentation-тесты (Espresso) без дополнительной прослойки. По сравнению с BrowserStack, Device Farm даёт больше контроля над пулом устройств, хотя интерфейс менее интуитивен.

Что входит в настройку?

Компонент Описание
Проект и IAM-роли Создание проекта, минимальные права
Пул устройств Фильтрация по платформе, версии ОС, производителю
Упаковка тестов Примеры для Appium, Espresso, XCUITest
Интеграция CI/CD CodePipeline, GitHub Actions, GitLab CI
Отчёты и уведомления Slack, Telegram, S3
Документация Инструкции для вашей команды, скрипты

Типы тестов: сравнение

Тип Скорость Поддержка Сложность упаковки
Appium Средняя Android, iOS Средняя (зависимости в ZIP)
Espresso Высокая Android (4.3+) Низкая (обычный APK)
XCUITest Высокая iOS (9.0+) Средняя (xcodebuild)

Как упаковать Appium-тесты для Device Farm?

Упаковка Appium-тестов — частая причина сбоев. Device Farm требует ZIP с package.json, node_modules и тестами. Структура для WebdriverIO:

tests.zip/
├── package.json
├── package-lock.json
├── node_modules/
└── test/
    └── specs/
        └── login.test.js

Конфиг WebdriverIO:

// wdio.conf.devicefarm.js
exports.config = {
  runner: 'local',
  specs: ['./test/specs/**/*.js'],
  capabilities: [{
    platformName: process.env.DEVICEFARM_DEVICE_PLATFORM_NAME,
    'appium:deviceName': process.env.DEVICEFARM_DEVICE_NAME,
    'appium:platformVersion': process.env.DEVICEFARM_DEVICE_OS_VERSION,
    'appium:app': process.env.DEVICEFARM_APP_PATH,
    'appium:automationName': process.env.DEVICEFARM_DEVICE_PLATFORM_NAME === 'iOS' ? 'XCUITest' : 'UiAutomator2',
  }],
  hostname: 'localhost',
  port: 4723,
};

Device Farm сам запускает Appium-сервер, переменные передаются автоматически.

Нативные тесты: Espresso и XCUITest

Espresso работает быстрее Appium, так как выполняется в одном процессе с приложением. Загрузка APK и тест-APK через AWS CLI:

PROJECT_ARN=$(aws devicefarm create-project --name "MyApp" --query 'project.arn' --output text)
APP_UPLOAD=$(aws devicefarm create-upload --project-arn $PROJECT_ARN --name "app-debug.apk" --type ANDROID_APP --query 'upload.{arn:arn,url:url}' --output json)
APP_URL=$(echo $APP_UPLOAD | jq -r '.url')
APP_ARN=$(echo $APP_UPLOAD | jq -r '.arn')
curl -T app/build/outputs/apk/debug/app-debug.apk "$APP_URL"
TEST_UPLOAD=$(aws devicefarm create-upload --project-arn $PROJECT_ARN --name "app-debug-androidTest.apk" --type INSTRUMENTATION_TEST_PACKAGE --query 'upload.{arn:arn,url:url}' --output json)
TEST_ARN=$(echo $TEST_UPLOAD | jq -r '.arn')
curl -T app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk "$(echo $TEST_UPLOAD | jq -r '.url')"
aws devicefarm schedule-run --project-arn $PROJECT_ARN --app-arn $APP_ARN --device-pool-arn $POOL_ARN --name "Espresso Run" --test type=INSTRUMENTATION,testPackageArn=$TEST_ARN,filter="com.example.LoginTest"

Для iOS используйте XCUITest, упаковка через xcodebuild.

Пошаговая инструкция по настройке Device Farm

  1. Создайте проект Device Farm и настройте IAM-роли с минимальными правами (devicefarm:* на проект).
  2. Сформируйте пул устройств: выберите платформу, версии ОС, производителей и отфильтруйте по AVAILABILITY: HIGHLY_AVAILABLE, чтобы избежать очередей.
  3. Загрузите приложение (APK/IPA) и тестовый пакет через AWS CLI или консоль. Убедитесь, что тесты упакованы правильно (ZIP с зависимостями).
  4. Запустите тестовый прогон, выбрав пул и тип теста (Appium, Espresso, XCUITest).
  5. Настройте интеграцию с CI/CD (CodePipeline, GitHub Actions) и уведомления (Slack, Telegram).

Интеграция с CI/CD

Добавьте этап в buildspec.yml для CodePipeline:

phases:
  build:
    commands:
      - ./gradlew assembleDebug assembleAndroidTest
      - APP_ARN=$(aws devicefarm create-upload --project-arn $DEVICE_FARM_PROJECT_ARN --name "app.apk" --type ANDROID_APP --query 'upload.arn' --output text)
      # ... загрузка и запуск
      - aws devicefarm get-run --arn $RUN_ARN --query 'run.result'

IAM-роль CodeBuild должна иметь разрешения devicefarm:* на проект.

Почему тесты падают при первом запуске?

Типичные ошибки:

  • Неправильная упаковка Appium-тестов — ZIP без node_modules.
  • Пул устройств без фильтра AVAILABILITY: HIGHLY_AVAILABLE — прогон встаёт в очередь на час.
  • Неверные переменные окружения — Device Farm передаёт DEVICEFARM_DEVICE_PLATFORM_NAME и другие.
  • Отсутствие прав на запись в S3 для артефактов.

Официальная документация AWS рекомендует использовать пулы высокой доступности для минимизации времени ожидания.

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

Артефакты доступны через API:

aws devicefarm list-artifacts --arn $JOB_ARN --type FILE --query 'artifacts[*].{name:name,url:url}' --output table

Типичные артефакты: Logcat, Screenshots, Video, Test spec output. Наши инженеры настраивают автоматическую отправку отчёта в Slack или Telegram.

Кейс: как настройка Device Farm сэкономила 40 часов в месяц

Один из клиентов — финтех-стартап с Android-приложением, тестируемым на 20 устройствах локально. Каждый прогон регрессии занимал 8 часов ручного труда. После настройки Device Farm с интеграцией в GitLab CI время сократилось до 1,5 часов полностью автоматически. Мы настроили пул из 10 параллельных устройств, подключили уведомления в Slack и экспорт отчётов в S3. Затраты на облачную ферму оказались ниже стоимости содержания собственного парка устройств.

Наши инженеры имеют AWS-сертификации и 10+ лет опыта в мобильной разработке. Мы гарантируем, что первый прогон будет успешным в течение 3 дней после начала работ.

Свяжитесь с нами для бесплатной оценки вашего проекта. Закажите настройку AWS Device Farm и получите первый успешный прогон через 3 дня. Все скрипты и документация остаются у вас.

Подробнее о Device Farm читайте в официальной документации AWS.

Тестирование мобильных приложений: 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 с шардингом.

Фреймворк Платформа Gray Box Скорость Системные диалоги
XCUITest iOS Нет Высокая Да (через addUIInterruptionMonitor)
Espresso Android Да (IdlingResource) Высокая Ограничено
Detox React Native Да Средняя Ограничено
Patrol Flutter Частично Средняя Да
Appium iOS + Android Нет Низкая Да

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

Ошибка Последствие Решение
Использование текстовых меток в селекторах Тесты падают при локализации accessibilityIdentifier из enum
Отсутствие IdlingResource для кастомных Executor Espresso не ждёт ответа сервера Регистрация в IdlingRegistry
Включённые анимации на реальном устройстве в Detox Flaky тесты из-за таймингов animations: disabled в E2E билде
Параллелизация без изоляции состояния Гонки данных между тестами Запуск каждого теста в свежем симуляторе

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

  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 после внедрения.