Automation test android что это

ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ ANDROID-ПРИЛОЖЕНИЙ С ИСПОЛЬЗОВАНИЕМ ПРОТОКОЛА WEBDRIVER НА ПЛАТФОРМЕ.NET Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Ананьев Владимир Юрьевич

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

TEST AUTOMATION TECHNOLOGY OF ANDROID APPLICATIONS USING THE WEBDRIVER PROTOCOL ON THE.NET PLATFORM

The article deals with the development of automated tests utilizing the WebDriver Protocol. The WebDriver and Appium technologies are analyzed, that allow implementation of automated tests of Android applications at the level of the graphical interface on the .NET platform. The most useful patterns in the development of GUI tests are investigated. The project architecture is proposed, which allows you to simply develop reliable and supported automated tests of mobile applications on the .NET platform .

Текст научной работы на тему «ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ ANDROID-ПРИЛОЖЕНИЙ С ИСПОЛЬЗОВАНИЕМ ПРОТОКОЛА WEBDRIVER НА ПЛАТФОРМЕ.NET»

ИНФОРМАТИКА, ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА И УПРАВЛЕНИЕ

ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ ANDROID-ПРИЛОЖЕНИЙ С ИСПОЛЬЗОВАНИЕМ ПРОТОКОЛА WEBDRIVER НА ПЛАТФОРМЕ .NET

Ананьев Владимир Юрьевич

Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича,

TEST AUTOMATION TECHNOLOGY OF ANDROID APPLICATIONS USING THE WEBDRIVER PROTOCOL ON THE .NET PLATFORM

Ananev Vladimir Iurievich

Master’s student of

Federal State Budget-Financed Educational Institution of Higher Education The Bonch-Bruevich Saint Petersburg State University of Telecommunications

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

Abstract: The article deals with the development of automated tests utilizing the WebDriver Protocol. The WebDriver and Appium technologies are analyzed, that allow implementation of automated tests of Android applications at the level of the graphical interface on the .NET platform. The most useful patterns in the development of GUI tests are investigated. The project architecture is proposed, which allows you to simply develop reliable and supported automated tests of mobile applications on the .NET platform.

Ключевые слова: автоматизация тестирования, тестирование программного обеспечения, Android, Appium, .NET, NUnit, WebDriver.

Key words: test automation, software testing, Android, Appium, .NET, NUnit, WebDriver.

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

Обзор предыдущих исследований. Тестирование программного продукта получило развитие, начиная с середины прошлого века. Процесс тестирования был предельно формализован, отделен от процесса непосредственной разработки ПО. Существовала концепция так называемого «исчерпывающего тестирования» — проверки всевозможных путей выполнения кода со всеми возможными входными данными. Однако выяснилось, что исчерпывающее тестирование на практике зачастую нереализуемо, так как количество возможных путей и входных данных очень велико. Стали исследоваться вопросы оптимизации тестирования. Процессинг тестирования обрел свою теорию. Говоря о родоначальниках тестирования, нужно сказать о книге «Искусство тестирования программ» Гленфорда Майерса [1]. Достойным источником информации о процессах тестирования являются разработки Рекса Блэка в книге «Ключевые процессы тестирования» [2]. Информативным представляется исследование о практике тестирования С Куликова [3].

В начале 21 века развитие тестирования продолжалось в контексте поиска все новых и новых путей, методологий, техник и подходов к обеспечению качества [4, а 5-10]. Серьезное влияние на понимание тестирования оказало появление гибких методологий разработки и таких подходов, как «разработка под управлением тестирования».

В настоящее время для упрощения процесса тестирования и сокращения временных затрат на этапе контроля качества в процессе разработки программного обеспечения стали часто применять автоматизацию. Автоматизация тестирования сегодня воспринимается как неотъемлемая часть большинства проектов с целью сокращения затрат путем использования программных средств для выполнения тестов и проверки результатов их выполнения.

Целью исследования является анализ технологий и подходов к разработке проекта автоматизации тестирования Android-приложения на уровне графического интерфейса с использованием протокола WebDriver на платформе .NET. Основная часть.

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

Для упрощения процесса тестирования и сокращения временных затрат на этапе контроля качества в процессе разработки программного обеспечения часто применяют автоматизированное тестирование. Средства автоматизации позволяют: •увеличить скорость выполнения тест-кейсов;

•снизить влияние человеческого фактора в процессе их выполнения; •минимизировать затраты при многократном выполнении тест-кейсов;

•выполнять тест-кейсы, непосильные человеку ввиду сложности, скорости и других причин [4, с. 5-10].

