- Описание
- Философия Appium
- Компоненты
- Архитектура
- Преимущества и недостатки
- Сравнение с Selendroid и Robotium
- C Espresso
- Установка
- На Mac
- Пример теста
Описание
Кроссплатформенный фреймворк с открытым кодом для автоматизации тест-кейсов мобильных приложений — нативных, гибридных и веб-приложений. Создавался изначально для тестирования на Android и iOS, как на основных мобильных платформах, со временем удобство и удачность фреймворка привели к созданию WAD-драйвера (WinAppDriver) для тестирования десктопных Windows-приложений. Проект начинался как инструмент командной строки, устанавливаемый через node,js, со временем появился удобный интерфейс, инспектор элементов, и прочие удобства.
Три вида мобильных приложений
Нативные
Традиционно требовательные к «железу» и ориентированные на производительность, написанные на «языках семейства С» и с помощью соответствующих SDK. Разработка обходится дорого, но такие приложения:
- Быстрые и отзывчивые
- Выглядят приятно
- Хорошо интегрируются с аппаратной частью
- Интуитивный UI/UX
Стоит посмотреть на Spotify, Snapshot, Pinterest и Skype на смартфоне, чтобы понять, что нативное приложение при прочих равных — лучше.
Веб-приложения
Вместе с тем, у нативных приложений есть некоторые недостатки; бывают ситуации, когда лучше веб-приложение; оно запускается в мобильном браузере, поэтому не требуется его (иногда усложненная) установка, а разработка намного дешевле и быстрее. Разрабатываются такие приложения на HTML/CSS/JavaScript, отсюда преимущества:
- Малая стоимость разработки
- Проще поддержка
- Не обязательна официальная «приемка» в аппстор
- Не нужна инсталляция
Например, мобильный Aliexpress это веб-приложение.
Гибридные
Сочетают преимущества нативных и веб-приложений. Скачиваются из аппстора и имеют доступ ко всем нужным функциям смартфона. Представляют собой «веб-приложение в контейнере». Тоже разрабатываются на HTML/CSS/JS, и могут запускаться на любой платформе. Поэтому имеют заметные преимущества:
- Одна кодовая база на всех платформах
- Быстрая разработка
- Удобное масштабирование и перенос между платформами
- Доступ ко всем аппаратным функциям смартфона
Гибридные приложения: Basecamp, Instagram.
В Appium можно тестировать все три типа мобильных приложений, на обеих платформах, и этим он удобен.
Философия Appium
В процессе разработки создатели фреймворка старались учесть недостатки существовавших на то время тестовых фреймворков «первого поколения» и создали 4 принципа Appium:
- Для автоматизации приложения не нужно рекомпилировать его и вообще как-то модифицировать.
- Не должно быть привязки к какому-то языку или фреймворку.
- При автоматизации API не нужно изобретать колесо — лучше воспользоваться имеющимися лучшими решениями.
- Фреймворк должен быть с открытым кодом.
Компоненты Appium
Клиент-серверная архитектура
В «сердце» Appium — веб-сервер с REST API. Он получает запросы от клиента, слушает его команды, выполняет их на девайсе, и отправляет HTTP-ответ с результатом выполнения. Клиент-серверная архитектура имеет преимущество: можно писать тесты на любом ЯПе, поддерживающем клиентский API по HTTP (а проще воспользоваться одной из библиотек Appium). Можно поставить сервер на другой машине, не той на которой выполняются тесты. Можно хранить код тестов на облачном сервисе типа Sauce Labs.
Сессии
Клиенты открывают сессию с сервером, каждая библиотека имеет особенности, общее то что все они отправляют запрос Post/session на сервер, с JSON-объектом, имеющим название “desiredcapabilities”. Сервер откроет сессию автоматизации и отправит ID сессии, который будет использован при отправке будущих команд.
DesiredCapabilities
Это набор ключей и значений (например в форме map или hash), отправляемых Appium-серверу, и описывающих, какую открыть сессию автоматизации, или как изменить поведение сервера во время сессии. Например, отправляется набор platformName в iOS, чтобы открыть iOS-сессию (а не Android). Или свойство safariAllowPopups ставится в положение true, и тогда во время сессии в Safari JS будет разрешено открывать всплывающие окна.
Appium Server
Написан на node.js. Может быть собран и установлен из исходников или прямо из NPM.
Appium Clients
Клиентские библиотеки (на Java, Ruby, Python, PHP, JavaScript, C#), поддерживающие расширения WebDriver-протокола для Appium. Они работают вместо стандартного WebDriver-клиента.
Appium.app и Appium.exe
GUI-обертки вокруг Appium-сервера, поставляемые вместе со всем необходимым ему, включая Инспектор, контролирующий иерархию приложения.
Архитектура Appium
Appium это HTTP-сервер, написанный на node.js, который создает WebDriver-сессии для iOS и Android. Appium запускает тест-кейс на девайсе, то есть запускает там сервер и слушает через прокси команды от основного Appium-сервера. Тестировщик пишет сценарии, выполняемые на девайсе/эмуляторе путем отправки запросов/ответов на Appium-сервер.
iOS
Appium «проксирует» команду в скрипт UIAutomation, запускаемый в окружении Mac Instruments. Оно предназначено для профилирования, контроля и билда приложений, а также имеет компонент для автоматизации. В нем можно писать команды на JavaScript, и через UIAutomation API команды взаимодействуют с интерфейсом. Автоматизация Appium работает через эти библиотеки.
Выше изображена архитектура Appium в контексте автоматизации на iOS. Жизненный цикл команды выглядит так: веб-драйвер Selenium принимает команду в коде и отправляет ее, в JSON-форме, HTTP-запросом на Appium-сервер. Этот сервер обрабатывает контекст (iOS или Android) и направляет команду на сервер команд Instruments (работающий на node.js), тот ее «подхватывает» и выполняет через bootstrap.js в iOS-окружении Instruments. После выполнения команды клиент отправляет Appium-серверу ответ, который с деталями записывается в логи.
Android
Примерно так же, Appium направляет через прокси команду в UIAutomator на девайсе. UIAutomator — нативный фреймворк UI-автоматизации, поддерживающий запуск тест-кейсов на JUnit непосредственно на девайсе из командной строки. Основной язык Java, и возможны все другие ЯПы, поддерживаемые WebDriver.
На диаграмме имеем bootstrap.jar (вместо bootstrap.js), здесь тест-кейс, скомпилированный из Java-кода. При его выполнении запускается TCP-сервер на девайсе и клиент в Appium-процессе.
В прошлом году вышел Appium 2.0, его архитектура изображена ниже:
Преимущества и недостатки
Плюсы
- Бесплатный и открытый
- Кроссплатформенность, гибридные и нативные приложения
- Совместим с JSON-веб-драйвером и Selenium Grid
- «Облачное тестирование» через testdroid
- Поддержка C#, Java, PHP, Python, Ruby
- Удобная автоматизация
- Не нужна рекомпиляция
- Поддерживает симуляторы, эмуляторы и реальные девайсы одновременно
- Инспектор для записи и воспроизведения тестов
- Поддержка протокола JSON wire
- Большое комьюнити с советами
- Хорошая поддержка Android выше версии 4.1
Минусы
- В iOS не поддерживается несколько сценариев в нескольких симуляторах одновременно
- Android ниже версии 4.1 не поддерживается (хотя таких приложений уже меньше 3%)
- В чем-то ограниченная поддержка гибридных приложений (но тут смотря что считать «гибридным»: можно переключаться между webview- и нативным контекстами, включив debug для WebView)
- Поддержка жестов до сих пор не идеальна
- Не очень полная документация
- Иногда проблемы с изображениями
- В версии для Windows иногда глючит Инспектор
Сравнение Appium с Selendroid и Robotium
Appium | Selendroid | Robotium |
Открытый код. Бесплатный | Открытый код. Бесплатный | Открытый код. Бесплатный |
Поддерживает и iOS, и Android | Только Android | Только Android |
Не нужно видеть код приложения и библиотеки | Нужен код приложения | Нужен код приложения |
Не нужно реинсталлировать приложение | Нужно реинсталлировать | Небольшое изменение в коде Robotium приводит к полному ребилду |
Поддерживает много фреймворков и языков программирования | Совместим с Selenium и Jenkins | Только Java. Не поддерживает Selenium |
Большое доброе комьюнити | Хуже чем у Appium | Небольшое комьюнити |
Сравнение Appium и Espresso
Как следует из описания Espresso на официальном сайте, тестовый фреймворк Espresso предоставляет API для UI-тестов пользовательских автоматизированных сценариев. Espresso отличается тем, что предназначен Google для функциональных тестов Android-интерфейсов. Espresso изначально приспособлен к автоматизации белого ящика, имея доступ к коду приложения.
Appium же, изначально делался кроссплатформенным и приспособленным к «черному ящику», имея дело с тестами «внешней стороны» приложения. Через фреймворк UIAutomator Appium запрашивает UI-элементы интерфейса.
Установка Appium
- Скачиваем, по списку:
- Ставим Java. Не забывая о переменных окружения.
- Ставим Android Studio и создаем проект:
- Разархивируем клиентскую библиотеку отдельно от jar-файлов Appium.
- В Android Studio переключаемся на Project View:
- Выбираем файлы, разархивированные на этапе 4, и кладем их в папку libs. Выделяем их и добавляем в качестве библиотеки:
- После этого увидим файл build.gradle в папке нашего приложения. Кликаем его и делаем ребилд проекта. Все, Appium поставлен:
На Mac
Через NPM.
- Ставим Node.js и проверяем, поставилось ли:
brew install node node -v npm -v
- Ставим Appium и проверяем:
npm install -g appium appium -v
- Ставим клиент Appium и запускаем Appium:
npm install wd appium
Также ставим Appium doctor:
npm install appium-doctor -g
Или можно просто скачать Appium на официальном сайте и поставить.
Подключение реального Android-девайса на Mac
Что понадобится:
- Установленная Java
- Прописать переменную окружения JAVA_HOME (проверяется командой java -version)
- Девайс
- Кабель
- Скачиваем Android SDK.
Или c официального сайта, или так:
brew install android-sdk brew cask install android-sdk
- Разархивируем папку platform-tools:
sdkmanager "platform-tools" "platforms;android-28"
- Прописываем переменные окружения:
ANDROID_HOME — путь к папке android-sdk
PATH — добавить к пути к папке platform-tools
export ANDROID_HOME=/usr/local/share/android-sdk echo $ANDROID_HOME export PATH="/usr/local/Caskroom/android-sdk/4333796/platform-tools:${PATH}"
Делаем переменные окружения глобальными в Мас-системе, командой:
cd ~/ cat .bash_profile
Если bash_profile не существует:
- touch .bash_profile vi .bash_profile
нажимаем «i» и добавляем следующее:
Установка PATH для ANDROID_HOME:
export ANDROID_HOME=/usr/local/share/android-sdk
Добавление platform-tools в PATH:
PATH="/usr/local/Caskroom/android-sdk/4333796/platform-tools:${PATH}"
Нажимаем «esc» и пишем:
:wq!
Нажимаем «enter». Теперь ANDROID_HOME и PATH заданы.
echo $ANDROID_HOME echo $PATH
Запускаем команду:
adb devices
- Настраиваем Android-девайс:
Включаем Developer Mode.
Включаем USB Debugging.
- Подключаем девайс через USB-шнурок. Если спросит, активируем USB Debugging.
- Запускаем команду:
adb devices
И проверяем, виден ли ID девайса.
Пример теста в Appium
Для тестов в Appium нужны, в зависимости от платформы, следующие драйверы:
XCUITest Driver (iOS и tvOS)
Espresso Driver (Android)
UiAutomator2 Driver ( Android)
Windows Driver ( Windows Desktop)
Mac Driver (Mac Desktop)
Проверка инсталляции
В нашем случае пробный тест будет на Mac. Сначала проверим все зависимости appium-doctor’ом. Он устанавливается командой npm install -g appium-doctor, далее он запускается командой appium-doctor с флажком —ios или —android и проверяет зависимости.
Клиенты
Как шла речь выше, Appium это фактически HTTP-сервер с обертками, который «сидит и ждет» подключений от клиента с указаниями, какую сессию запустить, и какие действия выполнить. То есть всегда нужен клиент, клиентская библиотека (или например cURL для экстремалов).
Как уже знаем, Appium «общается» по протоколу Selenium, то есть WebDriver Protocol. В Appium доступны многие действия через стандартные клиенты Selenium. И скорее всего, такие клиенты уже установлены, если на машине раньше тестировали веб-браузеры на мобильных платформах.
Appium умеет делать множество вещей, недоступных в Selenium, благодаря своим клиентам, расширяющим функциональность стандартных Selenium-клиентов — список клиентов здесь. Итак, скачиваем там клиент для любимого языка, и приступаем.
Запуск Appium
Запускаем с командной строки:
appium
Или большой кнопкой Start Server в Appium Desktop. Появится приветствие с номером версии и порта (стандартный 4723). Чтобы поменять порт по какой-то причине, при запуске добавляется флажок -p с номером порта. (Также бывают другие полезные параметры запуска).
Первый тест
Запустим стандартный Android-тест Hello World. Будем работать с драйвером UIAutomator2. Язык программирования выберем JavaScript, чтобы не заморачиваться лишними зависимостями. Android мы выбрали потому, что он доступен на всех платформах. Если интересуют другие языки и платформы, в разделе на официальном сайте есть примеры кода.
Теперь убедимся, что у нас настроен и работает эмулятор Android 8.0. Также нужно скачать тестовый APK.
Настройка Appium Client
Возьмем в качестве клиента Webdriver.io. Создаем папку, затем запускаем:
npm init -y
После инициализации проекта ставим Wedriver.io:
npm install webdriverio
Запуск сессии
Теперь создаем файл теста index.js и инициализируем объект клиента:
const wdio = require("webdriverio");
Далее нам нужно запустить Appium-сессию. Описываем набор опций для сервера и DesiredCapabilities, и вызываем с ними wdio.remote. Как мы уже знаем, DesiredCapabilities это набор ключей и их значений, отправляемых на Appium-сервер во время запуска сессии, объясняющих серверу, какие действия планируются. Минимальный набор capabilities-свойств должен включать:
- platformName: название платформы
- platformVersion: ее версия
- deviceName: тип девайса
- app: путь к приложению (примечание: если автоматизируется веб-браузер, указывается browserName)
- automationName: название драйвера
Список всех Capabilities здесь.
Описываем сессию в файле теста:
const opts = { path: '/wd/hub', port: 4723, capabilities: { platformName: "Android", platformVersion: "8", deviceName: "Android Emulator", app: "/path/to/the/downloaded/ApiDemos-debug.apk", appPackage: "io.appium.android.apis", appActivity: ".view.TextFields", automationName: "UiAutomator2" } }; async function main () { const client = await wdio.remote(opts); await client.deleteSession(); } main();
Выполнение команд
Как видим, был указан порт Appium и DesiredCapabilities. В своем тесте нужно будет заменить путь к app на реальный путь к тестовому приложению на своей машине. Мы зарегистрировали это в webdriver.io и теперь имеем объект клиента, подключающийся с Appium-серверу. Далее можем запустить сессию, выполнять команды в тесте, и закрыть сессию. В нашем случае, просто введем текст в поле и проверим, что он корректный:
const field = await client.$("android.widget.EditText"); await field.setValue("Hello World!"); const value = await field.getText(); assert.strictEqual(value, "Hello World!");
После открытия сессии и запуска приложения мы передали команду в Appium найти соответствующий элемент в иерархии и ввести туда текст. Далее это же поле было проверено на корректность текста.
const wdio = require("webdriverio"); const assert = require("assert"); const opts = { path: '/wd/hub', port: 4723, capabilities: { platformName: "Android", platformVersion: "8", "appium:deviceName": "Android Emulator", "appium:app": "/path/to/the/downloaded/ApiDemos-debug.apk", "appium:appPackage": "io.appium.android.apis", "appium:appActivity": ".view.TextFields", "appium:automationName": "UiAutomator2" } }; async function main () { const client = await wdio.remote(opts); const field = await client.$("android.widget.EditText"); await field.setValue("Hello World!"); const value = await field.getText(); assert.strictEqual(value,"Hello World!"); await client.deleteSession(); } main();
Можно также запустить этот тест командой:
node index.js
Если все сделано верно, Appium ответит массой сообщений в логах, приложение появится на экране и невидимый пользователь будет в нем действовать)
***
Для подробного ознакомления:
- Список команд Appium
- Каталог полезных примеров для новичков
- Здесь комьюнити, где помогают советами
- Известные проблемы с Appium
***