GUI teszt automatizálás Sikuli-val

Programozóként dolgozok jelenleg a munkahelyemen. Ahogy az alapkód növekszik és mind több ember dolgozik rajta, egyre több váratlan zavar jelentkezik a modulban, egy tőle teljesen független modul változtatásai miatt. Főleg az editor adta meg magát sokszor az ártalmatlan engine változtatások miatt. Ennek a kiküszöbölésére, az editor automatizált tesztelésére kerestem megoldásokat.

(Ebben a cikkben, én csak a GUI területen, fekete doboz tesztelésről fogok írni.)

Figyelembe vett alternatívák

A nyomozást az “AutoIt”-al kezdtem ami már egy kicsit ismerős volt számomra.

AutoIt

• Basic-szerű programozási nyelv Windows platformon
• Az UI elemeket a control ID-je, control class-ja, vagy a rajta lévő szöveg alapján azonosítja.
• Nagyon hasznos Windows-os alapvető automatizálásokra
• ingyenes

TestComplete

• Üzleti teszt automatizálási eszköz
• AFAIK, ez hasonló mechanizmust használ az UI elemeket azonosítására, mint az  AutoIt.
• Teljes értékű IDE támogatás
• Több programozási nyelv támogatott

SIKULI

• Jython-alapú, multi-platformos
• Számítógépes látás-alapú UI elemek azonosítása
  • Azonosságot keres képek összehasonlítása alapján a felhasználó által megadott százalékos tűréshatár figyelembevételével
• Alap IDE támogatás
• Kezdetleges fejlesztés
• Nyílt forráskód

A SIKULI innovatív koncepciója és az a tény, hogy képes reagálni akármilyen “izére” a képernyőn – nem csak a rendszeres UI elemekre – rávett arra, hogy használjam. Könnyedén áttekintheted a SIKULI funkcióit pár segédletet olvasva, vagy ezt a videót megtekintve:

A következőkben arról fogok írni, hogy hányféle kalandot éltem át a SIKULI-val, mióta ezt az eszközt használom.

Hogyan működik?

Az első cél az volt, hogy automatizáljam a napi regressziós teszteket, amit a QA srácok manuálisan végeztek a szerkesztő felületen. Eddig mintegy hetven százalékukat automatizáltam. Miután minden regisztrált teszt futása befejeződött, egy jelentés készül html formátumban. Ez azt mutatja, hogy az egyes tesztek hogyan futottak, milyen esetekben találtunk hibát. A következő dolgokat teszteljük:

• Editor futtatása / befejezése
• Belső szerkesztő ablakok megnyitása / bezárása
• Új szint létrehozása, és mentése
• Egy meglévő szint betöltése
• Szint exportálása
• Nézet mód kapcsoló
• Belső szerkesztők alapvető funkciótesztjei

De a teljes folyamat nem volt olyan egyszerű, mint vártam. Kiderült az is, hogy a számítógépes látás-alapú innováció egy kétélű kard.

Amit megtanultam

• Magas fenntartási költségek : Ha bármilyen változás történik a GUI-n, mint például ikon / szövegváltoztatás, vagy teljes átméretezés, minden vizsgált képet frissíteni kell. Ez roppant fárasztó és időigényes lehet.
• Kiméricskélni, megtalálni a vizsgálandó kép megfelelő régióját: ha valaki a kis terület mellett dönt, az egyezés pontossága csökkenhet azáltal, hogy sok esetben több mint egy találatot kap. Ha túl nagy régiót választunk, a teszt túlságosan érzékeny lesz minden GUI változásra, és a karbantartási költségek sokkal magasabb lesz.
• Eredményértékelési hiba: Az eredmény értékelése általában a képek összehasonlítása alapján történik. Ismételten, ez túl érzékeny a kis UI változásokra.
• Még kezdetleges a fejlesztés, a SIKULI szélei még elég csiszolatlanok, és akad benne néhány hiba. Például volt egy memóriavesztés, ami egy meghatározott API függvénnyel állt kapcsolatban. A hiba az volt, hogy egy billentyű beviteli “type()” API nem működött megfelelően, ha a billentyűzetkiosztás nem angol volt. Ilyenkor a vágólapot voltam kénytelen használni és a “paste()” API függvényt, hogy a szöveg bekerüljön a megfelelő helyre. Vagy egy másik példa, hogy egy olyan lényeges funkció mint a képek átnevezése az IDE-ben hiányzott (ezt már a legújabb verzióban pótolták). Ilyen esetben nem volt jó rendszerezési megoldás, ami a tesztsorozatok növekedésével igen nagy hátrány jelentett. Szerencsére a SIKULI fejlesztők nagyon gyorsan válaszolnak a kérdésekre és kérésekre, valamint QnA fórumuk is segítőkész volt.
• Nehéz debuggolni: a teljes körű debug környezet hiánya miatt. Régen az ideálisnál hosszabb ideig tartott a hibákat azonosítani és javítani, ha egy meglehetősen hosszú teszt funkció nem úgy működik, mint azt vártuk.
• Végrehajtási sebesség nem olyan gyors, mint amire számítottam, mert kép összehasonlításokat hajt végre. Igazság szerint ez nem is hiba. Csak egy-egy adott IDE funkció használatánál ezek a belassulások idegesítőek lehetnek és nagyban hátráltatnak a feladatvégzésben.

Tanulság

Úgy tűnhet, hogy elég rossz színben ábrázolom a rendszert, de ne érts félre. Ha más alternatívát használunk (amelyek a GUI vezérlő ID / osztály-alapú azonosításon alapulnak) ott is hasonló karbantartási problémákkal találkozhatunk. Továbbá vannak olyan helyzetek, amikor a SIKULI egy pofonegyszerű megoldást nyújt, míg az alternatív megoldásokban időigényes lehet ezt megcsinálni.

• Ha a fejlesztés továbbra is ilyen lendületesen folyik, úgy gondolom a SIKULI egy érett és jövőre tekintő eszközzé válhat.
• Szinte lehetetlen, hogy egy stabil és alacsony fenntartási költségű GUI automatizált tesztelést építsünk ki, ha kizárólag külső UI azonosításban gondolkodunk. Ha egy külső szoftver mélyebben tudja, vizsgálja az alkalmazást, mondjuk a teszt szkriptelhetősége által, akkor egy olyan teszthalmazt építhetünk, amely nagyobb lefedettséget biztosít, stabilabb és könnyebb karbantartani.
• Számomra a SIKULI nagyon hasznosnak bizonyult a regressziós teszteknél.
• Sokat segíthet néhány személyes hétköznapi feladat automatizálására az otthoni számítógépen.

Ugyanezt a bejegyzést a személyes blog-omon is megtekintheted, persze csak ha tudsz koreaiul olvasni. 😉

Forrás: http://www.altdevblogaday.com/2011/06/21/gui-test-automation-using-sikuli/

Szerző: Jaewon Jung