Selenium был первоначально разработан Джейсоном Хаггинсом в 2004 году в качестве внутреннего инструмента в ThoughtWorks. Позже к Хаггинсу присоединились другие программисты и тестировщики в ThoughtWorks. В том же году Selenium был опубликован как ПО с открытым исходным кодом.

В 2007 году Хаггинс присоединился к Google. Вместе с другими разработчиками, в частности, с Дженнифер Беван, продолжил разработку Selenium. В то же время Саймон Стюарт из ThoughtWorks разработал инструмент автоматизации браузера под названием WebDriver. В 2009 году, после встречи разработчиков на конференции Google по автоматизации тестирования, было решено объединить два проекта и назвать новый проект Selenium WebDriver, или Selenium 2.0. С течением времени Selenium стал основным инструментом управления веб-браузерами.

В 2012 года Саймон Стюарт (изобретатель WebDriver), который тогда работал в Google, и Дэвид Бернс из Mozilla вели переговоры с W3C о том, чтобы принять WebDriver в качестве стандарта. В июле 2012 года был выпущена рабочая версия документа, а стандарт был принят июне 2018 года.

WebDriver — это стандарт W3C, описывающий API для автоматизации браузеров, и инструмент, который реализует данный стандарт. Для эмуляции действий пользователя при работе с мобильными приложениями существует много инструментов автоматизации, однако есть только один, реализующий стандарт W3C WebDriver [5, с. 36-38].

Appium как реализация стандарта WebDriver для управления мобильными устройствами Appium — это инструмент для автоматизации тестирования нативных, мобильных, веб-приложений для iOS, Android и Windows платформ. Важным его преимуществом является кросс-платформенность: он позволяет писать тесты на разные платформы, используя один и тот же API, что дает возможность повторно использовать один и тот же код.

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

1) разработчики не должны пересобирать или модифицировать приложения для автоматизации его тестирования;

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

Appium имеет клиент-серверную архитектуру. Сервер получает команды, которые необходимо исполнить и возвращает результат выполнения.

Клиент-серверная архитектура позволяет разрабатывать сценарии для тестов на любом языке программирования, который поддерживает протокол HTTP. При выполнении команд Appium-сервер переводит стандартные команды в вызовы методов ПО управления устройством. Для Android используется UI Automator, для iOS — XCUITest. Таким образом Appium инкапсулирует различные технологии управления различными устройствами в единый интерфейс, предусмотренный стандартом.

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

Выполнение команд всегда происходит в контексте сеанса. Клиенты инициируют сеанс с сервером, указывая набор так называемых «желаемых свойств» (Desired capabilities). Набор «желаемых свойств» сервера содержит в себе указания, управление, каким устройством требуется клиенту и каким приложением необходимо управлять. В случае, если сервер не может обеспечить сессию с требуемыми свойствами, запрос создания сессии завершится с ошибкой.

Appium поддерживает работу как с эмуляторами, так и с реальными устройствами. Для упрощения работы и минимизации затрат мы будем использовать эмулятор Android устройств от Google, который поставляется вместе с пакетом разработки Android-приложений Android Studio.

После установки Android Studio и требуемого Android SDK необходимо создать эмулятор требуемой версии и запустить его при помощи команды «emulator -avd «.

Убедиться в том, что эмулятор или устройство доступно для Appium можно, запустив команду «adb devices».

Паттерны проектирования, специфичные для автоматизированного тестирования

Так как одно действие пользователя может требовать нескольких операций с WebDriver, предлагается отделить действия пользователя от деталей реализации данных действий. Таким образом минимизируются изменения в логике самих тестов, необходимые для их адаптации при изменении интерфейса. Для реализации этой абстракции использован шаблон проектирования, известный, как Page Object. Он состоит в том, что каждой странице веб-сайта или приложения в соответствие ставится класс, а доступная на странице функциональность описывается методами этого класса. Это позволяет исключить дублирование кода и описывать в тестовых сценариях логику взаимодействия в терминах высокоуровневого функционального описания системы. Код, использующий библиотеки для управления браузером, скрыт внутри классов — наследников описания страницы. Исследования показывают, что применение данного шаблона упрощает поддержку тестовых скриптов [5, с. 36-38].

При создании экземпляра класса, инкапсулирующего какую-либо страницу, может возникнуть несоответствие реального состояния приложения и его модели. Для того, чтобы этого избежать, создадим абстрактный класс ScreenBase, от которого наследуются остальные классы Page Object. Код класса ScreenBase:

public abstract class ScreenBase

public abstract AndroidElement pageLoadedVerifierElement

protected DriverContainerData driverContainerData; protected AndroidDriver ad;

