iOS automatiseringstest med Xcode UI-ramme

⚡ Smart opsummering

iOS-automatiseringstest med Xcode registrerer og afspiller brugergrænsefladehandlinger mod en applikation under test, efter en testdrevet cyklus af design, test, implementering og test igen, indtil alle cases består.

  • 🔘 TDD-cyklus: Design, test, implementer og test igen danner de fire faser, der anvendes i test af iOS-applikationer.
  • ☑️ Forudsætninger: En Mac, der kører OS X med Xcode IDE, et automatiseringsframework og iOS SDK installeret.
  • Instrumentrute: Automatiseringsinstrumentet optager et script, viser det i scriptloggen og afspiller det igen efter behov.
  • 🧪 OCUnit-rute: Et mål for enhedstestbundt, et aktivt skema, en testgruppe og en testklasse skrevet i Objective-C.
  • ⚠️ Udfasning: UIAutomation-instrumentet blev udfaset i Xcode 8 og fjernet; XCUITest er den understøttede efterfølger.
  • 🛠️ Moderne ækvivalent: Et UI Testing Bundle-mål plus XCUIApplication-forespørgsler erstatter det optagede Instruments-script.

iOS-automatiseringstest med Xcode UI Automation-framework, der kører et optaget script mod en app

iOS Automation Test vha Xcode

For at garantere kvaliteten af ​​din iOS-applikation bør du følge den testdrevne udviklingsproces, der er vist i figuren nedenfor.

Testdrevet udviklingscyklus til iOS-automatiseringstest, der viser design-, test-, implementerings- og retestfaser

Testdrevet udvikling (TDD) er en test model, der anvendes til test af iOS-applikationer, og den er en del af den bredere praksis for mobil testI denne model skal en tester følge de 4 faser nedenfor:

  • Design: Find ud af, hvad du vil teste, og design dine testcases.
  • Test: Kør alle tests og se om nogen testcases fejler.
  • Implementere: Revisér din kode og ret de fejl, der forårsagede, at testen mislykkedes.
  • Test igen: Hvis en test mislykkes, vend tilbage til designet. Hvis alle testtilfælde består, opfylder koden hele det testede krav.

Opsætning Xcode Projekt til UI-testning

For at oprette et iOS-testprogram skal du bruge en Mac. Følgende skal allerede være installeret på din Mac:

  • OS X — operativsystemet til en Mac.
  • Xcode IDE — udviklingsværktøjet til iOS.
  • Et automatiseret testframework — UI-automatisering, OCUnit og så videre.
  • iOS SDK 4 eller højere.

⚠️ Versionsnotat: Ovenstående forudsætninger beskriver værktøjskæden fra den æra, hvor de to følgende gennemgange blev skrevet. På en nuværende Mac, Xcode XCTest- og XCUITest-frameworks medfølger i æsken, og det separate UI Automation-instrument er ikke længere en del af installationen. De oprindelige trin er bevaret nedenfor, fordi de dokumenterer, hvordan frameworket fungerede, og den moderne ækvivalent er beskrevet længere nede.

Sådan opretter du iOS Automation ved hjælp af UI Automation Framework

De otte trin nedenfor optager et script med Automation-instrumentet og afspiller det mod den applikation, der testes.

Trin 1) Start Instruments

Åbn XCode -> Åbn udviklerværktøj -> Instrument

Åbningsinstrumenter fra Xcode Åbn menuen Udviklerværktøj

Trin 2) Tilføj automatiseringsinstrument

I vinduet Instrumenter skal du vælge instrumentet Automation.

Valg af automatiseringsinstrumentet i skabelonvælgeren for instrumenter

For at oprette et testscript skal du enten optage en testscenarie eller du programmerer det manuelt.

Trin 3) Tryk på den røde knap

Et instrument starter – stop optagelsen med det samme. Hvis du vil starte optagelsen, skal du trykke på den røde knap.

Rød optageknap i Instruments-værktøjslinjen, der bruges til at starte og stoppe en trace

Trin 4) Opret et nyt script

I Scripts-vinduet skal du klikke på Tilføj > Opret for at oprette et nyt script.

Menuen Tilføj og Opret i vinduet Instrumentscripts for et nyt automatiseringsscript

