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: