Kuvittele, että voisit kirjoittaa skriptejä, jotka toimivat automaattisesti vuorovaikutuksessa iOS-sovelluksesi kanssa, ja pystyä tarkistamaan tulokset. UI Automationin avulla voit. UI Automation on Applen tarjoama työkalu, jolla voit suorittaa iOS-sovelluksellesi korkeatasoisempaa testausta kuin mitä XCTestillä on mahdollista saavuttaa.

1. TESTAAJAN TESTAAJAN TESTAAJAN TESTAAJAN TESTAAMINEN Valkoisen laatikon ja mustan laatikon testaus

Olet ehkä kuullut vertailun valkoisen laatikon testauksesta ja mustan laatikon testauksesta sen suhteen, miten ohjelmistoa voisi testata. Jos nämä käsitteet eivät ole sinulle tuttuja, selitän, miten ne toimivat.

Valkolaatikkotestaus

Kuvittele, että laatikon sisällä toimii ohjelmisto. Valkoisen laatikon testauksen avulla voit nähdä laatikon sisälle ja tarkastella kaikkia ohjelmiston toimintaa koskevia yksityiskohtia ja tehdä sitten valistuneita päätöksiä siitä, miten ohjelmistoa testataan. Kirjoittamiesi testien avulla voit myös päästä syvemmälle ohjelmistoon.

Yksikkötestaus on white box -testausta. Kun kirjoitetaan yksikkötestejä, testaajalla on hienojakoinen pääsy testattavaan koodiin. Testaaja voi itse asiassa kirjoittaa testejä, jotka hyödyntävät testattavaa ohjelmistoa menetelmä- tai yksikkötasolla.

IOS-ohjelmistokehityksessä käytämme XCTest-kehystä tämäntyyppisen testauksen suorittamiseen. Katso toinen kirjoittamani opetusohjelma XCTestin käytön aloittamisesta.

Mustalaatikkotestaus

Mustalaatikkotestauksessa laatikko on läpinäkymätön. Testaaja ei näe laatikon sisälle. Testaaja ei pääse käsiksi eikä tiedä koodipohjan toteutuksesta testien kirjoittamista varten. Sen sijaan testaajan on pakko käyttää sovellusta loppukäyttäjän tavoin olemalla vuorovaikutuksessa sovelluksen kanssa ja odottamalla sen vastausta ja todentamalla tulokset.

Tällaista testausta voidaan toteuttaa ainakin kahdella tavalla.

• Testaajalla, joka suorittaa toistuvasti ja manuaalisesti useita ennalta määriteltyjä vaiheita ja todentaa tulokset visuaalisesti.
• Käyttää erikoistuneita työkaluja sovelluksen testaamiseen API-rajapinnoilla, jotka käyttäytyvät samalla tavalla kuin ihminen toimii vuorovaikutuksessa.

IOS-sovelluskehityksessä Apple tarjoaa työkalun nimeltä UI Automation mustan laatikon testauksen suorittamiseen.

2. Testaajan on tehtävä mustan laatikon testaus. Mikä on UI Automation?

UI Automation on työkalu, jonka Apple tarjoaa ja ylläpitää iOS-sovellusten korkeamman tason automaattiseen testaukseen. Testit kirjoitetaan JavaScriptillä Applen määrittelemän API:n mukaisesti.

Testien kirjoittamista voidaan helpottaa tukeutumalla sovelluksen käyttöliittymäelementtien saavutettavuusmerkintöihin. Älä kuitenkaan huolehdi, jos näitä ei ole määritelty, on olemassa vaihtoehtoja.

UI Automation API:sta puuttuu tyypillinen xUnit-pohjainen formaatti testien kirjoittamiseen. Yksi ero yksikkötestaukseen verrattuna on se, että testaajan on manuaalisesti kirjattava onnistumiset ja epäonnistumiset. UI Automation -testit ajetaan Applen kehittäjätyökalujen mukana tulevan Instruments-työkalun Automation-välineestä. Testit voidaan ajaa iOS-simulaattorissa tai fyysisessä laitteessa.

3. UI-automaatiotestien kirjoittaminen

Vaihe 1: Avaa esimerkkiprojekti

Olen päivittänyt edellisessä iOS-testausoppaassa käytetyn esimerkkiprojektin muutamilla uusilla käyttöliittymäelementeillä, jotka tarjoavat hyödyllisiä koukkuja UI-automaatiotestien lisäämiseen. Lataa projekti GitHubista. Avaa projekti ja suorita sovellus varmistaaksesi, että kaikki toimii odotetulla tavalla. Sinun pitäisi nähdä alla olevan kaltainen käyttöliittymä.