Trin 5) Vælg målet

Du er nu i Tracvinduet. Brug Vælg-knappen Target rullemenuen for at navigere til fejlfindingsversionen af ​​din app.

Vælg Target rullemenu i Instrumenter TracVinduet peger på debug-buildet

I dette tilfælde Apples prøve SimpleDrillDown app'en bruges som den applikation, der testes. Den har den grafiske brugergrænseflade, der er vist nedenfor.

SimpleDrillDown-eksempelapplikationsgrænseflade brugt som applikationen under test

Trin 6) Start med at optage dit script

Optag dit script ved at trykke på optag-knappen øverst eller nederst i værktøjet.

Optageknap i kanten af ​​Instruments-vinduet, der starter scriptoptagelse

Nu kan du udføre nogle brugergrænsefladehandlinger på din applikation under test, og dit script er optaget.

Trin 7) Se dit script

For at se dit script skal du trykke på Trace Rullemenuen Log / Redigeringslog og skift til scriptlogvisningen.

TracRullemenuen Log og Editor Log bruges til at skifte til scriptlogvisningen

Du vil se dit optagede script.

Optaget UI-automatiseringsscript vist i Instruments-scriptlogvisningen

Trin 8) Spil dit script

Tryk på afspilningsknappen. Scriptet kører, og du kan stoppe det, når logfilerne vises.

Afspilning af det optagede automatiseringsskript med logoutput i instrumentvinduet

⚠️ Historisk bemærkning: Automatiseringsinstrumentet, der blev brugt i disse otte trin, blev udfaset i Xcode 8 og senere fjernet, så den er ikke længere til stede i den nuværende Xcode installationer. Trinene er gemt her som en oversigt over, hvordan frameworket fungerede; for nyt arbejde skal du bruge XCUITest-gennemgangen længere nede på denne side.

Sådan opretter du iOS-automatisering ved hjælp af OCUnit-ramme

Den anden rute placerer testene inden for Xcode projektet selv snarere end inde i Instrumenter.

Trin 1) Start Xcode IDE, Tilføj mål for enhedstestbundt

Tilføjelse af et mål for enhedstestpakke til et eksisterende Xcode projekt

Trin 2) Skriv navnet på den nye enhedstestpakke som vist på figuren ovenfor, og klik derefter på Udfør.

Trin 3) Gør Enhedstest til det aktive mål

Valg af enhedstestpakken som aktivt mål i Xcode

Trin 4) Tilføj en gruppe til testklasser

Oprettelse af en projektgruppe til at afholde iOS-enhedstestklasser

Trin 5) Tilføj en enhedstestklasse

Tilføjelse af en ny enhedstestklassefil i testgruppen i Xcode

Trin 6) Start nu din implementering

Tom enhedstestklasse i Xcode editor klar til testimplementering

OCUnit bruger sproget Objective-C til at oprette testprogrammet, så udvikleren skal kende sproget. Moderne Xcode versioner leveres enhedstest gennem XCTest i stedet, som understøtter både Objective-C og Swift, men mål-og-klasse-strukturen vist i disse seks trin er uændret.

UIAutomation vs. XCUITest: Hvad har ændret sig

Da begge ovennævnte frameworks tilhører en tidligere generation af Apple-værktøjskæden, er det værd at være præcis omkring, hvad der erstattede dem, og hvorfor.

Aspect UI-automatisering (instrumenter) XCUIT Test
Status Udfaset i Xcode 8 og fjernet fra senere udgivelser Apples understøttede UI-testrammeværk
Hvor testene findes Scripts i et instrument trace-dokument Et mål for en UI-testpakke indeni Xcode projekt
Sprog JavaScript Swift eller Objective-C
Testløber Automatiseringsinstrumentet XCTest, den samme runner som enhedstests
Kontinuerlig integration Akavet — drevet gennem instrumenter Kører fra kommandolinjen sammen med enhedstests
Indspilning Optageknap i Instruments-værktøjslinjen Optageknap i Xcode redaktør, som udsender Swift

