Windows asztali alkalmazások tesztelésének automatizálása

• 

Az automatizált tesztek futtatásának előnyei minden szoftvertesztelő számára láthatóak. Az így készült tesztkészletek alkalmasak alkalmazások funkcióinak gyors tesztelésére. Gyakorlatilag egy hatékony konzisztencia ellenőrzést kell megvalósítaniuk. A funkcionális teszt részbeni automatizációjának köszönhetően elkerülhető a tesztelés repetitív feladatokból álló része, mindamellett, hogy teszteléshez szükséges időablak mérete drasztikusan redukálható. Tipikusan ilyen tevékenység az űrlapok beküldése vagy fájlok tömeges feltöltése. A célterület és a tesztelendő alkalmazás funkcionalitása okán korlátokba ütközhetünk. Korlátot azonban az egyes platformok speciális jellege is létrehozhat. A Windows asztali alkalmazások automata tesztelése kihívást rejtő feladat, kiváltképp ingyenes segédalkalmazásokkal, keretrendszerekkel dolgozva. Ez a cikk a Windows asztali alkalmazások black-box módszertannal való tesztelésének lehetséges megoldásait járja körül – bemutatva a feladathoz rendelkezésre álló eszközöket – mind az ingyenesen, mind üzleti csomagban hozzáférhetőeket. Két csoportra oszthatóak az eszközök, felhasználási célterület szerint megkülönböztetünk white-box és black-box teszthez alkalmasakat. Azonban balról jobbra az átjárhatóság bizonyos köztes megoldásokkal részben biztosítható, amire a cikkben példát is hozok.

A Windows asztali alkalmazások csupán egy gyűjtőfogalom, ami számos technológiát foglal magában. Ezek közti választás gyártói oldalról egy kulcsfontosságú része az úgynevezett “vendor lock-in” stratégiának is. A black-box teszteléshez használható eszközöknél az első lépés a tesztelendő alkalmazás és a teszteszköz kompatibilitásának vizsgálata. Elmondható, hogy nem létezik mindig működő recept a Windows alkalmazások tesztelésére, nincsenek olyan jól bevált univerzális eszközök, mint amik a webes alkalmazások tesztelésének eszköztárában szerepelnek. Az eltérő technológiákkal fejlesztett alkalmazásokban megjelenő objektumok azonosításához és tárolásához eltérő megoldásokra van szükség. Ezért is van jelen sok, egy-egy célfeladatra alkalmas eszköz ezen a területen. Sajátosságuk, hogy a webes alkalmazások területén már jól ismert és elterjedten alkalmazott “headless” futtatást nem támogatnak ezen megoldások, hiszen a felületi elemek emulálása azok megjelenítése nélkül nem megvalósítható. A következő fejezetben sorra veszem azokat az eszközöket, amelyekkel egy tesztelő találkozhat blogokban, cikkekben, összehasonlításokban, bemutatva a keretrendszerek és segédeszközök alapvető természetét és lehetséges felhasználási területét.

A bemutatásra kerülő tesztelési keretrendszerek rendelkeznek a kulcsszó alapú automatizálás lehetőségével. A módszer lényege, hogy nem szkripteken alapul, hanem a futtatás kulcsszavak alapján történik, amik közvetetten hívják meg a szkripteket. Így biztosított a kódok újrafelhasználhatósága is. Az eszközöknek így mindegyike a tesztelési keretrendszerek evolúciójának a negyedik lépcsőfokán áll. Elengedhetetlen, hogy olyan automatizáló eszközt válasszunk, amely a csapat produktivitását maximalizálja, a szükséges funkciókat biztosítja, emellett azonban nem köti meg a tesztelő kezét felesleges konvenciókkal. A tesztelési módszertan előzetes átgondolása nagyon fontos ehhez. A tesztelés hatékonyságának növeléséhez elsődleges szempont a megfelelő tesztesetek létrehozása.

Elérhető szoftver megoldások a tesztelés gyakorlati kivitelezéséhez:

Az eszközök nagy hátránya, hogy általánosságban csak 1-1 GUI technológiát támogatnak, így AWT, SWT vagy csak Swing Java esetleg JavaFX alkalmazások teszteléséhez ideálisak. A rendszerek nagy része a webes alkalmazások tesztelésénél jól bevált Selenium megoldásán alapszik, annak egy adaptációja..

A Windows Application Driver a Microsoft keretrendszere UWP és Win32 alkalmazások tesztelésére, azonban csak Windows 10 alatt használható.

A Coded UI tesztek Visual Studio komponensként hozhatóak létre. Rendelkezik interakció rögzítési és kódgenerálási megoldással is. Azonban ez black-box tesztelésre nem használható, a saját fejlesztésű alkalmazások fejlesztői tesztjeinek gyors és hatékony megvalósítására alkalmas.

Az egyik legismertebb eszköz, a Winium csak WPF, WinForms, illetve Windows Phone-ra készült alkalmazásokat támogat, .

A SikuliX, amely az MIT-n fejlesztett Sikuli szoftveren alapul egy nyílt forráskódú eszköz. Python-t használhatunk a scriptek megírásához. OpenCV-n alapuló megoldás, ami a képernyő egyes elemeinek gépi felismerésén alapul. Ebből adódik, hogy az elkészült megoldás gyakorlatilag egy adott rendszer pillanatyni konfigurációjához kötött.

A TestFX esetében – amely nevéhez híven JavaFX alkalmazások teszteléséhez ideális – a teszt szkriptnek és a tesztelendő alkalmazásnak ugyanazon JavaFX folyamatban kell futnia. Ellenkező esetben API kapcsolat biztosítása szükséges az állapotgráf lekérdezéséhez. A Scenic View alkalmas egy JavaFX alkalmazás állapot gráfjának vizsgálatára, id és style adatok lekérésére az alkalmazás forráskódjához való hozzáférés nélkül. (A Scenic View megoldása: https://bitbucket.org/scenicview/scenic-view/src/73003b257b7e/src/main/java/org/fxconnector)

A Robot Framework egy általános célú kulcsszó alapú tesztelési keretrendszer, amely két különálló komponensből áll. Megvalósítja a teszt adatok és a tesztelés alatt álló alkalmazással kommunikáló kódkönyvtárak közötti transzfert. A tesztek fejlesztése Python-ban vagy Jython-ban történik. Fő felhasználási területe az elfogadási tesztelés(Acceptance testing). Windows alkalmazások teszteléséhez a TestFX esetében már ismertetetthez hasonló megoldásra van szükség. Egy lehetséges implementáció: https://github.com/eficode/JavaFXLibrary .

Az AutoIt v3 a Windows ablakainak, standard elemeinek, beépített natív alkalmazásainak és a folyamatok kezelésére alkalmas megoldás. A kívánt elemek rögzítése után az azokkal végzendő műveleteket au3 fájlokban írjuk le. Az így létrejött, a BASIC-hez hasonló szkriptekből exe fájlt fordítva tudjuk meghívni akár egy Java forrásból. Ebből adódóan ez kiegészítő megoldásnak lehet jó, adott esetben webes alkalmazás esetén a fájl kiválasztó ablak kezelésére. A segédeszközök, keretrendszerek mellett találkozhatunk wrapperekkel is, amelyek egy meglévő alapra építenek hozzáadott funkcionalitást. Jelen esetben ilyen az AutoItX4Java is, amely az AutoIt adta lehetőségeket teszi elérhetővé Java kódból. https://github.com/accessrichard/autoitx4java Az így elkészült kódok karbantarthatósága nehézkes lehet, hiszen a wrapper is folyamatos aktualizálásra szorul az újabb keretrendszer verziók megjelenése nyomán.

Az egyik legismertebb, üzleti csomagban kínált alternatíva a MicroFocus Unified Functional Testing keretrendszere, amely a korábban HP Quick Test Professional néven ismert szoftvercsomag utódja, 12 éves múltra tekint vissza. A szoftvernek nagy előnye, hogy natívan integrálható a HP Application Lifecycle Management néven ismert komplex szoftver termék menedzser termék csomaggal. Az ALM az adminisztrációt központosítja és az üzleti követelményektől egészen a késztermékig végigkövethetjük használatával a tervezés, fejlesztés, tesztelés fázisai. A termék használata során kiemelt figyelmet kell fordítani a számunkra hasznos bővítmények kiválasztására, a többinek pedig a kikapcsolására, hiszen lassú működést tapasztalhatunk ellenkező esetben. Támogatja teljes tesztesetek rögzítését is a felvevő eszközével, azonban az így kapott szkriptek minősége gyakran nagyon alacsony.

Univerzális megoldásnak a Zaptest tekinthető. A MicroFocus Unified Functional Testing-hez hasonló funkció csoportokkal rendelkezik, azonban folyamatos fejlesztés alatt áll, illetve a program használata során alacsonyabb válasz időkkel kell számolnunk. A termék Windows / iOS / Android / Mac / Linux / BB platformokra írott szoftverek teszteléséhez használható. A tesztkészlet összeállítása VBScript vagy JavaScript nyelven történhet. Támogatása kiemelkedő, az ingyenesen használható fórumon is egy napon belül választ kaphatunk egy szakértőtől. A HP ALM és a JIRA integráció is biztosított gyártói illesztőkkel. Nagy előnye, hogy használatával a teljes ökoszisztéma lefedhető, hiszen támogat mobil platformokat, webes és asztali alkalmazásokat is. Az ingyenes kiadása gyakorlatilag csak kipróbálásra, ismerkedésre alkalmas, hiszen For / While ciklusok nem használhatóak benne.

Az Applitools Eyes megoldása egy komplex megoldás a teszteredmények validálására és a kiértékelésükre, ezáltal kicsit kilóg a sorból, hiszen itt nem egy klasszikus értelemben vett keretrendszerről beszélhetünk. Önmagában egy SaaS, azaz szoftver szolgáltatás, ami azt jelenti, hogy az infrastrukturális felépítést teljes egészében elfedi, a felhasználó csak az alkalmazási réteggel kerül kapcsolatba. A tesztelendő rendszerrel való közvetlen interakciót nem valósítja meg, hanem egyes SDK biztosította interfészeken kommunikál azokkal. Számos technológiát és platformot támogat, több mint 40 SDK-t számlál az egyes platformok kezeléséhez.

Összefoglalásként a tesztelés előtt mindig fontos a tesztelési koncepció és terv elkészítése. A tesztelendő alkalmazás alapvetően meghatározhatja a használható keretrendszerek körét, hiszen univerzális megoldások, mindig működő receptek nem léteznek. Gyakran több, autonóm megoldás kombinációja jelentheti a megoldást a specifikus tesztelési feladatra. Az ár-érték arány, kompatibilitás, terméktámogatás és használhatóság tekintetében a ZAPTEST megoldása a legjobb választás véleményem szerint. Mind az Atlassian termékekhez, mind a HP ALM-hez biztosít integrációs lehetőségeket natív megoldásokkal. Ennek köszönhetően a csapat által valószínűleg már használt és megismert teszt menedzsment eszközt nem szükséges cserélni a teszteszköz váltáshoz, amellett, hogy maga az eszköz is teret enged a tesztelői önmegvalósításnak.