Menü Bezárás

Windows asztali alkalmazás tesztelésének automatizációja

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.

Kovács Ákos

Kovács Ákos vagyok, 2015-ben diplomázott mérnökinformatikus. Certified Tester (ISTQB). Tesztautomatizálási mérnökként dolgozok. Bővebben: akoskovacs.hu

Latest posts by Kovács Ákos (see all)

Vissza