Статьи

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

  1. зміст
  2. Оточення для автоматизації
  3. Пошук і робота з елементами
  4. Приклад знаходження локаторів в нативних додатках
  5. Робота з драйвером
  6. приклад ініціалізації
  7. Робота з контекстами
  8. Пристрої або емулятори
  9. доступність елементів
  10. Можливі проблеми
  11. Mobile Automation Workflow
  12. хмарні сервіси
  13. Переваги хмарних сервісів:

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

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

зміст

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

Види мобільних додатків:

  • Нативні.
  • Веб.
  • Гібридні.

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

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

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

Тестувати такі додатки потрібно в умовах, максимально наближених до реальної середовищі, - на емуляторах або пристроях.

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

Оточення для автоматизації

iOS Automation

Android Automatoin

Maс OS

Mac OS / Windows / Linux

XCode

Android SDK

Node Js

Emulator setup

Appium

Appium

Application

Application

Haxm driver (for SDK 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 і саме .apk-додаток, або Chrome.apk для Android. Важливо знати, що у стандартного емулятора Android існує не велика проблема: SDK - емулятор дуже повільний, щоб його прискорити, при створенні емулятора можна поставити галочку "Us e 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: Швидка установка

Android: Є підводні камені при налаштуванні

iOS: Доведеться покопатися

iOS: вимагає xCode і мінімальних налаштувань

швидкість прогону

швидко

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

Mobile Automation Workflow

Власне, ось так все і повинно працювати в ідеалі. Оригінальне додаток - файл, який нам потрібно звідкись взяти, а потім використовувати при прогоні тестів. Таким чином, щоб процес автоматизації був реалізований правильно, потрібна збірка, яка збере мобільний додаток. Наприклад, автоматичне прибирання Аndroid-додатки, яка створить .apk-файл. Далі може по триггеру автоматично запускатися Jenkins Джоба, яка буде передавати локацію зібраного .apk-додатки і проганяти на ньому потрібні тести. Можна налаштувати збірку додатки і прогін на ній тестів щоночі, таким чином, тести у нас завжди будуть 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-годинні тести можна прогнати за годину-дві.

Що для старту вимагає iOS?
Чому?
Які локатори існують?
Як це працює?
Але що якщо нам необхідно забезпечити мультіпоточность?

Новости