В этой статье мы рассмотрим инструмент Appium. Данная статья является вводным материалом для введения в автоматизированное тестирование мобильных приложений. Она покажет с какими трудностями возможно придется столкнуться при использовании данного инструмента.
Рассмотрим небольшую задачу на примере «калькулятора», попробуем написать автоматизированные тесты для тестирования его и… Начнем с саааамого начала :)
Содержание
- Что такое Appium ?
- Необходимый минимум.
- Постановка и решение задачи.
- Конклюжен :)
Что такое Appium ?
Пару слов о мобильном тестировании. Можно дома не иметь компьютер, ноутбук, но свою жизнь мы не воспринимаем без мобильных девайсов. Тестирование мобильных приложений занимает большую нишу в… тестировании… Мммм… масло масленное, но это так. Эта ниша довольно-таки сложна.
Девайсов такое огромное количество со своими операционными системами, со своими графическими интерфейсами, разрешениями экранов и т.д. Мне кажется список этот нескончаемый. Так вот, в силу огромного разнообразия мобильных устройств, было бы неплохо иметь автоматизированные тесты для наших приложений, дабы уменьшить страдания тестировщиков и не превращать тестирование одной функциональности на сотнях девайсах в “сущий ад” (см. изображение ниже).
Существуют многочленные инструменты для написания автотестов под мобильные девайсы. Для решения поставленных передо мною задач, я выбрал Appium, так как он одновременно подходит для Android и iOS и можно писать автотесты используя «всеми любимую» Java.
Appium— это бесплатный кроссплатформенный инструмент с открытым исходным кодом, который помогает автоматизировать приложения как для Android, так и для iOS. Appium придерживается того же подхода, что и Selenium WebDriver, который получает HTTP-запросы в формате JSON от клиентов и преобразует их в зависимости от платформы, на которой он работает.
Необходимый минимум
Итак, что нам необходимо для работы с Appium?
Для создания тестов под Android выдвигаются следующие требования:
- Java (version >= 7)
- Android SDK API (version >= 17)
- Android Virtual Device (AVD) / real device
- Intel Hardware Accelerated Execution Manager
Для того, чтобы эмулятор Android устройства работал со скоростью, приближенной к скорости работы реального устройства, необходимо установить Intel Hardware Accelerated Execution Manager. Это поможет сократить время на запуск и отладку приложения.
Для iOS:
- Mac OS X (version >= 10.7)
- Xcode (version >= 5.1)
- Java (version >= 7)
- Homebrew
- NodeJS
- npm
Также рекомендую установить appium-doctor, чтобы диагностировать возможные проблемы при установке и настройке нужных компонентов на обеих платформах.
Постановка и решение задачи
Итак, представим, что нам необходимо написать автоматизированные тесты для приложения калькулятор для Android устройств. Для этого нам необходимо скачать Appium с официального сайта и установить его у себя на «машине».
Запускаем Appium.
По умолчанию Appium готов слушать localhost с портом 4723. Здесь оставим все без изменений и стартанем сервер.
Теперь Appium готов обрабатывать наши запросы.
Наш будущий автотест необходимо запускать либо на эмуляторе либо на реальном девайсе. Для универсальности данной статьи, рассмотрим работу теста на эмуляторе. Для этого нам понадобится Android Studio. Качаем и инсталим ее самостоятельно. Затем открываем и переходим в Tools — AVD Manager.
Теперь откроем терминал и выполним команду adb devices. Она покажет список приаттаченых девайсов.
Мы видим, что список девайсов пуст, потому что ни один эмулятор не запущен, ни один реальный девайс не подключен к нашей «машине».
Запустим все эмуляторы, которые у нас есть. В моем случае — это два эмулятора. Повторно выполним команду adb devices.
Теперь мы получили непустой список, который содержит ID наших приаттаченных устройств — эмуляторов и девайсов, если таковы имеются.
С эмулятором разобрались, приступим к написанию кода. Как было описано выше, в своих тестах я использую Java.
Для начала создадим экземпляр AndroidDriver. Конструктор данного класса ожидает на вход два параметра:
Desired capabilities — JSON-объект (набор пар ключ-значение), отправленный клиентом серверу.
Desired capabilities описывают особенности создаваемой сессии (имя девайса/эмулятора, операционную систему (ОС), версию ОС, запускаемое приложение и т.д.).
Пример capabilities:
Опишем наши capabilities и создадим AndroidDriver.
deviceName — обязательный парасметр, но для Android он не проверяется. Если говорить о iOS, то при указании имени, необходимо использовать одно из зарезервированных имен (пример такиих имен приведен в комментариях к коду). Описание других параметров приведены в коде (см. изображение выше), но на некоторых из них мы заострим внимание.
udid — уникальный идентификатор устройства. Данный идентификатор устройства мы можем получить командой adb devices.
appPackage — имя Java пакета Android приложения, которое мы хотим запустить.
appActivities — имя activities, которое мы открываем.
appPackage и appActivities можно получать различными способами, но самый простой из них, установить приложение «APK Info» из Google Play.
После открытия данной программы Вы будете видеть список всех установленных приложений. Нас интересует Calculator. Выбираем его из списка.
И тут находится вся необходимая нам информация.
Заполнили их. Далее создаем экземпляр AndroidDriver: прописываем URL Appium и передаем вторым параметром объект capabilities.
Данный код, лишь запустит калькулятор на эмуляторе. Нам необходимо научиться как-то управлять элементами калькулятора, чтобы мы смогли написать простой тест. Принцип тут схож как и в Selenium Web Driver. Нам необходимо обращаться к элементам через какие-либо локаторы. Для их получения нам поможет Appium Inspector. Открываем Appium.
Теперь все наши capabilities описанные в коде, необходимо перенести в Inspector, во вкладку Desired Capabilities.
Стартуем Session.
Инспектор транслирует то, что отображено на устройстве.Чуть правее расположено дерево всех элементов текущей Activity. Чтобы получить атрибуты элемента, необходимо лишь выбрать нужные нам элемент.
После выбора, отображается все атрибуты, которые доступны для данного элемента.В данном случае, нам не так важно как обращаться к элементу: по ID или xPath. Но в больших и сложных приложениях, лучше использовать ID, так как xPath очень замедляет прохождение тестов. Также, при тестировании гибридных приложений — ID будет один для Android и iOS, а xPath — разные. Мы научились получать необходимые атрибуты. Теперь по аналогии с Selenium Web Driver — получим необходимые элементы в коде.
Для получения элемента, я использую метод findElementById. Можно создавать экземпляр класса MobileElement и работать с ним, а можно и без создания. Тут мы определяем элементы цифры 2, + и 3. В конце ожидаю, что результат будет равен 5. В итоге получилось следующее:
Тест и работу по созданию сессии я вынес в отдельные методы. Теперь попробую продемонстрировать, что у нас получилось.
Конклюжен :)
В данной статье я показал, как быстро начать работу с Appium и что для этого необходимо. Как вы могли заметить, начать писать простые тесты не так уж и сложно. Дальше можно прикрутить отчет к проекту, к примеру, Allure. Но это уже совсем другая история :)
Возможно у вас возникнут индивидуальные проблемы при установке различных инструментов, которые необходимы для работы с Appium. Но все эти проблемы легко решаются поиском в Google :)
Тема тестирования под iOS не раскрыта, но я хочу «сказать», а точнее написать пару слов о ней.
Для того, чтобы запустить приложение через Appium на iOS, много времени я потратил на настройку среды (xCode, Appium, сертификаты разработчика и т.д.). Нужно было открыть проект Appium через xCode, указать сертификаты разработчика и иные настройки, собрать проект и лишь потом получилось выполнить команды через Appium на iOS девайсах. После каждого обновления Appium необходимо производить данную процедуру. Возможно, у вас все получится гораздо проще, стоит верить в это. Пока я не нашел другого решения, возможно оно и есть, но меня пока это устраивает.
Хочу еще раз отметить, что при обращении к элементам лучше использовать ID, чем xPath. Даже если элемент не содержит ID, то попросите/заставьте разработчика указывать ID. Это облегчит вам жизнь и увеличит скорость выполнения тестов.
И еще, чем больше у вас реальных устройств, тем больше вероятность найти баг до того, как найдут его конечные пользователи. В принципе, можно и создать свою фабрику девайсов. Но мне кажется, целесообразней все-таки смотреть в сторону облачных решений, например, BrowserStack, SauceLabs и другие.
У меня все!
P.S. Проект в GitHub
P.P.S. Немножко моей группы
Теперь точно все!
