Инструменты мобильной автоматизации

Кроссплатформенный инструмент против родных

Выбор здесь один и он про компромисс. Appium - кроссплатформенный: один набор тестов работает и на Apple, и на Android, писать можно на привычном языке, потому что он говорит с устройством по общему протоколу управления браузерами и приложениями. Плата за универсальность - он медленнее и хрупче, потому что между тестом и приложением стоит лишняя прослойка.

Родные инструменты - Espresso у Android и XCUITest у Apple - живут внутри платформы, поэтому быстрее и стабильнее: они знают, когда приложение закончило работу и готово к следующему действию. Плата - это два разных набора тестов на двух языках, лежащих в проекте приложения, а значит нужна помощь разработчиков.

// Практический критерий: если команда одна и небольшая, обычно берут кроссплатформенный набор ради единой кодовой базы. Если платформы развивают отдельные команды и важны скорость и стабильность прогонов - родные. А вот способ находить элементы одинаков в обоих случаях: по идентификатору доступности, который ставят разработчики, а не по координатам или порядковому номеру - те рассыпаются на другом разрешении, а разрешений в матрице десятки.

кроссплатформенный набор

один код на обе системы ценой скорости и устойчивости

идентификатор доступности

устойчивая метка элемента; координаты и номера рассыпаются на другом экране

Эмулятор и настоящий телефон

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

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

// Отсюда типичная дыра: вся автоматизация живёт на эмуляторах, потому что так проще для сборки, и именно те баги, ради которых мобильное тестирование вообще существует, остаются непокрытыми. Если своего шкафа с телефонами нет, матрицу арендуют - облачные фермы дают доступ к настоящим устройствам, включая старые модели, которых уже не купить.

эмулятор

виртуальное устройство: дёшево и быстро, но не всё воспроизводит

ферма устройств

облако настоящих телефонов для матрицы без своего шкафа

Консоль устройства, трафик, сборки

Главный инструмент на Android - ADB (Android Debug Bridge), консоль связи с устройством. Через неё берут системные логи, ставят и удаляют приложение, чистят его данные, эмулируют звонок и координаты, снимают экран, открывают ссылки внутрь приложения. Разница в баг-репортах огромная: «крашнулось» против «вот лог падения с этого места» - это неделя переписки против часа работы.

Перехват трафика приложения (Charles, mitmproxy) даёт две вещи. Первая - подменять ответы сервера и получать сложные состояния без участия разработчиков: пустой список, ошибка оплаты, просроченный токен доступа. Вторая - видеть, что приложение реально отправляет, включая аналитику: это единственный способ поймать отправку личных данных открытым текстом.

// Сборки для проверки раздают через магазины для тестировщиков, и внутри сборки держат переключатель окружения, чтобы одна и та же версия ходила на тестовый сервер и на боевой. А на сервере сборки, который сам собирает приложение и гоняет тесты на каждое изменение, мобильные тесты выстраивают ступенями: короткий смоук (несколько шагов, подтверждающих, что главное работает) на изменение, полная матрица - ночью, с сохранением видео, логов и снимков экрана при падении.

ADB

Android Debug Bridge: консоль связи с устройством - логи, данные, ссылки, эмуляция

перехват трафика

подмена ответов сервера и контроль того, что приложение реально отправляет

Как отвечать: «Кроссплатформенный инструмент или родные - как выбрать?»

Это компромисс, и выбираю по составу команды и по тому, что важнее. Кроссплатформенный Appium даёт один набор тестов на обе системы и привычный язык, что удобно небольшой команде, которой не потянуть два стека. Платишь за это скоростью и устойчивостью: между тестом и приложением стоит лишняя прослойка. Родные инструменты, Espresso и XCUITest, живут внутри платформы, поэтому быстрее и стабильнее - они точно знают, когда приложение готово к следующему действию, - но это два отдельных набора в проекте приложения, и без вовлечённости разработчиков не обойтись. Поэтому если команда одна, беру кроссплатформенный ради единой базы; если платформы развивают разные команды и важна скорость прогона - родные. Что не зависит от выбора: элементы ищу по идентификатору доступности, а не по координатам, потому что координаты рассыпаются на другом разрешении, а разрешений в матрице десятки. И помню, что часть проверок вообще нельзя автоматизировать на эмуляторе - жесты, камера, уведомления, батарея, прошивки производителей требуют настоящих устройств.

Почему это сильный ответ: обе стороны компромисса названы с причинами, дан внятный критерий выбора, и добавлены две вещи, не зависящие от инструмента, - устойчивые локаторы и потребность в настоящих устройствах.

На чём валят

• −Держать всю автоматизацию на эмуляторах: уведомления, камера и прошивки производителей не покрыты.
• −Искать элементы по координатам и порядковым номерам - другое разрешение всё ломает.
• −Баг-репорт «крашнулось» без лога с устройства - неделя переписки вместо часа.
• −Ни разу не посмотреть трафик приложения - отправку личных данных в аналитику иначе не поймать.
• −Гонять полную матрицу устройств на каждое изменение - очередь на сборке в полдня.