Тестування автоматизації iOS за допомогою Xcode UI Framework

⚡ Розумний підсумок

Автоматизоване тестування iOS за допомогою Xcode записує та відтворює дії інтерфейсу користувача в тестовій програмі, дотримуючись циклу проектування, тестування, впровадження та повторного тестування, доки кожен випадок не буде пройдено.

🔘 Цикл TDD: Проектування, тестування, впровадження та ще раз тестування – це чотири фази, що застосовуються до тестування iOS-додатків.
☑️ Необхідні умови: Mac під керуванням OS X з Xcode Встановлено IDE, фреймворк для автоматизації та iOS SDK.
✅ Маршрут інструментів: Інструмент автоматизації записує скрипт, відображає його в журналі скриптів і відтворює на вимогу.
🧪 Маршрут OCUnit: Цільовий об'єкт пакета модульних тестів, активна схема, група тестів та клас тестів, написані на Objective-C.
⚠️ Припинення дії: Інструмент UIAutomation було вилучено з підтримки у Xcode 8 та видалено; XCUITest є підтримуваним наступником.
🛠️ Сучасний еквівалент: Цільовий пакет тестування інтерфейсу користувача та запити XCUIApplication замінюють записаний скрипт Instruments.

Детальніше

Тестування автоматизації iOS за допомогою Xcode

Щоб гарантувати якість вашого iOS-додатку, слід дотримуватися процесу розробки на основі тестування, показаного на рисунку нижче.

Розробка, керована тестуванням (TDD) – це a Тестування модель, яка застосовується до тестування iOS-додатків, і вона вписується в ширшу практику мобільне тестуванняУ цій моделі тестер повинен дотримуватися 4 етапів, наведених нижче:

Дизайн: Визначте, що ви хочете протестувати, та розробіть свої тестові випадки.
Тест: Виконайте всі тести та перевірте, чи є якісь тестові випадки, які зазнають невдачі.
Реалізація: RevОптимізуйте свій код та виправте помилки, які призвели до невдалого проходження тесту.
Перевірте ще раз: Якщо тест не пройшов, поверніться до початкового стану проєкту. Якщо всі тестові випадки пройшли успішно, код повністю відповідає вимогам тестування.

Налаштовуючи Xcode Проект для тестування інтерфейсу користувача

Щоб створити тестову програму для iOS, вам потрібен Mac. На вашому Mac вже має бути встановлено наступне:

OS X — операційна система для Mac.
Xcode IDE — інструмент розробки для iOS.
Автоматизована система тестування — Автоматизація інтерфейсу користувача, OCUnit тощо.
iOS SDK 4 або вище.

⚠️ Примітка до версії: Наведені вище передумови описують інструментарій епохи, в яку були написані два наступні покрокові посібники. На сучасному Mac, Xcode У комплекті постачаються фреймворки XCTest та XCUITest, а окремий інструмент автоматизації інтерфейсу користувача більше не входить до інсталяції. Нижче збережено оригінальні кроки, оскільки вони документують, як працював фреймворк, а сучасний еквівалент описано далі.

Як створити автоматизацію iOS за допомогою UI Automation Framework

Вісім кроків нижче записують скрипт за допомогою інструменту автоматизації та відтворюють його в тестованому застосунку.

Крок 1) Запустіть інструменти

Відкрити XCode -> Відкрити інструмент розробника -> Інструмент

Крок 2) Додайте інструмент автоматизації

У вікні «Інструменти» виберіть інструмент «Автоматизація».

Щоб створити тестовий скрипт, потрібно або записати тестовий сценарій або ви програмуєте це вручну.

Крок 3) Натисніть червону кнопку

Вмикається інструмент — негайно зупиніть запис. Якщо ви хочете розпочати запис, натисніть червону кнопку.

Крок 4) Створіть новий сценарій

У вікні «Сценарії» натисніть «Додати» > «Створити», щоб створити новий скрипт.

Крок 5) Виберіть ціль

Ви зараз у Tracвікно. Використайте кнопку «Вибрати» Target розкривний список, щоб перейти до версії програми для налагодження.

У цьому випадку, зразок Apple SimpleDrillDown Як тестова програма використовується app. Її графічний інтерфейс показано нижче.

Крок 6) Почніть записувати свій сценарій

Запишіть свій сценарій, натиснувши кнопку запису вгорі або внизу інструмента.

Тепер ви можете виконувати деякі дії інтерфейсу користувача у вашому тестованому застосунку, і ваш скрипт буде записано.

Крок 7) Перегляньте свій сценарій

Щоб переглянути свій сценарій, натисніть TracРозкривний список Журнал / Журнал редактора та переключіться на вигляд журналу скрипта.

Ви побачите свій записаний сценарій.

Крок 8) Відтворіть свій сценарій

Натисніть кнопку відтворення. Скрипт запуститься, і ви зможете зупинити його після появи журналів.

