Тестирование мобильных приложений на Android

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

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

• размером и разрешением экрана;
• версией Android;
• форм-фактор устройства;
• системы команд процессора;
• фронтальная камеры, NFC, внешняя клавиатура и т.д.

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

Автоматическое тестирование приложений для Android

Рассмотрим несколько средств для автоматического тестирования функциональности, которые входят в состав Android SDK или  распространяются с открытым исходным кодом.

Принцип автоматического тестирования приложений

Наша задача — с наибольшей точностью автоматизировать действия, выполняемые вручную. Рассмотрим эти действия. Будем использовать несколько приложений и несколько устройств с Android. Для каждого приложения и каждого устройства нужно выполнить следующие действия:

• Установить приложение на устройство
• Запустить приложение
• Протестировать приложение, используя выбранный метод
• Удалить приложение
• Сбросить устройство в исходное состояние
• На каждом этапе нужно собирать и анализировать данные (журналы и снимки экрана). Ниже описываются средства для автоматизации этих действий.
• Управление устройствами Android

Прежде всего необходимо выбрать компьютер, который будет использоваться для запуска автоматических тестов, и установить на нем Android SDK. В данном примере мы используем настольный компьютер с операционной системой Linux*. На каждом устройстве необходимо отключить экран блокировки и увеличить «время перед переходом в спящий режим» до максимального значения. Для некоторых методик тестирования также нужно отключить изменение ориентации экрана. В составе Android SDK предусмотрено две программы для управления устройствами с Android: ADB и monkeyrunner* ADB (Android Debug Bridge) — это программа командной строки для управления устройствами с Android.

Методы автоматического тестирования Android

Тестирование с помощью Monkey*

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

Основное преимущество Monkey в отсутствии затрат на обслуживание. К тому же нагрузочное тестирование может выявлять сложные и малозаметные ошибки.

Недостатки тестирования с помощью Monkey:

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

Автоматическое тестирование с помощью Monkey можно считать неплохой начальной проверкой для любого приложения. Этот метод может дать достаточно полезные результаты для определенного приложения. Но при низком качестве тестирования следует использовать другие методы.

Тестирование с помощью MonkeyRunner

MonkeyRunner позволяет не только создавать сценарии для управления устройствами с Android, но и создавать сценарии для тестирования приложения на определенном устройстве. Основное преимущество – гибкость, а недостаток в сложности написания скриптов, даже в простых случаях. Создание скриптов monkeyrunner занимает немало времени, поэтому обычно этот метод использовать нецелесообразно. Но в некоторых случаях его применение может оказаться весьма полезным.

Тестирование с помощью getevent и sendevent

Программы getevent и sendevent позволяют пользователю записывать последовательность действий и затем воспроизводить ее. Для запуска этих программ не требуются права доступа root.

Преимущества:

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

Недостатки:

• Последовательности необходимо записывать отдельно для каждого приложения и для каждого устройства. При изменении интерфейса приложение потребуется переделать все записанные действия;
• Этот метод не проверяет состояние приложения во время тестирования. Если отклик приложения задерживается (например, из-за длительной загрузки веб-страницы), то результаты тестирования будут неверными;
• Воспроизведение быстрых и сложных последовательностей занимает больше времени, чем их запись. Поэтому такой метод не всегда подходит для тестирования динамических игр, где важно быстрое реагирование.

Тестирование с помощью Robotium

Robotium не входит в состав Android SDK, эта программа распространяется с открытым исходным кодом. Сценарии Robotium определяют действия на уровне пользовательского интерфейса приложений, а не на уровне устройства ввода. Например, в сценарии требуется коснуться кнопки «ОК». В этом случае скрипт monkeyrunner будет построен следующим образом: «имитировать касание экрана в точке с координатами (x0, y0)». Скрипт Robotium будет построен иначе: «нажать кнопку с текстом «ОК».

Описание действий на уровне интерфейса позволяет сделать тестовый скрипт независимым от расположения и размеров элементов интерфейса, разрешения и ориентации экрана. Кроме того, в Robotium можно проверять реакцию приложения на действия. Например, предположим, что после нажатия кнопки «ОК» должен появиться список с элементом «Элемент 1». В Robotium можно проверять имена элементов списков. Проверка состояния приложения после каждого шага позволяет с легкостью находить шаг, на котором произошла ошибка.

Недостатки:

• Для каждого приложения требуется разрабатывать тестовый сценарий на языке Java*. Для этого требуется время и навыки программирования;
• При смене интерфейса приложения потребуется переделать последовательность событий;
• Создавать сценарии Robotium сложнее, чем записывать события с помощью getevent / sendevent;

В целом, Robotium позволяет создавать тестовые сценарии высшего качества с разумными затратами.

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

