Automation test андроид что это такое

Автоматизация тестирования мобильных приложений: сравнение инструментов

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

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

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

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

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

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

UI Automator

Мощный инструмент тестирования с продвинутой внешней интеграцией. Это значит, что данный фреймворк не только позволяет тестировать само приложение, но также способен “общаться” с операционной системой и другими приложениями — например, активировать и деактивировать Wi-Fi, GPS, открывать меню настроек в ходе теста и производить другие внешние взаимодействия.

Предназначение UI Automator — тестирование “чёрного ящика” (black-box testing). Это значит, что анализ производится с позиций внешнего пользователя без доступа к коду.

К основным особенностям относятся:

• UI Automator Viewer для отслеживания и анализа компонентов, отображаемых на экране в ходе теста. Он даёт информацию об элементах и их свойствах, что облегчает создание более релевантных тестов.
• API для получения информации о состоянии девайса и запуска процессов на нём.
• UI Automator APIs для проведения кроссплатформенных тестов.

Ссылка на документацию.

Espresso

Более лёгкий по сравнению с UI Automator инструмент, не подходящий для взаимодействия с внешними приложениями, но удобный для тестирования “белого ящика” (white-box) с доступом к исходному коду конкретного приложения или тестирования “серого ящика” (grey-box), при котором имеется доступ к некоторым внутренним процессам и структуре.

Вместе с тем, Espresso выделяется мощным API https://github.com/hamcrest. Интерфейс добавляет удобные методы для проверок в автотестах, например:
assert_that(1, less_or_equal(2)). Для тестирования webview при этом используются специальные методы.

UI Automator и Espresso взаимно дополняют друг друга и могут использоваться в комплексе в рамках одного проекта.

Автоматизация тестирования iOS-приложений

XCUITest

Инструмент для black-box тестирования без обращения к коду приложения. Работает только с нативными продуктами — к сожалению, провести cross-app тесты не получится.

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

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

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

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

EarlGrey

У EarlGrey акцент сделан на воспроизведении пользовательского опыта. Пока элементы на экране не представлены визуально, имитация работы с приложением не запускается.

При этом отмечается ряд удобств и преимуществ. Во-первых, специалистам нравится то, как фреймворк синхронизирует запросы, UI и потоки. Не нужно никаких waitforview и wait.

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

Универсальные инструменты

Универсальные инструменты (или “комбайны”) позволяют не ограничивать свой выбор только Android или iOS, а работать с обеими платформами.

Такие инструменты применимы для тестирования приложений следующих видов:

• Нативные приложения (native apps) — написанные непосредственно под Android, iOS и Windows SDK.
• Мобильные веб-приложения (mobile web apps) — доступные через мобильный браузер, например, Safari или Chrome.
• Гибридные приложения (hybrid apps) — пользователь работает с оболочкой веб-приложения, то есть, взаимодействует с веб-контентом через интерфейс нативного приложения.

Detox

На наш взгляд, Detox удобен для приложений, написанных на React Native. Тесты пишутся на JavaScript, при этом iOS и Android приложения генерируются из одного и того же кода JavaScript и максимально похожи. Это позволяет использовать одинаковые тесты для обеих платформ.

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

Detox может обращаться к памяти и отслеживать выполняемые процессы. Принцип grey-box помогает бороться с неустойчивостью, выражающейся в том, что при сквозном тестировании:

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

Как ни странно, “серый ящик” показывает не только лучшую устойчивость, но и более высокую скорость по сравнению с “чёрным ящиком”. Избегая разного рода пауз, waitUntil, grey-box может быть в 5-10 раз быстрее.

Detox не нуждается в WebDriver, работая с нативным драйвером через JSON. Он задействует нативные методы прямо на устройстве. Внутри данного фреймворка применяются EarlGrey для iOS и Espresso для Android.

Фреймворк работает как с эмуляторами, так и с физическими устройствами.

Appium

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

При тестировании используются фреймворки от вендоров — то есть вы работаете именно с исходным приложением. Для Android 4.2+, соответственно, применяется UiAutomator/UiAutomator2, а для iOS 9.3+ — XCUITest. В качестве оболочки фреймворков используется WebDriver (он же — Selenium WebDriver).

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

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

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

Ranorex

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

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

Легко интегрируется с существующей CI-средой: с такими системами управления заявками, как Jira и TFS, а также с системами контроля версий — например, Git и SVN.

В Ranorex прокачано data-driven тестирование с подгрузкой данных из SQL, CSV, Excel.

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

Сочетает все три подхода к тестированию: black-box, white-box и grey-box.

TestComplete

Платная среда для автоматизации тестирования мобильных, веб и десктопных приложений. Поддерживает Android и iOS, а в разрезе типов приложений: нативные, веб-приложения и гибридные.

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

• Регрессионное;
• Data-driven testing;
• Распределённое тестирование и не только.

В TestComplete есть Recorder — в нём тесты создаются путём записи действий и настройки команд в редакторе. Далее они могут запускаться как непосредственно в самом инструменте, так и экспортироваться в сторонние приложения.

Данный инструмент распознаёт объекты и элементы управления, предлагая специальные команды для эмуляции взаимодействия пользователя с ними. Интегрируется с Jenkins, Git и Jira, что позволяет запускать непрерывное бесшовное тестирование.

Подводя итоги

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

Рассмотрим на примере. Если перед вами стоит задача протестировать небольшое приложение в сжатые сроки, в первую очередь нужно учитывать такие факторы, как тип тестируемого приложения и опыт ваших специалистов. Если тесты пишет разработчик, лучше выбрать родной язык и инструмент для его платформы (см. в таблице ниже). Если тестами занимаются специалисты SDET, которые знакомы с другими языками (Java, JavaScript, Python и др.) и работали с Selenium, удобно использовать Appium. Если опытного SDET в команде нет, а тесты будут писать специалисты QA, лучше выбрать платные фреймворки, поскольку в них есть утилиты для записи тестов и более стабильная техподдержка, чем в open source фреймворках.

Из нашей практики:
Мы работали с одним интернет-магазином, у которого было два мобильных приложения – на iOS и Android. Для покрытия тестами основных пользовательских сценариев мы выбрали Appium по нескольким причинам:

• кроссплатформенность, возможность частично переиспользовать код
• подходит для end-to-end тестов, может работать с веб
• наличие в команде специалистов, хорошо знающих Selenium, который служит оболочкой данного фреймворка.

В результате Appium полностью оправдал ожидания, мы успешно провели тесты для iOS и Android. При этом следует учитывать, что подобные end-to-end тесты с Appium не проводятся на каждом merge request, поскольку это занимает много времени.

В заключение предлагаем вашему вниманию таблицу, которая поможет подобрать инструмент для вашего проекта. Стоит отметить, что в некоторых случаях приведенное в таблице деление является условным. Где-то для простоты сделано обобщение и приведены только самые основные параметры. Инструменты тестирования постоянно развиваются, поэтому при выборе фреймворка важно проверять актуальную документацию.

Источник

Автоматизация тестирования 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:
Для нашего случая:

Источник