Cloud-alapú app tesztelés bevezetése
Tapasztalataink a Calabash és Xamarin Test Cloud párossal
Régi vágyunk volt, hogy:
- le legyenek fedve funkcionális automata tesztekkel az alkalmazásaink,
- a teszteket tudjuk fizikai eszközökön futtatni,
- és képesek legyünk egy cloud szolgáltatáson keresztül több száz fizikai eszközön megismételni ugyanezt.
Ebben a posztban arról lesz szó, hogyan sikerült megvalósítani a fentieket.
Ok, de miért is fontos ez?
Egyre több olyan mobilappot fejlesztünk, ami komplex felépítésű, nemzetközi piacra készül, és havonta akár több százezer aktív felhasználót is elér, akik a legkülönbözőbb készülékeket és oprendszereket használják. Ilyen nagyságrendnél már egy piaci viszonylatban észrevehetetlen, 0.1%-ban használt eszköz is havi szinten több ezer user sessiont jelenthet, ami nem kis fejfájást okoz, ha esetleg egy bug átcsúszik a manuális teszten.
Habár több tucatnyi tesztkészülékünk van, melyek méretben és erősségben is pont megfelelnek az aktuális statisztikáknak, de ezt a poolt rendszeresen frissítenünk kell, és egyszerűen képtelenség 100%-os lefedettséget biztosítanunk — na meg nincs is túl sok értelme.
Viszont pont erre valók azok a cloud-alapú szolgáltatások, amik abból élnek, hogy több száz készüléket tartanak, és ezeket használhatod automata tesztek futtatására –úgy, hogy az egész folyamatról képek, videók és pontos reportok is készülnek. Elég menő.
Mivel nagyon szerettünk volna eljutni idáig, ezért elkezdtünk kísérletezni a BDD-vel, valamint megvizsgáltuk a piacon elérhető felhőalapú tesztplatformokat, hogy végül megalapozottan választhassuk ki a végső befutót, amire megéri berendezkedni hosszabb távon is.
A cél pontosítása
A CI workflow-nk (amiről az előző posztban írtunk) kialakítása során azt is felírtuk a wishlistre, hogy az elkészült buildeken a statikus kódelemzés és unit tesztek lefutása után automatizált funkcionális tesztekkel kiszűrhessük a hibákat még az app kiadása előtt.
Ehhez olyan eszközt akartunk választani, amiben a test scriptek egyaránt futtathatóak házon belül a build szervereinken, valamint módosítás nélkül egy felhőalapú szolgáltatásban is.
Célunk volt a manuális regressziós tesztelésre fordított idő (közel nullára) csökkentése, és az, hogy a fejlesztéseinket a házon belül rendelkezésre álló fizikai eszközökön túl egy sokkal nagyobb, szintén valódi készülékeket magába foglaló device poolon is futtatni tudjuk, mielőtt userek tömegei számára elérhetővé tennénk egy újabb release-t.
De szintén hasznos egy ilyen eszköz akkor is, mikor egy legacy appot kell átvennünk és továbbfejlesztünk, ami természetesen bizonyos szintű refaktorálással jár — ilyen esetekben is egyből az érintett funkciókhoz kapcsolódó tesztekkel kezdünk.
Kell egy BDD tool
Mint ahogy a többi alkalmazott eszköz kiválasztása során, úgy ez esetben is alaposan körbejártuk és összehasonlítottuk az elérhető megoldási lehetőségeket.
Számunkra az alábbi szempontok voltak a legfontosabbak:
- Cross-platform megoldás legyen (egyformán kezelje a két legnagyobb mobil platformot).
- Az elkészült tesztek futtathatóak legyenek lokálisan és olyan felhőalapú szolgáltatásokban is, amelyek fizikai eszközöket használnak.
- Lehetőleg ne kelljen a feladatra külön Java, Swift, Objective-C, PHP, JS, Python vagy C# fejlesztőket allokálni, a tesztek írása legyen haladós, ha megoldható, maradjon QA-n belül a task.
- A tesztírásban is megvalósítható legyen a cross-platform megközelítés: egy test script kezelje mindkét platformot.
- A folyamat jól riportolható legyen, vagy még jobb, ha a collaborative testing irányában is körvonalazódnak lehetőségek, melynek a megvalósítása egy későbbi célunk.
- A kód újrafelhasználása minél magasabb mértékben megvalósuljon.
Így utólag visszatekintve azért egy kicsit magas elvárásokat támasztottunk az új eszközzel szemben.
Megvizsgáltunk egyébként nem cross-platform megoldásokat is, de ezek alkalmazása a device cloudok kiválasztásánál okozott volna gondot, illetve továbbra sem tartottuk stratégiailag szerencsésnek a két platformon két, egymástól teljesen eltérő irányba történő elindulást.
A feladat QA divízión belül tartásával fenn akartuk tartani azt az állapotot, hogy a fejlesztések funkcionális teszteléséhez ne kelljen fejlesztői erőforrást allokálni — a QA manager harmadik szemként nagyobb eséllyel talál meg logikai bukfenceket, ill. hibákat, valamint szimultán futhat a fejlesztés és a tesztelés.
Melyik felhőalapú szolgáltatást válasszuk?
A test cloudok kiválasztásánál első körben az alábbi szempontokat tartottuk szem előtt:
- fizikailag létező eszközökön futtassa a teszteket;
- kezelje azt a keretrendszert (is), amit lokálisan és a build szervereinken használunk;
- a felhő device poolja nagyrészt illeszkedjen a saját projektjeink analitikájában mért eszközökhöz és OS verziókhoz — annak pl. semmi értelme nem lett volna, ha indiai viszonyokra épülő device poolt használunk, ami pár százalékban egyezik csak az EMEA régióban mért adatokkal;
- legyen group és user management, az ügyfeleink is kaphassanak betekintést a tesztelési folyamatokba (kollaboratív képességek további előnyt jelentenek);
- legyen megfizethető.
A emulátoros/szimulátoros szolgáltatások azért estek ki, mert ezeket a saját szervereinken is meg tudjuk valósítani, ezekért nem akartunk feleslegesen fizetni, valamint a tapasztalataink szerint Android esetében az emulátorokon végzett tesztelés egyébként sem képes komolyan vehető eredményeket visszaadni, és nem tud megfelelő válasz lenni, ha egy ilyen különösen verzió fragmentált piacon végzett tesztelés a cél.
A fenti szempontok alapján már a kutatás kezdetén hamar kiestek a technikailag megbízhatatlan, komolytalan UX/UI-jal vagy elszállt árazással rendelkező megoldások. Már eleve úgy kerestünk teszteszközt, hogy figyeltük a ráépülő szolgáltatásokat is.
Érdemes egyébként folyamatosan monitorozni a piacot, az elmúlt egy-másfél évben is nagyon sok változás történt, új szolgáltatók jelentek meg, egyesek funkciókat bővítettek, a pricing szinte folyamatosan változik mindenhol, és akvizícióból sincs hiány (SeeTest, MonkeyTalk, TestDroid, Xamarin).
Végül a több tucatnyi lehetőséget elég hamar leszűrtük, és már csak az volt a kérdés, hogy a két legkomolyabb játékos közül melyiket válasszuk.
Appium vs. Calabash
Appium is an open source test automation framework for use with native, hybrid and mobile web apps. It drives iOS, Android, and Windows apps using the WebDriver protocol.
http://appium.io/Calabash enables you to write and execute automated acceptance tests of mobile apps. It’s cross-platform, supporting Android and iOS native apps. It’s also open source and free, developed and maintained by Xamarin.
http://calaba.sh/
A témában bőven akad cikk, de a legtöbb csak felületes ismereteken alapszik, és téves információkat közöl, amelyek minket is kicsit elbizonytalanítottak, de végül kipróbáltuk mindkettőt, és a Calabash-t választottuk.
A test drive alatt sikerült megcáfolnunk pár tévhitet is.
Tévhit 1: A Calabash nem kezeli a hibrid appokat.
Kezeli, a WebView-val is elbánik. A webes elemekre hivatkozhatunk CSS-sel, JS-sel és XPath-szal. Nekünk is szükségünk van rá néhány appunkban, ahol WebView-ban jelennek meg third-party szolgáltatók. De találunk cikket, ami ugyanezt a problémát az Appiummal kapcsolatban hozza fel.
Tévhit 2: A Calabash valójában két eszköz, az Appium egy.
Az valóban igaz, hogy a Calabash-nál platformonként telepítenünk kell egy-egy gemet, valamint a használható metódusokban és a query language képességeiben is van némi különbség a két platform között, de ezek közel sem akkora eltérések, amiket ne lehetne elég rövid idő alatt megszokni.
A jelenlegi Calabash gemek fejlesztésével párhuzamosan már zajlik a 2.0-s verzió fejlesztése is, amiben a két platformot összefésülik.
Tévhit 3: A Calabash használatához külön buildeket kell készíteni, Appiummal nem.
Androidon ezt automatikusan megcsinálja a Calabash, a tesztfuttatás megkezdése előtt kiegészíti az APK fájlt egy HTTP szerverrel.
iOS-en már be kell ágyazni egy frameworköt, és új targettel kell lebuildelni az appot, de ez közel sem olyan ördögtől való dolog, mint elsőre hangzik. Pláne, hogy a build szerverünkön a GitLab CI-ban erre van egy külön jobunk, ami a test stage-ben automatikusan elkészíti a kiegészített IPA-t. A fejlesztőknek emiatt külön munkája nincsen.
Tévhit 4: Calabash-ban nincs az Appium Inspectorhoz hasonló megoldás.
GUI-val rendelkező valóban nincs, de van helyette szöveges konzol, amiben ugyanúgy strukturáltan tudunk információkat megjeleníteni az appról, és queryket használva elég hatékonyan tudunk szűrni is.
Mivel ez gyakorlatilag egy IRB Calabash libraryvel, arra is van mód, hogy a snippetjeinket konzolból tesztelgessük, mielőtt beépítenénk a test scriptbe, és az egészet egyben akarnánk futtatni.
Aki az azonosítókat mégis grafikus felületen szeretné kinyerni, az mindettől függetlenül tudja használni az Android Studio UI Automator Viewerét és az Xcode Accessibility Inspectorját is.
Tévhit 5: Az Appiumot használva több nyelven is írhatunk teszteket, de Calabash-sal csak Rubyban kódolhatunk.
Ez szokott lenni a leginkább visszatartó erő, de a valóság összetettebb. Az tény, hogy a Calabash Rubyra épül, de a scriptek írásához közel sincs szükség a nyelv olyan mély ismeretére, mintha ugyanezen nyelven Appiumban akarnánk tesztet írni. A Calabash tesztek írásakor a Calabash API-ban megírt metódusokat kell használnunk. Ha ennél folyamatosan mélyebbre kell nyúlnunk, akkor valamit rosszul csinálunk. De elég csak megnézni egy Ruby nyelven írt scriptet Appiumon és Calabash-on. Melyik az összetettebb?
Test Cloudok
Ami mindenképp a Calabash felé döntötte a mérleg nyelvét, az az, hogy különösebb fejlesztői tapasztalat nélkül is gyorsan megtanulható és használható, míg az Appium egy sokkal komplexebb, és fejlesztői alaptudást igénylő eszköz.
Működésben és árban komolyan vehető, Appiumot támogató test cloud szolgáltatások a következők:
- Sauce Labs (az Appium fejlesztője)
- Amazon Web Services Device Farm
A Calabash-t pedig az alábbi két rendszer kezeli:
A Sauce Labs megoldása sajnos csak emulátorokkal és szimulátorokkal dolgozik, így elég hamar kiesett, az AWS Device Farmja pedig Calabash platformon a Xamarin Test Clouddal történt összehasonlításban maradt alul.
2016. március vége óta a TestObject is használható Appiummal, aki most kezd neki, annak érdemes azzal is futnia egy kört, de még így is drágább a szolgáltatás a Xamarin TC-nál, jóval kevesebb eszközük van, és funkcionálisan sem biztos, hogy képesek ugyanazt a szintet nyújtani.
Amazon Device Farm tapasztalatok
Nagyon sokáig úgy voltunk vele, hogy az Amazon megoldása lesz a befutó, egyrészt az árazása, másrészt — őszintén — a brand súlya miatt, de végül sajnos csalódnunk kellett:
- A teszteket nagyobb device poolon futtatva az eszközök átlag 15–20%-án fals hibákat produkál (pl. timeout, gesture probléma, sikertelen telepítések). Megismételve a teszteket az érintett eszközökön, nagy eséllyel hiba nélkül lefut a tesztkészlet. Ez az instabil működés Xamarinnál is előfordul néha, de csak az esetek 1–2%-ában.
- Calabash-ban a test script részeként lehet konfigurálni a futtató környezetre vonatkozó paramétereket is, meghatározni, hogy mi történjen két scenario között, hookokat vagy formattereket beállítani. Ezt viszont teljesen figyelmen kívül hagyja az Amazon, csak a saját support könyvtárával hajlandó futni.
- Egy test runban egy eszközön képes 50–60 percig is pörgetni a számlálót egy olyan hibánál, aminek runtime errorral azonnal meg kéne szakítania a folyamatot — és mivel perc alapon (is) kell fizetni, ezért ez eléggé megdobhatja a havi számlát.
- A UI nem túl kiforrott, hiányzik a user és group management is.
Meglepő, de tényleg nem jó ár-érték arányban (jelenleg) ez a szolgáltatás.
A Calabash és a Xamarin Test Cloud akcióban
Eddig leginkább arról esett szó, hogy a többi lehetőséget miért nem választottuk, most pedig következzen néhány mondat arról, hogy a Calabash-t és a Xamarint miért igen.
Vegetables are good for you
A Calabash tulajdonképpen egy függvénykönyvtár, amely képes kezelni Androidon és iOS-en a natív és hibrid appokat. Tehát egy olyan “robot kéz”, ami konzolból át tud nyúlni a mobilra, és tudja azt irányítani. Segítségével végrehajtható minden olyan interakció, amelyeket manuális tesztelésnél is használunk.
Az összes gesture, tapolás, képernyőforgatás, az elemek létezésének vizsgálata, attribútumainak, tartalmának lekérdezése megvalósítható a Calabash API metódusaival.
Kérhetünk a futtató eszközről is információkat, mint pl. típus, név, felbontás, szoftverkörnyezet és még rengeteg minden egyéb.
Ezeket a metódusokat ún. steppekbe kell foglalnunk Ruby nyelven, amely lépésekből fel fogjuk építeni a scenariókat, majd a teljes tesztkészletet.
Ilyen lépéseket kapunk alapból a telepített gemekhez is, de ezek a konzerv steppek csak kezdésnek jók, a gyakorlatban később nem sok hasznukat fogjuk venni.
Ezekre a Rubyban definiált lépésekre épülnek aztán egy külön rétegként, a szintén plain text formátumú, konkrét lépéseket tartalmazó a .feature fájlok. Ez lényegében egy basic englishben (pontosabban Gherkinben) írt forgatókönyv, amivel megmondjuk, hogy mit is szeretnénk csinálni, a háttérben a step fájlok meg feldolgozzák és valódi parancsokká alakítják az utasításainkat.
(Egy következő bejegyzésben részletesebben is bemutatjuk a Calabash feature fájlok felépítését és használatát.)
Cucumber
Ami pedig a Calabash-ra épülő Ruby és Gherkin állományainkat összefogja és végrehajtja, az a Cucumber. A segítségével futtathatók a tesztek fizikai eszközökön, emulátorokon és szimulátorokon, majd a tesztek eredményéről riportokat is készít.
A három eszköz együttes használatának legnagyobb előnye, hogy a tesztelési folyamatban résztvevők (ügyfelek, menedzserek, tesztelők és fejlesztők) ugyanazon platformon képesek együtt dolgozni. A tesztek bemeneti oldalát jelentő szöveges feature fájlok és a számos output sokféle exportálási lehetőséget kínál, illetve kollaborációs eszközök fejlesztését teszi lehetővé. Az egyik ilyen legígéretesebb fejlesztés a Cucumber Pro.
Egy teszt futása mindenféle varázslat nélkül, lokálisan is futtatható, a géphez csatlakoztatott tesztkészüléken. Az alábbi videón látható egy ilyen futás, valódi tesztekkel, valódi iPhone-on:
Élet a (device) farmon
Miután már vannak helyi gépen futó tesztjeink, csak annyi a dolgunk, hogy parancssorból feltöltjük a Xamarin Test Cloudra őket, és lefuttatjuk a tesztkészletet az összeállított device poolon.
A tesztek eredményéről jól áttekinthető, mutatós riportokat kapunk. Minden tesztlépésről készül screenshot, látjuk a processzor- és memóriahasználatot is.
A projektjeinket és a test runokat csapatokra és szériákra (kvázi branchekre) bonthatjuk, a folyamatban részt vevő szereplőknek pedig egyedi jogosultságokat adhatunk.
Összefoglaló
A Calabash-sal ugyan elég sok nehézségünk adódott a kezdetekben, és a betanulási idő sem volt feltétlenül gyors, de úgy gondoljuk, megérte — a Xamarin Test Clouddal párosítva egy rendkívül sokrétű teszteszközt kaptunk, a tesztelési folyamataink pedig jobbak lettek.
A tesztek technikai felépítéséről és azok hatékony cross-platform alkalmazásáról egy későbbi cikkünkben írunk.
Rólunk
A Mitóban az ügynökségi munkák mellett komoly fejlesztéseket is végzünk, büszkék vagyunk rá, hogy többek közt az OTP Bank, a Magyar Telekom, a Deutsche Telekom, a Wizz Air, a Szerencsejáték Zrt., valamint az izlandi lottótársaság számára szállíthatunk webes és mobil megoldásokat.
http://mito.hu és http://mito.hu/jobs
