инструменты для тестирования мобильных приложений
Автоматизация тестирования мобильных приложений: сравнение инструментов
Автоматизация тестирования помогает решить сразу несколько проблем — в том числе если речь идёт о мобильных приложениях. Вместо того чтобы вручную проводить рутинные трудоёмкие процедуры, специалисты могут делегировать значительную их часть фреймворкам. Автоматизация упрощает проверку и помогает ускорить регрессионное тестирование, а также даёт возможность использовать ранее недоступные типы тестирования.
Мы сравним несколько инструментов, которые зарекомендовали себя на рынке и продолжают развиваться. Эти знания помогут выбрать, какое решение использовать для тестирования того или иного мобильного приложения.
Данная статья вряд ли откроет новые горизонты для профессионалов, но может быть полезна новичкам, решившим освоить азы мобильного тестирования, и в некоторой мере — специалистам среднего уровня.
Классификация инструментов
Первое, от чего следует отталкиваться — это непосредственно платформа, на которой работает приложение. Исходя из этого, классифицируем перечень инструментов следующим образом:
Автоматизация тестирования приложений на Android
UI Automator
Мощный инструмент тестирования с продвинутой внешней интеграцией. Это значит, что данный фреймворк не только позволяет тестировать само приложение, но также способен “общаться” с операционной системой и другими приложениями — например, активировать и деактивировать Wi-Fi, GPS, открывать меню настроек в ходе теста и производить другие внешние взаимодействия.
Предназначение UI Automator — тестирование “чёрного ящика” (black-box testing). Это значит, что анализ производится с позиций внешнего пользователя без доступа к коду.
К основным особенностям относятся:
Espresso
Более лёгкий по сравнению с UI Automator инструмент, не подходящий для взаимодействия с внешними приложениями, но удобный для тестирования “белого ящика” (white-box) с доступом к исходному коду конкретного приложения или тестирования “серого ящика” (grey-box), при котором имеется доступ к некоторым внутренним процессам и структуре.
Вместе с тем, Espresso выделяется мощным API https://github.com/hamcrest. Интерфейс добавляет удобные методы для проверок в автотестах, например:
assert_that(1, less_or_equal(2)). Для тестирования webview при этом используются специальные методы.
UI Automator и Espresso взаимно дополняют друг друга и могут использоваться в комплексе в рамках одного проекта.
Автоматизация тестирования iOS-приложений
XCUITest
Инструмент для black-box тестирования без обращения к коду приложения. Работает только с нативными продуктами — к сожалению, провести cross-app тесты не получится.
С другой стороны, нативный характер фреймворка является преимуществом с той точки зрения, что при использовании XCUITest степень взаимопонимания разработчиков и тестировщиков находится на гораздо более высоком уровне, чем в случаях, когда одни и вторые используют разные языки.
Полезным дополнением является test recorder, который даёт возможность писать тесты путём записи действий в приложении даже тем, кто не работает с кодом.
Инструмент позволяет избежать типичных ошибок и лишних, недоступных пользователю манипуляций с кодом. Однако, при этом XCUITest имеет и некоторые недостатки.
XCUITest, в отличие от Espresso, работает в отдельном потоке, во время тестирования нужно дождаться появления определенных элементов и параметров. Актуальное состояние приложения не считывается, и задержки в обновлении данных могут привести к невозможности обнаружения запрашиваемых элементов.
EarlGrey
У EarlGrey акцент сделан на воспроизведении пользовательского опыта. Пока элементы на экране не представлены визуально, имитация работы с приложением не запускается.
При этом отмечается ряд удобств и преимуществ. Во-первых, специалистам нравится то, как фреймворк синхронизирует запросы, UI и потоки. Не нужно никаких waitforview и wait.
Во-вторых, как уже было сказано, особое внимание уделено отслеживанию видимости элементов. Инструмент обладает дополнительным слоем проверки подгрузки интерфейса и воспроизводит пользовательские жесты — свайпы, нажатия — непосредственно на уровне событий приложения.
Универсальные инструменты
Универсальные инструменты (или “комбайны”) позволяют не ограничивать свой выбор только Android или iOS, а работать с обеими платформами.
Такие инструменты применимы для тестирования приложений следующих видов:
Detox
На наш взгляд, Detox удобен для приложений, написанных на React Native. Тесты пишутся на JavaScript, при этом iOS и Android приложения генерируются из одного и того же кода JavaScript и максимально похожи. Это позволяет использовать одинаковые тесты для обеих платформ.
Ключевая особенность Detox — тестирование по принципу “серого ящика”. В данном случае фреймворк имеет некоторый доступ к внутренним механизмам, что позволяет соотносить внешнее поведение приложения с тем, что происходит на более глубоком уровне.
Detox может обращаться к памяти и отслеживать выполняемые процессы. Принцип grey-box помогает бороться с неустойчивостью, выражающейся в том, что при сквозном тестировании:
Detox не нуждается в WebDriver, работая с нативным драйвером через JSON. Он задействует нативные методы прямо на устройстве. Внутри данного фреймворка применяются EarlGrey для iOS и Espresso для Android.
Фреймворк работает как с эмуляторами, так и с физическими устройствами.
Appium
Преимущество Appium состоит в том, что писать тесты под каждую из платформ можно с помощью единого API, не прибегая к преобразованию приложения в какой-либо особый, совместимый с фреймворком вид.
При тестировании используются фреймворки от вендоров — то есть вы работаете именно с исходным приложением. Для Android 4.2+, соответственно, применяется UiAutomator/UiAutomator2, а для iOS 9.3+ — XCUITest. В качестве оболочки фреймворков используется WebDriver (он же — Selenium WebDriver).
В целом, это гибкий инструмент, который можно доработать под нужды проекта без необходимости подстраиваться под ограниченный набор языков разработки.
Ranorex
Платный комплексный инструмент для тестирования десктопных, мобильных и веб-приложений. Позволяет проводить тестирование как с применением программирования, так и вовсе без использования скриптов. Предоставляет возможность тестирования не только через эмуляторы, но также на живых девайсах.
Инструмент даёт возможность создавать и настраивать тесты, а также управлять ими централизованно. Вы можете создать тест в центре управления и запускать его в различных внешних средах и на любых девайсах.
Легко интегрируется с существующей CI-средой: с такими системами управления заявками, как Jira и TFS, а также с системами контроля версий — например, Git и SVN.
В Ranorex прокачано data-driven тестирование с подгрузкой данных из SQL, CSV, Excel.
Инструмент подходит абсолютно для любого устройства, поддерживает параллельное тестирование на каждом из них.
Сочетает все три подхода к тестированию: black-box, white-box и grey-box.
TestComplete
Платная среда для автоматизации тестирования мобильных, веб и десктопных приложений. Поддерживает Android и iOS, а в разрезе типов приложений: нативные, веб-приложения и гибридные.
Ориентированный, в основном, на функциональное и юнит-тестирование, инструмент также предоставляет возможность проводить многие другие виды тестирования:
Данный инструмент распознаёт объекты и элементы управления, предлагая специальные команды для эмуляции взаимодействия пользователя с ними. Интегрируется с Jenkins, Git и Jira, что позволяет запускать непрерывное бесшовное тестирование.
Подводя итоги
Планируя тестировать то или иное мобильное приложение, обратите внимание на перечисленные выше инструменты. Каждый из них имеет свои особенности, а иногда и ограничения.
Рассмотрим на примере. Если перед вами стоит задача протестировать небольшое приложение в сжатые сроки, в первую очередь нужно учитывать такие факторы, как тип тестируемого приложения и опыт ваших специалистов. Если тесты пишет разработчик, лучше выбрать родной язык и инструмент для его платформы (см. в таблице ниже). Если тестами занимаются специалисты SDET, которые знакомы с другими языками (Java, JavaScript, Python и др.) и работали с Selenium, удобно использовать Appium. Если опытного SDET в команде нет, а тесты будут писать специалисты QA, лучше выбрать платные фреймворки, поскольку в них есть утилиты для записи тестов и более стабильная техподдержка, чем в open source фреймворках.
Из нашей практики:
Мы работали с одним интернет-магазином, у которого было два мобильных приложения – на iOS и Android. Для покрытия тестами основных пользовательских сценариев мы выбрали Appium по нескольким причинам:
В заключение предлагаем вашему вниманию таблицу, которая поможет подобрать инструмент для вашего проекта. Стоит отметить, что в некоторых случаях приведенное в таблице деление является условным. Где-то для простоты сделано обобщение и приведены только самые основные параметры. Инструменты тестирования постоянно развиваются, поэтому при выборе фреймворка важно проверять актуальную документацию.
Путеводитель по инструментам автотестирования мобильных приложений
…несмотря на то, что он кое в чём неполон, содержит много сомнительного или,
во всяком случае, вопиюще неточного, он имеет два важных преимущества:
во-первых, он немного дешевле, [. ], а во-вторых, на его обложке большими
и приятными для глаз буквами написаны два слова «Без паники!»
— The Hitchhiker’s Guide to the Galaxy
Меня зовут Арсений Батыров, я работаю в отделе QA Badoo и занимаюсь в основном ручным тестированием веб-приложений. А ещё я веду курсы по ручному и автоматическому тестированию мобильных приложений.
Перед запуском нового курса я задумался, о каких инструментах стоит рассказать ученикам. Прошерстил Рунет и англоязычный Интернет в поисках сравнительных статей, но, как ни странно, не нашёл подходящего источника информации. И тогда я решил создать его сам.
Я преследовал три цели:
Содержание
Приложение и тесты
Для начала давайте поймём, с чем будут работать наши инструменты.
Есть две важные для нас сущности, не входящие в стек автоматизации: это приложение и тесты. К приложению обращаются все инструменты автоматизации. Оно взаимодействует с пользователем и другими приложениями через один или несколько интерфейсов: GUI, API, сетевой интерфейс, CLI и некоторые другие.
API(application programming interface) — основной интерфейс для взаимодействия с другими программами.
GUI (graphic user interface) — графический интерфейс, используется для взаимодействия с пользователем.
Net (networking interface) — работает через сеть и используется как продвинутыми пользователями, так и программами.
Тесты могут использовать все эти интерфейсы для взаимодействия с приложением. При ручном тестировании посредником между тестами и приложением является тестировщик: он преобразует текст тест-кейсов в действия с одним из интерфейсов приложения.
Для автоматизации нужно заменить тестировщика на инструменты, которые умеют взаимодействовать с одним или несколькими интерфейсами приложения. Также потребуются утилиты для запуска и формирования набора тестов.
Вместе все эти инструменты называются стеком автотестирования. Чтобы понять, как они взаимодействуют в стеке, необходимо их классифицировать. Представленная классификация условна и необходима в первую очередь для понимания инструментов и их сочетаемости.
Всего существует четыре группы инструментов: драйверы, надстройки, фреймворки и комбайны. Рассмотрим их подробнее.
Классификация инструментов
Драйвер
Утилиты автотестирования, как и другие программы, могут взаимодействовать с приложением только через программный интерфейс — по-другому они не умеют. Для работы через другие интерфейсы существуют специальные программы — драйверы.
Драйвер — программа, которая предоставляет API для одного из интерфейсов приложения.
Для каждого интерфейса, кроме, собственно, API, необходим свой драйвер. Например, когда вы даёте драйверу для GUI команду “Нажать на кнопку Menu”, он воспринимает её через API и отсылает в тестируемое приложение, где эта команда превращается в клик по графической кнопке Menu. Для взаимодействия с API приложения драйверы не нужны или почти не нужны — взаимодействие программное. А вот при работе с остальными интерфейсами без них не обойтись.
Наиболее сложными обычно являются драйверы для GUI, так как этот интерфейс сильно отличается от обычного для программы общения кодом. При этом в автоматизированном тестировании мобильных приложений GUI наиболее актуален, так как в интеграционном тестировании использовать чаще всего приходится именно его. Наиболее популярные драйвера для GUI в мобильном тестировании — UIAutomator и Espresso для Android, XCUITest — для iOS.
Надстройка
Когда функционала драйвера не хватает или он неудобен и сложен, над нимпоявляется ещё один уровень, который я буду называть надстройкой.
Надстройка — программа, которая взаимодействует с приложением через один или несколько драйверов, повышая удобство их использования или расширяя их возможности.
Фреймворк
С другой стороны тестов находится фреймворк запуска. В рамках данной статьи я буду коротко называть его “фреймворк”.
Фреймворк — это программа для формирования, запуска и сбора результатов запуска набора тестов.
Если драйверы и надстройки находятся между тестами и приложением, то фреймворк находится над тестами, организуя их запуск. Поэтому важно не путать понятия “драйвер” и “фреймворк”. Конечно, в некоторых фреймворках есть собственные драйверы для работы с приложениями, но это вовсе не обязательное условие. Самые заметные фреймворки в мобильном тестировании — xUnit и Cucumber.
Комбайны
Наконец, ещё одна группа утилит, использующихся для автоматизации тестирования мобильных приложений, — это комбайны, объединяющие в себе и фреймворки, и драйверы (причём не только мобильные), и даже возможности разработки. Xamarin.UITest, Squish, Ranorex — все они поддерживают автоматизацию тестирования iOS-, Android-, веб-приложений, а два последних — ещё и десктоп-приложений.
Итак, инструменты мы классифицировали. Осталось определить самые популярные в каждой категории и сравнить их.
Опрос
Для выявления самых популярных и используемых утилит я провёл опросы на нескольких сайтах, сообществах и каналах для QA-инженеров, задав три простых вопроса. Количество вариантов ответа я не ограничивал, чтобы не пришлось выбирать между разными типами инструментов. Также была возможность добавить собственный вариант — так появился достаточно длинный “хвост” из различных утилит, не вписывающихся в классификацию. Результаты не претендуют на статистическую точность, но отлично иллюстрируют тренды в индустрии автоматизации тестирования мобильных приложений по состоянию на январь 2018 года.
Как видно из результатов, лидирующие позиции занимают утилиты на базе WebDriver: Appium и Selenium. Из фреймворков наиболее популярны JUnit и Cucumber, причём второй популярнее — это удивляет, ведь у них всё-таки разные “весовые категории”. Официальные драйверы популярнее неофициальных для любых платформ — видимо, из-за качественной поддержки и большего количества возможностей, чем у сторонних разработок.
Тройка самых используемых языков программирования выглядит так: Java, Python, Ruby (причём Java лидирует с большим отрывом). Попадание Ruby в тройку лидеров я связываю с популярностью Cucumber.
Наконец, распределение по платформам довольно ожидаемое — Android с серьёзным отрывом опережает iOS, дальше идёт Mobile Web. Удивили разве что ответы про десктоп-приложения для Windows в последнем опросе, но некоторые комбайны позволяют тестировать мобильные и десктопные приложения одновременно.
Разобравшись с популярностью инструментов, переходим к сравнению наиболее значимых. Для каждого типа сначала приведена сравнительная таблица возможностей инструментов, которые к нему относятся. Я постарался собрать самую актуальную и достоверную информацию о каждом инструменте, но мог что-то упустить. Так что если вдруг найдёте ошибку в описании, обязательно напишите об этом в комментариях.
Сравнение инструментов
Драйверы
В мобильном тестировании драйверов немного, и зачастую они разрабатываются теми же компаниями, что и операционные системы. Для Android есть два официальных драйвера: UIAutomator, который на сегодняшний день имеет версию 2.0, и Espresso. Оба они входят в Android Testing Support Library, разрабатываются компанией Google и хорошо документированы. Помимо них, существуют проекты Robotium и Selendroid, которые разрабатываются сторонними компаниями. Все четыре продукта так или иначе работают на Android Instrumentation Framework — базовом API, который Android предоставляет для взаимодействия с системой.
Сначала давайте рассмотрим драйверы от Google. Оба инструмента умеют работать с WebView и гибридными приложениями, оба поддерживают разработку на Java и Kotlin и работают как с эмуляторами, так и с реальными устройствами.
UIAutomator
UIAutomator поддерживает версии Android начиная с API level 18 (Android 4.3). Он не требует внедрения своего кода в проект, то есть может взаимодействовать с уже скомпилированными приложениями. Более того, при работе с UIAutomator можно использовать возможности системы Android полностью: например, включить геолокацию, вызвать системное приложение, повернуть устройство, нажать на кнопку Home или сделать скриншот. Поэтому этот инструмент часто используют для функционального end-to-end-тестирования, самостоятельно или с надстройками.
У UIAutomator нет собственного рекордера для тестов, но зато есть утилита UI Automator Viewer, которая позволяет получать данные об элементах запущенного на эмуляторе или реальном устройстве приложения и показывает локаторы этих элементов. Тут же отображается иерархическая структура всех элементов, что очень удобно для использования их в тестах.
Espresso
Espresso, в свою очередь, предназначен скорее для white-box-тестирования и создавался как инструмент для разработчиков. Он поддерживает более старые API начиная с API level 10 (Android 2.3.3), однако требует доступа к исходному коду для запуска. Соответственно, Espresso не может самостоятельно работать с другими приложениями и системой Android. Зато у этого инструмента есть рекордер, с помощью которого можно записывать простые сценарии и использовать их на начальном этапе автоматизации.
В целом, если нужно тестировать только приложение, без учёта его взаимодействия с системой, и есть желание и возможность работать с исходниками, лучше использовать Espresso. К тому же в нём реализованы полезные функции вроде автоматической синхронизации тестов с UI приложения, и можно не писать различные wait-команды.
Кстати, эти инструменты можно использовать и вместе, потому что они — части одной библиотеки. Даже в одном тесте можно сочетать команды обоих инструментов.
Selendroid и Robotium
И Selendroid, и Robotium были выпущены ещё до появления официальных драйверов и существуют до сих пор.
Robotium поддерживает версии Android API начиная с API level 8 и умеет работать с WebView начиная с API level 15. Selendroid же работает c ограниченным списком версий API — от 10 до 19. Оба инструмента могут обращаться только к одному приложению, не требуют доступа к исходному коду и поддерживают работу на эмуляторах и реальных устройствах. Для Robotium тесты нужно писать на Java, а Selendroid поддерживает протокол WebDriver, что даёт возможность использовать практически любой популярный язык программирования.
У Selendroid есть утилита Inspector, с помощью которой можно просматривать иерархию элементов и записывать простые record-and-playback-тесты. А Robotium предоставляет плагин Robotium Recorder для IntelliJ IDEA и Android Studio со схожим функционалом.
В целом эти инструменты развиваются гораздо менее активно, чем драйверы от Google, и их аудитория значительно у́же. Тем не менее из результатов опроса видно, что некоторые компании до сих пор их используют.
XCUITest
В iOS для взаимодействия с приложением долгое время использовался драйвер UIAutomation (что, помимо прочего, вызывало путаницу из-за схожести с названием драйвера Android), но начиная с iOS 10 Apple прекратила поддержку этого драйвера, и вместо него появился драйвер XCUITest из пакета XCTest.
Он поддерживает iOS начиная с версии 9.0, а тесты для него пишутся на языках Objective-C и Swift, как и сами приложения. Для тестирования приложения не нужен доступ к его коду, а начиная с Xcode 9 драйвер умеет тестировать несколько приложений, в том числе и системных, одновременно. “Из коробки” XCUITest позволяет запускать тесты только на симуляторах, однако при помощи некоторых сторонних утилит можно заставить его работать и с реальными устройствами.
XCUITest имеет свой рекордер, встроенный прямо в интерфейс Xсode. С его помощью можно записывать простые UI-тесты, а также находить элементы UI и их свойства.
Надстройки
Appium
Appium — наиболее известная сегодня надстройка. Она позволяет тестировать приложения практически вне зависимости от платформы, типа и версии системы. Конечно, такой подход имеет несколько значительных достоинств и недостатков.
Самый простой из них — UIAutomator 2.0, с которым Appium взаимодействует напрямую, передавая ему необходимые команды. Он работает с версиями Android 5.0 и выше. С 4.2 до 5.0 можно использовать UIAutomator 1, а взаимодействие с более старыми версиями обеспечивает уже известный нам драйвер Selendroid. Для взаимодействия с XCUITest и обхода некоторых ограничений используется WebDriverAgent (WDA) от Facebook. WDA запускается в контексте симулятора или реального устройства и передаёт команды через API XCUITest.
Облачные платформы для мобильного тестирования
И вот настало то время, когда нашим нуждам тестирования стало тесно на рабочем столе тестировщика. Душа попросилась в облака. На самом деле нет. Не совсем.
Наши цели и задачи
(спешащий читатель, можешь мотать до следующего раздела)
Мы занимаемся разработкой финансового приложения для иностранного рынка, которое доступно в разных форматах: для десктоп-браузеров (веб-сайт и расширение для Google Chrome), для мобильных браузеров, а так же в виде гибридного приложения для телефонов. В связи со спецификой приложения, мы особое внимание уделяем тестированию приложения на различных конфигурациях и устройствах. Для нас важна стабильная и безопасная работа приложения как на настольных браузерах наших клиентов, так и на их любых устройствах.
Причиной поиска облачной фермы устройств для тестирования для нас стала смена формата работы с офисного на полностью удалённый и распределённый (между городами и странами). То есть, если раньше для тестирования мы могли раньше собрать разные устройства в кучу (в буквальном смысле) и протестировать в ручном режиме за одним столом очередную сборку, то сейчас это стало сделать попросту невозможно. Более того, с ростом функционала, для уменьшения ручной работы, регрессионные наборы важных тестов мы автоматизируем, а значит, после сборки нам нужно иметь возможность позвать тесты на желаемой конфигурации и устройстве, причём лучше это сделать сразу же, как только сборка раскатится на staging.
При этом самым простым и очевидным решением является использование эмуляторов для Android и симуляторов для iOS устройств в нашем DevOps конвеере. Однако, что сравнительно легко реализуется на рабочем компьютере разработчика, для использования в облаке становится сложной и дорогой задачей. Для быстрой работы того же эмулятора Android требуется x86 сервер с поддержкой HAXVM, а для симулятора iOS — только MacOS устройство с xcode. Но, к сожалению, даже решив такую задачу остаётся вопрос с разрывом между поведением программного обеспечения на эмуляторах и реальных устройствах. Например каждый второй релиз мы ловим странные баги на Samsung устройствах, которые не воспроизводятся на эмуляторах. Ну, и, конечно редкие экзотические «китайцы» «радуют» уникальным и багами, которые тоже хотелось бы ловить ещё на этапе разработки.
В результате у нас появилось понимание необходимости использования облачной фермы мобильных устройств, на которых мы могли бы быстро прогонять свои тесты и при необходимости производить отладку в ручном режиме. И к которой был бы доступ у всей нашей команды из любой точки мира (мы любим работать даже в путешествиях).
Наши тесты написаны на Python 3.7 (далее это будет важно), как стек мы используем tox + pytest + Selenium + Appium, ну и небольшой набор полезных питонячих библиотек. Мы обязательно тестируем машины на Windows и MacOS с браузерами Edge, Firefox, Chrome, Safari, а так же устройства на Android и iOS — с браузерами и приложением. Тестов у нас на каждое устройство не сильно много (меньше тысячи), но при тестировании в один поток на устройствах полный набор выполняется пару часов. Поэтому критерием выбора сервиса для нас будет:
Желательно, но не обязательно:
Результаты исследования рынка
За неделю я пошерстил интернет и попробовал с десяток разных сервисов. Большинство из них предоставляет бесплатное время для тестирования возможностей. Результаты моего исследования, тем более выводы носят субъективный характер. Ваше мнение и результаты могут отличатся от моего.
На Хабре я нашёл статью за 2017 год посвящённую этой же теме, но с тех пор появились и новые сервисы, да и наша задача чуть строже. Так, например, «вкусные» сервисы вроде Samsung Remote Test Lab, Firebase Test Lab, Xamarin Test Cloud нам, увы, не подходят.
Вне игры
Samsung Remote Test Lab
Сервис бесплатно предоставляет возможность попробовать поработать с различными устройствами Samsung, в том числе с самыми новыми, включая телевизоры или умные часы на Tizen (ограничение — максимум 10 часов в день, за день сервис бесплатно выдаёт 10 кредитов, что равно 2,5 часам в день, минимальная сессия — полчаса (2 кредита)). Это очень неплохо для отладки и поиска корневых причин возникновения ошибок на определённых устройствах, сервис даже предоставляет доступ к удалённой отладке (remote debug bridge, доступ к консоли и системным логам), но, к сожалению, сервис не предоставляет API-доступ к устройствам. Единственная возможность «автоматизировать» — это записать пользовательские действия и затем их воспроизвести в местном средстве автоматизации.
Firebase Test Lab
Visual Studio App Center
Сервисы на выбор
AWS Device Farm
Пожалуй, самая мощная ферма для тестирования на виртуальных и реальных устройствах на сегодняшний день (более 2500 устройств). Для нас это был приоритетный сервис, так как наши сервисы как раз развёрнуты в облаке AWS, кроме того, цены за минуту времени устройства начинаются от 17 центов. AWS позволяет работать как с нативными фреймворками, так и с Appium, Calabash, и другими фреймворками автоматизированного тестирования. Помимо автоматизированного тестирования, сервис предоставляет возможность ручной отладки. Ну и 1000 минут «на попробовать» — это очень заманчиво. Однако, дьявол как водится, кроется в деталях. С точки зрения тестирования у AWS есть несколько особенностей.
Мы, как я уже упомянул, используем Python 3.7, однако AWS Device Farm до сих пор работает с Python 2.7.6 (см. мануал здесь). И из коробки ничего не знает про tox. Для нас это означает отсутствие ряда возможностей и необходимость переработки части тестов для обеспечения обратной совместимости, так и создания окружения в обход tox. Кроме того, достаточно странный механизм загрузки тестового пакета (архив) подразумевает так же и загрузку приложения для тестирования. В нашем случае, если мы будем тестировать наш сервис через мобильный браузер, то загрузка приложения — лишний шаг. Впрочем, приложение можно заменить «заглушкой», а в окружении Python 2.7 создать venv с Python 3.7, и тогда в нём создать окружение с tox, который…
Amazon не был бы Amazon, если бы всё упиралось в старые версии. В качестве альтернативы (и ни у какого сервиса ниже такой возможности не будет) AWS предлагает использовать AWS Device Farm через AWS CLI (command line interface) (см. мануал здесь). То есть, мы можем подключить устройство из облака как реальное устройство к нашему компьютеру в режиме удалённой отладки (remote debug), правда, предварительно заменив adb на патченое (в списке бинарника под linux нет, но уверен, в природе он существует). То есть, настроив AWS CLI, для тестирования нам потребуется выполнить буквально несколько команд (ведь мы не собираемся использовать GUI в виде AWS Device Farm App).
Если мы хотим тестировать приложение, его так же можно загрузить через AWS SDK.
Но я не рассказал ключевой нюанс здесь. Мы снова натыкаемся на дьявола в деталях. Дело в том, что опция удалённой отладки доступна только если для AWS мы используем Private Devices план. Во-первых, данная возможность доступна только под запрос (нужно написать письмо в Amazon), во-вторых опция доступна для региона us-west-2, а в-третьих, фактически эта опция нас возвращает к сценарию, когда у нас есть сервер для тестирования с набором (или хотя бы одним) устройств подключенных к нему. Плюсы очевидны — мы это устройство можем использовать монопольно, что очевидно безопаснее и быстрее, с другой стороны лишаемся главного преимущества — выбора и разнообразия устройств.
Сервис мне в целом понравился, но для нашей команды, увы, в нём слишком много «но».
Bitbar
Процесс настройки прост, как взаимодействие двух перстов с асфальтом:
Kobiton
Настройка так же очень проста, в отличие от bitbar’a почти что оригинальный Appium.
BrowserStack
Experitest
SauceLabs
Perfecto
Сводные результаты
По всем критериям выбора сервисы весьма схожи, разница между сервисами в их производительности и цене (если нет особенностей, например, как в случае AWS). Поэтому сведём данные исследования в таблицу, посмотрим на скорость сервисов (с учётом подключения через US VPN), а так же на цену, для удобства сравнивая среднее месячное время тестирования на устройствах (5 релизов в месяц, по 2 часа тестирования на Android и iOS устройстве = 20 часов). В качестве референсных значений я использую данные со своего локального компьютера с эмулятором, опять-таки подключаясь к нему для чистоты эксперимента через VPN в США).
Выводы
Для меня было достаточно любопытно поисследовать и выбрать подходящий сервис для нашей команды. В целом, есть решения на любой вкус и под любые задачи, а по характеристикам и реализации сервисы весьма оказались похожи. В итоге, в зависимости от ваших задач я бы порекомендовал следующий выбор:
Вариант А: Если вам важна быстрота проверки, и нужны проверки сразу на десятках разных устройств — ваш выбор — Bitbar.
Вариант Б: Если у вас в приоритете результаты с референсных устройств, а конфигурационное тестирование вторично (но необходимо) — ваш выбор — BrowserStack. Это как раз наш кейс, так как статистически — 90% всех ошибок — это ошибки с референсных платформ и устройств (чаще всего баги общие для всех референсных платформ сразу). Оставшиеся 8% — это ошибки MS IE, с отказом от поддержки IE — 2% ошибки MS Edge, а 0,5% ошибки на специфичных конфигурациях.
Вариант В: Если вам важны проверки особых условий, вроде некачественной связи, геопозиции или Touch/FaceID, то ваш выбор — Experitest.
Ну а на долгосрочной перспективе, если ваша компания занимает большой офис, ваша работа Full-Time, то, как правило, организация своей, пусть даже мини-лаборатории с сервером под эмуляторы с подключенными 2-3 устройствами обойдутся дешевле и удобнее, чем использование специализированных сервисов.