Метод тестирования	Преимущества	Недостатки
Monkey — поток случайных действий пользователей	Затраты на обслуживание отсутствуют. Независимость от устройства. Нагрузочное тестирование может выявлять сложные и малозаметные ошибки.	Качество тестирования может различаться для разных приложений. Сложно воспроизводить последовательность действий, вызвавших ошибку, в отчетах об ошибках. Monkey не проверяет состояние приложения во время тестирования.
MonkeyRunner — скрипт для управления устройством	Гибкость	Сложность написания сценариев, даже для простых приложений.
Getevent/sendevent — запись и воспроизведение действий пользователя	Для записи последовательности событий не требуются навыки программирования.	Записанная последовательность действий подойдет только для одного устройства при фиксированной ориентации экрана. При смене интерфейса приложения необходимо переделывать последовательность событий. Этот метод не проверяет состояние приложения во время тестирования.
Robotium — API тестовых скриптов для проверки состояния	Действия описываются на уровне пользовательского интерфейса приложения. Скрипт может не зависеть от разрешения и ориентации экрана. Скрипт может проверять состояние приложения после действий.	Сложность написания сценариев на языке Java. При изменении интерфейса приложения необходимо переделывать скрипт.

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

Ручное тестирование Android приложений

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

Тестирование мобильных приложений существенно отличается от тестирования приложений, предназначенных для использования на персональных компьютерах. Приведем ряд основных моментов, которые нужно протестировать:

• Установка и запуск приложения, выход из приложения, повторный вход, удаление приложения с мобильного устройства;
• Мультитач и размер экрана. Корректность удаления 2-х элементов или просмотр двух элементов, нажатием на них одновременно. Проверка многократного быстрого нажатия на кнопку – часто при этом может случиться падение приложения. В приложении должны отсутствовать пустые экраны, чтобы пользователь не оказался в ситуации, в которой не очевидно, что делать. Также все элементы должны быть такого размера, чтобы пользователь мог однозначно нажать на них.
• Стабильность. Работа приложения при множестве запущенных приложений и долгое время, а также в случае недостатка места для установки или работы приложения. Поведение приложения при отсутствии в некоторых устройствах поддерживаемых приложением функций.
• Адаптация приложения к портретной и альбомной ориентациям устройства.
• Стресс. Реакция приложения на внешние прерывания:
  • входящие и исходящие SMS, MMS, звонки, оповещения других приложений;
  • переход устройства в режим ожидания;
  • выключение устройства, разрядка устройства;
  • зарядка устройства;
  • отключение интернета;
  • переход в другое приложение.
• Интернационализация. Проверка корректности работы приложения на разных языках (если данное приложение мультиязычное).
• Обратная связь с пользователем. Наличие информативных сообщений при попытке выполнить какое-либо действие (например, при удалении важной информации), а также присутствие визуальной индикации хода выполнения функций. У всех нажимаемых элементов должно быть «нажатое состояние» (отклик на действие), благодаря этому пользователь всегда будет видеть, действительно ли произошло нажатие.
• Обновление. Корректность обновления приложения до новой версии.
• Орфографические ошибки.

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

Особенности альфа/бета тестирования в консоли разработчика Google Play

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

Что нужно знать перед началом тестирования

В аккаунте разработчика доступны инструменты для альфа- и бета-тестирования различных версий вашего приложения. Тестирование приложения возможно без публикации рабочей версии APK-файла. Обратите внимание на следующую информацию:

• Присоединиться к группе тестировщиков может только пользователь с аккаунтом Google (@gmail.com) или Google Apps;
• При тестировании опубликованного ранее приложения обновление его альфа- и бета-версии получат только тестировщики. И только они смогут найти и скачать приложение, которое вы публикуете и проверяете впервые;
• Если вы впервые публикуете файл APK альфа- или бета-версии, ссылка станет доступна пользователям в течение нескольких часов. Примерно такое же время требуется, чтобы тестировщики смогли увидеть изменения, внесенные вами в уже опубликованную версию;
• Любые изменения на странице Цены и распространение (в том числе значения платное или бесплатное) применяются ко всем версиям приложения, включая тестовые, рабочие и будущие.

Мы рекомендуем начать с маленькой группы альфа-тестировщиков, а затем перейти к бета-тестированию с участием большего количества пользователей. Файлы дополнений можно тестировать с помощью альфа-канала распространения в консоли разработчика. Для тестирования нельзя использовать черновики, то есть файл APK должен быть опубликован как альфа-, бета- или рабочая версия. Файлы дополнений нельзя добавлять для первого загруженного файла APK нового приложения.

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

Процесс тестирования мобильных приложений / Touch Instinct corporate blog / Habr

Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

Под катом я расскажу как мы тестируем мобильные приложения.

Тестирование требований

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

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

Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций, вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам.

В основном на этом этапе используется basecamp.

Когда требования стали полны и непротиворечивы, тестировщик составляет smoke-тесты и функциональные тесты, покрывающие исходные данные. Тесты деляется на общие и специфические для разных платформ. Для хранения и прогона тестов мы используем Sitechсo.

Например, для проекта Trava на этом этапе было написано 1856 тестов.

Первый шаг тестирования закончен. Проект уходит в разработку.

Билд-сервер

Все наши проекты собираются на TeamCity билд-сервере.

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

Без «волшебного монитора» (кстати, работает на андроиде) часто тестировали старые билды. А новый билд с багами попадал заказчику. Теперь перед прогоном тест-кейсов достаточно взглянуть на монитор, путаница разрешилась.

