Sikuli – glöm allt du lärt dig om automatiserad GUI testning

Sikuli – glöm allt du lärt dig om automatiserad GUI testning

sikuli

Bild 1. Guds öga.

 

Lisa Ryrholm har, som examens jobb på Chalmers, arbetat i ett skarpt projekt i ett stort svenskt företag med ett nytt verktyg som jag tror många testare borde titta närmare på. Kontakta gärna henne, ifall du vill veta mer.

Jag blev så inspirerad hennes presentation så jag beslöt skriva denna  artikel i testzonen.

Första gången jag själv kom i kontakt med automatiserad GUI testning, för över tio år sen, fick jag alltid rådet att undvika navigera genom att försöka leta efter bitmaps i t.ex. ikoner bilder och knappar.  All pixel-navigering i  x- och y-koordinat-led var bannlyst där jag då jobbade. Det var nära nog en anledning till uppsägning från företaget om man försökte!

Sikuli, som betyder “Guds öga” , bild 1, på ett mexikanskt indianspråk, lär mig och dig att tänka om.

Sikuli gör just det vi tidigare fick rådet att inte göra, dvs. navigerar visuellt. Sikuli navigerar GUI genom avancerade bild-igenkännings-algoritmer, genom att “läsa av” skärmen grafiskt.

Ett paradigm skifte inom automatiserad GUI testning!

Därmed behöver vare sig testaren eller Sikuli förstå uppbyggnaden och interna mekanismer i ramverket som implementerade GUIT, eller fönsterhanteringssystemet.  Som oftast (alltid?) är fallet med andra GUI  Verktyg som automatiserar GUI, som t.ex. navigerar genom APIer som exponeras av Windows GUI system, HTML-  och Dokument Objekt modell .

Det spelar sålunda ingen roll om GUI är gjort i Gnome, Win32, Perl TK, MFC, HTML eller Java. Sikuli klarar alla.

 

Exempel med kalkylatorn

Enklast att förstå hur man skapar ett testskript är att följa dokumentation och inlärningsvideor på sikuli.org, men jag visar ändå grunderna;

I mitt exempel automatiserar vi kalkylatorn (calc.exe) i Microsoft Windows.

kalkulatorn

Bild 2. SUT – Kalkylatorn

 

I Sikuli IDE klickar man på en av de musrörelser, se bild 3, som ska utföras.

Skärmen blir då utgråad och man får möjligheten att selektera en rektangel på skärmen, den skärmbildssektion som musrörelsen ska arbeta på.

Selektionen utförs ungefär på samma sätt som med Skärm-Klipp-Verktyget ( “Snippit”) i Windows 7.

Ett test skript byggs sålunda upp alt eftersom med olika click() musrörelser.

 

När man sedan “Kör” scriptet visas det i loggen, se bild 3, vilken rad felet uppstod på.

Sikuli IDE

Bild 3. Sikuli IDE med Skript  som “körs”. Det visar “fel” på rad sju då någon bild(region) med svaret med texten”0″,  noll,  inte hittas. Vilket är förväntat  eftersom resultatet inte blir noll när man dividerar ett med noll.

Skriptspråket är Phyton, så vill man utföra andra åtgärder vid felnavigering, är det bara att lägga in ett try/except block och anropa kod(-bibliotek) som utför andra åtgärder.

Testprojektet och scripts kan givetvis sparas och senare exekveras på kommandoraden, för t.ex. driva ett bibliotek av Sikuli GUI tester via annat testramverk, eller i kombination med andra tex. Selenium.

Sikuli har ger möjligheten att leta bilder (bild-igenkänings-algoritmer) och text (OCR-algoritmer).

Man kan också skapa regioner som gör att den endast letar i en viss del av skärmen efter en (radio-)knapp. På så sätt har den inte lika många GUI objekt att välja på.

 

Summering

Fördelar

+ Ingen kunskap behövs om det fönster hanterings ramverk som ska testas

+ gratis

+ opensource – skrivet i Java – utvecklat av MIT Universitetet i USA.

+ mer “kundlik/människolik” navigering av GUI än t.ex. att navigera via Windows/Dokument Objekt Modell.

+ Verktyget är översatt till Svenska, även fel-loggen visas på Svenska (valbart)

+ Phyton script – utbyggnadsbart, anpassningsbart modernt skriptspråk.

 

Nackdelar

- ingen inspelningsläge, s.k. “record”, funktionalitet, dvs. manuell kodning behövs för att få ett körbart skript.

- klarar inte så bra av att navigera till knappar /ikoner /bilder som visuellt “ser” likadana ut:t.ex.:
två knappar med nästan samma nyanser av samma färg.

- Så kallade genomskinliga eller “Se-igenom-menyer” vanliga i nyare operativsystem (typ Windows 7) kan vara svåra att navigera.

- lokaliserad och internationaliserade knapp-text kan bli svårare automatisera

- Många likadana knappar / check-radio-boxar som ser likadana kan vara svåra att automatisera

- opensource – dvs. det finns inget serviceavtal med tidramar när incidenter ska svaras eller lösas inom, även om utvecklarna verkar vara måna om att svara inom rimlig tid.

- ganska nytt verktyg, typ max 2 år, ung användarbas

- Många av de negativa sakerna nämnda ovan plus många fler åtgärdas och behandlas i ett ramverk för att ge stabilare och mer deterministiska testresultat. Detta ramverk har Lisa Ryrholm tagit fram i hennes examensjobb. I hennes ramverket finns många metoder som gör Sikuli mer stabilt både när det gäller att hitta saker men också att felhantera. Är man intresserad, ta gärna kontakt med henne.

 

Referenser:

www.Sikuli.org – Allt om Sikuli – download, exempel, inlärnings-videos m.m.

Lisa Ryrholm, lisa.ryrholm at squeed.com

18 svar till Sikuli – glöm allt du lärt dig om automatiserad GUI testning

  1. Sikuli är grymt! Vi använder det flitigt i vår test automatisering på Spotify. Är ett mycket bra alternativ där andra verktyg går bet, som tex om man vill testa flash-appar.

    Vill bara lägga till en nackdel du glömde nämna, och en nackdel som absolut inte är en nackdel.

    1) För testautomatisering, så är det ibland svårt att skapa vettiga verifieringar [orakler] med Sikuli. Speciellt då om man jobbar med dynamiskt data. OCR funktionaliteten är svårt att få stabil, så vill man verifiera dynamisk text, så kan det vara knepigt.

    2) Du hade open source på både plus- och minus-sidan. Men vad gäller support kring open source i allmänhet, och Sikuli i synnerhet, har jag en absolut bättre användarupplevelse än med de flesta dyra köpeverktyg!

    • Algeroth Algeroth says:

      Ville ge en uppföljningspunkt på detta kring orakel i Sikuli. För vissa typer av tester är det helt klart en utmaningen, ytterligare ett exempel utöver dina är kraftigt animerade gränssnitt. Vi har dock funnit att man ofta kan komma runt många av dessa problem med hjälp av modulariserad design och smarta val av interaktionskomponenter och testfalls-strukturer. Detta är bland annat delar som vi tar upp i det Robusthetsramverk som Lisa Ryrholm arbetat med under sitt ex-jobb.

      Mvh

      Emil Börjesson

  2. Intressant koncept även om jag tror att man får mer värde/kostnad i automatisering av lägre nivåer än GUI generellt.

    Ett av mina viktigaste krav är snabbhet vid exekvering, robusthet samt att man kan köra på en server/låst session. Hur klarar sig Sikuli på dessa punkter?

    • Kort svar: Inte så bra.

      Längre svar: Eftersom Sikuli måste identifiera en mindre bilds förekomst på skärmen, så går testerna lååångsamt. Dessutom så händer det att Skikuli missar att hitta en förekomst, fast den finns där. Men det är inte så illa, jämfört med andra verktyg.
      Devisen är: “Kan du se det, så kan du automatisera det”, så en låst session funkar ju inte.

  3. Johan Brorson Johan Brorson says:

    Tack för en bra artikel.

    På plussidan skulle jag även vilja lägga till att eftersom Sikuli script är skrivet i Java, så kan man använda Sikuli script som ett Java bibliotek. Det innebär att man även kan skriva sina automatiska tester i Java och även integrera Sikuli med andra Java bibliotek som t.ex. Selenium.

  4. Tanja Souza Tanja Souza says:

    Några till Sikuli-frågor…

    Någon som har erfarenhet av hur man samlar in testresultatet på ett vettigt sätt från Sikuli? Att få ut en rapport över nattens körningar där det lätt går att se vilka av testerna som inte har gått igenom?

    Jag testade detta igår för första gången och kände att det är rätt känsligt för timing, hur länge det tar för en del av en webbsida att laddas. Gäller att lägga in frikostigt med sleeps el liknande i skripten?

    Hade också problem med att den bara ser det som faktiskt är på skärmen – hur hittar man på enkelt sätt något som man måste scrolla ner till? Leta upp scroll-baren och click för att sen leta vidare eller något smidigare?

    • Att enklast hantera testresultat i Sikuli, är i min mening, att logga till fil. I ditt script, logga frikostigt med både vad du gör och det utfall som skapas. Det kommer att hjälpa dig att förstå varför tester failade, eller beter sig underligt. Använd tidsstämplar och loggnivåer så blir det lättare att filtrera. Det finns färdiga ramverk för både python och java att använda för detta. (tex log4j)

      Jo, tajmingen kan vara viktig, men använd hellre Sikulis wait-funktionalitet än sleep. Annars går ditt script onödigt långsamnt.

      Inget annat att göra än att scrolla. Men tänk på att ibland kan man scrolla med Page-down knappen eller dylikt.

      • Michel Michel says:

        Sikuli är ett bra verktyg och tror personligen mycket på den typen av verktyg.

        Om automatisering baserad på bildigenkänning verkar intressant tycker jag ni skall testa JAutomate (www.jautomate.com), ett Svenskutvecklat verktyg som har några saker som Sikuli saknar. Bildigenkänningen hittar det den letar efter trots att bilden eller texten är markerad eller tom inverterad jämfört mot vad den var vid inspelningstillfället. Den har fullt stöd för record/playback av skript. Den har automatik för att vänta tills gränssnittet är stabilt. Ibland behöver man dock korrigera lite eller lägga till verifieringspunkter efteråt. För att göra uppspelningen ännu stabilare kan man skapa semi-automatiska skript som ber användaren göra färdigt ett steg som av någon anledning inte kunde utföras automatiskt. Man kan även instruera JAutomate att automatiskt söka efter en bild/text som inte är synligt på skärmen genom att använda sig av musrulling eller att klicka på föregående/nästa knappar.

        Även JAutomate är baserat på Java och har ett API som är enkelt att använda. Basversionen är helt gratis. Vill man kunna generera HTML rapporter måste man dock uppgradera till Pro.

        Nackdelen med JAutomate är även här att OCR funktionen fungerar sådär för att läsa en text med liten font.

        Testa gärna JAutomate och hör av er vad ni tycker!

        • Algeroth Algeroth says:

          Tack för tipset. Jag skall definitivt kolla in detta verktyg och se hur det står sig mot de övriga VGT verktyg som vi testat.

          Mvh

          Emil Börjesson

        • Jonas Jonas says:

          Använder Jautomate i rent regressionstest syfte mot en webbportal. Fungerar mycket bra, exekveringstiden av testerna blir dock fort väldigt lång. Har dock inte grottat ned mig i verktyget för att se vad man kan optimera osv.

          I det stora hela är det ett verktyg jag varmt rekommenderar att man kikar på.

  5. Thomas Klevmar thomas says:

    Tack för tipset Michel! Jag ska absolut titta på JAutomate. Föresten, någon med erfarenheter kanske kunde skriva en artikel om det?

  6. Johan Hoberg Johan Hoberg says:

    Jag håller med om att Sikuli verkar intressant för vissa typer av automatisering och som stöd för att “empower the tester” och göra manuell och semi-automatisk testning mer effektiv, men många av de generella problemen med UI-automatisering återstår även med detta verktyg i min mening.

    http://angryweasel.com/blog/?p=332

    http://www.testingmentor.com/imtesty/2011/12/01/api-testinghow-can-it-help/

    Ha det,

    Johan

  7. Algeroth Algeroth says:

    En mycket intressant artikel detta som lyfter fram de viktigaste koncepten i denna typ av testning, som vi på Chalmers valt att kalla visuell GUI testning eller VGT som förkortning.

    I dagsläget finns det väldigt få studier om just VGT och dessa verktyg, något som vi på Chalmers nu försöker ändra på.

    Jag själv forskar för tillfället om VGT och är faktiskt Lisa Ryrholms exjobbs-handledare. I min forskning samarbetar jag med ett antal företag som utvecklar säkerhetskritisk programvara, primärt Saab SDS i Göteborg som utvecklar flyglednings-system. I vår forskning har vi sett att VGT fungerar väl för automatisering av de flesta typer av manuella systemtester. Något som undersöktes genom att jämföra just Sikuli mot ett kommersiellt VGT verktyg på Saab. I dagsläget jobbar vi mot en fullskalig implementation av just Sikuli på Saab SDS i Göteborg och har redan varit delaktiga i införandet av VGT med Sikuli på Saab SDS i Järfälla, m.fl.

    Vår framtida forskning kommer bland annat innefatta ett Robusthetsramverk för VGT som Lisa Ryrholm varit med och tagit fram. Vi kommer även utföra studier om acceptansen av VGT hos den enskilda utvecklaren samt sätt att kombinera VGT med property-based testing och aspekter av Behavior Driven Development.

    Den absolut viktigaste aspekten som vi kommer titta på är dock kostnaderna för underhåll av dessa script och finna sätt att mitigara dessa i mån av behov. Studier om äldre generationer av GUI baserad testning påvisar att underhållskostnaderna kan vara stora. Dock tror vi att robustheten som bildigenkänningen ger dessa verktyg kommer lösa dessa tidigare problem.

    Vi på Chalmers tror starkt på denna teknik och söker ständigt samarbetspartners, så om ni vill ha mer information om VGT, eller Sikuli för den delen, så kontakta mig gärna för en diskussion om ämnet.

    För att ge några ytterligare inlägg om just Sikuli så kan jag börja med att säga att det finns en hel del knep för att göra Sikuli snabbare. Genom smarta avgränsningskommandon och smarta val av interaktionskomponenter kan man få upp exekveringstiden rejält!

    Angående utdata så är, som sagts tidigare i denna tråd, utdata till fil det enklaste alternativet men inte det enda! På grund av att VGT verktyg kan jobba mot alla typer av grafiska gränssnitt är det lika lätt att göra bland annat skärminspelningar. Detta är den lösning vi har i dagsläget på Saab, där script som av någon anledning misslyckas först återställs och sedan körs om samtidigt som exekveringen spelas in. Således får utvecklarna inte bara en loggfil utan även en filminspelning av vad som gått fel under nattens körningar.

    På grund av att Sikuli är baserad på Jython, Python på Java bas, är det även möjligt att använda både Java och Python biblotek i Sikuli scripten. Ett populärt sådant är Pythons Unit-test ramverk som ger ett utmärkt och kraftfullt stöd för enhetstestning med Sikuli på GUI nivå.

    Nu tror jag denna post blir väldigt lång, och jag har mängder mer att skriva! Men som jag redan nämnt, om ni vill veta mer så hör mer eller mindre gärna av er till mig via TestZonen eller min Chalmers mail.

    Ha det gott,
    Mvh

    Emil Börjesson

    • Jonas Jonas says:

      Tack för en välskriven och utförlig kommentar!
      Vågar vi hoppas på en artikel om hur implementationen ser ut? Och kanske en om robusthetsramverket när det börjar ta form. Mycket intressant detta!

      • Algeroth Algeroth says:

        Hej Jonas,

        det kommer bli ett antal artiklar under arbetets gång. Det som ligger närmast i tiden är dock robusthetsramverket. Det kommer då finnas tillgängligt på min hemsida:

        http://www.cse.chalmers.se/~algeroth/

        som jag kommer se till att hålla uppdaterad. Så titta in där lite då och då för senaste information.

        Ha det gott,
        Mvh

        Emil Börjesson

        • Johan Hoberg Johan Hoberg says:

          Blir väldigt intressant att följa ert arbete.

          Underhållskostnaderna och robustheten är som du säger väldigt intressanta och det kommer att bli väldigt spännande att se vilken data ni får fram på dessa två områden.

          Kommer ni också att titta på kostnaden att köra dessa automatiska tester och analysera resultaten, och jämföra detta med kostanden för att köra dem manuellt?

          Ytterligare en intressant aspekt är så klart också om det går att automatisera effektivare under UI:t, och titta på effektivitet och kostnadsaspekter där och jämföra med VGT – men det ligger nog längre in i framtiden.

          Väldigt intressant hur som helst.

          /Johan

  8. Günter Günter says:

    Sikuli är ett bra komplement till andra testexekveringsverktyg hos oss och har fyllt luckor som vi hade i vår testautomatisering. Vi anropar Sikuli script från QTP script och det fungerar utmärkt.

Kommentera