Хабр, привет! Меня зовут Мельников Станислав, руковожу группой автоматизированного тестирования. В статье расскажу, как мы организовали автоматизацию тестирования мобильного приложения и ушли от бесконечного ручного регресса к ферме устройств и авто-тестам, которые теперь живут в CI. Делюсь цифрами, граблями и планами. 

Почему мы вообще взялись за автоматизацию и с чего начали

Внедрение авто-тестов позволяет увеличить производительность и эффективность, сократить время на проведение тестирования, а также повысить качество продукта, с которым в итоге будет взаимодействовать пользователь. Кроме того, всегда может сработать человеческий фактор и будет допущена ошибка, в то время как авто-тест будет работать по заданному алгоритму.

С самого начала у нас был какой-то план, и мы его придерживались.

Выбор стеков и профиля тестирования

Нам нужно было решение, которое:

• поддерживает и Android, и iOS;

• совместимо с нашим основным стеком технологий (C#);

• доступно для покупки и использования в РФ;

• желательно — open-source.

Из всех представленных решений подходящим оказался Appium. Он полностью соответствует нашим требованиям и позволяет, помимо запуска авто-тестов, выполнять ручное тестирование на реальных удалённых устройствах. Также на нём можно написать простую автоматизацию без использования стороннего софта. В качестве тестового фреймворка выбрали Nunit, с которым команда уже была знакома.

Далее необходимо было определить профиль тестирования – виртуальный или физический. Мы изучили оба варианта: 

• Виртуальные – конечно, удобнее, когда не нужно приобретать множество реальных устройств и можно в любой момент при необходимости поменять параметры устройства. Вот только обслужить их ни разу не проще: для их обслуживания требуется использование мощного оборудования, ведь современные устройства – это вам не Nokia 3310.

• Физические – хоть и собрать всех покемонов все нужные устройства довольно дорогое удовольствие, но тем не менее тесты проходят в условиях, максимально приближенных к реальным.

Именно это и послужило для нас основным критерием в пользу выбора физического профиля тестирования и создания собственной фермы устройств. 

Построение инфраструктуры и подключение железа

У нас было 6 устройств Android, 4устройства iOS, USB-over-IP концентратор для удаленного подключения и несколько тестировщиков, которые пытались понять, как это все устроить.[ГВА(1] 

Сначала мы разбирались с необходимой архитектурой:

• два сервера: Windows или Linux — под Android, и iMac — под iOS;

• и хранилище данных - в нашем случае это сервер на Android, где мы держим необходимые сборки, конфигурации и софт.

А после уже согласовывали схему подключения: 

Настройка ПО на устройствах Android и iOS почти одинаково используются: Appium Server, Appium Framework и драйвер DistKontrol USB, чтобы подключиться к USB-over-IP и устройствам, подключенным к нему. При настройке ПО на iOS мы столкнулись с необходимостью сборки WebDriverAgent-Runner, который требует сертификат Apple, на данный момент заблокированный, поэтому устанавливается только в тестовом режиме при помощи пользовательской лицензии и сертификатов. На Android всё проще: используем AppiumAgent и режим отладки по USB. 

Первый тест и запуск авто-тестов 

Для описания элементов страниц мы использовали Appium Inspector. Это инструмент, позволяющий просматривать структуру приложения, выбирать элементы и копировать их свойства. В окне AppSource можно увидеть структуру приложения, выбрать нужный элемент и узнать его свойства, такие как индекс или id. Это позволяет либо вручную протестировать приложение, либо автоматизировать процесс, сохранив путь к элементу и добавив его в наш фреймворк авто-тестирования.

Также мы начали использовать веб-приложение, которое показывает статус авто-тестов в реальном времени. Оно ещё не развернуто на продакшене, но уже успешно работает в тестовом режиме. Цель — понимать, что происходит на устройстве во время теста, особенно если нет физического доступа к устройству. Там же можно управлять сессиями — например, завершать зависшие, которые остаются «подвешенными» из-за неправильного завершения или обрыва подключения.

Разберем плюсы и минусы, с которыми пришлось столкнуться при автоматизации тестов Android-версии приложения.

Плюсы:

• Приложение тестируется на устройствах от нескольких производителей, что позволило выявить дефекты, связанные с особенностями конкретного телефона: версией ОС, разрешением экрана.

• Рабочая станция авто-тестировщика теперь не выглядит как центр управления полетом. Подключать к ней физически телефоны не нужно.

Минусы

• Поскольку приложение тестируется на разных устройствах, то в авто-тестах приходится описывать взаимодействие со служебными функциями отдельно под каждый телефон. Например, переключение режима «В самолете», обработка диалога выдачи разрешений и т.д.

• Физическое взаимодействие с устройствами все-таки иногда требуется, например, выдача разрешений на отладку по USB. 

Что получилось и куда идём дальше 

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

Из ближайших целей:

• 100% покрытие iOS;

• развёртывание виртуальной фермы — это позволит тестировать не только на тех устройствах, которые у нас есть, но и на новых моделях;

• запуск авто‑тестов без участия человека сразу после выкладки;

Если у вас есть опыт решения проблем с iOS или идеи, как оптимизировать виртуальные фермы — пишите в комментариях. Будет интересно сравнить подходы!