Automation test android что это

Автоматизация Android. Супер простое руководство по созданию первого Espresso-теста

Здравствуйте, друзья. В преддверии старта курса «Mobile QA Engineer», хотим поделиться с вами переводом интересного материала.

Что такое Espresso?

Нет, это не напиток, который вы пьете каждый день, чтобы взбодриться. Espresso — это тестовый фреймворк с открытым исходным кодом, разработанный Google. Он позволяет выполнять сложные тесты пользовательского интерфейса на реальном устройстве или эмуляторе. Потребуется ли время, чтобы начать писать сложные тесты для Android?

Возможно. Но ничего не мешает вам сделать первый шаг и научиться писать простые тест-кейсы для Android с помощью фреймворка Espresso прямо сейчас.

Расскажите поподробнее об автоматизации?

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

Существует в основном два типа тестовых фреймворков:

1. Фреймворки, которым не нужен доступ к исходному коду и которые не интегрированы как часть проекта. Например, WebDriver, Appium, QTP.
2. Фреймворки, которым нужен доступ к исходному коду. Например, Espresso, KIF (Keep It Functional).

Основные компоненты Espresso

Есть три типа методов, доступных в Espresso:

1. ViewMatchers — позволяют найти объект в текущей иерархии представлений
2. ViewAssertions — позволяют проверить состояние объекта и подтвердить, что состояние соответствует критериям
3. ViewActions — эти методы позволяют выполнять различные действия с объектами.

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

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

1. Откройте Android Studio и создайте Bottom Navigation Activity.

Android Studio. Окно «Create New Project»

2. Назовите проект и выберите язык программирования.

Android Studio. Указание имени проекта

3. Перейдите в папку androidTest

Android Studio. Инструментальный тест.

Как вы можете видеть, там написан только один тест, и это не UI-тест, а JUnit-тест.

Сейчас нам нужно добавить простой тест пользовательского интерфейса. Для этого сначала создадим правило для открытия MainActivity.

Давайте добавим импорт аннотации JUnit Rule:

import org.junit.Rule; 

Следующее, что нужно сделать, — это добавить строку кода, указанную ниже, в дополнение к аннотации RunWith:

@Rule public ActivityTestRule activityActivityTestRule = new ActivityTestRule<>(MainActivity.class);

Теперь мы видим, что ActivityTestRule выделен красным. Это означает, что нам необходимо импортировать функцию ActivityTestRule. Но прежде нам нужно добавить библиотеку, способную сделать это. В двух словах, для этой задачи нам нужна помощь Gradle — системы автоматизации сборки, созданной специально для этой цели.

Давайте перейдем к файлу конфигурации Gradle и добавим эту библиотеку. Откройте файл с именем build.gradle (Module: app) и добавьте строку, указанную ниже:

androidTestImplementation 'com.android.support.test:rules:1.0.2'

Android Studio. Добавление зависимости.

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

Теперь, когда библиотека добавлена, следующим шагом будет ее импортирование в файле с инструментальным тестом:

import androidx.test.rule.ActivityTestRule; 

Android Studio. Импорт ActivityTestRule.

Хорошо, теперь мы готовы добавить наш первый тест. Введите этот код в ExampleInstrumentedTest:

@Test public void clickButtonHome()

Android Studio. Добавление теста и импортирование дополнительных элементов

Для нашего теста требуется импортировать дополнительные элементы, прежде чем он начнет работать. Нажмите кнопку «ОК», и мы, собственно, готовы к запуску нашего теста!

Запуск Espresso-тестов

Щелкните правой кнопкой мыши на нашем тесте слева и выберите «Run ExampleInstrumentedTest».

Поскольку это UI-тест, а не модульный тест, дальше мы увидим окно с выбором устройства, на котором мы хотели бы запустить его. У меня уже есть «Nexus 5X» в качестве устройства, поэтому мне нужно просто выбрать его.

В вашем случае, если вы никогда не развертывали Android-проект, выберите ваше реальное Android-устройство или нажмите «Create New Virtual Device» и создайте новое эмулируемое устройство для запуска тестов. Это может быть любое устройство из списка, на котором бы вы хотели запустить тесты.

Нажмите «ОК» и приготовьтесь увидеть магию!

Android Studio. Результаты выполнения теста

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

Android Studio. Выполненный тест.

Как видно из названия, мы нажали только одну кнопку в нижней панели навигации, которая называется «navigation_home» в иерархии MainActivity.

Давайте проанализируем что мы делали в этой цепочке методов:

public void clickButtonHome()

1. 1. Вызываем «onView». Этот метод является методом типа ViewMatchers. Мы находим объект в нашем Activity для выполнения чего-либо.
2. 2. Далее мы вызываем perform(click()). Этот метод является методом типа ViewActions. Мы указываем конкретное действие, которое нужно выполнить в этом случае — сделать одно нажатие (click). В Espresso доступно еще много методов действий, например:
3. 3. Последнее, что нам нужно сделать, это подтвердить, что действие, которое мы сделали, действительно соответствует нашим критериям, и для этого мы выполняем метод check(isDisplayed()), который является методом типа ViewAssertions. В этом случае мы проверяем, что этот объект (представление) действительно отображался на экране после выполнения действия нажатия.

Иерархия представлений в Android

Уважаемый читатель, я надеюсь, что смог объяснить вам, как писать базовые UI-тесты для Android с помощью Espresso.

Однако, вероятно, не так просто понять, что именно здесь произошло, если не знать, где все эти кнопки расположены и откуда они берутся. Для того, чтобы это узнать, нам нужно перейти в папку «res» с левой стороны, открыть папку «menu» и выбрать «bottom_nav_menu.xml».
Вот что мы увидим там:

Android Studio. Иерархия представления нижнего меню навигации.
Как видите, это строка, которая присваивает имя элементу меню:

android:id="@+id/navigation_home"

Именно это мы используем в нашем коде для запуска тестов. Также есть кнопки меню “navigation_dashboard” и “navigation_notifications”, доступные внизу, так что давайте продолжим и используем их в наших тестах.

Еще больше Espresso-тестов

Нам нужно вернуться к файлу ExampleInstrumentedTest и добавить туда еще пару тестовых функций:

@Test public void clickButtonDashboard() < onView(withId(R.id.navigation_dashboard)).perform(click()).check(matches(isDisplayed())); >@Test public void clickButtonNotification()

Единственное, что мы добавили, — это проверка еще нескольких элементов меню: “navigation_dashboard” и “navigation_notifications”.

Android Studio. Добавляем еще два теста.

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

Давайте продолжим и запустим эти тесты еще раз. Нажмите кнопку «Run».

Android Studio. Результаты выполнения тестов.

Все 4 теста пройдены. Все представления были найдены, нажаты и подтверждены в иерархии представлений.

Заключение

Espresso — это мощное решение для запуска UI-тестов. Теперь, когда вы знаете, как они создаются, вы готовы писать намного более мощные и сложные тесты.

• Android
• Automation Testing
• Android App Development
• Mobile Testing

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

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

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

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

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).

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

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

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

Заключение

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

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

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

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

What is automation testing?

If you’re in the technology sector, you’ll be familiar with the QA part of the product development cycle and you’re likely to have rolled your sleeves up and done some testing yourself, whether you’re an engineer, head of QA, or a CEO.

Automating as much of the QA process as possible is a sensible way to approach testing. As a provider of (non-automated) crowdsourced tests, many of our clients have an automation-first ethos which we can help support with flexible supply of more specialist manual testing.

So where do you draw the line? What can you and should you automate? Keep reading to find out below.

Recap | What is automation testing?

Test automation refers to the practice of using software tools and scripts to automate the execution of tests in software development and quality assurance processes. It involves creating scripts or test cases that can be run automatically, rather than requiring manual effort. Test automation aims to increase the efficiency and effectiveness of testing by reducing human errors, saving time, and improving test coverage.

While all testing, including regression testing, can be done manually, there are often greater benefits to doing much of it automatically. Automation testing can be run at any time of the day; it is faster and cheaper than manual testing; since Quality Engineers are able to deliver more tests than QAs, the former category is sometimes a career route for the latter and their ambition. Engineers, in particular, believe that tests “should” be automated, even when the business reality is much messier.

Automation developers generally write in C#, JavaScript, and Ruby as programming languages. There are many tools which can help write automated tests; and tools which help manage it too. Global App Testing integrates with TestRail , which is designed as a “hub” software and also integrates with automated test providers, so you can manage everything from one place.

What are the benefits and disadvantages of automation testing?

Benefit: Instant test return

An engineer can either test something themselves or send it to a QA. If they do the former they have context switched, and they are spending expensive engineer salary time on cheaper QA work. If they do the latter they will need to wait on a service department to deliver something and create a bottleneck, possibly a delay to release. Some aspects of the “crowd” offered by Global App Testing can mitigate these issues – 6 hour test return, overnight and weekend testing, and the other advantages of having a flexible, global supply of labor at your finger tips. But instant returns are always better.

Benefit: Labour hours saved with test automation

Testing can be time-consuming. Though automation may require an initial investment, it can save money in the long run to become more cost-effective. Team members use their time in other areas and are no longer required to carry out manual testing in many situations. Creating a test system which can be scaled also allows for more testing, and a more rigorous QA standard.

Downside: Flaky tests, unexpected maintenance

On the other hand, flaky tests are a burden. According to one survey launched by Global App Testing, flaky tests were the main reason that businesses moved away from automated testing. As a test becomes less frequent, or requires more challenging setup and maintenance, the case for automating it becomes weaker. We cover a detailed equation for calculating when a test should be manual in our blog: Should a test be automated? Or manual?

Benefit: More detailed reports in some respects

Automation testing can provide more detailed heuristics and reports than it is possible to get by a human filling out a form. Its also a different kind of data – a human will describe their experience of your app, which is more subjective and less detailed but matters a great deal – especially for kinds of bugs a machine can’t pick up.

Downside: Businesses often overestimate the extent they will deliver on automated testing

I n our 2022 Webinar , the automation paradox, we talked about some research by our friends in TestRail about how businesses typically overestimate the % of their testing suite which they will automate year on year. In TestRail’s annual survey, businesses identified that they would automate a further 20% of their suite; and every year, they automated less than 1% more. This optimism can often lead to miscalculation in terms of the amount of labor needed.

Deciding which tests to automate

Not only is it important to understand which tests to automate, but to understand a rough order of the desirability of automation because you are unlikely to be able to automate every test you would like to.

You may choose to prioritize according to any of the following schemas:

• Regression tests; your most common kinds of test cases
• Test cases that are time-intensive or need to be repeated often
• Tests that can lead to failure because of human error
• Repetitive and monotonous tests
• Extensive tests that require multiple data sets
• Tests that can’t be performed manually
• High-risk tests; e.g. which require a detailed answer which might be used in a legal context

Some tests you can’t automate:

• User experience (UX) testing and surveys; which can be done through Global App Testing
• Usability testing; in which users try to complete a goal
• Exploratory testing, which is an approach which does not involve test cases. This tests “unknown unknowns” by asking testers to simply find bugs. It can be extremely useful to find functional bugs outside the scope of the written test cases.
• User Acceptance Testing (UAT); UAT involves end-users testing the software in their own environment to ensure it meets their requirements and expectations. UAT is best performed by real users who can validate the software’s suitability for their specific needs and provide feedback. The involvement of end-users and their unique perspectives make UAT less suitable for full automation.

Some tests are more difficult to automate:

• Internationalization or localization testing . Localization testing ensures software functions correctly for a specific locale. It involves validating language, cultural, and regional aspects. It’s challenging to automate due to the need for human validation of linguistic accuracy, cultural context, UI layout, and complex scenarios that require manual verification in diverse localized environments.

• Mobile app testing . Mobile app testing is the process of verifying the functionality, usability, and performance of a mobile application across various devices, operating systems, and network conditions. It is challenging to automate due to the vast device fragmentation, diverse screen sizes, OS versions, hardware capabilities, and the need for manual testing to ensure optimal user experience on different mobile devices.

Tests which are normally automated

Although most tests can be automated (theoretically; all tests) – here are the most common categories of automated test.

Code analysis

Code analysis consists of different testing tools, including dynamic analysis and static analysis. You can apply different ones to tackle separate tests. For instance, some look for possible security flaws, while others check for usability. To run these tests, the developer will need to write code. Once this has been done, though, there’s no human interference for the rest of the testing process.

Unit tests

Unit testing is all about checking individual components of the software or product, as you would developing iOS technology for an iPhone or Android for Samsung. This means that each element of the software is fully tested before the finished version is. These tests can be written by developers, but now that automation testing has come into play, there’s no need.

Businesses would typically deploy these types of tests in the software development phase of the production process.

This graph shows the unit test life cycle:

Image alt text: no alt text

Integration tests

Integration tests, also known as end-to-end tests, are often more complicated to set up than some other tests. The application models are integrated and tested as a group. This means that communication between each module can be tested, to figure out how well they work as a whole.

Automated accepted tests

Automated accepted tests (AAT) are similar to behavior-driven development (BDD) and automated acceptance test-driven development (AATDD). The acceptance test is created before a new feature is developed. It sets a precedent for the feature to meet and is usually written by developers, the business, and quality assurance (QA) in tandem. In future, they can also be used as regression tests.

Smoke tests

This type of testing is used to check whether the product is stable or not. If it’s not stable, it gets sent back to the developers marked as an ‘unstable build’. They can then run further tests if needed to identify the root cause of the problem. This diagram shows how the smoke test process works:

Image alt text: no alt text

How a manual testing solution can help you automate more tests

We dive into more tools and services below. But you should check out our webinar on how a manual testing solution can help you automate more of your testing suite.

How can enterprise businesses utilize automation?

Enterprise businesses should be leveraging automation in order to improve their business processes and operating systems, particularly those in the technology industry. Automation provides valuable tools for businesses to use to their advantage, whether that be for improving product delivery times or to meet increasing security standards.

• Achieving Continuous Integration and Deployment (CI/CD): Test automation plays a vital role in CI/CD pipelines, where code changes are frequently integrated, built, and deployed. Automated tests can be seamlessly integrated into the CI/CD process, enabling rapid feedback on the quality of each build and reducing the chances of introducing new bugs.

• Regression Testing: Enterprise applications often undergo regular updates and enhancements. Test automation allows for efficient regression testing by re-running automated test cases to ensure that existing functionalities haven’t been affected by recent changes. This helps in maintaining the stability and reliability of the software over time.

• Scalability and Reusability: Automated tests can be easily scaled up to handle large test suites and execute tests across multiple platforms and configurations. Additionally, automation frameworks and libraries promote the reuse of test scripts, reducing duplication of effort and increasing efficiency.
• Resource Optimization: Test automation reduces the reliance on manual testing, freeing up valuable resources to focus on more complex and creative tasks. Testers can shift their focus from repetitive, mundane tests to exploratory testing, usability testing, and analyzing test results.
• Consistent and Reliable Testing: Automated tests provide consistency in test execution, ensuring that the same steps and test data are used consistently across multiple test runs. This eliminates human error and makes the testing process more reliable and reproducible.

To effectively implement test automation in an enterprise setting, it is important to invest in appropriate tools, establish a robust automation framework, ensure collaboration between development and testing teams, and continuously maintain and update the automated test suite as the software evolves

The Automation Test Process

The automation test process should be familiar to technology professionals, especially developers. To begin automation testing from scratch, it is important to follow a systematic approach. The following is an overview of the automation test process, starting from selecting the appropriate test tool to test execution.

Selecting the Test Tool

Choose the test tool that best fits your requirements. Depending on the goals of your testing, different types of automation testing tools may be suitable. For example, if your aim is to identify specific software bugs, code analysis automation testing tools may be more appropriate. Some popular test automation tools and web apps available in the market include Selenium IDE, WebDriver, UFT, Ranorex, Cucumber, TestComplete, and Appium. Many of these tools provide tutorials and some are open source, so it’s important to have a thorough understanding of each tool and its potential benefits for your testing process.

Establishing the Scope of Automation

Define the specific area of testing that will be automated and determine its extent. During this step, assess the current state of your team, prepare the necessary test data, and set up the testing environment. Automated testing minimizes the need for human intervention, allowing tests to run even when the team is not actively engaged.

Consider the following factors when determining the scope of your automation testing:

• Complexity of the test: Evaluate the complexity of the tests to decide which ones are suitable for automation.
• Main testing goals: Identify the primary objectives of your testing efforts to prioritize automation accordingly.
• Resources and business components: Consider the availability of resources, both in terms of tools and personnel, as well as the business components involved in the testing process.
• Technical feasibility: Assess the technical feasibility of automating the specific tests, considering factors such as system architecture, compatibility, and dependencies.

By carefully establishing the scope of automation, you can focus your efforts on the most critical areas and optimize the efficiency of your testing process.

Planning Stage

The planning stage involves the development of a comprehensive testing strategy. This encompasses the selection and utilization of the automation test tool, framework design, and defining its features. Clear goals should be established to determine the desired outcomes of the testing process. Collaborating with the development team, a detailed timeline should be created for scripting and executing test cases. The scope of automation, including in-scope and out-of-scope elements, must also be considered.

Execution Stage

The execution stage represents a pivotal phase in the automation testing process. With the test tool and strategy in place, tests are executed. Depending on the chosen test, developers may need to write code, familiarize themselves with Web Services Description Language (WSDL), and utilize the tool’s API or user interface for automated test execution. Prior to test execution , API testing may be necessary. Automated tests generate reports that provide a summary of the testing progress, enabling analysis and comparison for future tests.

Ongoing Maintenance

Ongoing maintenance is an integral part of the automation testing process, especially if future tests are planned using reusable test scripts. Even with prepared scripts, updates may be required to align with any changes to the automation test tool. Ensuring the scripts remain up to date is essential for subsequent test runs.

Ongoing maintenance also provides reassurance as the team makes their way to the next stage, or backtracks to run another test. When a method has been repeatedly tried and tested, you’re more likely to be provided with an accurate outcome.

T est automation tooling

When embarking on unit testing frameworks, a team should familiarize themselves with the framework’s characteristics, runners, assertions, screen capture capabilities, test suites, and its integration with continuous integration (CI). Prominent unit testing frameworks include JUnit for Java and Pytest for Python.

Adhering to established testing protocols is of paramount importance in the technology industry, particularly in the context of continuous delivery (CD) and continuous testing (CT). DevOps and agile software development teams often incorporate CD and CT into their testing strategies.

Automation possesses the potential to revolutionize business operations. It is an opportune moment to embrace new technologies and acquire methodologies that enhance workplace productivity and efficiency. Do not hesitate to experiment with various tools to identify the most suitable one. Each business and the software or products being developed are unique, warranting a tailored approach

If you require assistance with your quality assurance (QA) strategy, we invite you to schedule a call with one of our Quality Consultants for a complimentary consultation.

Popular test automation tools and software

Global App Testing is agnostic about the best tools and software for automation testing. But the following tools are popular and we know are used by clients:

Selenium: Selenium is one of the most widely used open-source test automation frameworks for web applications. It provides a suite of tools for automating web browsers across different platforms and supports various programming languages like Java, C#, Python, and more. Selenium WebDriver is particularly popular for browser automation, while Selenium Grid allows for parallel test execution.

Appium: Appium is an open-source automation tool specifically designed for mobile app testing. It allows you to write and execute tests for Android, iOS, and Windows apps using popular programming languages such as Java, C#, Ruby, and Python. Appium supports both native and hybrid mobile applications, offering cross-platform compatibility.

JUnit: JUnit is a widely used unit testing framework for Java applications. It provides a simple and elegant way to write repeatable tests and has extensive community support. JUnit facilitates test automation at the unit level, ensuring that individual units of code work as expected.

TestNG: TestNG is another popular testing framework for Java applications, offering more advanced features than JUnit. It supports various types of testing, including unit, functional, and integration tests. TestNG provides powerful annotations, test configuration, parallel test execution, and advanced reporting capabilities.

Cucumber: Cucumber is a behavior-driven development (BDD) testing tool that allows you to write tests in a human-readable format. It uses Gherkin syntax, enabling collaboration between business stakeholders and technical teams. Cucumber supports multiple programming languages, including Java, Ruby, JavaScript, and more.

Jenkins: Jenkins is a leading open-source automation server that facilitates continuous integration and delivery (CI/CD) processes. It provides extensive automation capabilities for building, testing, and deploying software projects. Jenkins allows you to automate test execution, generate test reports, and integrate with other tools in your software development pipeline.

TestComplete: TestComplete is a comprehensive test automation tool that supports desktop, web, and mobile applications. It offers record and playback functionality, making it suitable for both technical and non-technical testers. TestComplete supports various scripting languages, including JavaScript, Python, and VBScript.

Apache JMeter: Apache JMeter is an open-source tool designed for load testing and performance measurement of web applications. It can simulate heavy user loads and analyze the performance of web servers, databases, and other resources. JMeter supports distributed testing, allowing you to scale tests across multiple machines.

Инструкция по установке ПО, необходимого для тестирования Android приложений

Перед Вами поэтапная инструкция по установке софта, необходимого для тестирования Android приложения на реальном устройстве либо на эмуляторе Android приложения (AVD).

Установка и настройка Appium

Appium – это инструмент автоматизации тестирования мобильных приложений, использующих Webdriver API. Он представляет собой HTTP-сервер, написанный на NodeJS, который создает и обрабатывает WebDriver-сессии. В своей работе Appium придерживается того же подхода, что и Selenium WebDriver, который получает HTTP-запросы в формате JSON от клиентов и преобразует их в зависимости от платформы, на которой он работает.

