Автоматизація мобільних додатків на базі Appium


Автор: Антон Сирота (QA, Automation)

У цій статті, заснованої на лекції, яку я нещодавно читав, ми розглянемо фреймворк Appium. Це вступний матеріал, призначений для розуміння, як в принципі відбувається автоматизація мобільних додатків, що для цього потрібно з чого, власне, починати роботу і з якими труднощами доведеться зіткнутися.

Автоматизація мобільних додатків — відносно нове явище, але попит на неї постійно зростає. Дещо-які труднощі є і з Appium, хоча в цілому процес автоматизації з його використанням вже налагоджений.

Зміст
 Оточення для мобільного автоматизації
 Пошук і робота з елементами
 Робота з драйвером
 Робота з контекстами
 Емулятор або реальний пристрій?
 Можливі проблеми/труднощі
 Процес мобільного автоматизації
 Хмарні сервіси

Види мобільних додатків:
 Нативні.
 Веб.
 Гібридні.

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

Рідні додатки. Основний вид мобільних додатків, встановлюються на телефон і працюють безпосередньо на телефоні. Рідні додатки не вимагають браузера та інтернету, а якщо і вимагають, не залежні від їх наявності.

Веб-додатки. Зараз часто зустрічаються адаптивні дизайни, які адаптують веб-додаток з десктопної версії під мобільну. Тестувати такі програми потрібно в умовах, максимально наближених до реальної середовищі, — на емуляторах або пристроях.

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

Оточення для автоматизації
iOS Automation Android Automatoin
Мас OS Mac OS / Windows / Linux
XCode Android SDK
Node Js Emulator setup
Appium Appium
Application Application
Haxm driver (SDK for Emulator)


Перед тим як починати процес автоматизації, важливо зрозуміти, яке оточення потрібно буде налаштувати. І, природно, дві основні операційні системи, з якими доведеться мати справу, — iOS і Android.

Що для старту вимагає iOS? Apple — цілісна система, тому, якщо завтра потрібно буде автоматизувати iOS-додаток, вам потрібна буде операційна система Mac, як варіант — розгортати все можна на Mac-mini. Чому? Тому що нам потрібен буде xCode з Mac OS.

Таким інструментом буде Appium. Є дві можливості запуску Appium: UI або консольна. Для установки і запуску консольної версії нам додатково знадобиться NodeJs. А UI-версію можна завантажити з офіційного сайту, і вона відразу буде готова до роботи.

Якщо ми говоримо про автоматизацію веб-додатків, нам буде необхідно переконатися, що на емуляторі встановлений браузер. Для Android це буде Google Chrome для iOS — Safari (який по дефолту завжди вже є у емуляторі).

Якщо тестуємо нативне додаток, яке нам дали розробники, ми повинні переконатися, що воно є на нашій машині, і вказати шлях — як до нього можна отримати доступ до Appium.

Для Android-автоматизації питання вибору операційної системи не настільки критичний — тут все можна налаштувати під Windows, Linux і MacOS. Потрібно врахувати, що під віртуальною машиною не завжди виходить розгорнути Android-автоматизацію через відсутність графічного адаптера, без якого ми просто не зможемо запустити Android-емулятор. Для старту нам буде потрібен Android SDK, тобто девелопмент-кіт для Android, в якому вже є вбудований емулятор.

Наступний крок — налаштування емулятора. Там же можна створити і налаштувати емулятор і емулювати практично будь Android пристрій.

Також нам знадобиться Appium та сама.апк-додаток, або Chrome.apk для Android. Важливо знати, що у стандартного емулятора Android існує не велика проблема: SDK — емулятор дуже повільний, щоб його прискорити, при створенні емулятора можна поставити галочку «Use host GPU», при цьому повинен бути встановлений Haxm-драйвер (згаданий у списку). Тоді емулятор починає працювати з більш-менш пристойною швидкістю. Звичайно, є й більш стабільні і швидкі інструменти типу Genymotion — він умовно безкоштовний, але, якщо ви захочете використовувати його у своєму проекті, вам доведеться здобувати платну ліцензію.

Пошук і робота з елементами
Tools:
 Appium Inspector
 UI Automator Viewer (Android)
 UI Automation (iOS)

Locators:
• Xpath
• Id
• Class
• Name
• UI Automation id
• Css (mobile web only)
• Accessibility id (ios only)

Якщо ви працюєте з мобільними веб-додатком, можна просто відкрити його в браузері, зменшити до розміру потрібного пристрою і знаходити потрібні елементи.

