Your browser is not supported anymore. Please update to a more recent one.


Download Chrome

Download Firefox

Download
Internet Explorer

Download Safari

Путеводитель по инструментам автотестирования мобильных приложений

1 февраля | Арсений Батыров


…несмотря на то, что он кое в чём неполон, содержит много сомнительного или,
во всяком случае, вопиюще неточного, он имеет два важных преимущества:
во-первых, он немного дешевле, [...], а во-вторых, на его обложке большими
и приятными для глаз буквами написаны два слова «Без паники!»
— The Hitchhiker's Guide to the Galaxy
Привет, Хабр!

Меня зовут Арсений Батыров, я работаю в отделе QA Badoo и занимаюсь в основном ручным тестированием веб-приложений. А ещё я веду курсы по ручному и автоматическому тестированию мобильных приложений.

Перед запуском нового курса я задумался, о каких инструментах стоит рассказать ученикам. Прошерстил Рунет и англоязычный Интернет в поисках сравнительных статей, но, как ни странно, не нашёл подходящего источника информации. И тогда я решил создать его сам.

Я преследовал три цели:

  1. Классифицировать инструменты в стеке автотестирования, чтобы стали понятны их иерархия и сочетаемость.
  2. Показать, какие инструменты популярны сегодня на рынке.
  3. Рассказать про самые популярные инструменты каждого типа и сравнить их по нескольким параметрам.

Результатом моих трудов стал этот путеводитель по наиболее популярным и простым в освоении инструментам автотестирования мобильных приложений.

Пользуйтесь!

  • Выбираете инструмент — посмотрите сравнение.
  • Хотите узнать, как устроена автоматизация на мобильных устройствах — загляните в классификацию.
  • Хотите добиться повышения зарплаты — освойте популярный инструмент.

Содержание


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

Приложение и тесты


Для начала давайте поймём, с чем будут работать наши инструменты.

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



API(application programming interface) — основной интерфейс для взаимодействия с другими программами.

GUI (graphic user interface) — графический интерфейс, используется для взаимодействия с пользователем.

Net (networking interface) — работает через сеть и используется как продвинутыми пользователями, так и программами.

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



Для автоматизации нужно заменить тестировщика на инструменты, которые умеют взаимодействовать с одним или несколькими интерфейсами приложения. Также потребуются утилиты для запуска и формирования набора тестов.



Вместе все эти инструменты называются стеком автотестирования. Чтобы понять, как они взаимодействуют в стеке, необходимо их классифицировать. Представленная классификация условна и необходима в первую очередь для понимания инструментов и их сочетаемости.

Всего существует четыре группы инструментов: драйверы, надстройки, фреймворки и комбайны. Рассмотрим их подробнее.
class

Классификация инструментов

cl_driver

Драйвер


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

Драйвер — программа, которая предоставляет API для одного из интерфейсов приложения.



Для каждого интерфейса, кроме, собственно, API, необходим свой драйвер. Например, когда вы даёте драйверу для GUI команду “Нажать на кнопку Menu”, он воспринимает её через API и отсылает в тестируемое приложение, где эта команда превращается в клик по графической кнопке Menu. Для взаимодействия с API приложения драйверы не нужны или почти не нужны — взаимодействие программное. А вот при работе с остальными интерфейсами без них не обойтись.

Наиболее сложными обычно являются драйверы для GUI, так как этот интерфейс сильно отличается от обычного для программы общения кодом. При этом в автоматизированном тестировании мобильных приложений GUI наиболее актуален, так как в интеграционном тестировании использовать чаще всего приходится именно его. Наиболее популярные драйвера для GUI в мобильном тестировании — UIAutomator и Espresso для Android, XCUITest — для iOS.
cl_wrapper

Надстройка


Когда функционала драйвера не хватает или он неудобен и сложен, над нимпоявляется ещё один уровень, который я буду называть надстройкой.

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