protected TimeSpan pageLoadWaitTimeSpan = TimeSpan.FromSeconds(3); public ScreenBase()

protected ScreenBase(AndroidDriver ad, DriverContainerData driverContainerData, TimeSpan? pageLoadWaitTimeSpan = null, bool assertIsOpenAfterWait = false,

bool doScreenShotAfterPageLoadWait = true)

private void WaitUntilIsOpen(bool assertIsOpenAfterWait)

Assert.IsTrue(IsOpen(), $»Не удалось обнаружить окно «); >

protected void WaitUntilIsOpen(TimeSpan PageLoadWaitTimeSpan)

WebDriverWait wait = new WebDriverWait(ad, PageLoadWaitTimeSpan); wait.IgnoreExceptionTypes(typeof(WebDriverTimeoutException), typeof(TimeoutException));

_ = wait.Until(_ => IsOpen());

public virtual bool IsOpen()

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

Chain of Invocations

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

Применяя данный паттерн, разработчик не может совершить ошибку, когда действие с классом Page Object будет некорректно для текущего состояния приложения.

Управление состоянием AndroidDriver Для управления Android-устройством в Appium под .NET предоставляется класс AndroidDriver. Создадим класс-обёртку, который управлял бы созданием драйвера, его уничтожением и требуемыми свойствами сервера.

public class DriverContainerData

public string deviceName < get; set; >public Uri appiumUrl < get; set; >public string app < get; set; >public string appPackage

public string appActivity

public class DriverContainer

public AndroidDriver driver

public readonly DriverContainerData containerData;

private readonly AppiumOptions options = new AppiumOptions();

public DriverContainer(DriverContainerData d)

this.containerData = d; options.PlatformName = «Android»;

options.AddAdditionalCapability(MobileCapabilityType.Udid, d.deviceName); options.AddAdditionalCapability(MobileCapabilityType.App, d.app); options.AddAdditionalCapability(AndroidMobileCapabilityType.AppPackage, d.appPackage); options.AddAdditionalCapability(AndroidMobileCapabilityType.AppActivity, d.appActivity); options.AddAdditionalCapability(MobileCapabilityType.NoReset, true);

public void CreateDriver()