Якщо додаток нативне або гібридне, знадобиться Appium Inspector — вбудований інспектор в Appium працює з Android, і з iOS. Тобто, якщо у вас запущена UI-версія Appium, ви можете натиснути Inspect, після чого з'явиться дерево елементів програми. Також є окремі програми: UI Automator Viewer для Android UI Automation для iOS. Це допоміжні інструменти, що дозволяють бачити елементи і знаходити їх, щоб в подальшому використовувати при автоматизації.

Які локатори існують? Навіть для рідних додатків, ми можемо використовувати той же мова розмітки, що і для веб-додатків — Xpath. ID, якщо у елементів є будь-які ID. Можна також використовувати Class чи Name, є ще й UI Automation ID — він може стати в нагоді, якщо в стандартному дереві не видно якогось елемента. Тобто, коли елемент є на пристрої, є на емуляторі, ми його бачимо, але в дереві елементів у xml його немає — таке теж буває. UI Automation дозволяє записати ваші дії, згенерувати після цього код, частини якого можна використовувати в автоматизації. Можна використовувати CSS, але потрібно врахувати, що CSS-локатори будуть працювати тільки при автоматизації мобільних веб-додатків.

Приклад знаходження локаторів в нативних додатках
Відкриваючи UI Automation Viewer, зліва ви побачите скріншот екрану, праворуч — дерево елементів, які є в додатку. Ми можемо піти по дереву і побудувати Xpath. Локатор буде використовувати два слеша та включати елементи, які дозволять побудувати залежність.

У нас є дерево і деталі по кожному елементу додатку. Тобто ми беремо якийсь елемент, і можемо бачити у нього class, index, text, id і т. д. Все це можна використовувати при пошуку елемента. При побудові локатора, ми можемо знайти елемент по класу, якщо клас унікальний. Також у нас може бути resource_id, всередині якого є id=, такі елементи можуть знаходиться безпосередньо по id=. Appium Inspector буде дуже схожий на UI Automation viewer, який йде в пакеті з Android SDK (папка tools, і в ній uiautomatorviewer.bat файл, який запускає UI Automation viewer і дозволяє дивитися дерево елементів). З його допомогою можна бачити елементи не тільки на емуляторі — ви можете знаходити ті ж самі елементи з реального пристрою, якщо він підключений через кабель.

У UI Automation Viewer можна клікнути на кнопку device screenshot, тоді він підключається до емулятор з допомогою ADB і отримує через нього скріншот і xml відкритої програми. Після отримання скріншота і дерева елементів ми можемо перевірити, чи є у нас потрібні елементи і перевірити, за якими атрибутами можна скласти унікальний локатор. Таким чином і знаходяться елементи в нативних додатках.

Робота з драйвером
WebDriver — RemoteWebDriver – AppiumDriver = IOSDriver / AndroidDriver

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

Після цього можна будувати безпосередньо автоматизацію. Також варто згадати прошарку автоматизації, де кінцева точка — ваш додаток, яке встановлено на пристрої, рівнем нижче — пристрій, з ним і взаємодіє Appium, який встановлюється окремо. Команди в Appium передаються з коду, який в цілому буде виглядати майже так само, як при автоматизації веб-додатків з використанням Selenium. Тобто у вас використовується той же Page Object, ви працюєте з елементами, тільки це будуть вже не WebElements, а MobileElements. Сам код взаємодіє з Appium через драйвер.

Веб-драйвер — інтерфейс, в якому є каркас можливих дій. Далі йде RemoteWebDriver, який успадковує WebDriver. Далі — AppiumDriver, який буде необхідний при автоматизації мобільних рідних додатків (при автоматизації мобільних веб-додатків можна використовувати RemoteWebDriver). І вже від AppiumDriver, успадковуються IOSDriver і AndroidDriver, в яких певні дії реалізуються по-своєму для кожної операційної системи.

Якщо детальніше:
 WebDriver — базовий інтерфейс.
 RemoteWebDriver — часто використовується для автоматизації із застосуванням Selenium Grid (автоматизація веб-додатків).
 AppiumDriver — загальний абстрактний клас для автоматизації мобільних додатків.
 IOSDriver — використовується для iOS Automation.
 AndroidDriver — використовується для Android Automation.

Використовувати RemoteWebDriver при автоматизації мобільних веб-додатків не завжди зручно, тому що іноді виникає необхідність звернутися до певних нативним частинах. У тому ж Facebook, якщо ви будете автоматизувати мобільний веб-версію програми, після введення логіна і пароля вискочить пропозицію запам'ятати пароль. А після апрува вискочить нативний pop-up, який буде блокувати сайт, поки ви не натиснете «Ok». Щоб це зробити, вам потрібно AppiumDriver (або iOSDriver/AndroidDriver), який зможе працювати з нативним контекстом, т. к. RemoteWebDriver може працювати тільки з веб-контекстами.

AppiumDriver (General abstract class for Mobile) — абстрактний клас для мобільного автоматизації і для автоматизації Android/iOS. Залежно від пристрою, ви можете використовувати IOSDriver або AndroidDriver, який успадковується від AppiumDriver.

Приклад ініціалізації


Цей приклад взятий з реального проекту. Тут ми можемо вказати необхідні нам capability. Після того як середовище для автоматизації готова, можна реалізувати всі в коді, який і далі буде відправляти потрібні запити в Appium. Щоб це зробити, вам потрібно вказати URL, за яким він буде йти в Appium, і потрібні capability.

У прикладі ініціалізації показано налаштування для Mobile Chrome і Mobile Safari. У capability позначено browserName, де ми вказуємо, чи буде це Chrome або Safari. Далі у нас можуть бути використані різні пристрою і платформи. Є ще autoAcceptAlerts, щоб не вискакували нативні аллерты, і newCommandTimeout, який встановлюється, щоб повідомити драйверу, при якому просте йому завершити сесію.

Робота з контекстами
Отримати всі контексти:
getDriver().getContextHandles();
Перемкнути контекст:
getDriver().context("WEBVIEW");
getDriver().context("NATIVE_APP");
getDriver().context("CONTEXT_NAME");

Більшою мірою це стосується гібридних додатків. При автоматизації рідних додатків допоможе нам або Appium Inspector, або UI Automator Viewer. Що стосується гібридних додатків, коли відкривається нативне додаток, після певних кроків можна в цьому ж додатку відкрити веб-сторінку, або буде відображатися її частину.



У цьому прикладі відкритий Appium Inspector. Саме так він виглядає, коли відкрито IOS-додаток. Дерево елементів тут відкривається послідовно. Ви вибираєте який-небудь елемент і, якщо всередині є ще елементи, відобразиться наступне дерево внутрішніх елементів. Тут є можливість бачити контексти, тобто ви можете вибрати NATIVE_VIEW — нативний контекст, або WEB_VIEW — веб-контекст.

Буває і так, що у вас йде нативна шапка в додатку, а нижче слід вбудована веб-сторінка. У таких випадках у вас є кілька контекстів, і ви можете перемикатися між ними для пошуку потрібних елементів.

Як це працює? Якщо говорити, як це реалізується в коді, у вас є драйвер, в якому є можливість отримати всі контексти викликом методу getContextHandles().

Також у вас є Appium-інспектор, щоб підтвердити, що всі контексти в наявності; є можливість вивести з коду всі контексти, які є на поточний момент, після чого ви можете перемикатися на ці контексти.

Тобто основне, що вам знадобиться — це метод getContextHandles(), який бере всі контексти, які є на відкритої сторінці додатка.

Якщо потрібно переключитися між контекстами, відкриваєте в тесті нативне додаток, доходите до веб-частини, після чого потрібно перейти з нативного контексту на веб. Для цього викликаєте метод context(), який є в AppimDriver, і вказуєте в ньому контекст, на який потрібно перейти — приміром, WEB_VIEW або NATIVE_VIEW.

Пристрою або емулятори
Real Device Emulator
Простота налаштування Android: Швидка установка
iOS: Доведеться покопатися
Android: Є підводні камені при налаштуванні
iOS: вимагає xCode і мінімальних налаштувань
Швидкість прогону Швидко Android: швидкість залежить від емулятора
iOS: низька швидкість запуску, швидкий прогін
Стабільність Відносно стабільно Android: Є певні нестабільності
iOS: Проблему можна вирішити додатковими bash-скриптами
Поведінка Може відрізнятися в залежності від версії OS Може відрізнятися в залежності від версії OS
Доступність елементів WebView елементи можуть визначатися, як Native WebView елементи доступні, як веб-елементи
Ми працювали і з реальним пристроями, і з емуляторами. У кожному випадку виявилися плюси і мінуси.

Реальне Android-пристрій в цілому вдається налаштувати досить швидко. Потрібно переконатися, що на пристрої включений developer mode. А після підключення пристрою потрібно на самому телефоні підтвердити підключення, натиснувши на выскочившем вікні «Ok», і все — ціною мінімальних зусиль ви готові автоматизувати мобільні додатки на Android.