У надстройки могут быть следующие функции:
  1. Модификация поведения (без изменения API).
    Например:
    • дополнительное протоколирование,
    • валидация данных,
    • ожидание выполнения действия в течение определённого времени.
  2. Повышение удобства и/ или уровня абстракции API через:
    • использование синтаксического сахара — удобных названий функций, более коротких обращений к ним, унифицированного стиля написания тестов;
    • неявное управление драйвером, когда, например, он инициализируется автоматически, без необходимости прописывать каждое такое действие вручную;
    • упрощение сложных команд вроде выбора события из календаря или работы с прокручивающимися списками;
    • реализацию альтернативных стилей программирования, таких как процедурный стиль или fluent.
  3. Унификация API драйверов.
    Здесь надстройка предоставляет единый интерфейс для работы сразу с несколькими драйверами. Это позволяет, например, использовать один и тот же код для тестов на iOS и Android, как в популярной надстройке Appium.
cl_framework

Фреймворк


С другой стороны тестов находится фреймворк запуска. В рамках данной статьи я буду коротко называть его “фреймворк”.

Фреймворк — это программа для формирования, запуска и сбора результатов запуска набора тестов.



В задачи фреймворка входят:
  • формирование, группировка и упорядочивание набора тестов,
  • распараллеливание набора (опционально),
  • создание фикстур,
  • запуск тестов,
  • сбор результатов их выполнения,
  • формирование отчётов о выполнении (опционально).
Можно заметить, что эти функции не связаны с тестированием только мобильных приложений — их можно успешно применять и в тестировании десктоп- и веб-приложений. Дело в том, что фреймворк не должен обеспечивать взаимодействие тестов и приложения — он работает только с тестами, и тип приложения не имеет значения.

Если драйверы и надстройки находятся между тестами и приложением, то фреймворк находится над тестами, организуя их запуск. Поэтому важно не путать понятия “драйвер” и “фреймворк”. Конечно, в некоторых фреймворках есть собственные драйверы для работы с приложениями, но это вовсе не обязательное условие. Самые заметные фреймворки в мобильном тестировании — xUnit и Cucumber.
cl_combine

Комбайны


Наконец, ещё одна группа утилит, использующихся для автоматизации тестирования мобильных приложений, — это комбайны, объединяющие в себе и фреймворки, и драйверы (причём не только мобильные), и даже возможности разработки. Xamarin.UITest, Squish, Ranorex — все они поддерживают автоматизацию тестирования iOS-, Android-, веб-приложений, а два последних — ещё и десктоп-приложений.



Итак, инструменты мы классифицировали. Осталось определить самые популярные в каждой категории и сравнить их.
quiz

Опрос


Для выявления самых популярных и используемых утилит я провёл опросы на нескольких сайтах, сообществах и каналах для QA-инженеров, задав три простых вопроса. Количество вариантов ответа я не ограничивал, чтобы не пришлось выбирать между разными типами инструментов. Также была возможность добавить собственный вариант — так появился достаточно длинный “хвост” из различных утилит, не вписывающихся в классификацию. Результаты не претендуют на статистическую точность, но отлично иллюстрируют тренды в индустрии автоматизации тестирования мобильных приложений по состоянию на январь 2018 года.







Как видно из результатов, лидирующие позиции занимают утилиты на базе WebDriver: Appium и Selenium. Из фреймворков наиболее популярны JUnit и Cucumber, причём второй популярнее — это удивляет, ведь у них всё-таки разные “весовые категории”. Официальные драйверы популярнее неофициальных для любых платформ — видимо, из-за качественной поддержки и большего количества возможностей, чем у сторонних разработок.

Тройка самых используемых языков программирования выглядит так: Java, Python, Ruby (причём Java лидирует с большим отрывом). Попадание Ruby в тройку лидеров я связываю с популярностью Cucumber.

Наконец, распределение по платформам довольно ожидаемое — Android с серьёзным отрывом опережает iOS, дальше идёт Mobile Web. Удивили разве что ответы про десктоп-приложения для Windows в последнем опросе, но некоторые комбайны позволяют тестировать мобильные и десктопные приложения одновременно.

Разобравшись с популярностью инструментов, переходим к сравнению наиболее значимых. Для каждого типа сначала приведена сравнительная таблица возможностей инструментов, которые к нему относятся. Я постарался собрать самую актуальную и достоверную информацию о каждом инструменте, но мог что-то упустить. Так что если вдруг найдёте ошибку в описании, обязательно напишите об этом в комментариях.
compare

Сравнение инструментов

drivers

Драйверы




В мобильном тестировании драйверов немного, и зачастую они разрабатываются теми же компаниями, что и операционные системы. Для Android есть два официальных драйвера: UIAutomator, который на сегодняшний день имеет версию 2.0, и Espresso. Оба они входят в Android Testing Support Library, разрабатываются компанией Google и хорошо документированы. Помимо них, существуют проекты Robotium и Selendroid, которые разрабатываются сторонними компаниями. Все четыре продукта так или иначе работают на Android Instrumentation Framework — базовом API, который Android предоставляет для взаимодействия с системой.

Сначала давайте рассмотрим драйверы от Google. Оба инструмента умеют работать с WebView и гибридными приложениями, оба поддерживают разработку на Java и Kotlin и работают как с эмуляторами, так и с реальными устройствами.
uiautomator

UIAutomator


UIAutomator поддерживает версии Android начиная с API level 18 (Android 4.3). Он не требует внедрения своего кода в проект, то есть может взаимодействовать с уже скомпилированными приложениями. Более того, при работе с UIAutomator можно использовать возможности системы Android полностью: например, включить геолокацию, вызвать системное приложение, повернуть устройство, нажать на кнопку Home или сделать скриншот. Поэтому этот инструмент часто используют для функционального end-to-end-тестирования, самостоятельно или с надстройками.

У UIAutomator нет собственного рекордера для тестов, но зато есть утилита UI Automator Viewer, которая позволяет получать данные об элементах запущенного на эмуляторе или реальном устройстве приложения и показывает локаторы этих элементов. Тут же отображается иерархическая структура всех элементов, что очень удобно для использования их в тестах.


espresso

Espresso


Espresso, в свою очередь, предназначен скорее для white-box-тестирования и создавался как инструмент для разработчиков. Он поддерживает более старые API начиная с API level 10 (Android 2.3.3), однако требует доступа к исходному коду для запуска. Соответственно, Espresso не может самостоятельно работать с другими приложениями и системой Android. Зато у этого инструмента есть рекордер, с помощью которого можно записывать простые сценарии и использовать их на начальном этапе автоматизации.

В целом, если нужно тестировать только приложение, без учёта его взаимодействия с системой, и есть желание и возможность работать с исходниками, лучше использовать Espresso. К тому же в нём реализованы полезные функции вроде автоматической синхронизации тестов с UI приложения, и можно не писать различные wait-команды.

Если же вам нужно протестировать приложение в связке с другими или с функциями системы, а доступ есть только к .apk, выбирайте UIAutomator.

Кстати, эти инструменты можно использовать и вместе, потому что они — части одной библиотеки. Даже в одном тесте можно сочетать команды обоих инструментов.
selendroid_robotium

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

XCUITest


В iOS для взаимодействия с приложением долгое время использовался драйвер UIAutomation (что, помимо прочего, вызывало путаницу из-за схожести с названием драйвера Android), но начиная с iOS 10 Apple прекратила поддержку этого драйвера, и вместо него появился драйвер XCUITest из пакета XCTest.

Он поддерживает iOS начиная с версии 9.0, а тесты для него пишутся на языках Objective-C и Swift, как и сами приложения. Для тестирования приложения не нужен доступ к его коду, а начиная с Xcode 9 драйвер умеет тестировать несколько приложений, в том числе и системных, одновременно. “Из коробки” XCUITest позволяет запускать тесты только на симуляторах, однако при помощи некоторых сторонних утилит можно заставить его работать и с реальными устройствами.