⚠️ Історична довідка: Інструмент автоматизації, який використовувався у цих восьми кроках, був застарілим у Xcode 8 та пізніші версії видалено, тому його більше немає в поточній Xcode встановлення. Кроки зберігаються тут як запис того, як працював фреймворк; для нової роботи скористайтеся покроковим керівництвом XCUITest далі на цій сторінці.

Як створити автоматизацію iOS за допомогою фреймворку OCUnit

Другий шлях розміщує тести всередині Xcode самого проєкту, а не всередині інструментів.

Крок 1) Початок Xcode IDE, додавання цільового пакета модульного тестування

Крок 2) Напишіть назву нового пакета модульних тестів як показано на малюнку вище, а потім натисніть кнопку «Готово».

Крок 3) Зробіть модульне тестування активною ціллю

Крок 4) Додайте групу для тестових занять

Крок 5) Додайте клас Unit test

Крок 6) Тепер розпочніть впровадження

OCUnit використовує мову Objective-C для створення тестової програми, тому розробник повинен знати цю мову. Сучасний Xcode версії постачаються одиничне тестування через XCTest, який підтримує як Objective-C, так і Swiftале структура цілі та класу, показана в цих шести кроках, залишається незмінною.

UIAutomation проти XCUITest: що змінилося

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

Аспект	Автоматизація інтерфейсу користувача (інструменти)	XCUITest
Статус	Застаріло в Xcode 8 та видалено з пізніших релізів	Підтримуваний фреймворк для тестування інтерфейсу користувача від Apple
Де тести живуть	Скрипти всередині інструментів tracелектронний документ	Цільовий пакет тестування інтерфейсу користувача всередині Xcode проект
Language	JavaScript	Swift або Objective-C
Випробувальний бігун	Інструмент автоматизації	XCTest, той самий раннер, що й модульні тести
Постійна інтеграція	Незручно — проїжджаючи через інструменти	Запускається з командного рядка разом з модульними тестами
запис	Кнопка запису на панелі інструментів «Інструменти»	Кнопка запису в Xcode редактор, який видає Swift

Практичним наслідком є те, що набір XCUITest — це звичайний вихідний код проекту. Він перевіряється, версіонується та виконується, як і решта кодової бази, що є основною причиною запису-tracмодель зникла.

Як написати тест інтерфейсу користувача iOS за допомогою XCUITest

Сучасний еквівалент восьми кроків інструментів є коротким. Структура нижче відображає ту саму ідею запису-потім-відтворення, але результатом є вихідний файл, а не trace.

Додайте ціль. In Xcode виберіть Файл > Новий > Target та виберіть шаблон UI Testing Bundle або поставте галочку навпроти опції включення тестів під час створення нового проєкту.
Відкрийте згенерований тестовий клас. Xcode створює підклас XCTestCase з порожніми методами налаштування та тестування.
Запустіть тестовану програму. Створіть екземпляр XCUIApplication та викличте для нього функцію запуску, яка запустить додаток в окремому процесі.
Запитуйте та дійте. Отримуйте доступ до елементів через запити елементів — кнопки, таблиці, статичні тексти — та викликайте tap, typeText або свайп по них.
Стверджувати. Використайте XCTAssert, щоб перевірити, чи існує очікуваний елемент після дії.
Запустити. Виконайте тест з Xcode навігатор тестів або з командного рядка, щоб той самий пакет працював у режимі безперервної інтеграції.

Мінімальний тест має таку форму:

import XCTest

final class AppUITests: XCTestCase {

    func testTappingFirstRowShowsDetail() {
        let app = XCUIApplication()
        app.launch()

        // act on the first row of the list
        app.tables.cells.element(boundBy: 0).tap()

        // verify that the next screen appeared
        XCTAssertTrue(app.staticTexts.firstMatch.waitForExistence(timeout: 5))
    }
}

Реєстратор все ще існує: розміщення курсора всередині методу тестування та натискання кнопки запису в редакторі автоматично генерує ці запити, що є прямим нащадком кроку 6 вище. Ширші принципи тестування автоматизації застосовувати без змін.

Зразок автоматизації інтерфейсу користувача Code

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

Зразок автоматизації інтерфейсу користувача — тестовий скрипт для демонстрації автоматизації інтерфейсу користувача.

Поширені запитання

Ні. Xcode а симулятори iOS працюють лише на macOS, тому потрібен Mac або локально, або як розміщена машина для збірки. Хмарні ферми пристроїв та розміщені постачальники неперервної інтеграції існують саме для того, щоб команди без обладнання Mac все ще могли запускати пакет.

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

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

Appium керує iOS за допомогою драйвера XCUITest, який замінив старіший драйвер UIAutomation. Перевагою є одна кросплатформна мова тестування для iOS та Android; компроміс — це додатковий рівень між тестом та власним раннером Apple.

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

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

Кожен тест перезапускає програму та очікує на анімацію. Стабільність покращується, якщо встановлювати ідентифікатори доступності замість зіставлення за мітками, чекати на існування елемента, а не перемикатися в режим очікування.ping, скидати стан між тестами та зосереджувати кожен випадок на одному шляху.

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