iOS-automaatiotestaus Xcode Käyttöliittymäkehys

⚡ Älykäs yhteenveto

iOS-automaatiotestaus Xcode tallentaa ja toistaa käyttöliittymän toimintoja testattavassa sovelluksessa testipohjaisen suunnittelu-, testaus-, toteutus- ja uudelleentestaussyklin mukaisesti, kunnes jokainen tapaus läpäisee testin.

  • 🔘 TDD-sykli: Suunnittelu, testaus, toteutus ja testaus uudelleen muodostavat iOS-sovellustestauksen neljä vaihetta.
  • ☑️ Edellytykset: Mac-tietokone, jossa on OS X ja Xcode IDE, automaatiokehys ja iOS SDK asennettuna.
  • Instrumenttien reitti: Automaatiotyökalu tallentaa skriptin, näyttää sen skriptilokissa ja toistaa sen tarvittaessa.
  • 🧪 OCUnit-reitti: Yksikkötestauspaketin kohde, aktiivinen järjestelmä, testiryhmä ja Objective-C:llä kirjoitettu testiluokka.
  • ⚠️ Vanheneminen: UIAutomation-työkalu vanhentui vuonna Xcode 8 ja poistettu; XCUITest on tuettu seuraaja.
  • 🛠️ Nykyaikainen vastine: UI Testing Bundle -kohde ja XCUIApplication-kyselyt korvaavat tallennetun Instruments-skriptin.

iOS-automaatiotestaus Xcode Käyttöliittymän automaatiokehys, joka suorittaa tallennettua komentosarjaa sovellusta vastaan

iOS-automaatiotestaus käyttäen Xcode

iOS-sovelluksesi laadun varmistamiseksi sinun tulee noudattaa alla olevassa kuvassa esitettyä testipohjaista kehitysprosessia.

Testipohjainen kehityssykli iOS-automaatiotestaukselle, joka näyttää suunnittelu-, testaus-, toteutus- ja uudelleentestausvaiheet

Test-Driven Development (TDD) on a testaus malli, jota sovelletaan iOS-sovellustestaukseen, ja se sopii laajempaan käytäntöön mobiilitestausTässä mallissa testaajan on noudatettava seuraavia neljää vaihetta:

  • Suunnittelu: Mieti, mitä haluat testata, ja suunnittele testitapauksesi.
  • Testi: Suorita kaikki testit ja katso, epäonnistuuko jokin testitapaus.
  • toteuttamisessa: RevMuokkaa koodiasi ja korjaa virheet, jotka aiheuttivat testin epäonnistumisen.
  • Testaa uudelleen: Jos testi epäonnistuu, palaa takaisin suunnitteluun. Jos kaikki testitapaukset läpäisevät, koodi täyttää kaikki testatut vaatimukset.

Asettaa Xcode Käyttöliittymän testausprojekti

iOS-testiohjelman luomiseen tarvitset Macin. Macissasi on oltava jo asennettuna seuraavat:

  • OS X – Macin käyttöjärjestelmä.
  • Xcode IDE — iOS:n kehitystyökalu.
  • Automatisoitu testauskehys — Käyttöliittymäautomaatio, OCUnit ja niin edelleen.
  • iOS SDK 4 tai korkeampi.

⚠️ Versiohuomautus: Yllä olevat vaatimukset kuvaavat aikakauden työkaluketjua, jossa seuraavat kaksi läpipeluuohjetta kirjoitettiin. Nykyisessä Macissa Xcode toimitetaan XCTest- ja XCUITest-kehykset pakkauksessa, eikä erillinen käyttöliittymän automaatiotyökalu ole enää osa asennusta. Alkuperäiset vaiheet on säilytetty alla, koska ne dokumentoivat kehyksen toiminnan, ja moderni vastine on kuvattu myöhemmin.

iOS-automaation luominen UI Automation Frameworkin avulla

Alla olevat kahdeksan vaihetta tallentavat skriptin automaatiotyökalulla ja toistavat sen testattavassa sovelluksessa.

Vaihe 1) Käynnistä Instruments

Avaa XCode -> Avaa kehittäjätyökalu -> Instrumentti

Avausinstrumentit Xcode Avaa kehittäjätyökalujen valikko

Vaihe 2) Lisää automaatiolaite

Valitse Instrumentit-ikkunassa Automaatio-instrumentti.

Automaatioinstrumentin valitseminen Instrumentit-mallin valitsimessa

Testiskriptin luomiseksi joko tallenna testiskenaario tai ohjelmoit sen manuaalisesti.

Vaihe 3) Paina punaista painiketta

Instrumentti käynnistyy – lopeta tallennus välittömästi. Jos haluat aloittaa tallennuksen, paina punaista painiketta.

Punainen äänityspainike Instrumentit-työkalurivillä, jota käytetään äänityksen aloittamiseen ja pysäyttämiseen trace

Vaihe 4) Luo uusi skripti

Luo uusi skripti napsauttamalla Skriptit-ikkunassa Lisää > Luo.

Lisää- ja Luo-valikko Instruments Scripts -ikkunassa uutta automaatioskriptiä varten