XCUITest имеет свой рекордер, встроенный прямо в интерфейс Xсode. С его помощью можно записывать простые UI-тесты, а также находить элементы UI и их свойства.


wrappers

Надстройки



appium

Appium


Appium — наиболее известная сегодня надстройка. Она позволяет тестировать приложения практически вне зависимости от платформы, типа и версии системы. Конечно, такой подход имеет несколько значительных достоинств и недостатков.

Appium поддерживает множество драйверов, не только мобильные:
  • iOS
    • XCUITest
    • (deprecated) UIAutomation
  • Android
    • (beta) Espresso
    • UIAutomator 2.0
    • (deprecated) UIAutomator
    • (deprecated) Selendroid
  • Windows Driver (для десктопных Windows-приложений)
  • Mac Driver (для десктопных Mac-приложений)
Поддержка такого разнообразия драйверов реализуется довольно интересным образом: Appium использует версию интерфейса WebDriver, известную всем по Selenium WebDriver. И, помимо большого количества поддерживаемых платформ, у такого подхода есть и другие преимущества:

  • возможность писать тесты на любом языке, который поддерживает WebDriver (а в этот список входят практически все популярные языки программирования). Более того, это позволяет “отвязать” тесты от использования “родных” для приложения языков. Наиболее актуально это для iOS, ведь тесты на XCUITest можно писать только в Xcode. С Appium же в данном случае можно использовать любой язык и любую удобную среду разработки;
  • лёгкий переход к тестированию гибридных и веб-приложений: протокол WebDriver уже (почти) стал стандартом для автоматизации веба;
  • использование любого тестового фреймворка — почти все они умеют так или иначе работать с протоколом WebDriver, а значит, у них не возникнет проблем с подключением к Appium;
  • отсутствие необходимости добавлять что-то в код приложения — для каждой платформы используются драйверы, которым не нужен доступ к коду. Помимо удобства в развёртывании, это означает возможность тестировать именно тот билд приложения, который увидят пользователи, а не специальную тестовую сборку.
Нас в большей степени интересует поддержка мобильных приложений, поэтому остановимся подробнее на реализациях драйверов UIAutomator 2.0, Selendroid и XCUITest.

Самый простой из них — UIAutomator 2.0, с которым Appium взаимодействует напрямую, передавая ему необходимые команды. Он работает с версиями Android 5.0 и выше. С 4.2 до 5.0 можно использовать UIAutomator 1, а взаимодействие с более старыми версиями обеспечивает уже известный нам драйвер Selendroid. Для взаимодействия с XCUITest и обхода некоторых ограничений используется WebDriverAgent (WDA) от Facebook. WDA запускается в контексте симулятора или реального устройства и передаёт команды через API XCUITest.



Недостатки Appium вытекают из его достоинств:
  • тесты ломаются чаще, чем те, что написаны для нативных драйверов, из-за ошибок в коде самой надстройки. Особенно это актуально для iOS, ведь там добавляется WDA;
  • Appium не умеет находить и сравнивать картинки в приложениях и не может напрямую работать с алёртами в Android;
  • ограниченная поддержку Android API < 17, но это, возможно, будет исправлено подключением Espresso в качестве драйвера.
  • Тем не менее надстройка Appium очень популярна и активно развивается, поэтому многие проблемы могут решиться сообществом в будущем.
wda

WebDriverAgent


Переходим к надстройке WebDriverAgent, которую Appium использует для работы с iOS. Фактически это реализация серверной части протокола WebDriver, которая позволяет управлять устройствами на iOS. Причём функционал доступен достаточно обширный: можно запускать и останавливать приложения, использовать жесты и проверять видимость элементов на экране.

