iOS automatiseringstesting med Xcode UI-rammeverk

⚡ Smart oppsummering

iOS-automatiseringstesting med Xcode registrerer og spiller av brukergrensesnitthandlinger mot en applikasjon under test, etter en testdrevet syklus med design, test, implementering og testing igjen til alle tilfeller er bestått.

  • 🔘 TDD-syklus: Design, test, implementer og test igjen fra de fire fasene som brukes i testing av iOS-applikasjoner.
  • ☑️ Forutsetninger: En Mac som kjører OS X med Xcode IDE, et automatiseringsrammeverk og iOS SDK installert.
  • Instrumentrute: Automatiseringsinstrumentet registrerer et skript, viser det i skriptloggen og spiller det av på nytt på forespørsel.
  • 🧪 OCUnit-rute: Et enhetstestpakkemål, et aktivt skjema, en testgruppe og en testklasse skrevet i Objective-C.
  • ⚠️ Avskrivning: UIAutomation-instrumentet ble avviklet i Xcode 8 og fjernet; XCUITest er den støttede etterfølgeren.
  • 🛠️ Moderne ekvivalent: Et UI-testpakkemål pluss XCUIApplication-spørringer erstatter det innspilte Instruments-skriptet.

iOS-automatiseringstesting med Xcode UI Automation-rammeverket som kjører et innspilt skript mot en app

iOS-automatiseringstesting ved hjelp av Xcode

For å garantere kvaliteten på iOS-applikasjonen din, bør du følge den testdrevne utviklingsprosessen som vises i figuren nedenfor.

Testdrevet utviklingssyklus for iOS-automatiseringstesting som viser design-, test-, implementerings- og retestfaser

Testdrevet utvikling (TDD) er en testing modell som brukes til testing av iOS-applikasjoner, og den ligger innenfor den bredere praksisen med mobil testingI denne modellen må en tester følge de fire fasene nedenfor:

  • Design: Finn ut hva du vil teste og design testtilfellene dine.
  • Test: Kjør alle tester og se om noen testtilfeller feiler.
  • Implementere: Revise koden din og fikse feilene som forårsaket at testen mislyktes.
  • Test igjen: Hvis en test mislykkes, gå tilbake til designet. Hvis alle testtilfeller består, oppfyller koden hele det testede kravet.

Setter opp Xcode Prosjekt for UI-testing

For å opprette et iOS-testprogram trenger du en Mac. Mac-en din må allerede ha følgende installert:

  • OS X – operativsystemet for en Mac.
  • Xcode IDE — utviklingsverktøyet for iOS.
  • Et automatisert testrammeverk — UI-automatisering, OCUnit og så videre.
  • iOS SDK 4 eller høyere.

⚠️ Versjonsmerknad: Forutsetningene ovenfor beskriver verktøykjeden fra den tiden de to gjennomgangene som følger ble skrevet i. På en nåværende Mac, Xcode XCTest- og XCUITest-rammeverkene følger med i esken, og det separate UI-automatiseringsinstrumentet er ikke lenger en del av installasjonen. De opprinnelige trinnene er bevart nedenfor fordi de dokumenterer hvordan rammeverket fungerte, og den moderne ekvivalenten er beskrevet lenger nede.

Hvordan lage iOS-automatisering ved hjelp av UI Automation Framework

De åtte trinnene nedenfor spiller inn et skript med automatiseringsinstrumentet og spiller det av mot applikasjonen som testes.

Trinn 1) Start Instruments

Åpne XCode -> Åpne utviklerverktøyet -> Instrument

Åpningsinstrumenter fra Xcode Åpne Utviklerverktøy-menyen

Trinn 2) Legg til automatiseringsinstrument

I Instrumenter-vinduet velger du Automatiseringsinstrumentet.

Velge automatiseringsinstrumentet i instrumentmalvelgeren

For å lage et testskript, må du enten spille inn en testscenario eller du programmerer det manuelt.

Trinn 3) Trykk på den røde knappen

Et instrument starter – stopp opptaket umiddelbart. Hvis du vil starte opptaket, trykker du på den røde knappen.

Rød opptaksknapp i Instruments-verktøylinjen som brukes til å starte og stoppe en trace

Trinn 4) Lag et nytt skript

I Skript-vinduet klikker du på Legg til > Opprett for å opprette et nytt skript.

Legg til og Opprett-menyene i Instrumentskript-vinduet for et nytt automatiseringsskript

Trinn 5) Velg målet

Du er nå i Trace-vinduet. Bruk Velg-knappen Target rullegardinmenyen for å navigere til feilsøkingsversjonen av appen din.

Velg Target rullegardinmeny i Instrumenter TracVinduet som peker på feilsøkingsbygget

I dette tilfellet Apples eksempel SimpleDrillDown appen brukes som applikasjonen som testes. Den har det grafiske brukergrensesnittet som er vist nedenfor.

SimpleDrillDown-eksempelgrensesnittet brukt som applikasjonen under test

Trinn 6) Begynn å spille inn skriptet ditt

Ta opp skriptet ditt ved å trykke på opptaksknappen øverst eller nederst i verktøyet.

Opptaksknapp i kanten av Instruments-vinduet som starter skriptopptak

Nå kan du utføre noen brukergrensesnitthandlinger på applikasjonen din under testing, og skriptet ditt er registrert.

Trinn 7) Se skriptet ditt

For å se skriptet ditt, trykk på Trace Logg / Redigeringslogg-rullegardinmenyen og bytt til skriptloggvisningen.

Trace Rullegardinmenyene Logg og Redigeringslogg brukes til å bytte til skriptloggvisningen

Du vil se det innspilte skriptet ditt.

Innspilt UI-automatiseringsskript vist i Instruments-skriptloggvisningen

Trinn 8) Spill av manuset ditt

Trykk på avspillingsknappen. Skriptet kjører, og du kan stoppe det etter at loggene vises.

Avspilling av det innspilte automatiseringsskriptet med loggutdata i Instruments-vinduet

⚠️ Historisk notat: Automatiseringsinstrumentet som ble brukt i disse åtte trinnene ble avviklet i Xcode 8 og senere fjernet, så den er ikke lenger tilstede i dagens Xcode installasjoner. Trinnene er beholdt her som en oversikt over hvordan rammeverket fungerte. For nytt arbeid, bruk XCUITest-gjennomgangen lenger ned på denne siden.

Hvordan lage iOS-automatisering ved hjelp av OCUnit-rammeverket

Den andre ruten plasserer testene inne i Xcode projisere seg selv i stedet for inne i Instruments.

Trinn 1) Start Xcode IDE, Legg til enhetstestpakkemål

Legge til et enhetstestpakkemål til et eksisterende Xcode prosjekt

Trinn 2) Skriv navnet på den nye enhetstestpakken som vist i figuren ovenfor, og klikk deretter på Fullfør.

Trinn 3) Gjør enhetstesten til det aktive målet

Velge enhetstestpakken som aktivt mål i Xcode

Trinn 4) Legg til en gruppe for testklasser

Opprette en prosjektgruppe for å holde iOS-enhetstestklassene

Trinn 5) Legg til en enhetstestklasse

Legge til en ny enhetstestklassefil i testgruppen i Xcode

Trinn 6) Start nå implementeringen

Tom enhetstestklasse i Xcode editoren er klar for testimplementering

OCUnit bruker språket Objective-C til å lage testprogrammet, så utvikleren må kunne det språket. Modern Xcode versjoner sendes enhetstesting gjennom XCTest i stedet, som støtter både Objective-C og Swift, men mål-og-klasse-strukturen som vises i disse seks trinnene er uendret.

UIAutomation vs. XCUITest: Hva endret seg

Fordi begge rammeverkene som er brukt ovenfor tilhører en tidligere generasjon av Apple-verktøykjeden, er det verdt å være presis om hva som erstattet dem og hvorfor.

Aspekt UI-automatisering (instrumenter) XCUIT-test
status Utdatert i Xcode 8 og fjernet fra senere utgivelser Apples støttede rammeverk for UI-testing
Hvor testene finnes Skript i et instrument trace-dokument Et mål for en UI-testpakke inne i Xcode prosjekt
Språk JavaScript Swift eller Objective-C
Testløper Automatiseringsinstrumentet XCTest, samme løper som enhetstester
Kontinuerlig integrasjon Klosset — drevet gjennom instrumenter Kjører fra kommandolinjen sammen med enhetstester
Innspilling Opptaksknapp i Instruments-verktøylinjen Opptaksknappen i Xcode redaktør, som sender ut Swift