Ennen kuin kirjoitamme testejä, voit kokeilla esimerkkisovellusta tutustuaksesi sen toimintaan. Käyttäjänä voit syöttää tekstiä tekstikenttään ja napauttaa painiketta, jolloin näytöllä näkyy etiketti, joka näyttää käänteisen, syötetyn merkkijonon.

Vaihe 2: Luo käyttöliittymäautomaatiotesti

Nyt kun olet tutustunut esimerkkisovellukseen, on aika lisätä käyttöliittymäautomaatiotesti. UI Automation on työkalu, joka löytyy Instrumentsista. Jos haluat ajaa esimerkkisovelluksen Instrumentsissa, valitse Xcoden valikosta Product > Profile. Valitse Automation työkaluluettelosta.

Instruments-pääikkuna avautuu, ja siinä on valmiina yksi instrumentti, Automation-instrumentti (Automation-instrumentti suorittaa UI Automation -testitapauksia). Näet myös ikkunan alaosassa alueen, joka näyttää tekstieditorilta. Tämä on skriptieditori. Tähän kirjoitat UI Automation -testit. Noudata tätä ensimmäistä testiä varten alla olevia ohjeita lisäämällä jokainen rivi komentosarjaan komentosarjaditorissa.

Aloita tallentamalla viittaus tekstikenttään muuttujaan.

var inputField = target.frontMostApp().mainWindow().textFields();

Aseta tekstikentän arvo.

inputField.setValue("hi");

Varmista, että arvon asettaminen onnistui, ja jos se onnistui, läpäise testi. Hylkää testi, jos se ei ollut.

Vaikka tämä testi on melko triviaali, sillä on arvoa. Olemme juuri kirjoittaneet testin, joka testaa tekstikentän olemassaolon sovelluksen käynnistyksen yhteydessä ja joka testaa, voidaanko tekstikentän arvoksi asettaa satunnainen merkkijono. Jos et usko minua, poista tekstikenttä storyboardista ja suorita testi. Huomaat, että se epäonnistuu.

Tämä testi demonstroi kolme tärkeää osaa UI-automaatiotestien kirjoittamisesta. Ensinnäkin se näyttää, miten päästään käsiksi yksinkertaiseen käyttöliittymäelementtiin, tekstikenttään. Tarkemmin sanottuna käytämme sovelluksen perusnäkymän kaikkien tekstikenttien sanakirjaa target.frontMostApp().mainWindow().textFields() kautta ja etsimme sitten haluamamme tekstikentän etsimällä sen, jonka avain on Input Field. Tämä avain on itse asiassa tekstikentän saavutettavuustunniste. Tässä tapauksessa se on määritelty storyboardissa. Voimme määrittää saavutettavuustunnisteen myös koodissa käyttämällä NSObject:n accessibilityLabel-ominaisuutta.

Sovelluksen pääikkunan, etummaisen sovelluksen ja kohteen käyttäminen on yleistä, kun työskennellään UI-automaation kanssa. Näytän myöhemmin tässä opetusohjelmassa, miten tästä tehdään helpompaa ja vähemmän sanallista.

Toiseksi tämä osoittaa, että voit olla vuorovaikutuksessa näytöllä olevien käyttöliittymäelementtien kanssa. Tässä tapauksessa asetamme tekstikentän arvon, mikä jäljittelee käyttäjää, joka on vuorovaikutuksessa sovelluksen kanssa syöttämällä tekstiä tekstikenttään.

Kolmanneksi esimerkki näyttää myös tekniikan, jolla voidaan tarkistaa, mitä sovelluksessa tapahtuu. Jos arvon asettaminen onnistuu, testi hyväksytään. Jos arvoa ei aseteta, testi epäonnistuu.

Vaihe 3: Testien tallentaminen

Vaikka testien kirjoittaminen skriptieditorissa on kätevää, se muuttuu nopeasti hankalaksi ja vaikeasti ylläpidettäväksi. Jos lopetat Instrumentsin käytön, kaikki tallentamattomat muutokset hylätään. Meidän on tallennettava kirjoittamamme testit. Kopioi ja liitä testisi uuteen asiakirjaan suosikkitekstieditorissasi ja tallenna se. Löydät tässä ohjeessa luodut testit esimerkkiprojektista kohdasta Jumblify/JumblifyTests/AutomationTests.js.

Testin suorittamiseksi valitse keskimmäinen välilehti oikeanpuoleisessa paneelissa skriptieditorin vieressä ja valitse Lisää > Tuo

Sinua pyydetään valitsemaan tuotava skripti. Siirry tallennettuun skriptiin ja tuo se. Voit edelleen muuttaa komentosarjaa komentosarja-editorissa. Kaikki muutokset tallentuvat automaattisesti luotuun ulkoiseen tiedostoon.

Vaihe 4: Painikkeen napauttaminen

Päivitetään testimme testaamaan vuorovaikutusta painikkeen kanssa. Testimme lisää jo tekstiä tekstikenttään, joten meidän tarvitsee vain lisätä koodia painikkeen napauttamiseen. Mietitään ensin, miten painike löydetään näkymästä, jotta sitä voidaan napauttaa. Tähän on ainakin kolme tapaa, ja jokaisella lähestymistavalla on omat kompromissinsa.

Toteutustapa 1

Voidaan napauttaa ohjelmallisesti näytön (X, Y) koordinaattia. Teemme tämän seuraavalla koodirivillä:

target.tap({x: 8.00, y: 50.00});

Minulla ei tietenkään ole aavistustakaan, ovatko nuo edes painikkeen koordinaatit ruudulla, enkä aio murehtia sitä, koska tämä lähestymistapa ei ole oikea työkalu tähän työhön. Mainitsen sen vain, jotta tiedät sen olevan olemassa. Menetelmän tap käyttäminen target:ssä painikkeen naputtamiseen on virhealtista, koska kyseinen painike ei välttämättä ole aina kyseisessä koordinaatistossa.

Menetelmä 2

Painike on mahdollista löytää myös etsimällä pääikkunan painikkeiden joukosta, samalla tavalla kuin pääsimme käsiksi tekstikenttään ensimmäisessä testissä. Sen sijaan, että hakisimme painiketta suoraan näppäimen avulla, voimme hakea pääikkunan painikkeiden joukon ja kovakoodata joukon indeksin saadaksemme viittauksen painikkeeseen.

target.frontMostApp().mainWindow().buttons().tap();

Tämä lähestymistapa on hieman parempi. Emme kovakoodaa koordinaattia, vaan kovakoodaamme array-indeksin painikkeen löytämiseksi. Jos satumme lisäämään sivulle toisen painikkeen, se saattaa vahingossa rikkoa tämän testin.

Toteutustapa 3

Tästä päästään kolmanteen tapaan löytää painike sivulta, jossa käytetään saavutettavuusmerkintöjä. Käyttämällä saavutettavuusmerkintää voimme käyttää painiketta suoraan aivan kuten löytäisimme objektin sanakirjasta avaimen avulla.

target.frontMostApp().mainWindow().buttons().tap();

Mutta jos lisäät yllä olevan rivin skriptiin ja suoritat sen, saat virheilmoituksen.

Tämä johtuu siitä, ettemme ole vielä määritelleet painikkeelle saavutettavuusmerkintää. Voit tehdä sen kääntymällä Xcodeen ja avaamalla projektin storyboardin. Etsi painike näkymästä ja avaa oikealla oleva Identity Inspector (View > Utilities > Identity Inspector). Varmista, että Accessibility (Esteettömyys) on käytössä, ja aseta painikkeen Label (Merkintä) arvoksi Jumblify Button (Jumblify-painike).

Testin suorittamiseksi uudelleen sinun on ajettava sovellus Xcodesta valitsemalla Product > Run (Tuote > Suorita) ja profiloitava sovellus uudelleen valitsemalla Product > Profile (Profiili). Näin testit ajetaan, ja jokaisen testin pitäisi nyt läpäistä.

Vaihe 5: Tarkista sekoitettu merkkijono

Kuten aiemmin mainitsin, sovelluksemme ottaa syötteenä merkkijonon, ja kun käyttäjä napauttaa painiketta, se näyttää käänteisen merkkijonon. Meidän on lisättävä vielä yksi testi varmistaaksemme, että syötetty merkkijono on käännetty oikein. Varmistaaksemme, että UILabel on täytetty oikealla merkkijonolla, meidän on keksittävä, miten viitata UILabel:ään ja tarkistaa sen näyttämä merkkijono. Tämä on yleinen ongelma kirjoitettaessa automaatiotestejä, eli selvittää, miten sovelluksen elementtiin voidaan viitata, jotta sitä koskeva väite voidaan tehdä.

Lähes jokaiselle käyttöliittymäautomaatio-API:n objektille on olemassa metodi logElementTree. Tämä metodi kirjaa tietyn elementin sisäkkäiset elementit. Tämä on erittäin hyödyllistä, kun halutaan ymmärtää sovelluksen elementtien hierarkiaa, ja se auttaa hahmottamaan, miten tiettyyn elementtiin kohdistetaan.

Katsotaan, miten tämä toimii kirjaamalla pääikkunan elementtipuu. Katso seuraavaa koodiriviä.

target.frontMostApp().mainWindow().logElementTree();

Tämän rivin lisääminen testiskriptiin johtaa seuraavaan tulosteeseen:

Kuten näet, UIAWindow:n UIAStaticText-alielementti on UIAStaticText, ja näet myös, että sen nimi on ih, joka sattuu olemaan myös käänteinen merkkijono, joka meidän on tarkistettava. Nyt testimme loppuunsaattamiseksi meidän tarvitsee vain lisätä koodia, jolla pääsemme käsiksi tähän elementtiin ja tarkistamme, että se on läsnä.

Miksi meidän tarvitsee tarkistaa vain, että UIAStaticText-elementti on läsnä? Koska elementin nimi on syötetyn merkkijonon käänteinen merkkijono, sen läsnäolon tarkistaminen vahvistaa, että merkkijono on käännetty oikein. Jos elementtiä ei ole olemassa, kun siihen viitataan nimen – käännetyn merkkijonon – perusteella, se tarkoittaa, että merkkijonoa ei ole käännetty oikein.

4. Tarkista, että elementti on olemassa. Pinnan raapaisu

On niin monia muita tapoja, joilla loppukäyttäjä voi olla vuorovaikutuksessa iOS-laitteen kanssa sovellusta käyttäessään. Tämä tarkoittaa, että on monia muita tapoja, joilla voit käyttää UI Automationia näiden vuorovaikutusten simulointiin. Sen sijaan, että yrittäisin kaapata kattavan luettelon näistä vuorovaikutustapahtumista, ohjaan sinut UI Automationin viitedokumentaatioon.

Kunkin objektityypin, jonka kanssa voit olla vuorovaikutuksessa, voit tarkastella luetteloa kyseisen objektin käytettävissä olevista metodeista. Joillakin metodeilla haetaan objektin attribuutteja, kun taas toisilla simuloidaan kosketusvuorovaikutusta, kuten flickInsideWithOptions UIAWindow:lla UIAWindow.

Session tallentaminen

Kun yrität testata yhä monimutkaisempia sovelluksia UI Automationin avulla, huomaat, että toisinaan on melko työlästä käyttää toistuvasti logElementTree:tä etsimäsi elementin löytämiseksi. Tästä tulee myös työlästä ja monimutkaista sovelluksissa, joissa on monimutkainen näkymähierarkia tai navigointi. Näissä tapauksissa voit käyttää Instrumentsin toista ominaisuutta käyttäjän vuorovaikutuksen tallentamiseen. Vielä hienompaa on se, että Instruments tuottaa UI Automation JavaScript -koodin, jota tarvitaan tallennettujen vuorovaikutusten toistamiseen. Näin voit kokeilla sitä itse.

Instrumentsissa ja kun Automation-instrumentti on valittuna, etsi ikkunan alareunasta tallennus-painiketta.

Jos napsautat tallennus-painiketta, Instruments aloittaa tallennusistunnon alla olevan kuvakaappauksen mukaisesti.

Instruments käynnistää sovelluksesi iOS-simulaattorissa, ja voit olla vuorovaikutuksessa sen kanssa. Instruments luo skriptin vuorovaikutuksesi perusteella reaaliajassa. Kokeile sitä. Pyöritä iOS-simulaattoria, napauta satunnaisiin kohtiin, suorita pyyhkäisyele jne. Se on todella hyödyllinen tapa auttaa tutustumaan käyttöliittymäautomaation mahdollisuuksiin.

Monoliittisen koodipohjan välttäminen

Kuten varmaan voit ennakoida, jos jatkamme samalla menetelmällä luomaamme testitiedostoon lisää testejä, siitä tulee nopeasti vaikeasti ylläpidettävä. Mitä voimme tehdä estääkseen tämän tapahtumisen. Testeissäni teen kaksi asiaa ratkaistakseni tämän ongelman:

• Yksi testi yhdelle funktiolle: Tämä tarkoittaa, että kirjoittamiemme testien on keskityttävä tiettyyn toiminnallisuuden osaan. Annan sille jopa sopivan nimen, kuten testEmptyInputField.
• Ryhmittelen toisiinsa liittyvät testit yhteen tiedostoon: Ryhmittelen myös toisiinsa liittyvät testit samaan tiedostoon. Tämä pitää yhdessä tiedostossa olevan koodin hallittavana. Näin on myös helpompi testata erillisiä toiminnallisuuden osia suorittamalla testit tietyssä tiedostossa. Lisäksi voit luoda master-skriptin, jossa kutsut muissa testitiedostoissa ryhmiteltyjä funktioita tai testejä.

Oheisessa koodinpätkässä tuomme JavaScript-tiedoston, jolloin tuossa JavaScript-tiedostossa olevat funktiot ovat käytettävissämme.

#import "OtherTests.js"

Loppupäätelmä

Tässä oppitunnissa olet oppinut ylempien tasojen testauksen arvon ja sen, miten UI-automaatio voi auttaa täyttämään tämän aukon. Se on yksi työkalu työkalupakkiisi, jonka avulla voit varmistaa, että toimitat luotettavia ja vankkoja sovelluksia.