Автоматизоване мобільне тестування: перші кроки

Автор: Антон Пелянський, Test Engineer, Quality Assurance, Consultant, GlobalLogic Ukraine

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

Серед інших, не менш важливих задач є:

• Вивчення вимог до застосунку та інших проєктнихпроцедурних документів.
• Створення документації.
• Стратегія тестуванняТест планТест репорт.
• Матриця TraceabilityТест протоколи.
• Валідація тестових інструментів.
• Розробка тестового фреймворку автоматизації.
• Підняття проєкту для запуску автотестів.
• Опис інструкції по підняттю проєкту та запуску тестів.

А тепер про все це поговоримо детальніше.

З чого починається інженер автоматизації мобільного тестування?

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

Аналіз документів вам надасть:

• Фундамент для тест плану та дизайну тестів.
• Розуміння очікуваного функціоналу продукту.
• Поширення розуміння на всю команду.
• Узгодження з планом розробки.
• Виправлення нечітких вимог, які неможливо перевірити.

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

Є дві глобальні операційні системи iOS та Android, і різні версії цих систем підтримуються на різних пристроях. Зверніть особливу увагу на вимоги по сумісності: вони можуть як змусити вашу команду підтримувати застарілі пристрої, так і намагатись наздогнати тенденції ринку. Це допоможе зробити процес розробки та тестування більш ефективним. Що ж стосується дистрибуції – шляху передачі продукту до замовника, – то вона має бути заздалегідь чітко визначена і описана у відповідному документі, на кшталт Design Transfer Plan.

Підбір тестових пристроїв

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

При розробці кросс-платформенних застосунків, якщо у вас з самого початку зазначено, що продукт має бути і на iOS, і на Android, варто мати хоча б один фізичний пристрій для тестування для кожної окремої мобільної системи. Тут також варто зазначити, що підбір необхідної версії операційної системи для еталонних пристроїв залежить від вимог до застосунку.

Архітектура

Аби чіткіше розуміти, з чим ви матимете справу, пропоную розібратися в архітектурі заліза. Отож, поточна архітектура у iOS пристроях є arm64 (або ARMv8.0). Вона використовується у пристроях починаючи з iPhone 5S та iPad Air та підтримується версією iOS 7.0 та вище.

Більше, на зображенні нижче:

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

Нижче наведена табличка по розподілу архітектури центральних процесорів і архітектури на i- пристроях.

Всі дані, що наведені в табличці, можуть змінитися буквально за рік, тому надзвичайно важливим є слідкувати за тенденціями, цікавитися змінами, що стаються на ринку, аби завжди володіти актуальною інформацією.

Що ж стосується Android, то тут усе простіше.

У них дві основні архітектури – на ARM процесорах це armeabi-v7a (це 32- розрядна архітектура) та arm64-v8 – це 64-розрядна архітектура. Також є дві версії для процесорів Intel – це x_86 (для 32-розрядних процесорів) та x86_64 (для 64-розрядних процесорів). Варто зазначити що відсоток пристроїв що працюють на архітектурах x86 та x86_64 станом на 2017 рік складав 1.7%.

Як поширюються ті чи інші версії Android, можна дізнатися з графіку:

Оскільки є немало версій iOs та Android, а девайсів може бути понад 50 – то виникає логічне запитання:

Як нам все це перевірити?

Для цього є кілька доступних сервісів.

#1 Firebase Test Lab

Це хмарна інфраструктура для запуску тестів на мобільних пристроях. Цей сервіс підтримує запуск тестів на Android та iOS на цілому спектрі пристроїв, а також розуміє автоматизовані тести, написані на UIAutomator та Espresso для Android, а також XCTest для iOS.
Є безкоштовна версія, яка дозволяє запустити до 5 тестів на реальних пристроях і до 10 тестів на віртуальних пристроях за добу.
Firebase Test Lab є досить корисним сервісом, якщо ви тільки починаєте знайомитись з мобільною автоматизацією, а от для проєктних цілей безкоштовна версія не дуже підходить.

#2 Amazon Device Farm

Це сервіс для тестування мобільних додатків з хмарною інфраструктурою, який підтримує понад 170 різних мобільних пристроїв для запуску паралельних тестів. Amazon Device Farm підтримує більшість тестових фреймфорків для автоматизації, включаючи Appium, UIAutomator та XCTest. Перші 100 хвилин роботи тестів надаються сервісом безкоштовно. Якщо цього часу вам виявиться недостатньо, Amazon Device Farm пропонує платну підписку.

Емулятори vs Симулятори

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

Почнемо з різниці між ними:

• Симулятор відтворює виконання коду без прив’язки до середовища запуску коду (тобто це перевірка суто логіки виконання програми, тому у випадку якщо ця логіка зав’язана на залізі, то ця перевірка не пройде).
• Емулятор відтворює принципи роботи системи пристрою зі збереженням ключових властивостей та аспектів роботи. Емуляція відтворює код у необхідному для нього середовищі.

На iOS зараз доступні лише симулятори, а на Android – емулятори.  А тепер пропоную розглянути як все працює та відбувається наживо.

Запуск iOS симулятора через Xcode: покрокова інструкція

• Встановити Xcode через AppStore.
• Запустити Xcode.
• Вибрати бажаний пристрій зі списку доступних симуляторів.
• Запустити симулятор.

Виглядає це все так: відео.

Запуск Android емулятора через Android Studio:покрокова інструкція

• Встановити Android Studio.
• Запустити Android Studio.
• Відкрити Android Virtual Device Manager.
• Створити профілі бажаних пристроїв.
• Запустити емуляцію пристроїв.

Виглядає це наступним чином: відео.

Що ж, розібралися з Android емулятором, і тепер поговоримо про Appium.

Хто такий цей ваш Appium?

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

Appium дозволяє тримати тести для iOS та Android в одному фреймворку і використовувати одні й ті самі тести для обох платформ. Він підтримує тести, що написані на:

• Java (TestNG, JUnit)
• JavaScript (node.js)
• Python
• PHP
• Ruby

Отож, ви пишете тести тією мовою, яка вам більше до вподоби, після чого ці тести передаються на Appium сервер, написаний на Node.js, а далі Appium сервер переганяє саму логіку та назву локаторів та передає кінцеві тести на емулятори, або кінцеві пристрої.

Для Android використовується UIAutomator, для iOS – XCUITest.

Як це виглядає у коді? А ось так.

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