Den praktiske konsekvensen er at en XCUITest-pakke er vanlig prosjektkildekode. Den blir gjennomgått, versjonert og kjørt som resten av kodebasen, noe som er hovedgrunnen til at den registrerte-tracmodellen forsvant.

Slik skriver du en iOS UI-test med XCUITest

Den moderne ekvivalenten til de åtte instrumenttrinnene er kort. Strukturen nedenfor speiler den samme ideen om å spille inn og deretter spille av på nytt, men resultatet er en kildefil snarere enn en trace.

  1. Legg til målet. In Xcode velg Fil > Ny > Target og velg malen for UI-testingspakken, eller merk av for alternativet for å inkludere tester når du oppretter et nytt prosjekt.
  2. Åpne den genererte testklassen. Xcode oppretter en XCTestCase-underklasse med tomme oppsett- og testmetoder.
  3. Start appen som testes. Opprett en XCUIApplication-instans og kall `launch` på den, som starter appen i en separat prosess.
  4. Spør og handle. Nå elementer gjennom elementspørringene – knapper, tabeller, statiske tekster – og bruk trykk, skriv tekst eller sveip på dem.
  5. Hevde. Bruk XCTAssert til å bekrefte at det forventede elementet finnes etter handlingen.
  6. Løpe. Utfør testen fra Xcode testnavigator, eller fra kommandolinjen slik at den samme suiten kjører i kontinuerlig integrasjon.

En minimal test følger denne formen:

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

Opptakeren finnes fortsatt: å plassere markøren i en testmetode og trykke på opptaksknappen i redigeringsprogrammet genererer disse spørringene automatisk, som er en direkte etterkommer av trinn 6 ovenfor. De bredere prinsippene for automatiseringstesting gjelder uendret.

Eksempel på UI-automatisering Code

Denne artikkelen inneholder noen eksempler på kildekode. De hjelper deg å forstå veiledningen tydeligere og raskere.

Eksempel på UI-automatisering — testskript for demoen av UI-automatisering.

Spørsmål og svar

Nei. Xcode og iOS-simulatorene kjører bare på macOS, så en Mac er nødvendig enten lokalt eller som en hosted byggemaskin. Skybaserte enhetsfarmer og hosted CI-leverandører finnes nettopp slik at team uten Mac-maskinvare fortsatt kan kjøre pakken.

Maskinlæringsmodeller foreslår spørringer om erstatningselementer når en skjerm endres, gruppering av ustabile feil etter rotårsak og rangering av hvilke mislykkede kjøringer er ekte regresjoner. Dette er viktig for brukergrensesnitt, der små layoutendringer ellers ødelegger mange selektorer samtidig.

Den håndterer de repeterende delene bra – stillasene for testklasser, oppstartsargumenter, sideobjekt-innpakninger og standardversjon av påstander. Elementidentifikatorer må fortsatt samsvare med den virkelige appen, så hver genererte spørring må verifiseres mot den kjørende byggingen før den er klarert.

Appium driver iOS gjennom sin XCUITest-driver, som erstattet den eldre UIAutomation-driveren. Fordelen er ett plattformuavhengig testspråk for iOS og Android; avveiningen er et ekstra lag mellom testen og Apples egen runner.

En enhetstest kjører inne i appprosessen og kaller koden din direkte. En brukergrensesnitttest starter appen som en separat prosess og samhandler kun gjennom grensesnittet, så den er tregere, men validerer hva brukeren faktisk opplever.

Simulatorer er raskere og fungerer fint for de fleste funksjonelle flyter i en pipeline. Ekte enheter er nødvendige for kamera, biometri, push-varsler, ytelse og alt som berører maskinvaresensorer, så de fleste team kjører begge deler på forskjellige punkter i syklusen.

Hver test starter appen på nytt og venter på animasjoner. Stabiliteten forbedres når du angir tilgjengelighetsidentifikatorer i stedet for samsvarende etiketter, venter på at elementet eksisterer i stedet for å sove.ping, tilbakestill tilstand mellom tester, og hold hvert tilfelle fokusert på én reise.

Ikke direkte, fordi språkene og elementmodellene er forskjellige. Den vanlige metoden er å beholde de gamle skriptene som dokumentasjon på tiltenkt dekning, og deretter omskrive hvert scenario som et XCUITest-tilfelle, og starte med de reisene som feiler oftest i produksjon.

Oppsummer dette innlegget med: