Képzelje el, hogy olyan szkripteket írhat, amelyek automatikusan interakcióba lépnek az iOS-alkalmazással, és ellenőrizheti az eredményeket. Az UI Automation segítségével ezt megteheti. Az UI Automation az Apple által biztosított eszköz, amellyel magasabb szintű tesztelést végezhet az iOS-alkalmazásán, mint ami az XCTesttel elérhető.

1. Az UI Automation egy olyan eszköz, amellyel az iOS-alkalmazás tesztelése magasabb szinten végezhető el, mint ami az XCTesttel elérhető. Fehérdobozos versus feketedobozos tesztelés

Hallhatta már a fehérdobozos tesztelés és a feketedobozos tesztelés összehasonlítását azzal kapcsolatban, hogy hogyan tesztelhetünk egy szoftvert. Ha nem ismeri ezeket a fogalmakat, hadd magyarázzam el, hogyan működnek.

White Box Testing

Képzelje el, hogy van egy szoftver, amely egy dobozban fut. A fehérdobozos teszteléssel beleláthat a dobozba, és megnézheti a szoftver működésének minden apró részletét, majd megalapozott döntéseket hozhat a szoftver tesztelésével kapcsolatban. A megírt tesztek segítségével mélyebb szinten is be tudunk nyúlni a szoftverbe.

Az egységtesztelés a fehérdobozos tesztelés. A unit tesztek írása során a tesztelőnek finomszemcsés hozzáférése van a tesztelt kódhoz. A tesztelő tulajdonképpen olyan teszteket írhat, amelyek módszer- vagy egységszinten használják ki a tesztelt szoftvert.

Az iOS szoftverfejlesztésben az XCTest keretrendszert használjuk az ilyen típusú teszteléshez. Tekintse meg egy másik bemutatót, amelyet az XCTest használatának megkezdéséről írtam.

Fekete dobozos tesztelés

A fekete dobozos tesztelésben a doboz átláthatatlan. A tesztelő nem lát bele a dobozba. A tesztelő nem fér hozzá és nem ismeri a kódbázis implementációját, hogy teszteket írjon. Ehelyett a tesztelő arra kényszerül, hogy úgy használja az alkalmazást, mint egy végfelhasználó: interakcióba lép az alkalmazással, megvárja annak válaszát, és ellenőrzi az eredményeket.

Ez a fajta tesztelés legalább kétféleképpen hajtható végre.

• A tesztelő, aki ismételten és kézzel végrehajt egy sor előre meghatározott lépést, és vizuálisan ellenőrzi az eredményeket.
• Speciális eszközök használata az alkalmazás tesztelésére olyan API-kkal, amelyek az emberi interakcióhoz hasonlóan viselkednek.

Az iOS-alkalmazásfejlesztésben az Apple egy UI Automation nevű eszközt biztosít a fekete dobozos tesztelés elvégzésére.

2. A fekete dobozos tesztelés elvégzése. Mi az a UI Automation?

Az UI Automation egy olyan eszköz, amelyet az Apple biztosít és karbantart az iOS-alkalmazások magasabb szintű, automatizált teszteléséhez. A tesztek JavaScriptben íródnak, az Apple által meghatározott API-t betartva.

A tesztek írását megkönnyítheti, ha az alkalmazásban lévő felhasználói felület elemeinek hozzáférhetőségi címkékre támaszkodik. Ne aggódjon azonban, ha ezek nincsenek definiálva, rendelkezésre állnak alternatívák.

Az UI Automation API nem rendelkezik a tesztek írásához szükséges tipikus xUnit-alapú formátummal. Az egyik különbség a unit teszteléssel szemben az, hogy a tesztelőnek kézzel kell naplóznia a sikereket és a hibákat. Az UI Automation tesztek az Apple fejlesztői eszközeivel együtt járó Instruments eszközön belüli Automation eszközből futtathatók. A tesztek futtathatók az iOS-szimulátorban vagy egy fizikai eszközön.

3. UI-automatizálási tesztek írása

1. lépés: A mintaprojekt megnyitása

Az iOS-tesztelésről szóló előző bemutatóban használt mintaprojektet néhány további felhasználói felületelemmel frissítettem, amelyek néhány hasznos horgot biztosítanak az UI-automatizálási tesztek hozzáadásához. Töltse le a projektet a GitHubról. Nyissa meg a projektet, és futtassa az alkalmazást, hogy megbizonyosodjon arról, hogy minden az elvárásoknak megfelelően működik. Az alábbiakban láthatóhoz hasonló felhasználói felületet kell látnia.

Mielőtt bármilyen tesztet írnánk, nyugodtan próbálja ki a mintaalkalmazást, hogy megismerkedjen annak működésével. Felhasználóként szöveget írhat be a szövegmezőbe, és a gombra koppintva megjelenik a képernyőn egy címke, amely a fordított, beírt karakterláncot jeleníti meg.

2. lépés: UI-automatizálási teszt létrehozása

Most, hogy már megismerkedtünk a mintaalkalmazással, itt az ideje, hogy hozzáadjunk egy UI-automatizálási tesztet. Az UI Automation egy eszköz, amely az Instruments-ben található. A mintaalkalmazás futtatásához az Instrumentsben válassza ki az Xcode menüből a Product > Profile menüpontot. Az eszközök listájából válassza az Automation lehetőséget.

A fő Instruments ablak megnyílik, és egyetlen eszköz áll készen a futtatásra, az Automation eszköz (az Automation eszköz UI Automation teszteseteket hajt végre). Az ablak alsó felében egy szövegszerkesztőnek látszó terület is megjelenik. Ez a szkriptszerkesztő. Itt fogja megírni az UI Automation teszteket. Ehhez az első teszthez kövesse az alábbi utasításokat, minden egyes sort a szkriptszerkesztőben adjon hozzá a szkripthez.

Kezdje azzal, hogy a szövegmezőre való hivatkozást egy változóban tárolja.

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

Állítsa be a szövegmező értékét.

inputField.setValue("hi");

Ellenőrizze, hogy az érték beállítása sikeres volt-e, és ha igen, adja át a tesztet. Ha nem így történt, akkor bukja el a tesztet.

Noha ez a teszt meglehetősen triviális, mégis van értéke. Most írtunk egy tesztet, amely az alkalmazás indításakor egy szövegmező jelenlétét vizsgálja, és azt, hogy egy véletlenszerű karakterlánc beállítható-e a szövegmező értékeként. Ha nem hisz nekem, akkor távolítsa el a szövegmezőt a storyboardból, és futtassa a tesztet. Látni fogja, hogy nem sikerül.

Ez a teszt a felhasználói felület automatizálási tesztek írásának három fontos elemét mutatja be. Először is megmutatja, hogyan lehet elérni egy egyszerű felhasználói felület elemet, a szövegmezőt. Konkrétan az alkalmazás alapnézetének összes szövegmezőjét tartalmazó szótárhoz férünk hozzá a target.frontMostApp().mainWindow().textFields() segítségével, majd a Input Field kulcsú szövegmezőt keresve megkeressük a minket érdeklő szövegmezőt. Ez a kulcs valójában a szövegmező elérhetőségi címkéje. Ebben az esetben ez a storyboardban van definiálva. Az elérhetőségi címkét kódban is beállíthatjuk a NSObject accessibilityLabel tulajdonság segítségével.

Az alkalmazás főablakának, a legelöl lévő alkalmazásnak és a célpontnak a megkeresése gyakori, amikor a felhasználói felület automatizálásával dolgozunk. A bemutató későbbi részében megmutatom, hogyan lehet ezt egyszerűbbé és kevésbé hosszadalmassá tenni.

Második lépésként ez azt mutatja, hogy a képernyőn lévő felhasználói felület elemeivel interakcióba léphetünk. Ebben az esetben a szövegmező értékét állítjuk be, imitálva a felhasználó interakcióját az alkalmazással azáltal, hogy szöveget ír be a szövegmezőbe.

Harmadszor pedig a példa egy olyan technikát is mutat, amellyel ellenőrizhetjük, mi történik az alkalmazásban. Ha az értéket sikeresen beállítottuk, a teszt sikeres. Ha az érték nem kerül beállításra, a teszt sikertelen.

3. lépés: A tesztek mentése

Míg a tesztek írása a szkriptszerkesztőben kényelmes, hamar nehézkessé és nehézkesen karbantarthatóvá válik. Ha kilépünk az Instrumentsből, minden el nem mentett változtatás elvetésre kerül. Az általunk írt teszteket el kell mentenünk. Egyszerűen másoljuk be a tesztünket egy új dokumentumba a kedvenc szövegszerkesztőnkben, és mentsük el. Az ebben az útmutatóban létrehozott teszteket a mintaprojektben találja a Jumblify/JumblifyTests/AutomationTests.js alatt.

A teszt futtatásához válassza a jobb oldali ablaktábla középső fülét a szkriptszerkesztő mellett, és válassza az Add > Import.

A program felkéri az importálandó szkript kiválasztására. Navigáljon a mentett szkripthez, és importálja azt. A szkriptet továbbra is módosíthatja a szkriptszerkesztőben. A módosítások automatikusan el lesznek mentve a létrehozott külső fájlba.

4. lépés: A gomb megérintése

Frissítsük a tesztünket, hogy teszteljük a gombbal való interakciót. A tesztünk már hozzáteszi a szöveget a szövegmezőhöz, így csak a gomb megérintéséhez kell kódot hozzáadnunk. Először is nézzük meg, hogyan találjuk meg a gombot a nézetben, hogy meg lehessen koppintani. Ezt legalább háromféleképpen érhetjük el, és mindegyik megközelítésnek megvannak a maga kompromisszumai.

1. megközelítés

A képernyő egy (X, Y) koordinátáját programozottan megérinthetjük. Ezt a következő kódsorral tehetjük meg:

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

Nem tudom persze, hogy ezek egyáltalán a képernyőn lévő gomb koordinátái-e, és nem is fogok ezzel foglalkozni, mert ez a megközelítés nem a megfelelő eszköz erre a feladatra. Csak azért említem meg, hogy tudd, hogy létezik. A tap módszer használata a target gomb megérintésére hibakockázatos, mert az a gomb nem biztos, hogy mindig azon a bizonyos koordinátán van.

Módszer 2

A gombot a főablak gombjainak tömbjében való kereséssel is meg lehet találni, hasonlóan ahhoz, ahogyan az első tesztben a szövegmezőt is elértük. Ahelyett, hogy közvetlenül egy billentyűvel érnénk el a gombot, lekérdezhetjük a főablak gombjainak tömbjét, és keményen kódolhatunk egy tömbindexet a gombra való hivatkozáshoz.

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

Ez a megközelítés egy kicsit jobb. Nem keményen kódolunk egy koordinátát, hanem keményen kódolunk egy tömbindexet, hogy megtaláljuk a gombot. Ha véletlenül egy másik gombot is hozzáadunk az oldalhoz, az véletlenül megszakíthatja ezt a tesztet.

3. megközelítés

Ez elvezet a harmadik módszerhez, hogy megtaláljuk a gombot az oldalon, az elérhetőségi címkék használatával. Az elérhetőségi címke használatával közvetlenül elérhetjük a gombot, ahogyan egy kulcs segítségével keresünk egy objektumot egy szótárban.

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

Ha azonban a fenti sort hozzáadjuk a szkripthez, és futtatjuk, hibát kapunk.

Ez azért van, mert még nem definiáltuk a gomb elérhetőségi címkéjét. Ehhez lapozzunk át az Xcode-ra, és nyissuk meg a projekt storyboardját. Keressük meg a gombot a nézetben, és nyissuk meg a jobb oldali Identity Inspectort (View > Utilities > Identity Inspector). Győződjön meg róla, hogy a Hozzáférhetőség engedélyezve van, és állítsa a gomb Címkéjét Jumblify Button-ra.

A teszt újbóli futtatásához az Xcode-ból a Termék > Futtatás, majd a Termék > Profil kiválasztásával ismét profilozza az alkalmazást. Ez lefuttatja a teszteket, és most már mindegyik tesztnek át kell mennie.

5. lépés: A zűrzavaros karakterlánc ellenőrzése

Amint korábban említettem, alkalmazásunk egy szöveges karakterláncot fogad bevitelként, és amikor a felhasználó megérinti a gombot, megjeleníti a fordított karakterláncot. Még egy tesztet kell hozzáadnunk, hogy ellenőrizzük, hogy a bemeneti karakterlánc megfelelően felcserélődött. Annak ellenőrzéséhez, hogy a UILabel a helyes karakterláncot tartalmazza, ki kell találnunk, hogyan hivatkozhatunk a UILabel-ra, és hogyan ellenőrizhetjük a megjelenített karakterláncot. Ez egy gyakori probléma az automatizálási tesztek írásakor, vagyis annak kitalálása, hogyan hivatkozzunk egy elemre az alkalmazásban, hogy állítást tegyünk rá.

A UI Automation API szinte minden objektumán van egy metódus, a logElementTree. Ez a metódus naplózza egy adott elem beágyazott elemeit. Ez nagyon hasznos az alkalmazásban lévő elemek hierarchiájának megértéséhez, és segít kitalálni, hogyan célozzunk meg egy adott elemet.

Nézzük meg, hogyan működik ez a főablak elemfájának naplózásával. Nézzük meg a következő kódsort.

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

Ha ezt a sort hozzáadjuk a tesztszkripthez, a következő kimenetet kapjuk:

Amint látható, van egy UIAStaticText aleleme a UIAWindow-nek, és az is látható, hogy a neve ih, ami történetesen a fordított karakterlánc is, amit ellenőriznünk kell. Most a tesztünk befejezéséhez már csak kódot kell hozzáadnunk, hogy hozzáférjünk ehhez az elemhez, és ellenőrizzük, hogy jelen van-e.

Miért csak azt kell ellenőriznünk, hogy a UIAStaticText elem jelen van-e? Mivel az elem neve a bemeneti karakterlánc megfordított karakterlánca, jelenlétének ellenőrzése megerősíti, hogy a karakterlánc helyesen lett megfordítva. Ha az elem nem létezik, amikor a név – a megfordított karakterlánc – alapján hivatkozunk rá, akkor ez azt jelenti, hogy a karakterláncot nem fordítottuk meg helyesen.

4. Az elem nem létezik. A felszínt kapargatva

A végfelhasználó sok más módon is interakcióba léphet egy iOS-eszközzel, miközben az alkalmazást használja. Ez azt jelenti, hogy sok más módon is használhatja az UI-automatizálást ezen interakciók szimulálására. Ahelyett, hogy megpróbálnám megragadni ezeknek az interakcióknak az átfogó listáját, inkább az UI Automation referenciadokumentációhoz irányítom Önt.

Minden olyan objektumtípus esetében, amellyel interakcióba léphet, megtekintheti az adott objektumon elérhető metódusok listáját. Egyes metódusok az objektummal kapcsolatos attribútumok lekérdezésére szolgálnak, míg mások az érintéses interakció szimulálására, mint például a flickInsideWithOptions a UIAWindow-nél.

Munkamenet rögzítése

Amint egyre bonyolultabb alkalmazásokat próbál tesztelni az UI Automation segítségével, rájön, hogy néha elég fárasztó a logElementTree ismételt használata a keresett elem megtalálására. Ez szintén fárasztóvá és bonyolulttá válik az összetett nézethierarchiával vagy navigációval rendelkező alkalmazások esetében. Ezekben az esetekben az Instruments egy másik funkcióját használhatja a felhasználói interakciók egy sorának rögzítésére. Ami még jobb, hogy az Instruments generálja a UI Automation JavaScript kódját, amely a rögzített interakciók reprodukálásához szükséges. Íme, hogyan próbálhatod ki magad:

Az Instrumentsben és az Automation eszköz kiválasztásával keresd meg a felvétel gombot az ablak alján.

Ha rákattintasz a felvétel gombra, az Instruments elindít egy felvételi munkamenetet, ahogy az alábbi képernyőképen látható.

Az Instruments elindítja az alkalmazásodat az iOS-szimulátorban, és interakciókat tudsz vele végezni. Az Instruments valós időben generál egy szkriptet az Ön interakciói alapján. Próbálja ki! Forgassa az iOS-szimulátort, koppintson véletlenszerű helyekre, hajtson végre egy swipe gesztust stb. Ez egy igazán hasznos módja annak, hogy segítsen felfedezni a felhasználói felület automatizálásában rejlő lehetőségeket.

A monolitikus kódbázis elkerülése

Amint azt valószínűleg előre láthatjuk, ha továbbra is újabb teszteket adunk hozzá az azonos módszerrel létrehozott tesztfájlhoz, az hamarosan nehezen karbantarthatóvá válik. Mit tehetünk, hogy ezt megakadályozzuk. Az én tesztjeimben két dolgot teszek, hogy megoldjam ezt a problémát:

• Egy teszt egy függvényhez: Ez azt jelenti, hogy az általunk írt teszteknek a funkcionalitás egy adott darabjára kell összpontosítaniuk. Még megfelelő nevet is adok neki, például testEmptyInputField.
• Összefüggő teszteket csoportosítok egy fájlban: A kapcsolódó teszteket is ugyanabban a fájlban csoportosítom. Ezáltal az egy fájlban lévő kód kezelhető marad. Ez megkönnyíti a funkcionalitás különálló darabjainak tesztelését is azáltal, hogy a teszteket egy adott fájlban hajtjuk végre. Ezenkívül létrehozhat egy mesterszkriptet, amelyben meghívja a más tesztfájlokban csoportosított függvényeket vagy teszteket.

A következő kódrészletben importálunk egy JavaScript-fájlt, és ez elérhetővé teszi számunkra az abban a JavaScript-fájlban lévő függvényeket.

#import "OtherTests.js"

Következtetés

Ezzel a bemutatóval megtanulta a magasabb szintű tesztelés értékét, és azt, hogy az UI-automatizálás hogyan segíthet betölteni ezt a hiányt. Ez egy újabb eszköz az eszköztárában, amely segít biztosítani a megbízható és robusztus alkalmazások szállítását.