Appium является, наверное, одним из самых известных инструментов тестирования мобильных приложений. Основные принципы Appium:

• Для автоматизированного тестирования приложения пользователю не нужно производить его рекомпиляцию или каким-то образом его модифицировать.
• Пользователь не должен быть привязан к конкретному языку программирования для написания тестов.
• Не нужно изобретать колесо, когда дело касается автоматизации тестирования API.
• Фреймворк для мобильного автоматизированного тестирования должен быть с открытым кодом, не только по названию, но и по духу.

Использование этих четырех принципов дает основные преимущества Appium:

• Бесплатная, свободно распространяемая платформа с открытым кодом.
• Содержит фреймворк или оболочку, которые переводят команды Selenium Webdriver в команды UIAutomation (iOS) или UIAutomator (Android) в зависимости от типа устройства, а не типа ОС. Т.е. отсутствует зависимость от типа ОС мобильного устройства.
• Поддерживает основные языки программирования: Java, Python, JavaScript, PHP, C# и Ruby.
• Поддерживает автоматизированное тестирование нативных, веб и гибридных мобильных приложений как на реальных девайсах, так и на эмуляторах или симуляторах.
• Поддерживает все основные платформы: iOS, Android, Windows, Firefox OS.

Конечно же, Appium не идеален. Имеются также некоторые недостатки:

• Поддерживает версии Android, начиная с 17 и выше. Более ранние версии не поддерживаются.
• Отсутствует прямая поддержка обработки предупреждений Android.
• Имеет более 50 открытых багов, связанных с iOS.

Для установки Appium нам необходимо выполнить следующие шаги:

• Устанавливаем Java JDK и прописываем к нему пути в переменной окружения JAVA_HOME;
• После чего устанавливаем Apache Maven. Создаем переменные окружения для Maven;
• Устанавливаем Node.js;
• Устанавливаем Appium с помощью команды npm install appium;
• Устанавливаем appium-doctor, чтобы проверить все зависимости для Appium с помощью команды npm install -g appium-doctor;
• Запускаем appium-doctor с параметром —ios или —android, чтобы убедиться, что все зависимости установлены корректно.

При тестировании native application для запуска Appium в консоли необходимо выполнить команду:

appium —address «127.0.0.1» —command-timeout «0» —session-override —debug-log-spacing —automation-name «Appium» —platform-name «Android» —platform-version «6.0» —app ‘путь к apk файлу тестируемого приложения’ —device-name «имя устройства»

Установка и настройка Android SDK

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

Android SDK поддерживает большое количество мобильных устройств, среди которых выделяют: мобильные телефоны, планшетные компьютеры, умные очки (в том числе Google Glass), современные автомобили с бортовыми компьютерами на ОС Android, телевизоры с расширенным функционалом, особые виды наручных часов и многие другие мобильные гаджеты и габаритные технические приспособления.

Для работы нам потребуется установить Android SDK (SDK tools package), c поддержкой API Level 17 или выше.

Для начала, необходимо создать переменную окружения ANDROID_HOME

ANDROID_HOME=C: installation location android-sdk PATH=%ANDROID_HOME%tools;%ANDROID_HOME%platform-tools

После чего скачать необходимые пакеты с помощью Android SDK Manager:

• Tools > Android SDK Tools
• Tools > Android SDK Platform-tools
• Tools > Android SDK Build-tools
• SDK Platform (most recent version)> SDK Platform
• SDK Platform (most recent version) > ARM EABI v7a System Image
• Extras -> Android Support Repository
• Extras > Android Support Library
• Extras -> Google Repository
• Extras -> Google USB Driver (Required on Windows systems only)
• Extras > Intel x86 Emulator Accelerator (HAXM installer)

Установка и настройка Android устройства

Для того, чтобы эмулятор Android устройства работал со скоростью, приближенной к скорости работы реального устройства, необходимо установить Intel Hardware Accelerated Execution Manager. Это поможет сократить время на запуск и отладку приложения.

Intel Hardware Accelerated Execution Manager (Intel HAXM) — это решение, работающее в паре с эмулятором Android для х86 устройств и использующее аппаратные возможности виртуализации (Intel VT).