Работает надстройка как с симуляторами, так и с реальными устройствами. Для обнаружения элементов есть интерфейс инспектора, открывающийся в браузере. Сама надстройка поддерживается командами Facebook и Appium и довольно активно развивается. При этом её можно использовать и отдельно от Appium, если по каким-то причинам последняя вам не подходит.
calabash

Calabash


Следующая весьма популярная надстройка — Calabash для Android и iOS. Инструмент разработан компанией Xamarin, но она прекратила его поддержку в 2017 году, и сейчас он поддерживается только сообществом.

Для каждой ОС есть своя надстройка — Calabash iOS или Calabash Android. Обе они поддерживают тестирование WebView и языки Ruby/ JRuby. Для работы Calabash Android не нужен доступ к исходникам приложения, а вот для работы Calabash iOS понадобится подключить к коду приложения Calabash framework. Также для работы с view вне нативного iOS-приложения используется дополнительный инструмент — DeviceAgent, который позволяет детектить эти views и взаимодействовать с ними. Теоретически это означает, что можно тестировать и WebView, но на практике лучше ограничиться теми views, которые выдаёт iOS для вашего приложения: различные оверлеи для подтверждения, отправка писем и вставка фотографий. Calabash Android поддерживает работу с WebView, но в достаточно ограниченных масштабах: тап, ввод текста, алёрты.

В целом Calabash — довольно стабильный и быстрый инструмент, имеющий полезные функции для приведения приложения в нужное состояние (бекдоры) и “из коробки” поддерживающий интеграцию с Cucumber. Но из-за отсутствия официальной поддержки при его использовании могут возникнуть проблемы, а сообщество не может гарантировать их быстрое решение.
earlgrey

Earl Grey


Earl Grey — это своего рода реализация Espresso для iOS, и она тоже разработана Google. Здесь всё стандартно для iOS-надстроек: её нужно обязательно добавить в проект в Xcode, тесты можно писать только на Objective-C и Swift, приложение можно тестировать только одно — внешних views она не видит. Зато поддерживается тестирование на реальных устройствах. Сама по себе надстройка интересная, поддерживается более-менее регулярно, но популярностью у тестировщиков почему-то не пользуется.
frameworks

Фреймворки




Фреймворки меньше всего связаны с тестированием мобильных устройств — они работают с тестами и интегрируются с любыми драйверами и надстройками. Поэтому я не буду их подробно рассматривать (этому посвящены сотни материалов в Интернете), а сделаю лишь поверхностное сравнение.
xunit

xUnit и TestNG


Наиболее популярны фреймворки семейства xUnit. Они создавались как инструменты для unit-тестирования, и первым таким сервисом был JUnit. При этом они могут работать не только с модульными тестами, но и с любыми другими. Благодаря своей универсальности фреймворки xUnit используются повсеместно и доминируют в тестировании веб-приложений. JUnit работает только с Java, но сейчас есть реализации таких фреймворков практически под любой популярный язык программирования.

Несколько отличается от этой группы фреймворк TestNG, в котором больше различных вспомогательных функций.
cucumber

Cucumber


Также популярны BDD-фреймворки, и в первую очередь Cucumber. В отличие от xUnit и TestNG, здесь тесты и их шаги формируются на основе документации и пишутся на Gherkin — языке, близком к естественному. Уточню, что Cucumber всё-таки нацелен на приёмочное тестирование, и реализовать на нём автоматизацию функционального тестирования довольно сложно.
combines

Комбайны



xamarin

Xamarin


Xamarin — это сервис для мобильной разработки и тестирования приложений, у которого есть собственные фермы с мобильными устройствами и инструменты для автоматизации тестирования, в том числе на этих фермах. Разработка ведётся в основном на C#, есть собственный рекордер.
ranorex

Ranorex


Ranorex — инструмент для автоматизации практически любых приложений. Умеет интегрироваться с Selenium, тестировать мобильные приложения на эмуляторах и реальных устройствах. Доступен только для Windows, в качестве языка для тестов использует C# и VB.NET. Также имеет рекордер для тестов.
squish

Squish


Squish — также умеет автоматизировать веб-, мобильные и десктопные приложения, поддерживает BDD, имеет собственный рекордер и IDE. Для написания тестов можно использовать Python, Perl, JavaScript, Tcl или Ruby.

Главное достоинство таких решений — полный цикл тестирования; нет необходимости конфигурировать отдельные утилиты и их взаимодействие. Однако все эти инструменты платные, зачастую с закрытым кодом и достаточно редко используются для тестирования мобильных приложений. Поэтому однозначно рекомендовать их я не могу.
conclusion

Заключение


Это, конечно, далеко не полный список возможных инструментов функционального тестирования мобильных приложений. За рамками этой статьи остались KIF, Frank, SilkMobile, TestComplete и множество других утилит. Статья задумывалась как путеводитель по основным инструментам, и я надеюсь, что она поможет кому-то понять стек автотестирования мобильных приложений и не ошибиться в выборе сервисов. Если у вас есть что добавить по теме, пишите в комментарии, я их обязательно прочту и дополню статью какими-то интересными вещами.

Для вашего удобства все инструменты я разместил в одной таблице и сделал список полезных ссылок — эти материалы вы найдёте в разделе “Шпаргалки” ниже.
credits

Благодарности


Огромное спасибо всей команде Badoo за помощь в подготовке и рецензировании статьи, вы классные! Отдельное спасибо — @z3us, @nizkopal и Виктору Караневичу.
hints

Шпаргалки







links

Полезные ссылки


Подкаст с обменом опытом автоматизации тестирования мобильных приложений
Курс по автоматизации, ради которого всё и затевалось
UIAutomator 2.0:
https://github.com/appium/appium/blob/master/docs/en/drivers/android-uiautomator2.md
https://bitbar.com/how-to-get-started-with-ui-automator-2-0/
https://developer.android.com/training/testing/ui-testing/uiautomator-testing.html
XCUITest:
https://github.com/appium/appium/blob/master/docs/en/drivers/ios-xcuitest.md
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/09-ui_testing.html
Espresso:
https://developer.android.com/training/testing/espresso/index.html
https://developer.android.com/training/testing/ui-testing/espresso-testing.html
Robotium:
https://github.com/RobotiumTech/robotium
https://github.com/RobotiumTech/robotium/wiki/Questions-&-Answers
Selendroid:
selendroid.io/setup.html
selendroid.io/faq.html
Calabash iOS:
https://github.com/calabash/calabash-ios
https://github.com/calabash/calabash-ios/wiki/DeviceAgent
Calabash Android:
https://badoo.com/techblog/blog/2017/01/24/break-limitations-with-calabash-android/
Earl Grey:
https://github.com/google/EarlGrey
https://bitbar.com/how-to-get-started-with-earlgrey-ios-functional-ui-testing-framework/
Appium:
appium.io/introduction.html
https://github.com/appium/appium
WebDriverAgent
https://github.com/facebook/webdriveragent
https://www.mutuallyhuman.com/blog/2017/04/20/webdriveragent-getting-started-with-automated-ios-testing
Cucumber:
https://cucumber.io/
xUnit
junit.org/junit5/
TestNG
testng.org/doc/
Xamarin.UITest:
https://developer.xamarin.com/guides/testcloud/uitest/
https://developer.xamarin.com/guides/testcloud/uitest/intro-to-uitest/
https://developer.xamarin.com/guides/testcloud/introduction-to-test-cloud/#The_Anatomy_of_the_Test_Cloud_Framework
Squish:
https://doc.froglogic.com/squish/6.0/tutorials-iphone.html
https://doc.froglogic.com/squish/6.0/tutorials-android.html
Ranorex:
https://www.ranorex.com/help/latest/android-testing
https://www.ranorex.com/help/latest/android-testing/automation-of-system-apps
https://www.ranorex.com/help/latest/ios-testing