Тестирование билдов бывает быстрое и полное.

Быстрое тестирование

Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз.

Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку.

Затем берутся все выполненные задачи и пофикшенные баги за итерацию из Jira и скурпулезно проверяется соответствие результата описанию таска. Если задача включала в себя новые элементы интерфейса, она отправляется дизайнерам для сверки с макетами.

Некорректно выполненные задачи переоткрываются. Баги заносятся в Jira. К не UI багам обязательно прикладываются логи со смартфона. К UI багам скриншоты с пометками что не так.

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

Для андроид приложений запускаются monkey тесты.

adb shell monkey -p ru.stream.droid --throttle 50 --pct-syskeys 0 --pct-ap
pswitch 0 -v 5000

По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере (да, название галочки не очень правильное :).

Если в процессе тестирования не было найдено blocker, critical и major багов, ставится галочка «можно показывать заказчику». Ни один билд не отсылается заказчику без одобрения отдела тестирования. (По согласованию с заказчиком иногда высылаются билды с major багами).

Критичность бага определяется по таблице.

После завершения тестирования PM получает подробное письмо-отчет.

Полное тестирование

Полное тестирование проводится перед релизом. Включает себя в себя быстрое тестирование, регресионное тестирование, monkey-тестирование на 100 устройствах и тестирование обновлений.

Регрессионное тестирование подразумевает прогон ВСЕХ тест-кейсов по проекту. Тест-кейсов не только за последнюю итерацию, но и за все предыдущие и общие тест кейсы по требованиям. Это занимает день-три на одно устройство в зависимости от проекта.

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

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

Релизный monkey-тест мы проводим на 10 iOS и 80 Android устройствах при помощи сервиса Appthwack.

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

Сборка уходит в релиз только при 100% прохождении всех тест-кейсов.

Тестирование внешних сервисов

Тестировать интеграцию с Google Analytics, Flurry или системой статистики заказчика непросто. Бывало, что в релиз уходили сборки с нерабочим Google Analytics и никто не обращал на это внимания.

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

Учет времени

Учет времени тестировщиков производится в отдельном Jira проекте. На составление тест-кейсов, прогон тестов, написание отчетов по проекту заводится отдельная задача и стандартными средствами в ней отмечается затраченное время.

UPD: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика

---

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

А/В-тесты на Android от А до Я / Redmadrobot corporate blog / Habr

Большая часть статей об A/B-тестах посвящена веб-разработке, и несмотря на актуальность этого инструмента и для других платформ, мобильная разработка несправедливо остаётся в стороне. Мы попытаемся эту несправедливость устранить, описав основные шаги и раскрыв особенности реализации и проведения A/B-тестов на мобильных платформах.

Концепция A/B-тестирования

A/B-тест нужен для проверки гипотез, направленных на улучшение ключевых метрик приложения. В простейшем случае пользователи делятся на 2 группы контрольную (A) и экспериментальную (B). Фича, реализующая гипотезу, раскатывается только на экспериментальную группу. Далее на основе сравнительного анализа показателей метрики для каждой из групп делается вывод о релевантности фичи.

Реализация

1. Делим пользователей на группы

Для начала нам необходимо понять, как мы будем делить пользователей на группы в нужном процентном соотношении с возможностью динамически его менять. Такая возможность будет особенно полезна, если вдруг выяснится, что новая фича повышает конверсию на 146%, а раскатана, например, всего на 5% пользователей! Наверняка нам захочется выкатить её на всех пользователей и прямо сейчас — без обновления приложений в сторе и сопутствующих временных издержек.

Конечно, можно организовать разбивку на сервере и каждый раз при необходимости что-то менять дёргать backend-разработчиков. Но в реальной жизни бэк зачастую разрабатывается на стороне заказчика или третьей компанией, и у серверных разработчиков и так хватает дел, поэтому оперативно регулировать разбивку, работая с третьими лицами, удаётся не всегда, а точнее, почти никогда, поэтому такой вариант нам не подходит. И тут на помощь приходит Firebase Remote Config!

В Firebase Console, в группе Grow есть вкладка Remote Config, где вы можете создать свой конфиг, который Firebase доставит пользователям вашего приложения.

Конфиг представляет собой мапу <ключ параметра, значение параметра> с возможностью присваивать значение параметра по условию. Например, пользователям с конкретной версией приложения значение X, всем остальным — Y. Более подробно о конфиге можно узнать в соответствующем разделе документации.

Также в группе Grow есть вкладка A/B Testing. Здесь мы можем запускать тесты со всеми вышеописанными плюшками. В качестве параметров используются ключи из нашего Remote Config. В теории можно прямо в A/B-тесте создать новые параметры, но это только внесёт лишнюю путаницу, поэтому делать так не стоит, проще добавить соответствующий параметр в конфиг. Значение в нем традиционно является значением по умолчанию и соответствует контрольной группе, а экспериментальное значение параметра, отличное от дефолтного — экспериментальной.

Прим. Контрольная группа обычно называется группой A, экспериментальная — группой B. Как видно на скрине, в Firebase по умолчанию экспериментальная группа называется “Variant A”, что вносит некоторую путаницу. Но ничто не мешает изменить её название.

Далее запускаем A/B-тест, Firebase разбивает пользователей на группы, которым соответствуют разные значения параметра, получив конфиг на клиенте, мы достаём из него нужный параметр и на основе значения применяем новую фичу. Традиционно параметр имеет имя соответствующее названию фичи, и 2 значения: True — фича применяется, False — не применяется. Подробнее о настройках A/B-тестов в соответствующем разделе документации.

2. Кодим

Не будем останавливаться непосредственно на интеграции с Firebase Remote Config — она подробно описана здесь.

Разберём способ организации кода для проведения A/B-тестирования. Если мы просто меняем цвет кнопки, то говорить об организации нет смысла, ибо организовывать особенно нечего. Мы рассмотрим вариант, в котором в зависимости от параметра из Remote Config показывается текущий (для контрольной группы) или новый (для экспериментальной) экран.

Нужно понимать, что по истечению A/B-теста один из вариантов экрана надо будет удалить, в связи с этим организовать код необходимо таким образом, чтобы минимизировать изменения в текущей реализации. Все файлы связанные с новым экраном стоит называть с префиксом AB и помещать в папки с таким же префиксом.

Если мы говорим об MVP в Presentation слое, выглядеть это будет примерно так:

Наиболее гибкой и прозрачной представляется следующая иерархия классов:

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

AbOrderStatusFragment будет переопределять методы, различающиеся в реализации, и иметь необходимые дополнительные. Таким образом, в текущей реализации изменится лишь разбивка одного класса на два и некоторые методы в базовом классе станут protected open вместо private.

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

В рамках такой организации скорее всего придётся отступить от принятого CodeStyle, что в данном случае допустимо, ибо соответствующий код будет удалён или отрефакторен по завершению A/B-теста (но, конечно, в местах нарушения CodeStyle стоит оставить коммент)

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

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

Ну, и, естественно, важно не забыть прокинуть значение параметра из конфига в параметры событий аналитики, чтобы была возможность сравнить метрики

Анализ результатов

Есть немало статей, подробно рассказывающих про способы анализа результатов A/B-тестов, например. Чтобы не повторяться, просто укажем суть. Нужно понимать, что разница метрик на контрольной и экспериментальной группе — случайная величина, и мы не можем сделать вывод о релевантности фичи только на основе того, что на экспериментальной группе показатель метрики лучше. Необходимо построить доверительный интервал (выбор уровня надёжности стоит доверить аналитикам) для вышеописанной случайной величины и проводить эксперимент до тех пор, пока интервал полностью не окажется в положительной или отрицательной полуплоскости — тогда можно будет сделать статистически достоверный вывод.

Подводные камни

1. Ошибка при получении Remote Config

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

Рассмотрим следующий кейс: у нас есть пользователь, которого Firebase отнёс к экспериментальной группе. Пользователь первый раз запускает приложение и запрос Remote Config возвращает ошибку — пользователь видит старый экран. При следующем запуске запрос Remote Config отрабатывает корректно и пользователь видит новый экран. Важно понимать, что такой пользователь не является релевантным для эксперимента, поэтому нужно придумать, как отсеивать такого пользователя на стороне системы аналитики, либо доказать, что число таких пользователей пренебрежимо мало.

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

Примечание. Данные за последние 30 дней. Общее кол-во запросов 673 529. Первый столбец, помимо сетевых запросов, содержит получения конфига из кеша, поэтому выбивается из общей формы распределения.

Данные графика:

 

Миллисекунды	Кол-во запросов
200	227485
400	51038
600	59249
800	84516
1000	63891
1200	39115
1400	24889
1600	16763
1800	12410
2000	9502
2200	7636
2400	6357
2600	5409
2800	4545
3000	3963
3200	2699
3400	3184
3600	2755
3800	2431
4000	2176
4200	1950
4400	1804
4600	1607
4800	1470
5000	1310
> 5000	35375

2. Накатка обновления Remote Config

Необходимо понимать, что Firebase кеширует запрос Remote Config. Дефолтное время жизни кеша составляет 12 часов. Время можно регулировать, но у Firebase, есть ограничение на частоту запросов, и если его превысить, Firebase нас забанит и будет возвращать ошибку на запрос конфига (Прим. для тестирования можно прописать настройку setDeveloperModeEnabled, в таком случае лимит применяться не будет, но сделать так можно для ограниченного числа устройств).

Поэтому, например, если мы хотим завершить A/B-тест и раскатать новую фичу на 100%, нужно понимать, что переход осуществится только в течение 12 часов, но это не главная проблема. Рассмотрим следующий кейс: мы провели A/B-тест, завершили его и подготовили новый релиз, в котором есть другой A/B-тест с соответствующим конфигом. Мы выпустили новую версию приложения, но у наших пользователей уже есть конфиг, закешированный с прошлого A/B-теста, и, если время жизни кеша ещё не истекло, запрос конфига не подтянет новые параметры, и мы опять получим пользователей отнесённых к экспериментальной группе, которые при первом запросе получат дефолтные значения конфига и в перспективе испортят данные нового эксперимента.

Решение этой проблемы весьма простое — необходимо форсировать запрос конфига при обновлении версии приложения путём обнуления времени жизни кеша:

val cacheExpiration = if (isAppNewVersion) 0L else TWELVE_HOURS_IN_SECONDS
FirebaseRemoteConfig.getInstance().fetch(cacheExpiration)

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

Выводы

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

Всем добра, удачного A/B-тестирования и повышения конверсий на 100500%.

6 шагов для успешного тестирования приложений под Android

 

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

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

Так к чему я это?

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

На фоне это мы поговорим,  какие особенности есть в тестировании мобильных приложений и на что нужно обратить внимание в первую очередь, прежде чем приступать к тестированию. И нашим объектом будет платформа Android.

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

1. Наши  устройства.

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

Если вы тестируете, то помните, что ваш парк должен включать не одно, не два и даже не десять устройств.

Часто на собеседования ко мне приходят тестироващики мобилок, и, когда разговор заходит о парке мобильных устройств, в 90% случае я слышу максимум 4-5 устройств, на которых принято тестировать в их компании.

Что???

Нельзя отталкиваться при выборе устройств от версии платформы!!!

Многие же считают, что если мы проверили приложение на Android 5.0 Lollipop на SAMSUNG Galaxy S6, то значит приложение работает.

Как бы не так!

Помимо платформы, есть ряд составляющих, таких как CPU, диагональ и разрешение экрана, ОЗУ, которые могут серьезно влиять на работоспособность Вашего приложения.

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

Полные результаты исследования можно посмотреть тут:

Мобильная лаборатория

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

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

2. Размер экрана и плотность.

Если про размер экрана все понятно, то обычные тестировщики не всегда сталкиваются с понятием плотности.

Итак, плотность экрана (Screen density) — это количество физических пикселей дисплея.

По сравнению с достаточно малым количеством экранов на iOS, вариаций по размеру экрана и его плотности для платформ Android добавляют дополнительную сложность в тестировании. Несмотря на то, что существует более 12 000 различных устройств, официально Android их разделяет на 4 класса по размеру экрана и 6 классов по плотности.

Как мы видим, самые популярным размером экрана является «Normal» с плотностью hdpi, xhdpi, xxhdpi и mdpi, что важно учитывать при подготовке парка устройств для тестирования мобильных приложений.

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

Ссылка на dashboard android

3. Версионность.

Официально Android поддерживает 10 платформ/версий, начиная с «Froyo» 2.2 и заканчивая «Marshmallow» 6.0. Но если говорить о сегодняшнем дне, то не все мобильные приложения поддерживают все версии и платформы. Поэтому, если и планировать тестирование, то нужно обязательно учитывать выполнение тест-кейсов на нескольких версиях Android.

Так, например, если мы посмотрим на текущий рынок, то  уже давно вышли такие версии, как «Lollipop» 5.0-5.1 (которая вышла еще в декабре 2014 года) и «Marshmallow» 6.0, но лидером по прежнему является  «KitKat» 4.4.

В чем важности использования различных платформ?

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

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

Я как то просматривал Play Market и меня удивило, что практически для каждого приложения пользователи пишут о том, что на том или ином устройстве их приложение работает не правильно!

И иногда это действительно вымораживает нервирует. Когда вы скачиваете приложение особенно не через wi–fi и метров под 900, запускаете его, а в ответ приложение не открывается!

Отсюда могу сказать, что важно протестировать продукт как минимум на 4-х, а лучше 5-ти версиях Android.

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

Можем идти дальше!

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

4. Общая функциональность.

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

Начнем по порядку.

• Регистрация и вход в систему. 

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

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

• Ключевые функции.

Любые функции, которые особенно связаны с текстовым набором, скроллингом, кнопкой «Назад» и другие, без которых функционирование приложение просто невозможно для нормального пользователя, должны обязательно проверяться в ходе тестирования. Кроме того, необходимо обязательно проверить, что приложение будет корректно работать при последовательном использовании физических кнопок и тачскрина.
Недавно скачал себе приложение KFC. Моей злости не было предела! Мало того, что у меня просто не нажимались кнопки добавления в корзину, так он  еще и загружается минуту! И ресторан я свой искал руками, т.к. приложение упорно говорило мне, что я нахожусь в противоположной части города!

Как ведет себя приложение, когда батарея телефона на полном, среднем и низком заряде? Может ли пользователь воспользоваться вызовами или тестовыми сообщениями? Вы всегда должны знать, насколько работа других приложений (зачастую стандартных) может повлиять на работу Вашего приложения.  Для этого очень полезен анализ crashlog.  Например, у меня на Lenovo, когда работает музыка через Bluetooth, постоянно при повторном запуске Яндекс Навигатора и при нажатии на кнопку GPS перезагружается телефон. Это ужасно, особенно когда ты едешь на скорости 100км/ч и у тебя пропал GPS, а нужно его перезагрузить. Начинается паника, куда ехать… И напоследок разработчики Android будут аплодировать стоя,  самое крутое, что перезагружается телефон вот в таком формате:

И тут начинается лотерея! Физически тачскрин работает в портретной ориентации, а экран обрезан на половину и отображается в альбомной ориентации. Когда я первый раз наткнулся на такой баг, я 30 минут пытался попасть по кнопке перезагрузить телефон!

Но вернемся к теме мобильного тестирования.

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

Как видно, клавиатура закрывает всю возможность выбрать предыдущие адреса! Поэтому либо выбираем первый адрес, либо вводим его. Ну или тратим 5 минут, на то, что бы попробовать прокрутить адреса, при этом не нажав случайно на адрес или клавиатуру!!!

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

• Влияние на работу устройства.

Говоря об эксплуатации, подразумевается работа приложения в обычном режиме. Для тестирования необходимо запустить приложение и использовать его в течении 6-12 часов. При использовании необходимо каждые 30 минут или 1 час  измерять уровень заряда батареи. Зачастую такая проверка автоматизирована, чтобы не тратить время тестировщика на сбор данных. Если результаты теста показывают, что снижение уровня заряда батареи происходит раньше 6 часов при условии работы со всеми фоновыми функциями вашего телефона, то это явно указывает на проблемы в приложении.
Я думаю у каждого была ситуация, когда вы скачиваете приложение, а потом оно сжирает у вас за 30 минут 20% аккумулятора. Я не помню их названия, но такие были точно!

5.      Дополнительные проверки.

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

Спец символы.  Если приложение, которые вы тестируете включает поля поиска или формы ввода, обязательно нужно проверить на возможность ввода спецсимволов.

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

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

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

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

6. Безопасность Android.

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

Любая система должна обеспечивать соблюдение требований к информации:

• Конфиденциальность. Недоступны ли личные данные пользователей?
• Целостность. Нет ли возможности извне изменить личные данные при их передаче?
• Аутентификация. Как приложение проверяет, что именно я являюсь владельцем аккаунта?
• Доступность. Как и при каких условия возможность сломать/ сделать неработоспособным приложение?
• Отказоустойчивость. Как ведется учет всех отказов системы?

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

И помните, что излишняя навязчивость пользователю политики конфиденциальности тоже может отбить желание пользоваться мобильным приложением!

Ну и напоследок….
Мне пришлось изрядно порыться в Google Play, но это оказалось очень полезным.

Удалось относительно определить основные проблемы, с которыми сталкиваются пользователи:

• 55% жалуются на установку
• 24% жалуются на производительность
• 13% говорят об отказах приложения
• 5% пишут, что их приложение подтормаживает или зависает.
• 2% жалуются на UI
• 1% на проблемы с конфиденциальностью или безопасностью.

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

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

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

Надеюсь было полезно! 

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

…несмотря на то, что он кое в чём неполон, содержит много сомнительного или,
во всяком случае, вопиюще неточного, он имеет два важных преимущества:
во-первых, он немного дешевле, […], а во-вторых, на его обложке большими
и приятными для глаз буквами написаны два слова «Без паники!»
— 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 < 17, но это, возможно, будет исправлено подключением Espresso в качестве драйвера.
• Тем не менее надстройка Appium очень популярна и активно развивается, поэтому многие проблемы могут решиться сообществом в будущем.

WebDriverAgent

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

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

Calabash

Следующая весьма популярная надстройка — Calabash для Android и iOS. Инструмент разработан компанией Xamarin, но она прекратила его поддержку в 2017 году, и сейчас он поддерживается только сообществом.

Для каждой ОС есть своя надстройка — Calabash iOS или Calabash Android. Обе они поддерживают тестирование WebView и языки Ruby/ JRuby. Для работы Calabash Android не нужен доступ к исходникам приложения, а вот для работы Calabash iOS понадобится подключить к коду приложения Calabash framework. Также для работы с view вне нативного iOS-приложения используется дополнительный инструмент — DeviceAgent, который позволяет детектить эти views и взаимодействовать с ними. Теоретически это означает, что можно тестировать и WebView, но на практике лучше ограничиться теми views, которые выдаёт iOS для вашего приложения: различные оверлеи для подтверждения, отправка писем и вставка фотографий. Calabash Android поддерживает работу с WebView, но в достаточно ограниченных масштабах: тап, ввод текста, алёрты.

В целом Calabash — довольно стабильный и быстрый инструмент, имеющий полезные функции для приведения приложения в нужное состояние (бекдоры) и “из коробки” поддерживающий интеграцию с Cucumber. Но из-за отсутствия официальной поддержки при его использовании могут возникнуть проблемы, а сообщество не может гарантировать их быстрое решение.

Earl Grey

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

Фреймворки

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

xUnit и TestNG

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

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

Cucumber

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

Комбайны

Xamarin

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

Ranorex

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

Squish

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

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

Заключение

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

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

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

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

Шпаргалки

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

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

Понимание и освоение тестирования Android-приложений: часть 1

Представляем вашему вниманию статью Аритры Роя, инженера-проектировщика и Full-stack разработчика.

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

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

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

Зачем беспокоиться о тестировании?

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

В течение долгого времени мне было непонятно, почему я должен тратить время на автоматические тесты вместо того, чтобы делать это вручную обычным способом. Я знал так называемые «теоретические» причины, но не были ясны фактические последствия написания и не написания тестов.

Уверенность в вашем коде

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

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

Избавление от ошибок регрессии

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

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

Написание минималистичного кода

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

Предположим, что вы следуете Test-Driven Development (TDD), и написали тест. Теперь вашей основной целью будет написание только нужного кода, чтобы пройти этот конкретный тест. Вы не будете писать лишний или ложный код, который вы написали бы в противном случае.

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

Пирамида тестирования

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

Юнит-тестирование

Это основной блок тестов, которые вы будете писать в своем приложении – около 70% ваших общих тестов. Это небольшие, сфокусированные тесты, которые могут запускаться прямо на вашей локальной машине, и, поскольку они работают непосредственно в вашей локальной среде, они очень быстрые, а время их выполнения очень мало.

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

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

Интеграционные тесты

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

Эти тесты обычно проверяют, работают ли два разных модуля или компонента вместе так, как должны. Это сильно отличается от тестирования бизнес-логики, о котором мы говорили ранее. Как правило, эти тесты являются средними по размеру (больше, чем юнит-тесты, но короче, чем end-to-end тесты) и должны составлять около 20% от общего количества тестов, написанных для вашего приложения.

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

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

End-to-end тестирование

Предположительно, вы будете использовать лишь несколько таких тестов. В идеале вы должны постараться сделать так, чтобы около 10% ваших тестов были end-to-end вариантами. Как следует из названия, вы будете использовать эти тесты для полного тестирования потока – с начала и до конца.

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

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

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

Android Dev Подкаст. Выпуск 17. Droidcon Moscow, Multi-window, тестирование и профилирование

Типы тестирования на Android

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

Не волнуйтесь, они не очень отличаются от того, что мы обсуждали ранее, но в Android мы склонны классифицировать тесты на основе того, работают ли они на локальном компьютере или на реальном устройстве/эмуляторе.

Локальные unit-тесты

Это те тесты, которые могут выполняться локально на вашей девелоперской машине. Эти тесты находятся в module/src/test/java и не имеют никакого доступа к любым API-интерфейсам Android.

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

Для модульного тестирования мы используем JUnit, который является очень популярным фреймворком юнит-тестирования, помогая нам писать четкие и понятные тесты. Мы также можем использовать Robolectric, который является еще одной популярной платформой тестирования, позволяющей нам также тестировать зависимости Android.

Инструментальные тесты

Это те тесты, которые относятся к категории тестов «Integration» и «End-to-End». Все эти тесты находятся в module /src/androidTest/java.

Обратите внимание на добавление префикса «android» перед «тестом», означающим, что эти тесты должны запускаться на устройстве Android или эмуляторе и иметь доступ к зависимостям Android. Они в основном известны как «source sets», если вам интересно.

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

Теперь у вас может возникнуть вопрос, почему эти тесты называются «инструментальными»? Это связано с тем, что они используют Android Instrumentation API через InstrumentationRegistry для управления компонентами Android и их жизненными циклами вручную, вместо того, чтобы позволять системе их контролировать.

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

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

Выводы

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

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

Автоматизированное тестирование мобильных приложений / Habr

Я провел настоящее исследование ситуации с автоматизированным тестированием интерфейса мобильных приложений. Речь идет не о тестировании модулей, а именно о тестировании интерфейса финального приложения. И, да, прямо на телефоне!

Зачем это нужно? В первую очередь, для гарантированного улучшения качества вашего ПО и улучшении настроения тестировщиков.

В чем идея? Чаще всего тестирование мобильных приложений осуществляется людьми: тестировщик берет приложение, iPhone 3, iPhone 4, iPad, если ему не повезло, то еще берет пару андроидов и GalaxyTab, и тестирует ваше приложение, 80% тестирования составляют примерно такие сценарии:
— запустить приложение, убедиться, что оно не падает;
— перейти на вкладку места, убедиться, что все пункты на месте;
— зайти в один из пунктов, убедиться, что описание на месте;
…

Такие тесты проводятся после каждого релиза и занимают очень много времени.

В свое время в вебе на помощь пришел Selenium, который позволил через специальный плагин к браузеру записывать действия тестировщика (все помнят макросы в MS Word?) и затем проигрывать их автоматически с проверкой результата. Можно запускать тесты даже на разных браузерах! Мы использовали это решение в своей компании, и оно, действительно, работает. Усилия на разработку тестов окупились.

По сравнению с вебом мобильная разработка еще очень молодая область, и я не ожидал увидеть хороших решений для автоматизированного тестирования интерфейсов. Оказалось, что их более чем достаточно. Хочу рассказать вам о некоторых из них.

iPhone

UIAutomation

Начну со стандартного решения от Apple, которое входит в Instruments.

UIAutomation позволяет выполнять написанные на JavaScript тестовые сценарии как в эмуляторе, так и на устройстве. Тестировать можно любые свои приложения, включая, production сборки. Компилировать дополнительные библиотеки не требуется. Можно запускать скрипты из консоли.

Apple разработала специальный JavaScript API для тестирования. В нем описаны все стандартные элементы интерфейса. Элементы представлены деревом, есть специальные функции для быстрой выборки элементов по типам (buttons, tableViews, textFields…). Если специально не задавать в программном коде Accessibility Label, то элементы можно выбирать только по номеру.

window.tableViews()[0].visibleCells()[1].tap()

Выбор второй ячейки в первой таблице.

Я написал тестовый скрипт для нашего Goozy приложения, он логинится, проверяет, что выбрана вкладка «All», переходит на вкладку «Settings» и разлогинивается.

На написание этого скрипта у меня ушел час, при этом рядом я держал открытый XCode и смотрел, как же представлены элементы в дизайнере, как они генерируются динамически. Ко всему прочему, скрипты пишутся в маленьком окне (на скришноте UIAutomation показан справа), проверки синтаксиса нет, поддержки систем контроля версий нет.

[Подсвеченный код: paste.ly/7mnG]

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

UPD: В Xcode 4.3 появилась возможность записи тестов. Запуск из консоли практически невозможен.

UPD2: При работе с UIAutomation строго рекомендуется задавать всем компонентам Accessibility Label

FoneMonkey

Record&Play решение, интересно тем, что тесты записываются и редактируются (!) прямо из тестируемого приложения на телефоне или эмуляторе.

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

Fonemonkey умеет сохранять тесты в формате UIAutomation, поэтому вы можете после записи прогонять их на «чистых» приложениях.

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

UPD: Экспорт в UIAutomation работает очень криво, мне не удалось запустить полученные скрипты.

Платные собратья

Squish

Squish — это решение для тестирования Windows, Mac, Qt и iOs приложений. Лицензия на конкретного разработчика стоит (named license) $2400.

Система интегриуется в HP Quality Center, Seapine TCM или предоставляет Eclipse based IDE. Тестировать можно приложения на эмуляторе или устройстве, доступна запись тестов (record&play). Скрипты могут быть на Javascript, Python, Perl или Tcl.

У системы два минуса: для работы на устройстве (даже для прогона тестов) необходимо компилировать отдельную версию с их библиотекой; второй минус — это эклипс, если вы не разорились на HPQC, врядли, тестировщики смогут полноценно работать с eclipse-based IDE.

В целом, я не вижу принципиальных отличий от свободного FoneMonkey. Разве что, Squish поддерживает мультитач (support for automatic gestures).

JamoSolution

Одна из самых многообещающих платформ. JamoSolution позволяет тестировать iPhone, Android, Windows Mobile и BlackBerry приложения. При этом для всех платформ поддерживается запись тестов (record&play) и вы можете тестировать iPhone приложения на Windows!

У них есть прекрасные демонстрационные видео, вот тестирование под iPhone:

Под Android:

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

Android

Robotium

Самое популярное решение — это Robotium. «It’s like Selenium, but for Android» — утверждают разработчики, но это немного не так. Robotium не поддерживает запись тестов (Record&Play) и не умеет делать скриншоты.

Тесты пишутся на Java, фактически, Robotium — это библиотека для обычных Unit тестов, возможности запускать тесты на устройстве нет (remote control). Чтобы тестировать приложения, необходимо их собрать с этой библиотекой. Возможно тестировать приложения без исходников, но процесс нетривиальный.

TestDroid

Пока я проводил исследование, появилось новое решение для Android. TestDroid — это плагин для эклипса, который позволяет записывать тесты (record&play) в формате Robotium. Система взаимодейтсвует с телефоном путем стандартного Android debugger.

Одна лицензия на TestDroid Recorder стоит $600 в год. Разработчики обещают выпустить еще и TestDroid server, он позволит создавать кластеры для тестирования. Подключите к серверу несколько Android телефонов и запускайте тесты параллельно и удаленно.

К сожалению, решение еще в стадии бета-тестирования и не генерирует тесты на моем маке.

К тому же, судя по логам, не все действия записываются в тесты. Решение многообещающее, но стоит немного подождать.

Windows Phone 7

На момент написания статьи утилит для автоматизации тестирования интерфейса WP7 приложений не существовало.

Absolute Black Box

Наверняка вам знакомо понятие «Черного ящика», так вот, есть как минимум две системы мобильного тестирования работающих по этому принципу.

Это Perfecto Mobile и Device Anywhere.

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

Внутрь фотографии телефона вставлена картинка с веб-камеры. Управляется полностью мышкой.

Основной бизнес Perfecto Mobile и Device Anywhere это даже не автоматическое тестирование, а продажа времени устройств. У них стоят сотни различных телефонов (iPhone/Android/Blackberry…) и час работы с одним телефоном стоит около $15.

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

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

Где же автоматика?

Очень интересно реализовано автоматическое тестирование.

Проверка результатов выполняется сверкой картинок и распознаванием текста на экране OCR. Одна из платформ использует знаменитый ABBYY 🙂

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

Плюсы

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

Минусы

• автоматическое тестирование дорогое;
• большой лаг при взаимодействии с телефоном.

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

1. Под какую платформу разрабатываете?
2. Что за приложение? (игры, банковский сектор, бизнес приложения, медицина)
3. Используете ли unit тесты, почему?
4. Автоматизируете ли тестирование UI, почему?
5. Если бы стали автоматизировать, какой инструмент был бы для вас идеален?