Используя Intel HAXM, можно запустить несколько экземпляров Android-эмулятора на одном компьютере, не особо беспокоясь о производительности, о нагрузке на систему или о «тормозах» интерфейса. Подобный подход может быть весьма полезным в итеративном процессе создания и тестирования приложений, он способен дать огромный прирост производительности труда разработчиков.

Образы Android-эмуляторов, рассчитанные на архитектуры, отличные от x86, могут медленно запускаться и с задержкой откликаться на команды пользователя. Кроме того, в отличие от некоторых Android-эмуляторов сторонних производителей, с помощью Intel HAXM вы получаете возможность работать с последними версиями API и платформ Android сразу же после их выпуска.

Установка Intel Hardware Accelerated Execution Manager

Зайдите на сайт https://www.intel.com/content/www/us/en/developer/overview.html и скачайте установочный пакет для вашей платформы. Распакуйте пакет в каталог extras, находящийся в каталоге, в который был установлен Android SDK, перейдите в этот каталог и запустите установку Intel HAXM и следуйте подсказкам мастера установки.

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

В процессе установки может возникнуть такая ошибка

В этом случае проверьте настройки в BIOS, возможно виртуализация по-умолчанию отключена.

Для того, чтобы проверить, что все установлено верно и работает, необходимо в командной строке выполнить:

После выполнения данной команды вы увидите текущий статус службы.

Установка эмулятора Android x86

Теперь необходимо установить эмулятор, который будет работать с Intel HAXM.

Устанавливается он с помощью Android SDK Manager. Запускаем, отмечаем галочками интересующие нас образы и устанавливаем.

Запускаем AVD Manager

Жмем кнопку Create и заполняем параметры нового AVD.

• В окне свойств задаем произвольное название, например «Intel_Android»
• Выбираем версию, в моем случае версия «Android 6.0 – API Level 23»
• Устанавливаем остальные параметры (размер и наличие SD карты, разрешение и т.д.)
• Далее следует установить галочку в чекбоксе “Use Host GPU”

Жмём кнопку OK.

Запускаем и проверяем все ли настроено верно. Далее идем в настройки и смотрим название устройства. Если все было сделано правильно, в поле «Model number» мы увидим строку «Android SDK Build for x86».

Настройка реального устройства

С помощью Android SDK manager (или вручную, в директорию extrasgoogleusb_driver) нужно установить и настроить ADB, Android Debug Bridge.

ADB, Android Debug Bridge — это утилита командной строки, с помощью которой можно копировать файлы на устройство и обратно, устанавливать и удалять приложения, выполнять резервное копирование и восстановление, и многое другое используя команды.

Далее, на реальном устройстве необходимо включить отладку по USB. Чтобы узнать, как это сделать, перейдите по ссылке https://vynesimozg.com/kak-poluchit-dostup-k-menyu-opcii-razrabotchika-i-vklyuchit-otladka-usb/.

После включения отладки по USB, разблокируйте свой смартфон или планшет. Не используйте порт USB 3.0, только USB 2.0 при подключении к компьютеру.

Когда устройство подключили к компьютеру впервые, появится запрос на доверие компьютеру: поставьте галочку и нажмите кнопку OK. Отладка по USB включена.

Для того чтобы проверить видит ли ADB ваш телефон, нужно использовать команду

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

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

• Официальный сайт, с которого можно скачать ПО для работы с Android (Android Studio и Android SDK): https://developer.android.com/studio/index.html
• Инструкция по установке и настройке Android Studio: https://aristov-vasiliy.ru/knowledge/hello-world-v-android-studio/ustanovka-i-nastroyka-android-studio.html
• Официальный сайт с дистрибутивом и документацией по Appium:
  http://appium.io/
• Статья рассказывает, как установить Intel Hardware Accelerated Execution Manager, чтобы ускорить работу эмулятора Android: https://habr.com/ru/company/intel/blog/146114/
• Создание проекта в Android Studio и настройка AVD: https://startandroid.ru/ru/uroki/vse-uroki-spiskom/12-urok-3-sozdanie-avd-pervoe-prilozhenie-struktura-android-proekta.html
• Инструкция по получению доступа к меню “Опции разработчика” и включение отладки по USB на Android устройстве: https://vynesimozg.com/kak-poluchit-dostup-k-menyu-opcii-razrabotchika-i-vklyuchit-otladka-usb/
• Статья содержит подсказки и команды для запуска Appium: https://techblog.polteq.com/nl/4-tips-for-test-automation-on-android-7/