Android and ios automation

Instrumentation and Automation Application

The Instrumentation and Automation application is designed for a wide range of users working in the field of metrology, instrumentation and automation, as well as process control systems (automated process control systems). It may also be useful to students of technical universities and specialists of technical specialties.

Initially, it is supposed to be absolutely free. Currently, the following versions of the program are released:

Windows, macOS

Android, iOS

Supported languages: English, Russian, German, French and Spanish.

In the future, it is planned to release also for other mobile platforms, and also, the Professional version is being developed.

Desktop and mobile versions of the program are absolutely identical in their functional characteristics,- the same menu items, the same functions .. Also, it is possible to preload the selected documentation from the Internet on the device for subsequent work in off-line mode. This allows to use pre-loaded information in places where the Internet is not available. In addition, the Windows Help / Documentation installation file is available for the Windows version.

The program will update frequently, including new trends in instrumentation and automation, new instructions to devices, will be improved through direct communication with users of the program. It is also possible to include user documentation in the program, — anyone who wants to have something to say can send their own documentation, developments that will be included in the program. This makes the project truly popular.

Special attention is paid to mobile versions. The author of this project has practical experience in instrumentation and automation. In my experience I know how important it is to have the necessary background information in an operational setting. Very often it happens that the necessary information has to be looked for much longer than to fix some malfunction in the system. There would be a computer .. and there is no it .. At the same time, with the development of smartphones (tablets), it became possible to make programs on mobile devices. Thus, implement complex algorithms for computing in a handheld device.

The goal of the project is to make a handy, pocket application for those who are somehow connected with instrumentation and automation, metrology and process control systems.

The first version of the project is released for Android OS because the vast majority of people use mobile devices on this operating system. Also, the versions for other systems will be developed with the time.

Источник

first install ideviceinstaller, using Homebrew (http://brew.sh)

brew install libimobiledevice ideviceinstaller -u -i

Use the bundle ID of your application as the value of the app capability.

Use the UDID of your device as the udid capability.

As above, ensure that UI Automation is enabled in the Developer settings.

Following these steps should ensure your success! If you’re using newer versions of Xcode (7.x, for example), you may wish to consult the XCUITest Driver Real Device Docs as they may contain some pertinent information as well.

Real Device Hybrid / Web Testing

For hybrid and web testing, Appium requires the use of the Remote Debugging Protocol to send JavaScript to execute inside a web view. For real iOS devices, this protocol is encrypted and access must be facilitated using a 3rd-party tool, provided by Google, called ios-webkit-debug-proxy (IWDP). For information on installing and using IWDP within Appium, check out the IWDP doc.

For web testing, i.e., tests that run in the Safari browser, we have another hurdle to jump. On real devices, apps that are not signed by the developer cannot be instrumented with UIAutomation. Safari is one such app. Thus we have a helper app called SafariLauncher , which can be signed by the developer. Its sole purpose upon launching is to turn around and launch Safari, which can then be automated via the Remote Debugger in conjunction with IWDP. Unfortunately you cannot, in this case, move into the native context and do any automation of the browser itself.

For instructions on setting up SafariLauncher , check out the SafariLauncher doc.

Files generated by iOS test runs

Testing on iOS generates files that can sometimes get large. These include logs, temporary files, and derived data from Xcode runs. Generally the following locations are where they are found, should they need to be deleted:

Running iOS tests using Jenkins

First download the jenkins-cli.jar and verify that the Mac successfully connects to Jenkins master.

Next define a LaunchAgent for Jenkins to launch automatically on login. A LaunchDaemon will not work because daemons don’t have GUI access. Make sure the plist doesn’t contain the SessionCreate or User key as that may prevent tests from running. You’ll see a Failed to authorize rights error if misconfigured.

Finally set the owner, permissions, and then start the agent.

Источник

Автоматизация тестирования Android приложений с помощью UIAutomator

UIAutomator

UIAutomator разрабатывается корпорацией Google и поставляется вместе с Android SDK. UIAutomator – это аналог инструмента UIAutomation компании Apple для тестирования Android приложений. Android SDK предоставляет следующие инструменты для поддержки автоматизированного функционального тестирования пользовательского интерфейса:

• UIAutomatorviewer — графический инструмент для распознавания компонентов пользовательского интерфейса в Android приложении;
• UIAutomator — библиотеки Java API, содержащие методы для создания тестов пользовательского интерфейса.

Чтобы использовать эти инструменты, необходимо установить следующие компоненты среды Android:

• Android SDK Tools, версия 21 или выше;
• Платформа Android SDK, c API 16 или выше.

UIAutomator постоянно дорабатывается, поэтому самую свежую документацию можно найти на сайте: http://developer.android.com/tools/help/uiautomator/index.html.

Преимущества UIAutomator, для тестирования приложений:

• Отсутствие зависимости от разрешения экрана;
• Действия привязываются к Android UI компонентам. Это позволяет работать напрямую с элементами пользовательского интерфейса. Например, если необходимо нажать кнопку «ОК», можно средствами UIAutomator API отправить скрипту команду: нажми кнопку с надписью «ОК», и он её нажимает. Таким образом не приходится привязываться к координатам;
• Можно воспроизводить сложные последовательности действий пользователя, и всегда эта последовательность будет одинаковой;
• Тесты могут быть запущены необходимое количество раз на различных устройствах без необходимости изменения Java кода;
• Можно использовать внешние кнопки на устройстве (кнопка «назад», «выключить», «громкость» и т.д.).

Но есть и недостатки:

• Тяжело использовать для приложений, написанных на HTML 5 и OpenGL, так как в этих приложениях нет Android UI элементов. В связи с этим, необходимо либо привязываться к координатам, либо искать альтернативные варианты тестирования;
• Необходимо проверять, и в случае необходимости, обновлять Java скрипты при обновлении Android приложения.

Тестирование приложения с помощью UIAutomator состоит из следующих шагов:

1. Подготовка к тесту: установка приложения на устройство, анализ его UI компонент;
2. Создание автоматизированного теста для приложения;
3. Компиляция теста в JAR файл и копирование его на устройство;
4. Запуск теста и анализ результатов;
5. Исправление различных ошибок, найденых в процессе тестирования.

Разработка скрипта

Для ознакомления с технологиями UIAutomator далее будет представлена простая програма, осуществляющая несложные действия с устройством. В качестве тестируемого приложения будет использовано стандартное Android приложение — Messaging, а UIAutomator будет отправлять SMS-сообщение на определенный номер.

Определим действия, которые будут реализованы в тесте:

1. Поиск и запуск приложения;
2. Создание и отправка сообщения.

Как видите, все достаточно просто.

Подготовка к тесту

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

Для анализа пользовательского интерфейса необходимо:

Настройка среды разработки

Если вы используете Eclipse:

• Создаем новый Java проект в Eclipse. В этом проекте будем реализовывать UIAutomator скрипт. Назовем проект: SendMessage
• Вызываем контекстное меню нажав правой кнопкой мыши на проект в Project Explorer, и выбираем пункт Properties. В Properties находим Java Build Path и добавляем необходимые библиотеки:
  1. Для добавления поддержки JUnit необходимо выбрать Add Library > JUnit;
  2. Нажав Add External JARs… необходимо перейти в директорию с последней версией SDK в /platforms/ и выбрать в ней 2 файла: uiautomator.jar и android.jar

При использовании другой среды разработки, убедитесь, что файлы UIAutomator.jar и android.jar добавлены в настройки проекта.

UIAutomator API

Чтобы рассказать обо всех возможностях, которыми обладает UIAutomator для создания тест-скриптов, потребуется достаточно большое количество времени. Всю подробную информцию можно найти на сайте: http://developer.android.com/tools/help/UIAutomator/index.html

Создание скрипта

Для начала необходимо создать в проекте «SendMessage» новый файл с Java классом, например под именем SendMessage. Этот класс должен быть унаследован от класса UIAutomatorTestCase. Чтобы добавить библиотеку в Eclipse, достаточно воспользоваться сочетанием клавиш Ctrl+Shift+o. Аналогичным образом добавляются и другие библиотеки, поэтому не буду больше заострять на этом внимание.

Создадим три функции для тестирования основного функционала приложения:

1. Поиск и запуск приложения
2. Отправка SMS сообщения
3. Выход в главное меню приложения

Первая функция, запускающая все эти методы, своего рода main функция, будет выглядеть следующим образом:

Функция для поиска и запуска приложения

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

Отправка SMS сообщения

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

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

Таким образом, можно передавать параметры через командную строчку в скрипт. Это можно делать с помощью ключа –e. После него передается 2 значения: имя параметра и значение. Например, для передачи номера «777777», в качестве номера получателя, передадим параметры: -e to 777777. Для получения этих параметров в скрипте используется метод: getParams().

Но тут есть и несколько подводных камней. Например, не получается передать текст с некоторыми символами, UIAutomator их не воспринимает (пробел, &, , (, ), “, ’, и т.д., а так же юникодные символы). Для этого предлагаю делать замену этих символов при подаче их в скрипт какой-нибудь строкой, например, пробел заменим строкой: blogspaceblog. Это удобно, когда для запуска скрипта UIAutomator используем скрипт, который будет обрабатывать входные параметры. Добавим в проверку входных параметров парсинг и замену этих строк:

Выход в главное меню приложения

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

Сбор логов с теста

Для того, чтобы логировать результаты теста, можно использовать стандартный буффер Android. Для работы с ним необходимо подключить библиотеку в скрипте:
Всю информацию, которая интересна можно записывать в логи. Это можно делать с помощью функции:
Логи можно читать с устройства с помощью команды:

Более подробную информацию по logcat можно найти на официальном сайте: developer.android.com/tools/help/logcat.html

Получившийся код

Компиляция и запуск UIAutomator теста

1. Для генерации файлов конфигурации сборки теста необходимо выполнить следующую команду в терминале:
   Где — имя проекта, который создавался для теста UIAutomator (в нашем случае: SendMessage), — выбор устройства и Android API Level (можно получить список установленных устройств командой: /tools/android list targets) и — путь к директории с проектом.
   Необходимо экспортировать переменную окружения ANDROID_HOME:
   • Windows:
   • Unix:

   Заходим в директорию с проектом, в которой лежит сгенерированный на шаге 1 файл build.xml и выполняем команду:

Копируем собранный JAR файл на устройство с помощью команды adb push:
Для нашего случая:

Источник

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

…несмотря на то, что он кое в чём неполон, содержит много сомнительного или,
во всяком случае, вопиюще неточного, он имеет два важных преимущества:
во-первых, он немного дешевле, [. ], а во-вторых, на его обложке большими
и приятными для глаз буквами написаны два слова «Без паники!»
— 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 5.0 и выше. С 4.2 до 5.0 можно использовать UIAutomator 1, а взаимодействие с более старыми версиями обеспечивает уже известный нам драйвер Selendroid. Для взаимодействия с XCUITest и обхода некоторых ограничений используется WebDriverAgent (WDA) от Facebook. WDA запускается в контексте симулятора или реального устройства и передаёт команды через API XCUITest.

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

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

Источник