Vaihe 5) Valitse kohde

Olet nyt kohdassa Tracikkuna. Käytä Valitse-toimintoa Target avattavasta valikosta siirtyäksesi sovelluksesi virheenkorjausversioon.

Valita Target alasvetovalikko Instrumentit-kohdassa Tracikkuna osoittaa debug-koontiversioon

Tässä tapauksessa Applen esimerkki SimpleDrillDown -sovellusta käytetään testattavana sovelluksena. Sen graafinen käyttöliittymä on alla.

Testattavana sovelluksena käytetty SimpleDrillDown-esimerkkisovellusliittymä

Vaihe 6) Aloita käsikirjoituksen tallennus

Tallenna skripti painamalla tallennuspainiketta työkalun ylä- tai alaosassa.

Instrumentit-ikkunan reunassa oleva tallennuspainike, joka käynnistää skriptien tallennuksen

Nyt voit suorittaa joitakin käyttöliittymätoimintoja testattavassa sovelluksessasi, ja skriptisi tallennetaan.

Vaihe 7) Katso käsikirjoituksesi

Näet käsikirjoituksesi painamalla Trace Loki / Muokkausloki -pudotusvalikko ja vaihda komentosarjojen lokinäkymään.

Trace Loki- ja editorilokin pudotusvalikko, jota käytetään skriptilokin näkymään siirtymiseen

Näet tallennetun käsikirjoituksesi.

Tallennettu käyttöliittymän automaatiokomentosarja näkyy Instruments-komentosarjan lokinäkymässä

Vaihe 8) Toista käsikirjoituksesi

Paina toistopainiketta. Skripti suoritetaan, ja voit pysäyttää sen lokien ilmestyttyä.

Tallennetun automaatioskriptin toisto lokitulosteen kanssa Instrumentit-ikkunassa

⚠️ Historiallinen huomautus: Näissä kahdeksassa vaiheessa käytetty automaatiotyökalu vanhentui vuonna Xcode 8 ja myöhemmin poistettu, joten sitä ei enää ole nykyisessä versiossa Xcode asennukset. Vaiheet tallennetaan tähän tallenteena siitä, miten kehys toimi; uusiin töihin käytä XCUITest-läpikäyntiä myöhemmin tällä sivulla.

Kuinka luoda iOS-automaatio OCUnit-kehyksen avulla

Toinen reitti sijoittaa testit sisälle Xcode itse projektissa eikä Instrumentsin sisällä.

Vaihe 1) Aloita Xcode IDE, Lisää yksikkötestauspakettikohde

Yksikkötestauspaketin kohteen lisääminen olemassa olevaan Xcode projekti

Vaihe 2) Kirjoita uuden yksikkötestauspaketin nimi kuten yllä olevassa kuvassa näkyy, ja napsauta sitten Valmis.

Vaihe 3) Tee yksikkötestistä aktiivinen kohde

Yksikkötestauspaketin valitseminen aktiiviseksi kohteeksi Xcode

Vaihe 4) Lisää ryhmä testiluokille

Projektiryhmän luominen iOS-yksikkötestausluokkien järjestämistä varten

Vaihe 5) Lisää yksikkötestiluokka

Uuden yksikkötestausluokkatiedoston lisääminen testiryhmään kohdassa Xcode

Vaihe 6) Aloita nyt toteutus

Tyhjä yksikkötestausluokka kohdassa Xcode editori valmis testikäyttöönottoa varten

OCUnit käyttää Objective-C-kieltä testiohjelman luomiseen, joten kehittäjän on osattava kyseinen kieli. Moderni Xcode versiot toimitetaan yksikkötestaus XCTestin kautta, joka tukee sekä Objective-C:tä että Swift, mutta näissä kuudessa vaiheessa esitetty kohde- ja luokkarakenne pysyy muuttumattomana.

UIAutomation vs. XCUITest: Mikä muuttui

Koska molemmat yllä käytetyt kehykset kuuluvat Applen työkaluketjun aiempaan sukupolveen, on syytä olla tarkka siitä, mikä ne korvasi ja miksi.

Aspect Käyttöliittymän automaatio (instrumentit) XCUITest
Tila Vanhentunut vuonna Xcode 8 ja poistettu myöhemmistä julkaisuista Applen tukema käyttöliittymätestauskehys
Missä testit julkaistaan Instrumenttien sisällä olevat skriptit trace-dokumentti Käyttöliittymätestauspaketin kohde sisällä Xcode projekti
Kieli JavaKäsikirjoitus Swift tai Objective-C
Testijuoksija Automaatiolaite XCTest, sama suoritin kuin yksikkötestit
Jatkuva integraatio Hankala — ajettu instrumenttien läpi Suoritetaan komentoriviltä yksikkötestien rinnalla
Äänite Äänitä-painike Instrumentit-työkalurivillä Tallennuspainike kohdassa Xcode editori, joka tuottaa Swift

Käytännössä tämä tarkoittaa, että XCUITest-paketti on tavallista projektin lähdekoodia. Se tarkistetaan, versioidaan ja suoritetaan kuten muukin koodikanta, mikä on tärkein syy siihen, miksi tallennettu...tracmalli katosi.