Den praktiske konsekvens er, at en XCUITest-suite er almindelig projektkildekode. Den gennemgås, versioneres og udføres ligesom resten af ​​kodebasen, hvilket er hovedårsagen til den optagede-tracmodellen forsvandt.

Sådan skriver du en iOS UI-test med XCUITest

Den moderne ækvivalent til de otte instrumenttrin er kort. Strukturen nedenfor afspejler den samme idé om at optage og derefter afspille, men outputtet er en kildefil snarere end en trace.

  1. Tilføj målet. In Xcode vælg Filer > Ny > Target og vælg skabelonen UI Testing Bundle, eller marker muligheden for at inkludere tests, når du opretter et nyt projekt.
  2. Åbn den genererede testklasse. Xcode opretter en XCTestCase-underklasse med tomme opsætnings- og testmetoder.
  3. Start den app, der testes. Opret en XCUIApplication-instans og kald launch på den, hvilket starter appen i en separat proces.
  4. Spørg og handl. Nå elementer via elementforespørgsler — knapper, tabeller, statiske tekster — og kald tryk, skriv tekst eller swipe på dem.
  5. Hævde. Brug XCTAssert til at bekræfte, at det forventede element findes efter handlingen.
  6. Løb. Udfør testen fra Xcode testnavigator, eller fra kommandolinjen, så den samme suite kører i kontinuerlig integration.

En minimal test følger denne form:

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))
    }
}

Optageren findes stadig: når man placerer markøren i en testmetode og trykker på optageknappen i editoren, genereres disse forespørgsler automatisk, hvilket er en direkte efterkommer af trin 6 ovenfor. De bredere principper for automatiseringstest gælder uændret.

Eksempel på UI-automatisering Code

Denne artikel indeholder nogle eksempler på kildekode. De hjælper dig med at forstå vejledningen tydeligere og hurtigere.

Eksempel på UI-automatisering — testscript til UI Automation-demoen.

Ofte Stillede Spørgsmål

Nej. Xcode og iOS-simulatorerne kører kun på macOS, så en Mac er påkrævet enten lokalt eller som en hosted byggemaskine. Cloud-enhedsfarme og hosted CI-udbydere findes netop således, at teams uden Mac-hardware stadig kan køre pakken.

Maskinlæringsmodeller foreslår forespørgsler om erstatning af elementer, når en skærm ændres, gruppering af ustabile fejl efter rodårsag og rangering af hvilke kørsler, der mislykkedes, er ægte regressioner. Dette er vigtigt for brugergrænseflader, hvor små layoutændringer ellers ville ødelægge mange selektorer på én gang.

Den håndterer de gentagne dele godt – testklasse-scaffolding, launch-argumenter, page-object wrappers og assertion boilerplate. Element-id'er skal stadig matche den rigtige app, så hver genereret forespørgsel skal verificeres mod den kørende build, før den er betroet.

Appium driver iOS via sin XCUITest-driver, som erstattede den ældre UIAutomation-driver. Fordelen er ét testsprog på tværs af platforme til iOS og Android; afvejningen er et ekstra lag mellem testen og Apples egen runner.

En enhedstest kører inde i appprocessen og kalder din kode direkte. En brugergrænsefladetest starter appen som en separat proces og interagerer kun via brugergrænsefladen, så den er langsommere, men validerer, hvad brugeren rent faktisk oplever.

Simulatorer er hurtigere og nemmere at bruge til de fleste funktionelle flows i en pipeline. Der er brug for rigtige enheder til kamera, biometri, push-notifikationer, ydeevne og alt, der berører hardwaresensorer, så de fleste teams kører begge dele på forskellige punkter i cyklussen.

Hver test genstarter appen og venter på animationer. Stabiliteten forbedres, når du angiver tilgængelighedsidentifikatorer i stedet for at matche dem på etiketter, venter på elementernes eksistens i stedet for at sove.ping, nulstil tilstand mellem tests, og hold hver sag fokuseret på én rejse.

Ikke direkte, fordi sprogene og elementmodellerne er forskellige. Den sædvanlige metode er at beholde de gamle scripts som dokumentation for den tilsigtede dækning og derefter omskrive hvert scenarie som en XCUITest-sag, startende med de rejser, der oftest fejler i produktionen.

Opsummer dette indlæg med: