Разделы портала

Онлайн-тренинги

.
Путеводитель по инструментам автотестирования мобильных приложений
02.02.2018 00:00
    Автор: Арсений Батыров, Mobile QA тренер

    Оригинальная публикация: https://habrahabr.ru/company/badoo/blog/347986/

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

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

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

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

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

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

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

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


    Содержание


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

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

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

    Есть две важные для нас сущности, не входящие в стек автоматизации: это приложение и тесты. К приложению обращаются все инструменты автоматизации. Оно взаимодействует с пользователем и другими приложениями через один или несколько интерфейсов: 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.

    Надстройка

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

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


    У надстройки могут быть следующие функции:

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


    Фреймворк

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

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


    В задачи фреймворка входят:

    • формирование, группировка и упорядочивание набора тестов,
    • распараллеливание набора (опционально),
    • создание фикстур,
    • запуск тестов,
    • сбор результатов их выполнения,
    • формирование отчётов о выполнении (опционально).


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

    Если драйверы и надстройки находятся между тестами и приложением, то фреймворк находится над тестами, организуя их запуск. Поэтому важно не путать понятия “драйвер” и “фреймворк”. Конечно, в некоторых фреймворках есть собственные драйверы для работы с приложениями, но это вовсе не обязательное условие. Самые заметные фреймворки в мобильном тестировании — 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-команды.

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

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

    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 — наиболее известная сегодня надстройка. Она позволяет тестировать приложения практически вне зависимости от платформы, типа и версии системы. Конечно, такой подход имеет несколько значительных достоинств и недостатков.

    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 4.2 и выше. Взаимодействие с более старыми версиями обеспечивает уже известный нам драйвер Selendroid. Для взаимодействия с XCUITest и обхода некоторых ограничений используется WebDriverAgent (WDA) от Facebook. WDA запускается в контексте симулятора или реального устройства и передаёт команды через API XCUITest.

    Недостатки Appium вытекают из его достоинств:

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


    WebDriverAgent

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

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

    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. Но из-за отсутствия официальной поддержки при его использовании могут возникнуть проблемы, а сообщество не может гарантировать их быстрое решение.

    Earl Grey

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

    Фреймворки


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

    xUnit и TestNG

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

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

    Cucumber

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

    Комбайны


    Xamarin

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

    Ranorex

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

    Squish

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

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

    Заключение

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

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

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

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

    Шпаргалки


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

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

    Обсудить в форуме