Якщо ми маємо справу з iOS, доведеться покопатися — там при підключенні реального пристрою свої складності. Зв'язка з Appium можлива, але потрібно витратити час, щоб його налаштувати.

Якщо говорити про Android-емулятор, основний підводний камінь — проблема швидкодії. Стандартний емулятор дуже повільний, але установка haxm-драйвера і вибір Use Host GPU при налаштуванні емулятора дозволяють його прискорити.

Якщо це веб-автоматизація, важливо встановлювати правильну версію браузера. Наприклад, якщо у вас платформа х86, потрібно ставити Google Chrome теж версії х86.

Якщо розглядати iOS-емулятор, в цілому все не так складно — знадобляться мінімальні налаштування. Потрібно запустити Appium, щоб на Xcode був емулятор потрібної версії. Приміром, щоб прогнати тест на iPhone 6, під iOS 9.3, потрібно просто переконатися, що саме ця версія присутня в Xcode.

В цілому реальні пристрої працюють швидше, ніж емулятори. У випадку з емуляторами, у Android швидкість залежить від самого емулятора. В якості альтернативи Android є емулятор Genymotion, який встановлюється досить швидко і працює швидше і стабільніше стандартного. Використовуючи Genymotion, можна ганяти тести в декілька потоків на одній машині, що дозволяє помітно збільшити швидкість проходження тестів.

Якщо говорити про IOS-емуляторі, отримуємо високу швидкість прогону, але низьку швидкість запуску тесту. Тому що, якщо запускаємо тест нової сесії (а найчастіше нам це знадобиться, щоб працювати на чистому додатку), він буде кожен раз перевідкривати емулятор, що забирає час. При цьому самі тести біжать досить швидко.

В Android-емуляторах можуть спостерігатися певні нестабільності. Якщо говорити про реальних пристроях, все відносно стабільно. Але в цілому проблеми з нестабільними прогонами під стандартним емулятором можна частково вирішити додатковими batch-скриптами — вони перед стартом тестів будуть вбивати всі зайві процеси (які могли залишитися з попереднього прогону) і стартувати чисту сесію Appium і емулятора перед прогоном групи тестів.

Бувають випадки, коли поведінка програми може відрізнятися в залежності від версії операційної системи, якісь спливаючі вікна можуть не з'являтися взагалі або навпаки вискакувати постійно. Це дрібниці, але таке трапляється — такі моменти теж доводиться якось обробляти.

Доступність елементів
Досі ми помітили таке тільки в одному проекті: в нативному додатку відкривається веб-сторінка, а елементи на цій сторінці визначаються по-різному на емуляторі і реальному пристрої. Буває, що елементи на реальному пристрої визначаються як нативні, а в емуляторі все працює як WebView, тобто як звичайний веб-сайт, де ми можемо знайти елементи навіть за CSS-локатора.

Як я вже зазначив, подібну різницю ми помітили в одному проекті: ми могли з CSS-локатора знайти елемент, який буде відмінно працювати на емуляторі, але, коли запускаємо цей же тест на реальних пристроях, він в принципі нічого не знаходить, навіть веб-контекст, і бачить все як нативний контекст.

Можливі проблеми
 Деякі елементи можуть бути недоступні.
 Не всі стандартні методи працюють правильно (ex. scroll/swipe).
 Потрібно стежити за оновленнями.
 Потрібно стежити за відповідністю версій OS, Appium, Emulator).
 Важливо правильно налаштувати емулятор.

У випадку з автоматизацією мобільних додатків все ще не так ідеально налагоджено, як у веб-автоматизації, але в цілому всі проблеми, які ми розглянули, вирішувані. На це доведеться витратити якийсь час.

Як я згадував раніше, деякі елементи можуть виявитися недоступними. У нас був випадок, коли валідація на сторінці була візуально видно, але в дереві елементів її не було. Можна викликати getPageSource(), як при веб-автоматизації, і нам повернеться xml відкритої сторінки, тобто все, що видно на сторінці на даний момент. Але найчастіше, якщо елемент не доступний в інспекторі, xml теж нічого нового не відкриє. В цьому випадку є два варіанти вирішення: або залишати цей кейс на ручне тестування, або поспілкуватися з девелоперами, попросити їх додати ID інші додаткові атрибути.

Не всі стандартні методи працюють правильно. І тут треба розуміти, що Appium — фреймворк відносно новий, якщо порівнювати його, скажімо, c Selenium. Це помітно, якщо говорити про таких діях, як scroll/swipe, коли нам потрібно в нативному додатку прогорнути вліво/вправо, вгору/вниз. У AppiumDriver є метод scrollToText(), який може перегорнути сторінку до певного тексту, але, на жаль, поки для iOS він не завжди стабільно працює. Будьте готові, що доведеться писати свій кастомный scroll — в інтернеті є певні рішення, які можна використовувати.

У AppiumDriver є також метод swipe, але у нього дуже багато параметрів. Тому, щоб використати його в тестах, найчастіше потрібно буде писати свою обгортку, яка буде пересувати екран на певну кількість відсотків або пікселів вправо-вліво. Тобто в цілому питання вирішується, але з проблемою доведеться зіткнутися.

Необхідно стежити за оновленнями і відповідністю версією — що з того, що раніше в Appium не працювало, успішно працює в нових версіях. Тобто нам доведеться оновлювати Appium як Application так само, як API в коді. В обох випадках ми повинні намагатися підтримувати саму останню версію, тому що її регулярно покращують і допрацьовують. При цьому, якщо у вас остання версія Appium і який-небудь старий xCode зі старим емулятором, додаток, можливо, працювати не буде.

Mobile Automation Workflow


Власне, ось так все і повинно працювати в ідеалі. Нативне додаток — файл, який нам потрібно десь взяти, а потім використовувати при прогоні тестів. Таким чином, щоб був реалізований процес автоматизації правильно, потрібна збірка, яка збере мобільний додаток. Наприклад, автоматична збірка Аndroid-програми, яка створить .apk-файл. Далі може у відповідь на дію автоматично запускатися Jenkins завдання, яка буде передавати локацію зібраного.апк-додатки і проганяти на ньому потрібні тести. Можна налаштувати збірку програми та прогін на ній тестів кожну ніч, таким чином, тести у нас завжди будуть up-to-date, і ми зможемо щоранку бачити і аналізувати результати прогону тестів і виявляти баги максимально оперативно.

Хмарні сервіси


Для автоматизації iOS-тестів нам був необхідний Mac-mini. Але якщо нам необхідно забезпечити мультипоточность? Припустимо, є 300 тестів, і вони в один йдуть потік 12 годин, а отримати результати нам потрібно всього за годину. Працювати стає значно складніше: для кожного потоку потрібна окрема mac-машина. При цьому потрібно постійно стежити за оновленнями версій Appium, Xcode і OS.

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

Візьмемо BrowserStack. Цей вендор виділяє віртуальні машини, а ми просто вказуємо в коді RemoteUrl, за якою будуть ганятися тести. І, якщо ми вказали прогін три потоку, це автоматично буде розподілятися на три машини на стороні browserstack. До того ж, усі додатки вони оновлюють вчасно і уважно стежать за сумісністю. Значить, працювати стане значно легше. Найвагомішою перевагою хмарних сервісів в тому, що ви не витрачаєте багато часу на налаштування і підтримку оточень для автоматизованого тестування.

Переваги хмарних сервісів:
• Не витрачаємо час на налаштування середовища.
• Не витрачаємо час на підтримку середовища.
• Стабільна робота.
• Більш висока швидкість проходження тестів (найчастіше).
• Проста реалізація мультипоточности.

Хмарні сервіси також надають відеозапис того, що відбувається — це стосується і мобільних і веб-додатків. А якщо вам потрібно тестувати під певною системою, наприклад Windows XP або Internet Explorer 8, ви можете з легкістю встановити параметри при прогоні тесту, а хмарний сервіс автоматично запустить тест під потрібним оточенням. До речі, для мануального тестування той же browserstack надає можливість безкоштовного користування.

Тепер можна не витрачати час на налаштування середовища і її підтримку: просто говоримо тесту, на якому оточенні йому прогоняться, і завжди знаємо, що всі останні оновлення там вже встановлені.

Стабільна робота хмарних сервісів означає, що вам не потрібно буде писати додаткові скрипти, які контролюють стабільність прогону і старт скриптів в чистій сесії. Тести в хмарних сервісах зазвичай біжать швидше, хоча, якщо у вас буде абсолютно топова і дуже дорога Mac-машина, в швидкості можете і виграти. Але якщо у вас стоїть Mac-mini позаминулого року, навіть з хорошими позапрошлогодними параметрами, тест не буде таким швидким, як у більшості хмарних сервісів.

Тим більше, хмарний сервіс дозволяє нам запустити одну задачу в кілька потоків і, відповідно, ваші 9-годинні тести можна прогнати за годину-дві.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.