Тестване за автоматизация на iOS с Xcode Рамка за потребителски интерфейс

⚡ Умно обобщение

Автоматизирано тестване на iOS с Xcode записва и възпроизвежда действията на потребителския интерфейс спрямо тествано приложение, следвайки цикъл на проектиране, тестване, внедряване и повторно тестване, докато всеки случай премине успешно.

  • 🔘 TDD цикъл: Проектиране, тестване, внедряване и отново тестване формират четирите фази, прилагани при тестването на iOS приложения.
  • ☑️ Необходими условия: Mac с OS X и Xcode Инсталирани са IDE, рамка за автоматизация и iOS SDK.
  • Маршрут на инструментите: Инструментът за автоматизация записва скрипт, показва го в дневника на скриптовете и го възпроизвежда при поискване.
  • 🧪 Маршрут на OCUnit: Цел на пакета за модулни тестове, активна схема, тестова група и тестов клас, написани на Objective-C.
  • ⚠️ Отхвърляне: Инструментът UIAutomation беше остарял през Xcode 8 и е премахнат; XCUITest е поддържаният наследник.
  • 🛠️ Съвременен еквивалент: Целта на UI Testing Bundle плюс XCUIApplication заявки замества записания скрипт Instruments.

Автоматизирано тестване на iOS с Xcode Рамка за автоматизация на потребителския интерфейс, изпълняваща записан скрипт срещу приложение

Използване на тестване за автоматизация на iOS Xcode

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

Цикъл на разработка, управляван от тестове, за автоматизирано тестване на iOS, показващ фазите на проектиране, тестване, внедряване и повторно тестване

Разработка, управлявана от тестове (TDD) е a тестване модел, който се прилага за тестване на iOS приложения и е част от по-широката практика на мобилно тестванеВ този модел, тестерът трябва да следва 4-те фази по-долу:

  • Дизайн: Разберете какво искате да тествате и проектирайте своите тестови случаи.
  • Тест: Изпълнете всички тестове и вижте дали някои от тестовите случаи са неуспешни.
  • Прилагане: RevОптимизирайте кода си и поправете грешките, които са довели до неуспех на теста.
  • Тествайте отново: Ако тестът е неуспешен, връщане към дизайна. Ако всички тестови случаи са успешни, кодът отговаря на цялото тествано изискване.

Настройвам Xcode Проект за тестване на UI

За да създадете тестова програма за iOS, ви е необходим Mac. На вашия Mac вече трябва да е инсталирано следното:

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

⚠️ Бележка към версията: Горните предварителни изисквания описват инструментариума на епохата, в която са написани двете следващи ръководства. На текущ Mac, Xcode Доставя XCTest и XCUITest фреймворците в кутията, а отделният инструмент за UI Automation вече не е част от инсталацията. Оригиналните стъпки са запазени по-долу, защото документират как е работила рамката, а съвременният еквивалент е описан по-долу.

Как да създадете iOS автоматизация с помощта на UI Automation Framework

Осемте стъпки по-долу записват скрипт с инструмента за автоматизация и го възпроизвеждат в тестваното приложение.

Стъпка 1) Стартирайте Инструменти

Отвори XCode -> Отваряне на инструмента за разработчици -> Инструмент

Отваряне на инструменти от Xcode Отваряне на менюто с инструменти за разработчици

Стъпка 2) Добавете инструмент за автоматизация

В прозореца „Инструменти“ изберете инструмента „Автоматизация“.

Избиране на инструмента за автоматизация в селектора на шаблони за инструменти

За да създадете тестов скрипт, трябва да запишете тестов сценарий или го програмирате ръчно.

Стъпка 3) Натиснете червения бутон

Инструментът се включва — спрете записа незабавно. Ако искате да започнете записа, натиснете червения бутон.

Червен бутон за запис в лентата с инструменти „Инструменти“, използван за стартиране и спиране на trace

Стъпка 4) Създайте нов скрипт

В прозореца „Скриптове“ щракнете върху „Добавяне“ > „Създаване“, за да създадете нов скрипт.

Меню „Добавяне“ и „Създаване“ в прозореца „Скриптове на инструменти“ за нов скрипт за автоматизация

Стъпка 5) Изберете целта

Сега сте в Tracпрозорец. Използвайте бутона „Избери“ Target падащо меню, за да отидете до версията за отстраняване на грешки на вашето приложение.

Изберете Target падащо меню в инструментите Tracпрозорец, сочещ към компилацията за дебъгване

В този случай, примерът на Apple SimpleDrillDown приложението се използва като тествано приложение. Неговото графично потребителско име е показано по-долу.

Примерен интерфейс на приложението SimpleDrillDown, използван като тествано приложение

Стъпка 6) Започнете да записвате вашия скрипт

Запишете своя скрипт, като натиснете бутона за запис в горната или долната част на инструмента.

Бутон за запис в края на прозореца „Инструменти“, който стартира заснемането на скрипта

Сега можете да извършите някои действия в потребителския интерфейс на тестваното приложение и вашият скрипт е записан.

Стъпка 7) Вижте вашия скрипт

За да видите вашия скрипт, натиснете Trace Дневник / Дневник на редактора падащо меню и превключете към изгледа на дневника на скрипта.

TracПадащо меню „Дневник“ и „Дневник на редактора“, използвано за превключване към изгледа на дневника на скрипта

Ще видите вашия записан скрипт.

Записан скрипт за автоматизация на потребителския интерфейс, показан в изгледа на лога на скриптовете на инструментите

Стъпка 8) Пуснете вашия скрипт

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

Възпроизвеждане на записания скрипт за автоматизация с лог изход в прозореца „Инструменти“

⚠️ Историческа бележка: Инструментът за автоматизация, използван в тези осем стъпки, беше остарял през Xcode 8 и по-нови версии са премахнати, така че вече не присъстват в текущите Xcode инсталации. Стъпките са запазени тук като запис на това как е работила рамката; за нова работа използвайте ръководството за XCUITest по-надолу на тази страница.

Как да създадете iOS автоматизация с помощта на OCUnit framework

Вторият маршрут поставя тестовете вътре в Xcode самия проект, а не вътре в Instruments.

Стъпка 1) Старт Xcode IDE, Добавяне на цел за пакет за модулни тестове

Добавяне на цел за пакет за модулни тестове към съществуваща Xcode проект

Стъпка 2) Напишете името на новия пакет за модулни тестове както е показано на фигурата по-горе, след което щракнете върху „Готово“.

Стъпка 3) Направете Unit Test активната цел

Избиране на пакета за модулни тестове като активна цел в Xcode

Стъпка 4) Добавяне на група за тестови класове

Създаване на проектна група за провеждане на класовете за модулни тестове на iOS

Стъпка 5) Добавете клас Unit test

Добавяне на нов файл с клас за модулни тестове в тестовата група в Xcode

Стъпка 6) Сега започнете внедряването си

Празен клас за модулни тестове в Xcode редактор, готов за тестовата имплементация

OCUnit използва езика Objective-C за създаване на тестовата програма, така че разработчикът трябва да знае този език. Modern Xcode версиите се доставят модулно тестване чрез XCTest, който поддържа както Objective-C, така и Swift, но структурата „целя-клас“, показана в тези шест стъпки, е непроменена.

UIAutomation срещу XCUITest: Какво се промени

Тъй като и двете използвани по-горе рамки принадлежат към по-ранно поколение на инструментариума на Apple, струва си да бъдем точни относно това какво ги е заменило и защо.

Аспект Автоматизация на потребителския интерфейс (инструменти) XCUITest
Статус Оттеглено от Xcode 8 и премахнато от по-късни издания Поддържана рамка за тестване на потребителски интерфейс от Apple
Къде се намират тестовете Скриптове вътре в инструментите tracелектронен документ Цел на пакет за тестване на потребителски интерфейс вътре в Xcode проект
Език JavaСценарий Swift или Objective-C
Тест бегач Инструментът за автоматизация XCTest, същият бегач като модулните тестове
Непрекъсната интеграция Неловко — задвижвано чрез инструменти Изпълнява се от командния ред заедно с модулни тестове
запис Бутон за запис в лентата с инструменти „Инструменти“ Бутон за запис в Xcode редактор, който излъчва Swift

Практическото следствие е, че XCUITest пакетът е обикновен изходен код на проект. Той се преглежда, версира и изпълнява като останалата част от кодовата база, което е основната причина за записания...tracмоделът изчезна.

Как да напишем iOS UI тест с XCUITest

Съвременният еквивалент на осемте стъпки на инструмента е кратък. Структурата по-долу отразява същата идея за запис и повторно възпроизвеждане, но резултатът е изходен файл, а не trace.

  1. Добавете целта. In Xcode изберете Файл > Нов > Target и изберете шаблона UI Testing Bundle или отметнете опцията за включване на тестове при създаване на нов проект.
  2. Отворете генерирания тестов клас. Xcode създава подклас XCTestCase с празни методи за настройка и тестване.
  3. Стартирайте тестваното приложение. Създайте екземпляр на XCUIApplication и извикайте launch върху него, което стартира приложението в отделен процес.
  4. Запитване и действие. Достигайте до елементи чрез заявки за елементи — бутони, таблици, статични текстове — и ги извиквайте чрез tap, typeText или плъзгане.
  5. Твърдя. Използвайте XCTAssert, за да проверите дали очакваният елемент съществува след действието.
  6. Пусни. Изпълнете теста от 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

Тази статия включва някои примери за изходен код. Те ще ви помогнат да разберете урока по-ясно и бързо.

Пример за автоматизация на потребителския интерфейс — тестов скрипт за демонстрацията на UI Automation.

Въпроси и Отговори

Не. Xcode и iOS симулаторите работят само на macOS, така че е необходим Mac или локално, или като хоствана машина за изграждане. Ферми от облачни устройства и доставчици на хоствана непрекъсната интеграция съществуват именно за да могат екипи без Mac хардуер все още да изпълняват пакета.

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

Той се справя добре с повтарящите се части - скелето на тестови класове, аргументите за стартиране, обвивките на обекти на страници и шаблоните за твърдения. Идентификаторите на елементи все още трябва да съответстват на реалното приложение, така че всяка генерирана заявка се нуждае от проверка спрямо работещата компилация, преди да бъде доверена.

Appium управлява iOS чрез своя XCUITest драйвер, който замени по-стария драйвер UIAutomation. Предимството е един междуплатформен език за тестване за iOS и Android; компромисът е допълнителен слой между теста и собствения бегач на Apple.

Единичен тест се изпълнява вътре в процеса на приложението и извиква вашия код директно. UI тестът стартира приложението като отделен процес и взаимодейства само чрез интерфейса, така че е по-бавен, но валидира това, което потребителят действително преживява.

Симулаторите са по-бързи и фини за повечето функционални потоци в един конвейер. Необходими са реални устройства за камера, биометрия, push известия, производителност и всичко, което е свързано с хардуерни сензори, така че повечето екипи изпълняват и двете в различни точки от цикъла.

Всеки тест рестартира приложението и изчаква анимации. Стабилността се подобрява, когато задавате идентификатори за достъпност вместо съпоставяне по етикети, изчаквате съществуването на елементи, вместо да спите.ping, нулирайте състоянието между тестовете и фокусирайте всеки случай върху едно пътуване.

Не директно, защото езиците и моделите на елементите се различават. Обичайният път е да се запазят старите скриптове като документация за предвиденото покритие, след което всеки сценарий да се пренапише като XCUITest случай, започвайки с пътешествията, които най-често се провалят в продукцията.

Обобщете тази публикация с: