Testning av användargränssnitt

Transkript

1 Testning av användargränssnitt Författare: Christian Holmgren Sanna Mauritzon Datum: Sammandrag Rapporten är ämnad att ge en överblick över området att testa grafiska användargränssnitt. Detta är ett område som blir allt viktigare bland dagens produkter och som är under ständig utveckling. En stor mängd av de produkter som utvecklas idag har ett grafiskt användargränssnitt, ett så kallat GUI, och då även denna del av produkten behöver testas har flertalet verktyg utvecklats för att automatisera processen. I denna rapport presenteras ett antal verktyg och två analyseras djupare. Dessa är jfcunit och Abbot som båda är omfattande och har möjlighet att dynamiskt känna igen komponenter på skärmen för att gör testerna anpassningsbara. Fokus för analysen är delvis vilket verktyg som skulle passa vid ett projekt som använder sig av extreme programming men även hur marknaden ser ut, idag och i framtiden, samt hur de olika verktygen skiljer sig.

2 1. Inledning Denna rapport undersöker testning av grafiska användargränssnitt vid mjukvaruutveckling med fokus på automatisering av processen. Olika relevanta verktyg utvärderas utifrån olika kriterier, däribland användarvänlighet, fullständighet och anpassningsbarhet. Utifrån analysen läggs resultat fram som kan användas som stöd vid val av verktyg. Av verktygen som analyseras kommer två undersökas mer utförligt än de andra. Dessa verktygen är jfcunit 1 och Abbot 2. Två oberoende utvecklarteam av studenter vid Lunds Tekniska Högskola kommer utvärdera dessa verktygen under ett fiktivt projekt. Tanken med detta är att samla in synpunkter och i slutet kunna rekommendera ett verktyg som lämpar sig bäst för ett projekt av den typen. För utförligare beskrivning av projekttypen, se rubriken 1.1 Projekt. En förhoppning med studien är att kunna göra rekommendationer av verktyg som kan hjälpa andra projekt i framtiden. Alla verktyg som utvärderas kommer alltså beskrivas med fördelar och nackdelar så att kommande projekt kan använda sig av informationen för att välja ett verktyg som passar bäst i deras situation. 1.1 Projekt Projekten som kommer utvärdera jfcunit och Abbot är identiska med varandra i många avseende och ingår i en kurs på Lunds Tekniska Högskola. Nedanstående text beskriver båda projekten. Ytterligare information om kursen som innehåller projekten kan hittas på hemsidan för kursens kursplan 3. Projekten pågår under sju veckor med en iteration i veckan där nedlagd tid per vecka är cirka 14 timmar. De är agila projekt som följer extreme programmings (XP) metodik och kommer utföras i en skolmiljö. Varje projektgrupp är nio personer där en av dem är en äldre student som agerar coach. De yngre studenterna går alla civilingenjörsutbildningen med inriktning datateknik och har därför tidigare erfarenhet av mjukvaruutveckling. De har också viss erfarenhet av JUnit 4. Coacherna i projekten är författarna till denna rapport och agerar utöver coacher även tracker och i viss mån projektledare. Systemet som ska utvecklas är ett tidtagarsystem för endurotävlingar som ska utvecklas i programmeringsspråket Java. Tidigt i utvecklingen kommer det krav från kunden på ett grafiskt användargränssnitt som ska tydliggöra och hjälpa användarna. Eftersom produkten ska levereras till kunden är det viktigt att kunna kvalitetstesta även den del av koden som berör det grafiska användargränssnittet. Projektet upplägg består av åtta timmar långlabb varje vecka, två timmar planeringsmöte och

3 fyra timmar spike-tid. Varje vecka motsvarar en iteration och i hälften av iterationerna ingår en extern release som utvärderas av kunden. De fyra timmarna som projektmedlemmarna varje vecka ska lägga ner på spikes är tid som ska användas för att läsa material som är relaterat till kursen, sätta sig in i systemlösningar för att underlätta utvecklingen och andra projektrelaterade saker som coacherna bestämmer. Under planeringsmötet tidsestimeras och prioriteras nästa iterations stories i samförstånd med kunden. Veckans spikes delas också ut. 1.2 Utvärdering För att kunna göra en så rättvis jämförelse mellan de två verktygen som möjligt har ett formulär framställt som ska användas för utvärdering av både jfcunit och Abbot. För att se formuläret, studera Appendix A. De två projektgrupperna som testar de olika verktygen får mot slutet av projektet fylla i dessa utvärderingsformulär och svaren sammanställs sedan för att fastställa om något verktyg är att föredra framför det andra. Naturligtvis spelar andra faktorer roll vid fastställandet av det slutgiltiga resultatet men projektgruppernas åsikter kommer spela en viktig roll. 2. Automatiserad GUI-testning Grafiskt användargränssnitt heter på engelska Graphical User Interface, förkortat GUI och är ett begrepp som ofta används för att beskriva de fönster, knappar, menyer med mera som används vid kommunikation mellan användaren och datorn. När mjukvara innehållande ett GUI utvecklas behöver alla delar testas, både koden bakom gränssnittet och själva gränssnittet. Det går inte att släppa ett program som har fungerande kod men ingenting händer när man trycker på knapparna i gränssnittet. Då kan användarna inte interagera med programmet och det ses snabbt som värdelöst. 2.1 Problem vid GUI-testning Att testa ett programs GUI är annorlunda från att testa koden bakom gränssnittet. Ofta anses det vara svårare att testa GUI:t och detta beror på att andra problem dyker upp vid testning av denna programdel. Ett vanlig problem är att användarna av programmet har möjlighet att klicka och röra sig överallt i gränssnittet vilket leder till en enormt stor mängd möjliga händelser som behöver testas 5. En användare kan närsom stänga ner ett fönster, byta fokus, klicka någonstans på skärmen eller göra något annat som behöver behandlas på rätt sätt av programmet. Denna stora mängd möjligheter måste hanteras av utvecklarna vilket också betyder att den behöver testas så att rätt funktionalitet kan försäkras. Ett annat problem som uppstår då GUI ska testas är att många program har dolda beroenden samt behov av synkronisering 5. Det kan till exempel vara att en besökare på en resebyrås hemsida klickar på önskad destination och då ska aktuella flygförbindelser visas i en ruta. Det kan även vara så att synkroniseringen sträcker sig bortom användarens fönster, till

4 exempel då besökaren köper en flygbiljett och antalet fria flygbiljetter i flygbolagets databas ska minska. All denna funktionalitet behöver testas men det är inte alltid så lätt att kontrollera att synkroniseringen fungerar korrekt. I vissa fall döljer det sig mycket funktionalitet bakom GUI:t som kan ge fel som inte syns utåt. När testningen av ett GUI ska göras automatisk uppstår ytterligare problem, bland annat då mindre förändringar görs i GUI:ts utseende 6. Om en knapp flyttas ett par pixlar åt höger förstörs ingen funktionalitet utan bara utseendet ändras. Det kan vara svårt för automatiska verktyg att göra dessa bedömningar vilket ofta innebär att fel lär hittas vid testningen även om förflyttningen av knappen inte resulterade i några funktionalitetsfel. 2.2 Verktyg Flertalet verktyg har utvecklats för att hjälpa utvecklare och testare med att skapa och genomföra testning av användargränssnitt. Verktygen har olika tillvägagångssätt och därmed olika för- och nackdelar. Detta gör att vissa verktyg passar bättre in i vissa situationer och sämre i andra och gör det svårare att välja verktyg för ett projekt. Många verktyg använder sig av en metod som kallas inspelning/uppspelning som går ut på att spela in användarnas handlingar och spara i ett script för att sedan kunna spela upp händelserna igen och jämföra så att resultatet fortfarande är korrekt 7. Detta är ett smart sätt att snabbt skapa tester men har också en del nackdelar. Till exempel slutar scriptet att köra då en bugg upptäcks och allting behöver köras igen från början när buggen är fixad, för att kanske stöta på nästa bugg två sekunder efter där den förra hittades 8. Det kan också bli problem om utseendet på GUI:t jämförs med en bildfil. Ändras en liten pixel misslyckas testet, precis som det beskrivs i sektion 2.1 Problem vid GUI-testning. Inspelning/uppspelnings-metoden löser alltså inte alla problem som finns vid testning av användargränssnitt. Ett annat tillvägagångssätt för GUI-testning är en metod som fritt översatt kallas programmeringsmetoden 7. Med denna metoden skrivs tester i kod och det går lättare att anpassa testerna och göra att de klarar en del förändringar i GUI:ts utseende. På så sätt kan de problem som uppstår med script undvikas. En nackdel är att det kan ställa till stora problem att få testen att utföra det som ska testas. Att få tillgång till fönster för att utföra test i dem är ett stort problem då det inte finns några lätta sätt att få tag på dem. Själva testen blir också väldigt komplicerade och svårlästa då de måste hålla reda på all komponenthiarki. I kommande sektioner presenteras och utvärderas ett antal verktyg som har som uppgift att automatisera testning av GUI. Två verktyg kommer utvärderas grundligare än de andra och dessa verktyg är jfcunit och Abbot. Anledningen till att fokus läggs på dessa verktyg är att de erbjuder möjlighet att använda både inspelning/uppspelnings-metoden och programmeringsmetoden vilket ger användaren större möjligheter att skapa och modifiera tester 7. Först presenteras en del intressanta verktyg som även de kan användas för att testa GUI.

5 3. Några intressanta verktyg Utöver jfcunit och Abbot som utvärderas närmare senare i rapporten, finns det flertalet andra verktyg som hjälper till vid testning av grafiska användargränssnitt. Många av dem har inte samma omfattning, mångsidighet eller tillgänglighet och har därför inte valts ut för utvärdering. Istället presenteras några av dem kort nedan. 3.1 SwingUnit SwingUnit är ett automatiserat testnings verktyg för Java Swing applikationer 10. Det fungerar som ett vanligt macro eller script för Swing. SwingUnit använder sig utav kodtest och har inte stöd för att spela in script där muspekaren rör sig eller klickar på element. Det integrerar sig med JUnit vilket medför att det går att använda sig av de verktyg som finns i JUnit för att underlätta GUI- testningen. Testerna kan skrivas i en XML-fil (extensible Markup Language) vilket underlättar då XML är ett stort och utbrett format vilket medför att kunskapen om hur det skrivs är stor. Huvudkonceptet bakom SwingUnit är att kapsla in events i Swings komponenter och därigenom kunna utföra test operationer och avläsa resultaten. 3.2 GUITAR GUITAR (GUI Testing framework) är inte ett enda verktyg utan en svit av olika verktyg som tillsammans skapar möjligheter att testa grafiska användargränssnitt automatiskt 11. Tillsammans verkar de för att inte bara testa på ett smart sätt, utan även att automatisera processen av att skapa testfall. En stor fördel med GUITAR är att det är ett gratisverktyg. Nedanstående komponenter är exempel på de moduler som ingår i GUITAR. EFG2EIGConvert - Ett program som med hjälp av en graf över händelseflödet skapar en graf över händelseinteraktionen. Det mappar även varje båge i ursprungsgrafen med motsvarande både i utdatan. AbstractEIG2ExecutableTC - Använder utdatan från föregående program för att skapa exekverbara testfall. WGReplayer - Ett program som automatiskt kör GUI-testfall på applikationen. 3.3 Fest Fest är ett gratisverktyg som består av flera moduler vilka tillsammans underlättar testning av mjukvara 12. Det kan användas tillsammans med JUnit och grundkonceptet är att tillhandahålla en samling av API:er (Application Programming Interface) för testning. Det innehåller mer än bara funktionalitet för testning av GUI men det finns moduler som är speciellt avsedda för just GUI-testning. En sådan modul är GUI Functional Testing: Swing and JavaFX. Den gör precis vad det låter som, tillhandahåller API för funktionstestning av GUI.

6 De testfall som är producerade med hjälp av Fests moduler hittar objekt dynamiskt och en förändring i layouten hos GUI:t ska inte resultera i fel hos testfallet. Skulle ett testfall inte gå genom visas det tydligt vad som hände genom att bland annat uppvisa en hierarkisk bild över GUI:t. 3.4 Squish Squish är ett verktyg med fokus på att automatisera regressionstestningen av användargränssnittet 13. Det kan automatiskt spela in testscript och dessa script blir inte beroende av skärmens koordinater. Koden i scripten kan väljas till flera olika språk, däribland Python och JavaScript. Under testerna kan skärmdumpar verifieras men även den lagrade datan både internt i programmet och externt i tillhörande databaser. Det har en stor fördel i att det är anpassat till flera GUI-teknologier och därmed fungerar inte bara på Java Swing eller AWT utan även HTML, iphone CocoaTouch, Native Windows.NET och flera andra. En nackdel är dock att det inte är ett öppet program utan användaren måste betala för att få tillgång till produkten. 4. jfcunit jfcunit är ett gratis verktyg för att testa användargränssnitt. I detta avsnitt beskrivs och utvärderas verktyget. 4.1 Vad är det? jfcunit är ett verktyg designat för att underlätta testning av GUI:s. Det använder sig av det välkända testframeworket JUnit 4. jfcunit utvidgar JUnit vilket möjliggör för utvecklare som redan är bekanta med JUnit att lätt lära sig att använda jfcunit. Det vanligaste sättet att bygga GUI i java är att använda sig av standardbiblioteket Swing och det är endast mot detta som jfcunit kan användas. Detta för med sig nackedelen att verktyget kan bli begränsad ifall en annan lösning på hur GUI:t ska implementeras genomförs. jfcunit fungerar på följande sätt 1 : Den får tillgång till fönster och dialogfönster som öppnas genom javakod. Identifierar komponenter inom en komponenthiarki. Utför händelser på hittade komponenter, till exempel att det trycks på en knapp eller att text skrivs in i en ruta. jfcunit tillåter även att scripts skrivs i XML som driver testningen. Detta underlättar editeringen av scripts då XML enkelt och lätt kan ändras. jfcunit stödjer också utvecklingsverktyget Eclipse vilket gör det enkelt för användare att integrera verktyget direkt i sin utvecklingsmiljö genom att installera ett plugin.

7 En av de svåraste sakerna att testa är när ett nytt fönster skapas under exekvering. Detta eftersom det är svårt att få tag på det nya fönstret. Det finns ingen metod där det går att få tag på fönstret. Detta löser jfcunit genom att detektera när fönstret skapas i AWTs Event queue. Detta för dock med sig att testet alltid måste startas innan GUI:t då det är omöjligt att få tag på det annars. 4.2 Utvärdering Eftersom GUI-testning kan vara väldigt komplicerat valdes två utvecklare ut som skulle vara ansvariga för testningen. Dessa två fick som spike den första veckan att läsa på vad jfcunit var och hur det installerades. Deras andra spike under iteration 2 var att installera det och skriva något testfall så att de visste att det verkligen fungerade. Detta innebar att de lade ner 8 timmar var på att sätta sig in i hur jfcunit fungerade. Det bidrog även till att ingen tid förlorades på långlaborationerna då detta skulle ha bidragit negativt till projektets utveckling vilket vi ville undvika så långt som möjligt. I figur 1 och 2 går det att se hur det GUI som testades såg ut. Figur 1. Utseende av det grafiska användargränssnitt för registrering som testats av projektgruppen.

8 Figur 2. Utseende av det grafiska användargränssnitt för resultat som testats av projektgruppen. I iteration 3 fick utvecklarna som uppgift att skriva testfall för första gången som testade GUI:t. De första testen som producerades och som var enklast att skriva var att kontrollera om GUIelement existerade. Dessa test kan vara användbara men då det viktigaste i GUI-test är att input till de olika elementen fungerar fick utvecklarna instruktioner att koncentrera sig på test som producerade något. Detta tog länge tid men resultatet var att vi fick en mycket bättre testning. Under den femte iterationen fick projektmedlemmarna fylla i ett formulär, se appendix A, där de skulle utvärdera hur de upplevde jfcunit. Resultaten från denna utvärdering presenteras i nästa avsnitt. 4.3 Resultat av utvärdering De två utvecklarna som hade ansvaret för GUI-testning fick i slutet av projektet svara på en enkät, se Appendix A. Ingen av utvecklarna hade tidigare erfarenheter av att testa GUI:s. Detta innebar att hela konceptet var okänt och de var tvungna att lära sig allt från grunden. Detta bidrog till att det tog längre tid att lära sig hur testarna skulle utföras och hur verktyget fungerade. Eftersom det finns likheter mellan de olika verktygen skulle tidigare erfarenheter ha bidragit till en kortare inlärningstid. Trots detta tyckte utvecklarna att det endast tog 1-3 timmar att lära sig hur jfcunit fungerade vilket indikerar att det är ett lätt verktyg att lära sig under förutsättning att utvecklaren har använt sig utav JUnit tidigare.

9 Svarsalternativ Medelsvar Lätt att sätta sig in i 1 1 3,5 Kan vara användbart i arbetslivet 1 1 3,5 Lättanpassat 2 3 Lättintegrerbart med Eclipse och JUnit Verktyget underlättade utvecklingen av projektet 1 1 4,5 2 2 Kommer använda det igen 1 1 2,5 Tabell 1. Visar hur många personer som kryssat för respektive val i varje fråga. 1 = Stämmer inte alls, 2 = Stämmer inte, 3 = Stämmer något, 4 = Stämmer bra, 5 = Stämmer mycket bra. Sista kolumnen visar medelsvaret hos deltagarna. Svarsalternativ Medelsvar Hur viktigt tycker du det är att testa GUI vid programvaruutveckling? 1 1 2,5 Tabell 2. Visar hur många personer som kryssat för respektive val i den aktuella frågan. 1 = Mycket onödigt, 2 = Ganska onödigt, 3 = Ganska viktigt, 4 = Mycket viktigt. Sista kolumnen visar medelsvaret hos deltagarna. I Tabell 1 går det att utläsa resultaten från en del av svaren på frågeformuläret. På frågorna om vad de tyckte om jfcunit hade de ett positivt intryck utav verktyget. De tyckte att det var lättanpassat och att det integrerade på ett bra sätt med Eclipse och JUnit. De tror även att det kan vara användbart att kunna använda sig av jfcunit i arbetslivet. På frågan om de tyckte att verktyget underlättade vid utvecklingen av projektet var svaren inte så positiva. Båda angav att det knappt hjälpte alls vilket troligtvis beror på att det GUI som tas fram i projektet är en väldigt liten del av projektet. De var inte så positiva till om de kommer använda sig av jfcunit igen. Den frågan där svaren skiljer sig åt är hur viktigt de tycker att GUI-testning är. Detta visas i tabell 2. En tycker att det är ganska viktigt medans den andra tycker att det är ganska onödigt. En trolig anledningen till att de inte är helt positiva till detta är att de var tvungna att använda sig utav verktyget i ett projekt där det inte är speciellt viktigt att testa GUI:t. Det är möjligt att de skulle haft mer positiva omdömen om de först skulle ha introducerats till jfcunit i ett projekt där GUI:t är en mycket större del av utvecklingen.

10 4.3.2 Kommentarer från andra utvecklare Att det endast var två utvecklare som hade hand om GUI-testningen innebar inte att de andra utvecklarna inte kom i kontakt med testningen. Det var endast de ansvariga som skrev tester men övriga teammedlemmar interagerade också med testerna under utvecklingen. Under projektets gång så hade de diverse kommentarer på vad de tyckte om GUI-testningen och de kommentarerna redovisas här. I början av projektet upplevde de flesta utvecklarna att GUI-testningen endast hindrade dem från att effektivt kunna utveckla projektet. Då de tidiga testerna endast testade om element fanns i GUI:t tyckte de inte att testerna tillförde något. När de mer avancerade testerna togs fram i slutet av projektet, som faktiskt testade att sätta in värden i GUI:t och testa att de kom in korrekt, så ändrades kommentarerna till att vara lite mer positiva. De mest negativa kommentarerna om testerna var att det tog för lång tid att köra igenom dem vilket ledde till att testerna inte kördes så ofta. Detta är naturligtvis inte så bra då XP går ut på att det ska testas ofta. De tyckte också att det gick snabbare att testa GUI:t manuellt än att köra igenom testerna. En viktig aspekt att ta i beaktning är hårdvarans roll i dessa negativa åsikter. De datorer som projektutvecklingen sker på är inte så bra vilket är anledningen till att testerna tar så lång tid att köra igenom. Om alla GUI-testerna körs på en snabb dator går det betydligt snabbare att köra igenom dem vilket gör att det inte är några problem att GUI-testa. Alltså kan slutsatsen dras att hårdvaran är en av de stora anledningarna till att utvecklingsgruppen hade mestadels negativa kommentarer om jfcunit. 5. Abbot Detta avsnitt kommer behandla Abbot och den tillhörande texteditorn Costello. Tillsammans utgör de ett kraftfullt verktyg för att automatisera GUI-testning. 5.1 Vad är det? Abbot är ett verktyg för att automatisera testningen av användargränssnitt för programvara skriven i programspråket Java. Tillsammans med editorn Costello möjliggör det att både skriva programkod och spela in användarhändelser för att förenkla testning av GUI 7. Verktyget innebär bland annat att GUI-testen kan skrivas innan själva koden för GUI:t vilket gör att det passar bra vid testdriven utveckling. Detta beror på verktygets sätt att identifiera komponenter i gränssnittet. Eftersom Abbot stöder både inspelning/uppspelnings-metoden och programmeringsmetoden för att skapa tester till GUI:t kan verktyget användas på två olika sätt. Dels kan Costello spela in händelser och spara i script och dels kan tester liknande de i JUnit skrivas i ren kod. Om Costello används sparas inte händelserna utifrån var på skärmen musen befinner sig vilket hade gjort att testet misslyckats om små ändringar i GUI:t hade gjorts. Istället identifieras

11 komponenter på skärmen genom flertalet dynamiska attribut så att testen i största möjliga mån ska klara av att hantera ändringar. Om programmeringsmetoden används skrivs tester på samma sätt som JUnit-tester skrivs, men det finns en speciell API för Abbot och det är detta som gör verktyget så kraftfullt 9. Abbot står för A Better Bot och grundstenen i verktyget är komponenten Robot som simulerar händelser och tillhandahåller en mer abstrakt nivå för inmatning. 5.2 Utvärdering Eftersom det ingick så kallade spikes i projektet på fyra timmar per projektmedlem varje vecka utnyttjades denna tiden till att få en del av projektmedlemmarna insatta i Abbot och dess miljö. Under projektets första vecka tilldelades fyra projektmedlemmar uppgifter där de skulle svara på frågorna Vad är Abbot? och Hur installerar man det?. Veckan efter fick fyra projektmedlemmar (två som haft Abbot-spike veckan innan och två som inte haft det) spikes där de skulle svara på frågan Hur använder man Abbot?. Alla i projektgruppen fick även till uppgift att läsa på om det som skrivits om Abbot av medlemmarna under respektive spike. Under den tredje iterationen utvecklades testfall för att testa det grafiska användargränssnittet genom att använda Abbot. Även om inte alla medlemmar deltog i utvecklingen fick alla i uppgift att sätta sig in i hur framställningen av testfall fungerar och i den kod som faktiskt resulterat från iterationen. Denna kod var inte på någon högt avancerad nivå då själva gränssnittet inte var komplext. I figur 1 visas det testade gränssnittet. Under den femte iterationen fick projektmedlemmarna fylla i ett formulär, se appendix A, där de skulle utvärdera hur de upplevde Abbot. Resultaten från denna utvärdering presenteras i nästa avsnitt. Figur 3. Utseende av det grafiska användargränssnitt som testats av projektgruppen.

12 5.3 Resultat av utvärdering Ingen som svarade på enkäten hade tidigare använt ett verktyg som testar användargränssnitt. 80 % av projektmedlemmarna uppskattade att det tog mellan två och tre timmar att sätta sig in i Abbot, resterande del ansåg att det tog tre till sex timmar. I denna tiden ingick nedladdningstid, installationstid samt inläsningstid för att kunna skapa ett lyckat test i programmet. I tabell 3 visas svaren på vissa av de påståenden som besvarades i utvärderingen. Där går det att se att alla åtta projektmedlemmar svarat på varje påstående och att medelbetyget för Abbot inte är överväldigande högt. Det som fått lägst medelpoäng är Kommer använda det igen. En anledning till att projektdeltagarna tror att de inte kommer använda verktyget igen kan vara att de inte uppskattade alla komponenter som ingår och att de tror att andra, bättre verktyg finns på marknaden. En annan anledning kan vara att de tycker GUI-testning inte är en av de viktigaste punkterna vid programvaruutveckling, vilket går att se i tabell 4 där deras svar ligger lite under alternativet Ganska viktigt. Tabell 3 visar även ett lågt medelsvar för påståendet Verktyget underlättade utvecklingen av projektet. Efter efterforskningar till varför denna siffra var så låg framkom det att då testfallen endast testade delar av funktionaliteten hos GUI:t ansågs det inte riktigt vara värt den arbetsinsats som behövdes läggas för att skapa testen. De delar av GUI:t som inte testades borde enligt projektdeltagarna ha testats men detta ansågs vara för avancerat och gjordes därför inte. Svarsalternativ Medelsvar Lätt att sätta sig in i ,9 Kan vara användbart i arbetslivet ,9 Lättanpassat Lättintegrerbart med Eclipse och JUnit Verktyget underlättade utvecklingen av projektet ,6 Kommer använda det igen ,5 Tabell 3. Visar hur många personer som kryssat för respektive val i varje fråga. 1 = Stämmer inte alls, 2 = Stämmer inte, 3 = Stämmer något, 4 = Stämmer bra, 5 = Stämmer mycket bra. Sista kolumnen visar medelsvaret hos deltagarna.

13 Svarsalternativ Medelsvar Hur viktigt tycker du det är att testa GUI vid programvaruutveckling? ,9 Tabell 4. Visar hur många personer som kryssat för respektive val i den aktuella frågan. 1 = Mycket onödigt, 2 = Ganska onödigt, 3 = Ganska viktigt, 4 = Mycket viktigt. Sista kolumnen visar medelsvaret hos deltagarna. Från de fria kommentarerna hos projektmedlemmarna går det att dra slutsatsen att den del av Abbot som fungerade sämst under projektet var scripteditorn Costello. Denna ansågs ha buggar, dåliga felmeddelanden och ett icke användavänligt gränssnitt. Troligtvis har detta påverkat helhetsintrycket av verktyget. En annan aspekt som troligtvis har påverkat gruppens intryck av Abbot var att testen utvecklades efter GUI:t. En av Abbots styrkor är att GUI-testen med fördel kan utvecklas innan själva GUI:t men då detta inte skedde i projektet fick gruppen aldrig uppleva denna fördel. 6. Framtiden Eftersom grafiska användargränssnitt inte fanns i samma utsträckning för några årtionden sedan, är testningen av sådana något som är relativt nytt. Speciellt är verktyg för automatisering av GUI-test något som fortfarande håller på att utvecklas och därför kommer antagligen fler och mer omfattande verktyg dyka upp på marknaden i framtiden. Vi förutspår även att framtiden för med sig mer automatisering under testningsprocessen. Idag är det mycket fokus på bland annat inspelning/uppspelnings-metoder 6 men det finns redan idag program som försöker skapa testfall utifrån kod eller andra artefakter 11. Dessa kommer antagligen utvecklas ytterligare och på så sätt snabba upp testningen ännu mer. Vi kan inte tänka oss att testningen av GUI kommer upphöra i framtiden, eller att betydelsen av användargränssnitt kommer minska. Snarare tror vi på att GUI får en ännu viktigare roll i konsumentprodukter. Vi tror på en intressant och händelserik framtid för automatiserad GUItestning. 7. Slutsats Utvärderingen av GUI-testningsverktyg genomfördes på två olika sätt av utvecklingsgrupperna. I teamet som utvärderade jfcunit fick två utvecklare ansvaret för att lära sig verktyget och skriva testerna. I det andra teamet fick hela gruppen ett gemensamt ansvar och alla var tvungna att lära sig att skriva GUI-test. Den stora fördelen med att hela utvecklingsgruppen fick lära sig testverktyget var att det var möjligt att få ett mycket större antal svar på enkäten i slutet vilket bidrog till att det gick att utläsa ett mycket mer tillförlitligt svar på frågorna än när bara två utvecklare svarade på den som i jfcunit fallet. Anledningen till de olika utvärderingssätten var att de två projektgrupperna hade olika kunder som de levererade produkten till och dessa kunder ställde olika krav. I projektgruppen som utvärderade Abbot var kunden beredd att betala för

14 att få stabilitet i GUI:t och därmed beredd att betala för GUI-testen medan kunden i den andra gruppen inte betalade för denna aktivitet. Från enkätsvaren går det också att se att det verkar som att Abbot är svårare att lära sig att använda än vad jfcunit är. Tre stycken av utvecklarna som använde sig av Abbot tyckte att det var svårt att sätta sig in i, medans de två utvecklarna som använde jfcunit tyckte det var rätt så lätt att sätta sig in i verktyget. Anledningen till denna skillnad mellan verktygen kan bero på att de två utvalda projektmedlemmarna som testade jfcunit var mer intresserade av testning då de självmant tog på sig uppgiften att utvärdera verktyget. Av utvärderingsenkäten går det att dra några gemensamma slutsatser om GUI-testning. Intressant att notera är att ingen av projektgrupperna tyckte att testerna hjälpte speciellt mycket i projektet. Detta är sannolikt inte en kommentar om testningen i allmänhet utan beror troligare på projektens utformning och dess avsaknad av ett omfattande GUI i utvecklingsarbetet. Förhoppningen var från början att en rekommendation skulle kunna göras gällande vilket verktyg som var att föredra, men detta har visat sig vara svårt. De båda verktygen har sina egna för- och nackdelar vilket leder till att en tydlig rekommendation inte går att ge. Fördelen med jfcunit är att testerna skrivs som vanliga JUnit-test vilket innebär att en utvecklare som har använt sig av JUnit tidigare inte kommer att ha några stora problem med att börja använda sig av jfcunit. Abbots stora fördel är tillgången till scripteditorn Costello där testfallen kan spelas in och sedan modifieras genom att förändra den genererade koden. Tyvärr ansågs denna fördel också vara den största nackdelen med verktyget och därför är det svårt att rekommendera det för framtida projekt. För att kunna göra en rekommendation av ett verktyg på ett korrekt sätt skulle utvärderingen haft ett annat tillvägagångssätt. Hade båda projektgrupperna fått utvärdera båda verktygen kunde en mer korrekt jämförelse gjorts och respektive verktygs för- och nackdelar hade varit tydligare. Tyvärr valdes inte detta förfarande då författande ansåg detta ta för mycket tid från de två projekten. I kommande projekt som liknar de som presenterats här rekommenderas det att använda ett testningsverktyg som använder sig av inspelnings/uppspelnings-metoden. Detta därför att utseendet på det grafiska användargränssnittet inte förändras i så stor utsträckning och om det förändras kan ett nytt testfall spelas in och det gamla kasseras. Troligtvis kommer detta minska projektets kostnader jämfört med om tid läggs ned på att skapa dynamiska och avancerade tester genom hela projektet.

15 Referenser 1 Caswell, Matt; Aravamudhan, Vijay; Wilson, Kevin; Introduction to jfcunit; 2004; hämtad Wall, Timothy; Getting Started with the Abbot Java GUI Test Framework; 2008; hämtad Kursplan: Programvaruutveckling i grupp - projekt; hämtad hämtad Gerrard, Paul; Testing GUI Applications; EuroSTAR; Ruiz, Alex; Price, Yvonne Wang; GUI Testing Made Easy; Testing: Academic&Industrial Conference - Practice and Research Techniques, pages ; Ruiz, Alex; Price, Yvonne Wang; Test-Driven GUI Development with TestNG and Abbot; Oracle Corp., Redwood Shores, CA, USA; Li, Kanglin; Wu, Mengqi; Effective GUI Test Automation: Developing an Automated GUI Testing Tool, Chapter 2; SYBEX Inc., Alameda, CA, USA; hämtad hämtad GUITAR - A GUI Testing Framework; hämtad fest - Fixtures for Easy Software Testing; hämtad Squish - The cross-platform GUI test automation tool; hämtad

16 Appendix A: Frågeformulär