driver = new AndroidDriver(containerData.appiumUrl, options,

public void KillDriver()

if (driver != null)
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Фреймворк для тестирования NUnit NUnit — это фреймворк модульного тестирования для всех языков .NET. Первоначально NUnit был портирован с языка Java (библиотека JUnit). Впоследствии NUnit был полностью переписан c добавлением новых функций и поддержкой широкого спектра платформ .NET.

NUnit использует атрибуты для идентификации тестов. Основными атрибутами являются [Test] -атрибут, указывающий непосредственно на тестовый метод, и атрибут [TestFixture], указывающий на класс, в котором хранится некоторое множество методов с атрибутом [Test], [SetUp] — атрибут, которым помечаются методы, выполняемые перед каждым тестом из Test Fixture, [TearDown]. Причем, методы, помеченные данным атрибутом, выполняются после каждого теста из Test Fixture.

Интересен механизм определения порядка вызова методов SetUp и TearDown при наследовании классов Test Fixture. А именно, если в базовом классе определён метод SetUp, то он будет вызван перед каждым тестовым методом в классе-наследнике. Если имеет место многоуровневое наследование, то будут вызваны все методы SetUp в порядке наследования классов. Методы TearDown вызваются в обратном порядке наследования [6, с. 23-27].

Иерархия классов типа Test Fixture Благодаря особенностям реализации порядка вызова методов SetUp и TearDown в NUnit, мы имеем возможность построить приведение тестируемого приложения в определённое состояние к началу теста.

Для того, чтобы в каждом Test Fixture был Android Driver без необходимости дополнительных действий для работы с ним, создадим абстрактный класс TestFixtureBase:

public abstract class TestFixtureBase

protected DriverContainer cont;

protected AndroidDriver driver; [SetUp]

public void GetDriver()

Метод GetDriver() осуществляет получение DriverContainer из управляющего класса DriverManager в начале каждого теста.

Классы Test Fixture с самими тестами дальше наследуются от данного базового. Благодаря порядку вызова методов SetUp и TearDown разработчик может быть уверен, что к началу каждого теста приложение будет находиться в определённом состоянии, которое предусмотрено конкретным классом с атрибутом Test Fixture.

Так, в иерархии классов TestFixture можно выделить Test Fixture, который приводил бы приложение к началу теста в состояние неавторизованной зоны, SetUp-метод которой не будет содержать никаких операторов, и Test Fixture авторизованной зоны, SetUp-метод которой будет содержать авторизацию в приложении.

С учётом описанного функционала и особенностей возможна следующая структура проекта:

n a m e spa ce Abstra ct

abstract class ScreenBase

a bstra ct cl a ss Те stF i xtu re В a se

abstract class NotAuthorizedZoneFixture :

a bstra ct cl a ss Auth ori ze d Zon e F i xtu re :

sealed class TestFixture A:

sealed class TestFixture В :

При всем сказанном, как и для любого другого этапа разработки программного обеспечения, у этапа тестирования существуют характерные вопросы. Актуальность необходимости решения этих вопросов объясняется прежде всего, популярностью «гибких» (англ. agile) методологий разработки программного обеспечения.

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

Второй большой проблемой автоматизации тестирования является поддержка тестов в актуальном состоянии. Обновления тестов могут понадобиться как в случае изменения функционала, так и в случае изменения самих входных данных теста. Это характерно для обоих видов автоматизации. При реорганизации кода часто возникает необходимость обновить также юнит-тесты, а обновление кода собственно тестов, возможно, будет сравнимо по времени с изменением основного кода. Кроме того, в случае изменения интерфейса приложения возникает необходимость вновь переписать тесты, связанные с обновленными окнами, что при большом числе тестов может потребовать значительных ресурсов [6].

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

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

1. Технология Appium позволяет реализовывать автоматизированные тесты мобильных приложений под Android c использованием протокола WebDriver.

2.Шаблоны проектирования Page Object и Chain of Invocations являются наиболее полезными при разработке автоматических тестов графического интерфейса.

3.Предложенная архитектура проекта, позволяет просто разрабатывать надёжные и поддерживаемые автотесты мобильных приложений на платформе .NET.

Перспективой развития данного исследования является исследование вопроса параллельного запуска тест-кейсов и Android-эмуляторов, а также интеграция разработанного приложения в процесс CI.

1.Майерс Г, Баджетт Т., Сандлер К. Искусство тестирования программ. Изд-во Вильямс. 2016. 272 с.

2.Блэк Р. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. Изд-во «Лори». 2011. 576 с.

3.Куликов С. C. Тестирование программного обеспечения. Базовый курс / С. С. Куликов. — 3-е изд. Минск: Четыре четверти. 2020. 312 с.

4.Артюхова А. Проблемы автоматизации тестирования и подходы к их решению // «CETERIS PARIBUS». №10. 2016. С. 5-10.

5.Воробьев Н. А., Бурмин Л.Н., Степанов Ю.А. Сравнительный анализ средств тестирования мобильных приложений // Евразийский Союз Ученых (ЕСУ). № 6(75). 2020. С. 36-38.

6.Курейчик В.М., Родзин С.И. Компьютерный синтез программных агентов и артефактов // Программные продукты и системы. 2004. № 1. С. 23-27.

7.Кент Бек. Экстремальное программирование: разработка через тестирование. Библиотека программиста. СПб.: Питер, 2003. 224 с.

1.Myers G, Budgett T., Sandler K. The Art of Software Testing. Williams Publishing House. 2016. 272 p.

2.Black R. Key testing processes. Planning, preparation, implementation, improvement. Publishing house «Lori». 2011. 576 p.

3.Kulikov S. C. Software testing. Basic course / S. S. Kulikov. — 3rd ed. Minsk: Four quarters. 2020. 312 p.

4.Artyukhova A. Problems of test automation and approaches to their solution // «CETERIS PARIBUS». No. 10. 2016. Pp. 5-10.

5.Vorobiev N.A., Burmin L.N., Stepanov Yu.A. Comparative analysis of testing tools for mobile applications // Evrazijskij Soyuz Uchenyh (ESU). No. 6 (75). 2020.S. 36-38.

6.Kureichik V.M., Rodzin S.I. Computer synthesis of software agents and artifacts // Programmnye produkty i sistemy. 2004. No. 1. Pp. 23-27.

7.Kent Beck. Extreme Programming: Test Driven Development. Programmer’s library. SPb .: Peter, 2003. 224 p.

Home

Автотесты под Android — это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.

Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.

Зачем нужны автотесты?

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

Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.

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

Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У «Авито» есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project — стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.

Картина целиком

Итак, обещанная картина целиком.

Android Autotests Cheat Sheet

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

Процесс написания тестов

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

Выбор инструментов для написания автотестов

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

Первая развилка — это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.

Спойлер — мы за нативные решения. По нашему опыту, они:

стабильнее;
быстрее;
лучше интегрированы в IDE;
не содержат слоев, которые вносят нестабильность и заставляют иметь суперширокие экспертные знания.

Кроме того, Google поддерживает Espresso и UI Automator.

Больше почитать про сравнение вы можете в статьях:

Appium vs Espresso: Key Differences.
Appium vs. Espresso: Which Framework to Use for Automated Android Testing.
Appium vs Espresso: The Most Popular Automation Testing Framework in 2019.

На чистом Espresso и UIAutomator нынче редко кто пишет. Разработчики сделали различные удобные обертки, которые решают их проблемы. Сейчас у нас готовится статья об этих инструментах с классификацией и сравнением. Если кратко, то фреймворк, на который мы делаем ставку, это Kaspresso.

Kaspresso

Kaspresso — это фреймворк, который:

предоставляет DSL, значительно облегчающий написание автотестов;
дает встроенную многоуровневую защиту от флекающих тестов;
ускоряет работу UI Automator;
предоставляет полные логи о том, что происходит в тесте;
дает возможность запуска любых ADB-команд внутри тестов;
предоставляет механизм интерцепторов для перехвата всех действий и проверок. На данном механизме построено логирование и защита от нестабильных тестов;
описывает лучшие практики (исходя из нашего опыта) по написанию автотестов.

Вы можете прочитать о Kaspresso на GitHub и Habr.

Test runner

Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.

Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим — Orchestrator. AndroidJUnitRunner делает то, что от него и требуется — просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.

Но со временем требований к раннеру становится все больше. Вот некоторые из них:

запускать отдельные группы тестов;
запускать тесты только на определенных девайсах;
перезапускать упавшие тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
эффективно распределять тесты по девайсам с учетом истории прогонов и успешности предыдущих запусков;
подготавливать отчеты о прогоне в разных форматах;
отображать результаты прогона (желательно Allure based);
поддержать истории прогонов для дальнейшего анализа;
просто интегрироваться с вашей инфраструктурой.

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

Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:

Простой и нативной интеграции раннера с инфраструктурой, которая выдает эмуляторы. А еще лучше возможности сразу же запустить ваши тесты в облаке. Впрочем, это проблема не только Marathon — к сожалению, ни один известный нам раннер не берет на себя ответственность за получение эмуляторов, это всегда ложится на плечи разработчиков.
Плотной интеграции с фреймворками типа Kaspresso для получения максимальной, точной и корректной информации о тесте.

Кроме того, мы считаем, что раннер должен быть платформенным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.

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

На чем запускать тесты

Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:

Настоящий девайс.
Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя — как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них — необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
Чистый эмулятор.
Под «чистым» мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус — это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
Docker-образ Android-эмулятора.
Docker решает недостатки чистых эмуляторов.
Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора — это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
Минусы. Более высокий входной порог.

Мы делаем ставку на Docker.

В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:

Docker image от Avito;
Docker image от Google;
Docker image от Agoda.

Как уже было упомянуто выше, подготовка образа требует некоторой сноровки. Плюс зачастую есть желание эмулятор преднастроить: выключить анимацию, залогиниться в аккаунт Google, выключить Google Play Protect и многое другое. Все эти вещи непросто организовать. Поэтому в скором времени мы хотим выкатить подробную документацию о том, как готовить и использовать образы быстро.

Инфраструктура

Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.

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

Итак, что вам примерно предстоит:

Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
Самое трудоемкое — это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
Дальнейшая накатка необходимого ПО, встраивание в сети и прочее — это все за DevOps-инженерами.
На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
В его настройке опять-таки помогают DevOps-инженеры.
Связка полученного сервиса с Test Runner.
Одна из задач Avito Runner — сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.

В ближайшее время мы планируем выпустить Avito Runner и статьи, которые помогут настроить инфраструктуру.

Остальное

Не забывайте про такие немаловажные моменты, как:

вывод отчета по прогону тестов (Allure);
внедрение/синхронизация с TMS;
интеграция в CI/CD;
обучение разработчиков и тестировщиков;
процессы — кто, когда, сколько и какие автотесты пишет.

Про все это мы еще обязательно поговорим.

Заключение

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

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

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

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

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

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

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

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

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

Надстройка

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

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

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

Модификация поведения (без изменения API).

дополнительное протоколирование,
валидация данных,
ожидание выполнения действия в течение определённого времени.

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

Фреймворк

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

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

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

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

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

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

iOS
XCUITest
(deprecated) UIAutomation
Android
(beta) Espresso
UIAutomator 2.0
(deprecated) UIAutomator
(deprecated) Selendroid
Windows Driver (для десктопных Windows-приложений)
Mac Driver (для десктопных Mac-приложений)

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

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

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.

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