Kuinka kirjoittaa iOS-käyttöliittymätesti XCUITest-ohjelmalla

Kahdeksan instrumenttivaiheen moderni vastine on lyhyt. Alla oleva rakenne peilaa samaa äänitä ja toista -ideaa, mutta tulosteena on lähdetiedosto eikä trace.

  1. Lisää kohde. In Xcode valitse Tiedosto > Uusi > Target ja valitse UI Testing Bundle -malli tai valitse vaihtoehto, joka sisällyttää testit uutta projektia luotaessa.
  2. Avaa luotu testiluokka. Xcode luo XCTestCase-aliluokan, jossa on tyhjät setup- ja test-metodit.
  3. Käynnistä testattava sovellus. Luo XCUIApplication-instanssi ja kutsu sille launch-komentoa, joka käynnistää sovelluksen erillisessä prosessissa.
  4. Kysely ja toimi. Saavuta elementtejä elementtikyselyiden – painikkeiden, taulukoiden ja staattisten tekstien – avulla ja käytä niitä napauttamalla, kirjoittamallaText-komennoilla tai pyyhkäisemällä.
  5. Väitä. Käytä XCTAssert-funktiota varmistaaksesi, että odotettu elementti on olemassa toiminnon jälkeen.
  6. Juosta. Suorita testi kohdasta Xcode test navigatorista tai komentoriviltä, ​​jotta sama ohjelmistopaketti toimii jatkuvassa integraatiossa.

Minimaalinen testi noudattaa tätä muotoa:

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

Tallennin on edelleen olemassa: kohdistimen sijoittaminen testimetodin sisään ja tallennuspainikkeen painaminen editorissa luo nämä kyselyt automaattisesti, mikä on suora jälkeläinen yllä olevasta vaiheesta 6. Laajemmat periaatteet automaatiotestaus sovelletaan muuttumattomana.

Käyttöliittymän automaatiosuositus Code

Tämä artikkeli sisältää joitakin lähdekoodiesimerkkejä. Ne auttavat sinua ymmärtämään opetusohjelman selkeämmin ja nopeammin.

Käyttöliittymän automaatiosuositus — testiskripti käyttöliittymän automaation demolle.

UKK

Ei. Xcode ja iOS-simulaattorit toimivat vain macOS, joten Mac vaaditaan joko paikallisesti tai isännöitynä koontikoneena. Pilvilaitefarmit ja isännöidyt CI-palveluntarjoajat ovat olemassa juuri sitä varten, että tiimit, joilla ei ole Mac-laitteistoa, voivat silti suorittaa paketin.

Koneoppimismallit ehdottavat korvaavia elementtikyselyitä näytön muuttuessa, ryhmittelevät epätasaiset virheet perimmäisen syyn mukaan ja luokittelevat epäonnistuneet suoritukset aitoina regressioina. Tällä on merkitystä käyttöliittymäohjelmistoille, joissa pienet asettelun muutokset muutoin rikkovat useita valitsimia kerralla.

Se käsittelee toistuvat osat hyvin – testiluokan telineet, käynnistysargumentit, sivuobjektien kääreet ja väitteiden mallipohjan. Elementtitunnisteiden on silti vastattava todellista sovellusta, joten jokainen luotu kysely on tarkistettava käynnissä olevaa koontiversiota vasten ennen kuin siihen luotetaan.

Appium ohjaa iOS:ää XCUITest-ajurinsa kautta, joka korvasi vanhemman UIAutomation-ajurin. Etuna on yksi alustariippumaton testikieli iOS:lle ja Android; kompromissi on ylimääräinen kerros testin ja Applen oman juoksijan välillä.

Yksikkötesti suoritetaan sovellusprosessin sisällä ja kutsuu koodiasi suoraan. Käyttöliittymätesti käynnistää sovelluksen erillisenä prosessina ja toimii vain käyttöliittymän kautta, joten se on hitaampi, mutta validoi käyttäjän todelliset kokemukset.

Simulaattorit ovat nopeampia ja toimivat hyvin useimmissa toiminnallisissa prosesseissa. Oikeita laitteita tarvitaan kameraa, biometriikkaa, push-ilmoituksia, suorituskykyä ja kaikkea laitteistosensoreita koskettavaa varten, joten useimmat tiimit käyttävät molempia syklin eri vaiheissa.

Jokainen testi käynnistää sovelluksen uudelleen ja odottaa animaatioita. Vakaus paranee, kun asetat esteettömyystunnisteet otsikoiden sijaan ja odotat elementin olemassaoloa lepotilan sijaan.ping, nollaa tila testien välillä ja pidä jokainen tapaus keskittyneenä yhteen asiakaspolkuun.

Ei suoraan, koska kielet ja elementtimallit eroavat toisistaan. Tavallinen tapa on säilyttää vanhat skriptit aiotun kattavuuden dokumentaationa ja sitten kirjoittaa jokainen skenaario uudelleen XCUITest-tapauksena aloittaen niistä poluista, jotka epäonnistuvat useimmiten tuotannossa.

Tiivistä tämä viesti seuraavasti: