Инструкции

Автоматизация тестирования — это один из ключевых инструментов для улучшения качества продукта. Она не только упрощает рутинные процессы и экономит время, но и позволяет проверять приложение на десятках и сотнях устройств за считанные минуты. Однако настроить ее бывает не так просто. Разные версии Android, кастомные оболочки вендоров, особенности экранов — все это часто становится неприятным сюрпризом после нажатия кнопки Deploy. Чтобы обуздать этот хаос, мы создали мобильную ферму Selectel — сервис для тестирования мобильных приложений на реальных устройствах. В ней мы собрали самые незаменимые модели: от Honor и Huawei до Google Pixel. Именно на них чаще всего всплывают баги, отловить которые на эмуляторах попросту невозможно. Меня зовут Максим, я QA-специалист команды развития мобильной фермы в Selectel. В этой статье я проведу вас от уже привычного многим ручного тестирования до полноценной автоматизации с доступом к коллекции из ~400 разных устройств и интеграцией в CI/CD. В качестве примера приведу простую инструкцию по созданию Compose UI-теста под Android-устройство для проверки логики и верстки в вашем приложении. Этап 1. Создание первого теста и запуск на устройстве Начнем с написания первого автотеста и ручного запуска на одном из девайсов фермы. А дальше пройдем весь путь — от одиночных мануальных запусков до полностью автоматизированных прогонов на десятках устройств. Схематично этот процесс можно представить так: Шаг 1. Добавляем ADB-ключ Для начала добавьте свой ADB-ключ в панели управления Selectel. Он поможет вам подключаться к девайсу и запускать тесты. Для этого перейдите в раздел Профиль → Доступ → ADB-ключи. Подробнее о том, как подключиться к устройству мобильной фермы по ADB, рассказываем в документации. Шаг 2. Пишем тестовое приложение Теперь приступим к написанию теста. Для этого будем использовать Android Studio Quail | 2026.1.1. Создаем новый пустой проект (Empty Activity) с названием MobileFarmComposeUITest. Шаг 3. Пишем автотест Теперь сделаем базовый автотест, который будет открывать наше приложение, анализировать текст в шапке, нажимать на кнопку и проверять, что текст изменился. Для этого создаем файл /app/src/androidTest/java/com/example/mobilefarmcomposeuitest/MyFirstAutotest.kt со следующим содержимым. Шаг 4. Подключаемся к устройству фермы Далее возьмем под контроль один из девайсов фермы. Для этого переходим в панель управления и нажимаем на Продукты → Мобильная ферма → Добавить устройство. Для примера я выбрал TECNO-KJ6 — типичного представителя средней ценовой категории. Впрочем, для демонстрации модель не принципиальна: описанный ниже подход будет работать с любым Android-устройством, доступным в рамках фермы. Нажимаем на кнопку Начать использование. Подключаемся к устройству по ADB, используя строку формата adb connect, которая отображается в интерфейсе фермы под названием устройства. Проверяем, что устройство подключилось. Пишем в консоли: В случае успеха мы увидим ответ вроде: Шаг 5. Запускаем тест Возвращаемся в Android Studio. В шапке должен появиться новый доступный девайс. Теперь запускаем наш тест: либо кнопкой Play, либо командой ./gradlew connectedAndroidTest. Она запустит тест сразу на всех подключенных устройствах.Смотрим результат: Чудесно! Первые шаги сделаны. Но что если мы не хотим вручную подключаться к каждому устройству? Как узнать порт каждого из десятка девайсов в проекте и запускать тесты одним кликом? Для этого предлагаю воспользоваться открытым API мобильной фермы. Этап 2. Автоматизация подключения к устройствам с помощью API Предлагаю упростить всю рутину, которую мы выполняли руками на предыдущем этапе. Сделаем запуск тестов полностью автоматическим. Шаг 0. Создаем сервисного пользователя в панели управления Сервисный пользователь нужен для авторизации API-запросов. Создать его достаточно один раз. Сделать это можно в панели управления в разделе IAM → Сервисные пользователи. Для этого нажимаем на кнопку Добавить сервисного пользователя и назначаем ему роль mobile_farm.user или mobile_farm.admin с областью доступа «Аккаунт» или «Проект», если хотите разграничить доступ. mobile_farm.user имеет минимальный набор прав, необходимый для работы с устройствами. Его будет достаточно для большинства сценариев автоматизации. mobile_farm.admin помимо управления устройствами может заказывать новые девайсы и удалять их из проекта. Это пригодится, если в будущем планируете динамически управлять парком устройств — например, добавлять свежие модели под новые задачи и убирать устаревшие по завершении тестов. После создания сервисного пользователя не забудьте скопировать его имя и пароль. Они понадобятся нам чуть позже. Шаг 1. Добавляем ADB-ключ Для нового только что созданного сервисного пользователя не забудьте указать ADB-ключ в разделе IAM → Сервисные пользователи → Пользователь → Доступ. Помните, что ADB-ключ должен быть уникальным для каждого пользователя в панели. Если вы уже привязывали свой ключ на первом этапе при ручном подключении к устройству, его потребуется либо отвязать от вашего личного пользователя, либо сгенерировать новый уникальный ключ специально для автотестов. Таким образом мы получим пользователя с доступом к API, который будет брать девайсы под контроль и подключаться к ним по adb-строке. Шаг 2. Пишем скрипт для работы с API Теперь создадим Python-скрипт, который будет: авторизовываться в API, получать список всех устройств в проекте, захватывать их и переводить в использование, выводить необходимые данные для подключения через ADB. Шаг 3. Добавляем модуль для освобождения устройств Нужно заранее позаботиться о том, чтобы после завершения тестов устройства вернулись в общий пул. Добавим функции для их освобождения: сначала завершим ADB-сессию, затем выведем устройство из-под своего контроля через API. Таким образом освобожденные устройства станут доступны для других автотестов или пользователей проекта. Если пропустить этот шаг, телефон будет занят пользователем вплоть до истечения таймаута, даже после завершения работы теста. Шаг 4. Добавляем парсер аргументов Чтобы не запускать скрипт каждый раз с разными параметрами вручную, мы добавим ему интерфейс командной строки (CLI). Это позволит управлять устройствами одной короткой командой, например python3 device_control.py use или python3 device_control.py release. Параметры USERNAME, PASSWORD, DOMAIN_NAME и PROJECT_NAME можно легко получить из панели управления. USERNAME — это имя нашего сервисного пользователя. Например, MOBILE_FARM_ADMIN из первого шага. DOMAIN_NAME отображается в правом верхнем углу панели как идентификатор аккаунта. PROJECT_NAME — это название проекта, в котором лежат ваши устройства. Например, «My First Project», который создается по умолчанию при регистрации нового аккаунта. Шаг 5. Проверяем работу скрипта Далее запускаем команду захвата устройств аналогично тому, как если бы мы вручную подключались к каждому устройству в проекте и запускали на нем ADB-сервер. Выполним в терминале: Теперь каждое устройство, захваченное скриптом, будет отображаться в панели управления как занятое текущим пользователем. Бронь будет до тех пор, пока мы не откажемся от него или не истечет таймаут. При успешном выполнении мы получим список серийников всех Android-устройств в проекте, а также уникальную строку для adb-подключения к каждому из них. Теперь все устройства захвачены и готовы к выполнению тестов. Шаг 6. Запускаем тесты на всех устройствах Осталось подключиться к каждому устройству по ADB и запустить gradle-тесты. Это можно сделать двумя способами: вручную и автоматически. Способ 1. Ручной В этом случае мы вручную копируем строки подключения, полученные от скрипта на предыдущем шаге, и поочередно вводим их в терминал: После того как все устройства подключены, выполним команду для запуска тестов. Способ 2. Автоматический Добавим в функцию connect_to_all_devices() автоматическое выполнение adb connect. Запускаем CI/CD Будут ли все API-вызовы из приведенного выше скрипта выполняться через curl или запускаться в качестве Python-скриптов — не имеет значения. Главное, что мы на практике разобрались, как создать работающий инструмент, который легко можно встроить в любой процесс. К сожалению, как показывает практика, во многих проектах запуска тестов через CI/CD вовсе нет. Как и инфраструктуры, которая настраивается специально под команду QA. Однако даже если вы пока не используете пайплайны, подобный подход позволит значительно сократить трудозатраты на тестирование, упростить жизнь и подарить уверенность во время релиза новых фичей. Для тех, кто готов идти дальше, приведу пример .gitlab-ci.yml-файла, который можно интегрировать для автоматического запуска тестов на всех девайсах проекта. Он будет работать сразу после нажатия на кнопку Deploy. Заключение Мы проделали большой путь: от идеи и ручного запуска тестов до рабочего инструмента, который управляет устройствами и помогает запускать автотесты на любых Android-устройствах. Будет ли приведенный пример кода запускаться единожды вручную или интегрирован в пайплайны — решать вам. Но я надеюсь, что этот материал сделает ваш процесс тестирования проще и поможет перейти на новую ступень качества продукта. От себя скажу: не бойтесь пробовать что-то новое. Один написанный скрипт или автотест может легко сэкономить вам десятки, а то и сотни часов рутины. Начинайте с малого — с основного функционала и ключевых проверок, постепенно расширяя покрытие, пока автотестами не будет покрыта большая часть кейсов. Качество продукта строится шаг за шагом. И проверка своего приложения на капризных вендорах, кишащих всевозможными ошибками — один из таких шагов. Удачи в автоматизации!

Инструкции

Зарегистрируйтесь в панели управления