Automatiserade GUI-tester i praktiken Nivå: Kandidat
En fallstudie på Triona AB
Automated GUI-testing in practice – a case study at Triona AB
Författare: Robin Borg, Eva Dahl Thomas Handledare: Joonas Pääkkönen
Examinator: Pär Eriksson Ämne/huvudområde: Informatik Kurskod: GIK28T
Poäng: 15hp Examinationsdatum:
Vid Högskolan Dalarna finns möjlighet att publicera examensarbetet i fulltext i DiVA.
Publiceringen sker open access, vilket innebär att arbetet blir fritt tillgängligt att läsa och ladda ned på nätet. Därmed ökar spridningen och synligheten av examensarbetet.
Open access är på väg att bli norm för att sprida vetenskaplig information på nätet.
Högskolan Dalarna rekommenderar såväl forskare som studenter att publicera sina arbeten open access.
Jag/vi medger publicering i fulltext (fritt tillgänglig på nätet, open access):
Ja ☒ Nej ☐
Högskolan Dalarna – SE-791 88 Falun – Tel 023-77 80 00
Sammanfattning
Testning är en nödvändig men kostsam del av mjukvaruutveckling. Test utförs på olika abstraktionsnivåer och kan vara manuella eller automatiserade. På lägsta abstraktionsnivå, enhetsnivå, är automatiserad testning vanligt och relativt okomplicerat, medan
systemtester är svårare att automatisera. I synnerhet gäller detta tester på ett grafiskt användargränssnitt (GUI) som kräver speciella verktyg.
Triona vill undersöka möjligheterna att automatisera regressionstester från GUI:t av sin produkt C-Load, en molnbaserad webbtjänst för avtalsbaserad transportbokning.
Det primära syftet med denna fallstudie är att med en anpassad urvalsprocess utvärdera ett möjligt verktyg i förhållande till C-Load-förvaltningens förväntningar på automatiserad GUI testning (AGT) och att utifrån resultatet föreslå hur C-Load- förvaltningen kan gå vidare med val av verktyg för AGT. För att uppfylla syftet användes litteraturstudier, intervjuer och observationer av praktiska test.
Verktyg för GUI-testning kan delas in i tre huvudkategorier: skriptbaserade, modellbaserade och skriptlösa. Baserat på tidigare forskning drogs slutsatsen att ett skriptbaserat verktyg där koden i testskripten skrivs manuell bäst passar C-Load- förvaltningens krav och förutsättningar. Det mest använda verktyget av denna typ, Selenium WebDriver, utvärderades kvalitativt gentemot identifierade krav.
Av tidigare forskning framgår att vanliga utmaningar med skriptbaserade GUI-tester är att arbetsinsatsen för att skapa och underhålla testskript är stor och att testen kan vara opålitliga. Dessa problem framkom också i studiens intervjuer och observationer.
Slutsatsen är att det vore möjligt att automatisera regressionstester av C-Load med hjälp av Selenium Webdriver, och att det på sikt skulle kunna frigöra tid. Initialt krävs dock en omfattande insats för att implementera automatiserade tester i
förvaltningen och Selenium Webdriver uppfyller bara delvis C-Load-förvaltningens förväntningar på AGT. C-Load-förvaltningen rekommenderas att utvärdera fler verktyg innan beslut fattas. I en kommande urvalsprocess bör Triona beakta hur väl olika verktyg fungerar i förhållande till moderna webbramverk.
Nyckelord: automatiserad GUI-testning, Selenium Webdriver, automatiserade test, automatiserade regressionstest, verktyg för automatiserade GUI-test
Abstract
Testing is a necessary but costly part of software development. Tests are performed at different abstraction levels and can be either manual or automated. On the lowest level of abstraction, where unit testing is performed, automated testing is commonplace and relatively uncomplicated, whereas system testing is more difficult to automate. This is especially true for GUI-testing, which requires special tools.
Triona wished to investigate possibilities to automate regression testing of the GUI for its C-load product, which is a Cloud-based web-service for contract-based transport booking.
The purpose of this case study was to evaluate one tool for automated GUI-testing (AGT) against the C-Load team’s expectations on AGT, and based on the result recommend Triona how to proceed in the process of implementing AGT. Literature studies, observations and interviews were conducted to fulfil the purpose.
GUI-testing tools can be classified into three categories: script-based, model-based and scriptless. One conclusion was that a script-based tool, where test scripts are manually coded would best suit Triona’s needs. The most used tool in that
category, Selenium WebDriver, was tested and evaluated against requirements.
Prior research shows that common challenges encountered when using script-based GUI- tests are the workload required to create and maintain test scripts and that the tests can deliver inconsistent or “flaky” results. These challenges were confirmed during our analysis.
Our conclusion is that it is possible to automate C-Load regression tests with
Selenium WebDriver, and that it would eventually free up time. However, a considerable effort is initially required to implement automated
testing. Selenium Webdriver only partly fulfills the C-Load team’s expectations on AGT. Before a decision is taken, the C-Load team should evaluate more tools. When evaluating tools for AGT, Triona should take note that Selenium Webdriver can be deficient when it comes to testing applications based on modern web frameworks.
Keywords: automated GUI-testing, Selenium Webdriver, automated tests, automated regression tests, tools for automating GUI-tests
Förord
Med detta examensarbete avslutar vi vår utbildning på det systemvetenskapliga programmet vid Högskolan Dalarna. Vi vill tacka programansvarige Pär Eriksson för tre roliga och lärorika år.
Vi vill också rikta ett stort tack till Triona AB i Borlänge för att vi fick möjligheten att göra vårt examensarbete hos er. Särskilt tack till vår handledare Mirjami Olsson för stöd och vägledning under arbetets gång.
Slutligen vill vi tacka vår handledare på Högskolan Dalarna, Joonas Pääkkönen för goda råd.
Robin Borg och Eva Dahl Thomas, juni 2020
Begreppslista
AGT Automatiserad GUI-testning / Automated GUI-testing (Dobslaw et al, 2019).
DOM HTML Document Object Model. När en webbsida laddas in så skapas en dokumentmodell av sidan. Modellen fungerar som ett träd av objekt (W3Schools, 2020).
Förvaltning Ett uppdrag som ofta inkluderar både vidmakthållande och vidareutveckling utan något definierat slutdatum (M. Olsson, personlig kommunikation, 14 maj, 2020).
GUI Grafiskt Användargränssnitt / Graphical User Interface (Dobslaw et al, 2019).
NuGet Av Microsoft supporterad mekanism för att dela kod inom .NET. Ett NuGet- programpaket är en zip-fil med ändelsen nupkg, som bl.a.
innehåller kompilerad kod (Microsoft, 2019a).
POM Page object model, desginmönster som förbättrar underhållbarheten och minskar mängden kod-duplikation (Selenium, 2020b).
Projekt Ett uppdrag, ofta inkluderat utveckling, med definierat start- och slutdatum (M. Olsson, personlig kommunikation, 14 maj, 2020).
Testorakel Mekanism som kontrollerar att villkoren för att ett testfall har uppfyllts (Orakel, 2020).
VGT Visuell GUI-testning / Visual GUI-testing (Alégroth, 2015).
W3C World Wide Web Consortium (W3C) är ett internationellt samarbete där organisationer, heltidsanställda och allmänheten arbetar tillsammans för att utveckla webbstandarder. (W3C, u.å).
Innehållsförteckning
BEGREPPSLISTA ... I
1 INTRODUKTION ... 1
1.1 BAKGRUND ... 1
1.2 PROBLEMFORMULERING OCH SYFTE ... 3
1.3 FORSKNINGSFRÅGOR ... 4
1.4 KUNSKAPSBIDRAG ... 4
1.5 AVGRÄNSNINGAR ... 5
1.6 MÅLGRUPP ... 5
2 TEORETISK REFERENSRAM ... 6
2.1 VAD ÄR GUI-TEST? ... 6
2.2 TESTPYRAMIDEN ... 6
2.3 TRE TYPER AV VERKTYG FÖR AUTOMATISERADE GUI-TEST ... 7
2.3.1 Skriptbaserad GUI-testning ... 7
2.3.1.1 Record & Replay vs manuellt skriven kod ... 7
2.3.1.2 Komponentbaserade vs visuella verktyg ... 8
2.3.1.3 Page Object Model ... 10
2.3.2 Modellbaserad GUI-testning ... 10
2.3.3 Skritplös GUI-testning ... 11
2.4 SELENIUM ... 11
2.4.1 WebDriver ... 13
3 METOD ... 14
3.1 FORSKNINGSPROCESSEN ... 14
3.2 ANPASSAD URVALSPROCESS ... 15
3.3 FORSKNINGSSTRATEGI ... 17
3.4 LITTERATURSTUDIE ... 18
3.5 DATAINSAMLING ... 18
3.5.1 Intervjuer ... 18
3.5.1.1 Urval ... 19
3.5.2 Observationer ... 19
3.6 DATAANALYS ... 20
4 RESULTAT DEL 1 ... 22
4.1 IDENTIFIERA PROBLEM ... 22
4.2 DEFINIERA KRAV ... 22
4.2.1 Teknik ... 22
4.2.2 Arbetssätt ... 22
4.2.3 Förväntningar på AGT ... 23
4.2.4 Identifierade krav ... 23
4.3 ANALYS DEL 1 ... 24
5 DISKUSSION DEL 1 ... 26
5.1 SVAR PÅ FORSKNINGSFRÅGA 1 ... 27
6 RESULTAT DEL 2 ... 28
6.1 INTERVJUER OCH OBSERVATIONER ... 28
6.1.1 Intervjuer ... 28
6.1.1.1 Intervju med arkitekt och utvecklare Hansi Henningson ... 28
6.1.1.2 Intervju med utvecklare Pontus Berglund ... 28
6.1.1.3 Intervju med testare och kravanalytiker Cecilia Landberg ... 29
6.1.1.4 Intervju med utvecklare Olle Eriksson ... 30
6.1.2 Observationer ... 31
6.1.2.1 Tillvägagångssätt ... 31
6.1.2.2 Observationer per tema ... 32
6.2 ANALYS DEL 2 ... 34
6.2.1 Applicerbarhet ... 34
6.2.2 Webbläsare ... 34
6.2.3 Exekveringstid... 34
6.2.4 Total tid för testrelaterat arbete ... 35
6.2.4.1 Arbetsbörda med att skapa testskript ... 35
6.2.4.2 Arbetsbörda med att underhålla testskript ... 35
6.2.4.3 Opålitliga testskript ... 35
6.2.5 Teststrategi ... 36
7 DISKUSSION DEL 2 ... 37
7.1 SVAR PÅ FORSKNINGSFRÅGA 2 ... 39
7.2 NÄSTA STEG ... 39
7.3 FÖRANKRING OCH GENERALISERING ... 40
7.4 METODKRITIK ... 40
7.5 VIDARE FORSKNING ... 41
8 SLUTSATSER ... 42
KÄLLFÖRTECKNING ... 43
Bilaga 1: Intervjuguide
Bilaga 2: Kodexempel Page Object Model Bilaga 3: Transkriberingar av intervjuer
1 Introduktion
I detta kapitel beskrivs bakgrunden till studien. Studiens syfte och de forskningsfrågor som ska besvaras presenteras. Studiens kunskapsbidrag, avgränsning och målgrupp beskrivs också.
1.1 Bakgrund
Triona AB är ett IT-företag som kombinerar verksamhetskunnande inom framför allt transportinfrastruktur, trafik, transporter, skogsindustri och energi-/fordonsindustri med spetskompetens inom systemutveckling och systemförvaltning. En av Trionas produkter är webbtjänsten C-Load, en transportbokningsportal för avtalsbaserade transporter via bil, container (sjö) och tåg. Vid varje uppdatering av applikationen måste regressionstester köras för att kontrollera att uppdateringen inte orsakat fel i befintlig funktionalitet. Testare genomför då manuellt i C-Loads grafiska användargränssnitt (GUI) de steg som
specificeras i utvalda testfall. Eftersom C-Load finns på fem språk och måste fungera i fyra olika webbläsare blir dessa regressionstester omfattande och repetitiva. Att som idag utföra regressionstesterna helt manuellt är tidskrävande och risk för misstag föreligger.
Triona vill därför undersöka möjligheten att automatisera delar av regressionstesterna.
Vad innebär det då att automatisera regressionstester av mjukvara? Mjukvarutestning är processen att analysera funktionaliteten av hela eller delar av ett system med syftet att se om den utvecklade mjukvaran stämmer överens med de krav som finns (IEEE, 1994).
“Mjukvarutestning görs för att hitta så många fel som möjligt innan användarna hittar dem. Ju tidigare felen hittas, desto mindre kostar de att åtgärda” (Eriksson, 2008, s. 19).
Testning är en nödvändig men kostsam del av mjukvaruutveckling. Generellt står testning för 20 - 50% av kostnaden i ett utvecklingsprojekt (Ellims, Bridges & Ince, 2006).
Figur 1 visar den s.k. V-modellen, som illustrerar hur mjukvarutestning sker på olika nivåer och hur olika typer av testning är kopplade till steg i utvecklingsprocessen.
Figur 1. V-modellen illustrerar att mjukvarutestning sker på olika nivåer, kopplade till steg i utvecklingsprocessen. Efter Eriksson (2008).
V-modellens olika testtyper beskrivs av Eriksson (2008):
Komponenttest(enhetstest): Utvecklarna testar ett systems minsta beståndsdelar.
En komponent i taget.
Integrationstestning: När komponenterna är testade testas integrationen mellan samverkande komponenter.
Systemtestning: Systemtest omfattar flera aktiviteter, exempelvis övergripande test av samtliga funktioner, prestandatester och användbarhetstester.
Acceptanstester: Här testas, oftast av användarna, om kraven är uppfyllda så att systemet kan tas i bruk.
Utöver de ovan beskrivna testtyperna, som alltså sker på en viss nivå, tillkommer regressionstester, som verifierar att ändringar gjorda på systemet inte har haft oönskade effekter. Regressionstester kan ske på alla nivåer.
Mjukvarutest kan vara manuella eller automatiserade. Vid manuella tester använder en människa systemet och kontrollerar att det fungerar som avsett. Vid automatiserade tester används speciell mjukvara som styr exekveringen av systemet och jämför faktiskt resultat med förväntat resultat. Utöver exekvering och kontroll av resultat kan även design av testfall, skapandet av testskript och rapportering av resultat automatiseras (Garousi &
Mäntylä, 2015).
Enligt Alégroth (2015) finns det två huvudsakliga motiv till att automatisera tester: Att förbättra mjukvarans kvalitet och att sänka kostnaderna. Automatisering kan bidra till högre kvalitet genom att testerna går snabbare att köra och därmed kan köras oftare. När tester körs oftare hittas defekter tidigare. Därmed minskar risken för att defekter finns med i kod som levereras till kund. Dessutom blir det lättare att felsöka koden, eftersom risken minskar för att flera fel samverkar och skapar särskilt svårupptäckta fel. Kostnader kan sänkas genom att minska mängden manuellt arbete. Dock är det inte givet att
automatisering alltid är lönsamt, eftersom det medför såväl initiala som löpande kostnader (Alégroth, 2015; Dobslaw et al., 2019). Alégroth (2015) påpekar att automatisering kan leda till att kostnaderna för test ökar, men att den totala kostnaden för utveckling och test minskar, tack vare att defekter hittas snabbare.
Aho och Vos (2018) liksom Dobslaw et al. (2019) konstaterar att automatiserad enhetstestning är vanligt, men att systemtester är svårare att automatisera. I synnerhet gäller detta GUI-tester. Svårigheten med GUI-tester ligger enligt Prabhu och Malmurugan (2013) framförallt i att de är händelsedrivna istället för datadrivna. Händelser triggas av användarens interaktion med applikationen via GUI:t och speciella verktyg krävs för att simulera detta. Att kontrollera att det som visas i GUI:t är korrekt är en enkel uppgift för en människa men inte för ett verktyg (Algéroth, 2015). En annan svårighet är att även automatiserade GUI-test tar betydlig längre tid än enhetstester, eftersom man hela tiden måste vänta på att GUI:t ska uppdateras (Aho & Vos, 2018).
Som en följd av att iterativa metoder och kontinuerlig integration används mer och mer i systemutvecklingsprojekt har utvecklingscyklerna på senare tid blivit allt kortare, vilket lämnar mindre tid för test och kvalitetskontroll (Aho & Vos, 2018). Samtidigt har systemen som utvecklas blivit mer komplexa och mer krävande att testa. För att kunna hantera en större mängd test på kortare tid är det nödvändigt att minska det manuella
inslaget i tester även på GUI-nivå (Aho & Vos, 2018). Att automatisering av regressions- och GUI-tester är ett område med hög aktivitet bekräftas också av Cap Gemini, Sogeti och Micro Focus (2019) som kartlagt trender inom kvalitetssäkring och test med hjälp av en undersökning där 1725 IT-chefer deltog.
1.2 Problemformulering och syfte
Intresset för att automatisera GUI-tester är således stort och växande, inte bara hos Triona.
Att välja verktyg för automatisering är dock inte en enkel uppgift. Raulamo-Jurvanen, Mäntylä och Garousi (2017) konstaterar att det finns ett stort antal verktyg att välja mellan, och att hitta det rätta verktyget för ett givet fall är svårt. Processen för att välja verktyg går enligt Raulamo-Jurvanen et al. (2017) i korthet ut på att identifiera ett antal möjliga kandidater, jämföra dessa med varandra och slutligen välja det verktyg som bedöms vara mest lämpligt och effektivt i det aktuella fallet. Baserat på Raulamo- Jurvanen et al.:s (2017) resultat kan en typisk urvalsprocess se ut enligt figur 2.
Figur 2. Process för att välja verktyg för testautomatisering, baserad på Raulamo- Jurvanen et al. (2017).
Att följa denna process kräver att krav och utvärderingskriterier specificeras och att potentialen hos möjliga verktyg bedöms. Detta låter sig inte göras på ett detaljerat och tillförlitligt sätt utan kunskap eller tidigare erfarenhet av automatiserad GUI-testning (AGT). Raulamo-Jurvanen et al. (2017) understryker att tidigare erfarenheter och kunskap bör användas för att välja rätt verktyg. Även Alégroth (2015) och Vos, Marín, Escalona och Marchetto (2012) betonar vikten av empirisk erfarenhet för att kunna utvärdera tekniker och verktyg. Vos et al. (2012) påpekar att andras erfarenheter i större utsträckning skulle kunna användas om det fanns fler fallstudier som beskriver erfarenheter av att använda verktyg.
Två problem har alltså identifierats:
1. Triona behöver välja ett verktyg för att komma igång med automatiserade GUI- tester. Detta är en icke trivial uppgift, speciellt då tidigare erfarenhet av AGT saknas.
2. Det finns ett behov av fler fallstudier som beskriver erfarenheter av att använda verktyg för test av mjukvara.
På grund av begränsad kunskap och obefintlig erfarenhet av AGT hos både C-Load- förvaltningen och författarna till den här studien, är det inte möjligt att göra en fullständig urvalsprocess avseende verktyg för AGT inom studiens tidsram. Det primära syftet med studien är därför att med en anpassad urvalsprocess utvärdera ett möjligt verktyg i
förhållande till C-Load-förvaltningens förväntningar på AGT och att utifrån resultatet föreslå hur C-Load-förvaltningen kan gå vidare med val av verktyg för AGT. Detta syfte avser att bidra till att lösa det första identifierade problemet.
Ett sekundärt syfte med studien är att bidra till den samlade kunskapen om hur verktyg för GUI-test fungerar i praktiken, genom att beskriva de erfarenheter som görs i denna fallstudie. Detta syfte avser att bidra till att lösa det andra identifierade problemet.
1.3 Forskningsfrågor
Verktyg för AGT kan enligt Aho och Vos (2018) delas in tre typer: skriptbaserade, modellbaserade och skriptlösa. I den anpassade urvalsprocessen ersätts steget “Identifiera möjliga verktyg” med att besvara den mer grundläggande frågan: Vilken typ av verktyg för automatiserade GUI-test bedöms, baserat på tidigare forskning, som den mest lämpliga för att introducera AGT på Trionas produkt C-Load? Detta är den första forskningsfrågan som avses besvaras med studien.
Då analysen av den första forskningsfrågan pekade på ett skript- och komponentbaserat verktyg där kod skrivs manuellt skulle passa C-Load-förvalningens behov bäst, gjordes valet att testa det mest använda verktyget i den kategorin: Selenium WebDriver. Motivet till detta var bland annat att Selenium WebDriver är en defacto-standard för AGT. Därmed är det en lämplig referens, och det är inte troligt att Triona skulle välja ett annat verktyg av den typen utan att först ha testat Selenium WebDriver.
Den andra forskningsfrågan som avses besvaras är: Kan C-Load-förvaltningens förväntningar på AGT uppfyllas med Selenium WebDriver?
Studiens forskningsfrågor lyder således:
1. Vilken typ av verktyg för automatiserade GUI-test bedöms, baserat på tidigare forskning, som den mest lämpliga för att introducera AGT på Trionas produkt C- Load?
2. Kan C-Load-förvaltningens förväntningar på AGT uppfyllas med Selenium WebDriver?
1.4 Kunskapsbidrag
Studien sammanfattar tidigare forskning om olika metoder och verktyg för AGT, vilket möjliggör informerade bedömningar av vilken typ av verktyg som passar i en given situation. Studien bidrar också med beskrivningar som ger en grundläggande förståelse för hur Selenium WebDriver fungerar i praktiken. Beskrivningarna är användbara främst för den som helt saknar eller har liten erfarenhet av AGT. Delar av diskussionen om hur Triona kan gå vidare för att implementera AGT kan generaliseras till andra fall.
1.5 Avgränsningar
Ingen utredning görs av huruvida automatiserade tester är det bästa sättet att lösa de utmaningar Triona beskriver. Om Triona ser ett behov av en sådan utredning kan resultatet av denna studie användas som en del av underlaget. Studien omfattar endast
regressionstestning. Verktyget som testas har bara använts på desktopversionen av C- Load, inte mobilversionen. Verktyget testas fristående och inte som en del av den faktiska testprocessen. Studien omfattar bara ett fåtal utvalda testfall. Om övriga testfall som kan bli aktuella för automatisering innebär särskilda utmaningar har inte undersökts.
1.6 Målgrupp
Studiens målgrupp är främst personer som har intresse för, men begränsad erfarenhet av AGT. För att ha behållning av rapporten bör läsaren ha grundläggande kunskaper om systemutveckling, programmering och webbteknik.
.
2 Teoretisk referensram
I detta kapitel förklaras vanliga begrepp inom AGT och tidigare forskning som är relevant för att besvara forskningsfrågorna presenteras.
2.1 Vad är GUI-test?
Med begreppet GUI-testning avses att testa ett system från dess GUI. GUI-test utförs genom att utföra operationer på GUI:ts komponenter, t.ex. klicka på knappar, och kontrollera att systemets tillstånd ändras på det sätt som förväntas (Nguyen, Robbins, Banerjee & Memon, 2014).
Testfall för GUI-tester skapas genom att specificera vilken sekvens av operationer på GUI:ts komponenter som ska utföras, och vilket tillstånd systemet förväntas befinna sig i efter dessa operationer. Hur det verkliga tillståndet ska jämföras med det förväntade tillståndet för att avgöra om testet är godkänt kallas testorakel (Xie & Menon, 2007).
2.2 Testpyramiden
Garousi och Yildirim (2018) refererar till Cohn (2010) när de presenterar testpyramiden, se figur 3.
Figur 3. Testpyramiden illustrerar ett lämpligt principiellt förhållande mellan antalet automatiserade test på olika nivåer. Efter Garousi och Yildirim (2018).
Den ursprungliga testpyramiden handlar enligt Fowler (2018) om både manuella och automatiserade test, men Garousi och Yildirim (2018) använder den för att diskutera idén att testautomation bör byggas upp nedifrån, så att ett stort antal enhetstester bör
automatiseras men ju högre upp i pyramiden man kommer, desto färre testfall bör automatiseras. Anledningen till att färre testfall bör automatiseras högre upp i pyramiden är enligt Garousi och Yildirim (2018) att kostnaden för att utveckla och underhålla test, tiden det tar att köra test och risken för att fel missas är större högre upp i pyramiden.
Samtidigt är tester på högre nivå mer relevanta ur ett användarperspektiv och täcker en
större del av systemet som testas. Det är enligt Garousi och Yildirim (2018) en svår avvägningsfråga hur mycket som ska automatiseras på varje nivå. Berner, Weber och Keller (2005) poängterar att en i bra strategi för testautomation kombineras
automatiserade tester på olika nivåer: enhetstest, integrationstest och systemtest. Även Alégroth, Gao, Oliveira, & Memon (2015) konstaterar att det är nödvändigt att utföra test på olika nivåer av systemabstraktion, med olika metoder och verktyg (Alégroth et al., 2015). Alégroth et al. (2015) anser inte att GUI-test helt kan automatiseras, utan ser ett behov av explorativa manuella tester. Med ökat fokus på kontinuerlig integration ser dock Alégroth et al. (2015) ett framtida behov av verktyg som möjliggör fullt ut automatiserade GUI-test.
2.3 Tre typer av verktyg för automatiserade GUI-test
Att utföra GUI-tester manuellt tar lång tid, är enahanda och innebär risk för slarvfel (Dobslaw et al, 2019). Som konstaterades i inledningen finns det därför ett behov av att automatisera GUI-tester, vilket kräver särskilda verktyg som simulerar användarens interaktion med GUI:t. Aho och Vos (2018) delar in verktyg för AGT i tre kategorier utifrån vilken teknik och grad av automation som används för att generera testfall:
Skriptbaserat
Modellbaserat
Skriptlöst
2.3.1 Skriptbaserad GUI-testning
Skriptbaserade ramverk är enligt Aho och Vos (2018) de mest använda i industrin.
Testskript skapas genom att omvandla manuellt skrivna testfall till kod. Det är alltså bara själva exekveringen som automatiseras, medan testskripten skapas manuellt. Testfall kan skapas genom att skriva kod för hand eller genom att använda ett så kallat Record &
Replay-verktyg. Oavsett om testfallen skapas med kod eller Record & Replay kräver det mycket arbete (Aho & Vos, 2018). När GUI:t förändras måste testfallen uppdateras.
Arbetet med att underhålla testskript är enligt Aho & Vos (2018) den största utmaningen med att använda skriptbaserad GUI-testning. Kostnaden för att underhålla testskripten beror enligt Dobslaw et al. (2019) på storlek och frekvens av ändringar i GUI:t.
En annan stor utmaning är så kallade “flaky tests”. Det är test som är icke-deterministiska, d.v.s. de ger inte alltid samma resultat, även om testad kod och indata är de samma (Mascheroni & Irrazábal, 2018). Vi kallar hädanefter dessa test för opålitliga test. Det finns många anledningar till att test blir opålitliga, men en typisk orsak är att ett testskript försöker hitta ett element i GUI:t innan sidan har laddat klart (Mascheroni & Irrazábal, 2018; Presler-Marshall, Horton, Heckaman & Stolee, 2019). Debroy et al. (2018) förklarar att det kan verka vara en bra lösning att helt enkelt pausa skriptet en viss tid för att element ska hinna laddas, men att detta inte är en bra lösning, då man i princip alltid kommer att vänta onödigt länge eller för kort tid.
2.3.1.1 Record & Replay vs manuellt skriven kod
I Record & Replay-verktyg utförs stegen som ska ingå i testfallet manuellt och verktyget spelar in hela förloppet, som sedan kan spelas upp igen. Under inspelningen kan testaren skapa testorakel genom att ange vad som ska sparas som förväntat resultat. Vissa Record
Commented [EDT1]: Stycke borttaget
& Replay-verktyg innehåller funktionalitet för att redigera koden som skapats vid inspelningen. Thummalapenta, Sinha, Singhania och Chandra (2012) konstaterar att manuellt kodade skript och Record & Replay skiljer sig åt avseende krav på programmeringskunskaper och grad av kontroll. Record & Replay kräver inga
programmeringskunskaper men ger mindre kontroll än att skriva koden för hand. Debroy et al. (2018) beskriver hur de testade Record & Replay med Selenium IDE och upplevde bristen på kontroll över de selektorer som används för att identifiera element som ett problem. Den genererade koden var också klumpig och svår att underhålla.
Thummalapenta et al. (2012) påpekar att skript skapade med Record & Replay tenderar att vara sköra, d.v.s. de slutar lätt att fungera även vid små förändringar av GUI:t.
Utifrån en empirisk jämförelse mellan Record & Replay-verktyg och verktyg där koden skrivs för hand konstaterar Leotta, Clerissi, Ricca och Tonella (2013) att kodade testfall tar längre tid att skapa, men är mindre krävande att underhålla. I de fall Leotta et al.
(2013) studerade var den totala kostnaden för att skapa och underhålla skript lägre för de kodade verktygen än för Record & Replay-verktygen efter i genomsnitt två releaser.
2.3.1.2 Komponentbaserade vs visuella verktyg
Skriptbaserade ramverk kan enligt Dobslaw et al. (2019) också delas in i tre generationer utifrån vilken teknik som används för att identifiera de GUI-komponenter som används i testet, d.v.s. knappar, textboxar etc.
Den första generationens verktyg använde koordinater i GUI:t för att identifiera
komponenter. Denna typ av verktyg var enkla att komma igång med, men skripten krävde mycket underhåll eftersom de var väldigt sköra och måste göras om vid minsta ändring av GUI:t. Första generationens verktyg används därför inte längre.
Den andra generationens verktyg identifierar GUI-element genom referenser till den underliggande koden som definierar komponenterna, t.ex. Java Swing-objekt eller objekt i en webbsidas document object model (DOM) (Dobslaw et al., 2019). Alégroth (2015) kallar den andra generationens verktyg för komponentbaserade, en beteckning som också används i rapporten. Denna typ av verktyg ger betydligt stabilare testskript än första generationens teknik och används mycket i industrin.
Den tredje generationen kallas Visuell GUI-testning (VGT) och använder bildigenkänning för att identifiera GUI-komponenter. Testfall beskrivs med bilder av GUI:t och
kommandon som att klicka, dra etc. Denna typ av verktyg är ett försök att hitta en mellanväg där tröskeln för att börja använda tekniken inte är för hög, samtidigt som testskripten inte är alltför sköra. Den stora skillnaden mellan komponentbaserade verktyg och VGT är att i VGT agerar verktyget mot och kontrollerar korrektheten i den bild som faktiskt syns på skärmen, medan i andra generationens verktyg är det den underliggande koden som kontrolleras. Denna skillnad illustreras i figur 4 (Alégroth, 2015).
Figur 4. Teoretisk modell av ett system och dess lager samt manuella och automatiserade tekniker som vanligen används för att testa de olika lagren. Efter Alégroth (2015).
Alégroth (2015) utvärderade verktyg för VGT med hjälp av en rad fallstudier och experiment. Resultatet visar att verktyg för VGT jämfört med manuell testning har lika bra eller bättre förmåga att upptäcka defekter.
I en studie där komponentbaserade verktyg jämfördes med verktyg för VGT avseende bl.a. förmågan att upptäcka defekter, kom Alégroth et al. (2015) fram till att
komponentbaserade verktyg är bäst för systemtester, medan visuella verktyg är bäst för acceptanstester. Med systemtester avsågs tester som kontrollerar en applikations funktionalitet och med acceptanstester avsågs tester som kontrollerar både funktionalitet och utseende. Ett falskt positivt resultat innebär att testet fallerar trots att det borde ha passerat, d.v.s. falskt alarm. Ett falskt negativt resultat innebär att testet passerar trots att det borde ha fallerat, d.v.s. en defekt upptäcks inte. I studien fanns ingen signifikant skillnad mellan verktygen i antalet falskt positiva resultat för acceptanstest eller falskt negativa resultat för systemtest. Däremot gav det visuella verktyget signifikant fler falskt positiva resultat i systemtester och det komponentbaserade verktyget gav signifikant fler falskt negativa resultat i acceptanstester. Detta förhållande sammanfattas i figur 5.
Figur 5. Relationen mellan falskt positiva och falskt negativa resultat i system- respektive acceptanstest för ett komponentbaserat verktyg och ett visuellt verktyg.
Anledningen till att komponentbaserade verktyg genererar falskt negativa resultat i acceptanstester, där även utseendet ska kontrolleras, är att testen kan gå igenom trots att exempelvis en knapp är dold av ett annat element eller liknande. Detta eftersom komponentbaserade verktyg inte kontrollerar GUI:ts faktiska utseende. Verktyg för VGT å andra sidan generar fler falskt positiva resultat i systemtester eftersom visuella skillnader som inte är defekter gör att test ändå fallerar. Alégroth et al. (2015) konstaterar att
resultatet indikerar, men inte visar, att en kombination av verktygen skulle kunna användas för att effektivt automatisera både system- och acceptanstester.
Jämförelser av exekveringstid för komponentbaserade och visuella verktyg visar att komponentbaserade testskript exekveras tre till fyra gånger snabbare än visuella (Alégroth et al., 2015; Dobslaw et al., 2019). Att genomföra testfallen manuellt tog enligt Dobslaw et al. (2019) drygt dubbelt så lång tid som med det visuella verktyget. Även Alégroths (2015) resultat visar att visuella verktyg är snabbare än manuella tester, i ett av de beskrivna fallen 16 gånger snabbare.
För att undersöka hur VGT fungerar i praktiken på lång sikt gjorde Alégroth och Feldt (2017) en fallstudie på Spotify. Spotify, som levererar tjänster inom musikströmning, använde under flera år VGT med verktyget Sikuli, men övergav slutligen VGT till förmån för ett egenutvecklat komponentbaserat ramverk. Två av de främsta anledningarna till att Spotify övergav VGT var följande:
Skripten skapade med VGT har begränsad användbarhet för dynamiskt, icke deterministiskt innehåll. Icke deterministiskt innehåll vet man inte i förväg hur det kommer att se ut, och för att VGT ska fungera måste det finnas en bild sparad som beskriver den förväntade skärmbilden.
Att underhålla bilderna är krävande.
En nackdel som Spotify såg med att använda det komponentbaserade ramverket istället för VGT är att det inte verifierar att det användaren ser på skärmen verkligen är korrekt.
2.3.1.3 Page Object Model
Som tidigare nämnts är en stor nackdel med skriptbaserade metoder att skripten behöver underhållas. För att minska omfattningen av arbetet med att underhålla testskript är det vid manuell kodning vanligt att använda ett designmönster kallat Page Object Model (POM) (Debroy et al., 2018; Garousi & Yildirim, 2018; Leotta et al., 2013). För att minska kopplingen mellan testfall och applikationen som testas skapas så kallade Page Objects.
Page Objects är fasadklasser som abstraherar hela eller delar av webbsidor och innehåller metoder som kan användas av de klasser som innehåller testfallen. Alla detaljer om webbsidors implementation är inkapslad i Page Object-klasser, vilket innebär att när implementationen ändras är det ofta bara Page Object-klasserna som behöver ändras, medan testfallen är opåverkade. (Debroy et al., 2018; Leotta et al., 2013). I en studie av Leotta et al. (2013) gjorde introduktionen av POM att tiden för att anpassa koden minskade med en faktor 3 och antalet rader som behövde ändras med en faktor 8.
2.3.2 Modellbaserad GUI-testning
Modellbaserad testning är en metod för att automatisera skapandet av testfall (Janicki, Katara & Pääkkönen, 2012). Exekvering av skapade testfall kan vara automatiserad eller manuell. Först skapas en modell som beskriver systemet på en hög abstraktionsnivå, t.ex. i form av en finit tillståndsmaskin, och utifrån modellen skapas testfall med hjälp av lämplig algoritm.
Åtminstone i teorin är modellbaserad testning mer tidseffektivt och tillförlitligt än att skapa testfall manuellt (Janicki et al., 2011). Även arbetet med att underhålla testfall antas
minska med modellbaserad testning jämfört med skriptbaserad testning (Aho & Vos, 2018). Att skapa modeller från vilka det går att härleda fungerande testfall är dock en stor utmaning (Aho & Vos, 2018; Utting, Pretschner & Legeard, 2011). Modellen måste beskriva systemet korrekt och på rätt abstraktionsnivå. Om modellen är lika detaljerad som systemet fyller den ingen funktion, då den är lika svår att validera som systemet självt, och om modellen är för förenklad kan den inte användas för att skapa körbara testfall (Utting et al., 2011). Att skapa modellen kan göras enklare genom att extrahera den från en implementerad version av GUI:t och sedan använda testfallen på en senare version av GUI:t. Ett problem med en modell skapad på det sättet är att den inte inkluderar, och därmed inte testar, nya delar av GUI:t. Ett annat problem är att en sådan modell beskriver implementerad funktionalitet, vilket inte nödvändigtvis är detsamma som förväntad funktionalitet (Aho & Vos, 2018).
2.3.3 Skritplös GUI-testning
Vid skriptlös eller slumpmässig GUI-testning genereras test där verktyget utför handlingar i GUI:t i slumpmässig ordning och med slumpmässig input (Wetzlmaier & Ramler, 2017).
Syftet är att upptäcka fel som inte hittas med andra test. Metoden är enligt Aho och Vos (2018) billig att införa och kräver minimalt med underhåll eftersom inga testskript skapas.
Att köra testen tar dock lång tid.
De flesta verktyg för skriptlös testning stödjer inte manuellt definierade testorakel, utan kontrollerar bara att applikationen inte kraschar eller hamnar i ett läge där den inte svarar.
En utmaning i skriptlös GUI-testning är att få verktyget att göra effektiva val av handlingar som utförs. Målet är att hitta defekter så snabbt som möjligt, och ett helt slumpmässigt val av handlingar är inte det mest effektiva. Forskning pågår om hur generiska algoritmer, maskininlärning och artificiell intelligens kan användas för att göra skriptlösa verktyg mer effektiva (Aho & Vos, 2018). Wetzlmaier och Ramler (2017) rekommenderar att komplettera befintliga automatiserade regressionstester med skriptlösa test eftersom det gör det möjligt att upptäcka gömda fel med liten arbetsinsats.
2.4 Selenium
Det verktyg som valdes ut att användas i de praktiska test som ingår i studien var Selenium WebDriver, vilket är en del av Seleniumprojektet. I Seleniumprojektet finns det tre verktyg, WebDriver, IDE och Grid.
WebDriver är ett open source, skriptbaserat ramverk för webbautomation som kan köra tester mot alla webbläsare. WebDriver är en W3C rekommendation från och med 2018 (W3C, 2018) och är förmodligen det mest använda verktyget för AGT (Vila, Novakova &
Todorova, 2017) Skripten går att utveckla med Java, Python, C#, PHP, Ruby med flera språk. WebDriver tar emot de kommandon som finns i skripten och skickar dem till webbläsaren. Varje webbläsare har en egen så kallad “driver”, som tillåter WebDriver att styra webbläsaren utan att komma åt webbläsarens interna logik (Selenium, 2020a).
Selenium IDE är ett Record & Replay-verktyg som används för inspelning av testfall. Det går att skriva skript manuellt i IDE men för mer avancerade och robusta test behövs
WebDriver som ett komplement (Bhargava & Jain, 2018; Selenium, 2020a). Commented [EDT2]: Detaljer om IDE borttaget.
Selenium Grid är en proxyserver som gör det möjligt att parallellt köra test med olika webbläsare och olika operativsystem på multipla datorer eller virtuella maskiner (Selenium, 2020a).
Idag består Seleniumprojektet av Selenium IDE, Selenium Grid och WebDriver, även kallat Selenium 3. Figur 6 visar hur olika versioner av Selenium-verktygen hänger ihop och har utvecklats. Figuren bygger på en modell skapad av Zeng (2014). Selenium IDE är byggt på Selenium Core och har utvecklats parallellt med de andra verktygen. Den första versionen av Grid baserades på Selenium RC och WebDriver/Selenium 2, men i den andra versionen av Grid har man tagit bort Selenium RC, och Grid baseras nu bara på Selenium 3.
Figur 6. Modell som beskriver hur de olika delarna i Seleniumprojektet utvecklats.
Commented [EDT3]: Om hub och noder borttaget – kräver mer förklaring om det ska vara kvar
2.4.1 WebDriver
I detta avsnitt förklaras två centrala funktioner i Selenium WebDriver: att identifiera element och att hantera väntetid.
Identifiera element
För att identifiera element på en sida kan olika selektorer, som ID, CSS, XPath med flera användas. Enligt Seleniumdokumentationen (Selenium, 2020) är ID-selektorn att föredra, förutsatt att element på sidan har unika och konsekventa ID:n.
Om ett unikt ID inte är tillgängligt är CSS-selektorn att föredra. XPath är flexibelt, men syntaxen är komplicerad och den är känsligare för förändring i koden än CSS-selektorn.
Dessutom tenderar XPath-selektorn att vara långsammare än CSS-selektorn (Selenium, 2020).
XPath fungerar lika bra som CSS-selektorn, men syntaxen är komplicerad och den är känsligare för förändring i koden. Även om XPath är flexibelt, är de vanligtvis inte prestandatestade av webbläsarleverantörer och tenderar att vara långsamma på att gå igenom DOM-hierarkin (Selenium, 2020).
Nedan följer kodexempel som visar de tre selektorer som användes i studiens praktiska test: ID, CSS och XPath:
Id-selektor för att identifiera ett element med id “email”:
IWebElement element = driver.FindElement(By.ID("email"));
CSS-selektor för att hitta element med klass “primary-btn”CSS:
IWebElement element =
driver.FindElement(By.cssSelector(".primary-btn"));
XPath-selektor för att identifiera element av typen input innehållande texten “Email”:
IWebElement element =
driver.FindElement(By.XPath(“//input[text()=Email]”);
Hantera väntetid
Eftersom det tar en viss tid för en webbsida att ladda är det som Debroy et al. (2018) beskriver nödvändigt att säkerställa att det element man önskar utföra en handling mot verkligen är tillagda i sidans DOM. Ett sätt att göra detta i Selenium WebDriver är att ställa in en så kallad “Implicit Wait” som gör att Selenium WebDriver gör nya försök att hitta element tills den inställda tiden går ut. En “Implicit Wait” gäller under hela den aktuella testsessionen. Väntetiden sätts alltså en gång och gäller sedan varje gång ett element ska identifieras. Det är också möjligt att använda “Explicit Waits”, där man definierar ett villkor som ska uppfyllas innan exekveringen av skriptet fortsätter. Med
“Explicit Waits” är det alltså möjligt att definiera ett nytt, skräddarsytt villkor för varje element som ska identifieras (Selenium, 2020).
3 Metod
Här förklaras den forskningsprocess och den process för att välja ett verktyg som följdes i studien. Hur data samlats in och analyserats beskrivs också.
3.1 Forskningsprocessen
Figur 7 visar den forskningsprocess som följts i denna studie. Beskrivningen är inspirerad av den modell av forskningsprocessen som Oates (2006) presenterar. Motivationen till studien kom dels från Triona, som hade ett behov av att undersöka hur de kan
automatisera regressionstester, dels från författarnas intresse för test och automatisering.
Litteraturstudien genomfördes i enlighet med Oates (2006) i två delar. Den första delen av litteraturstudien gav en förståelse för ämnet och ett intressant problemområde kunde ringas in: val av verktyg/teknik för automatiserad GUI-testning. Syfte och
forskningsfrågor formulerades, och utifrån dessa valdes forskningsstrategin, en fallstudie.
För att besvara forskningsfråga 1 genomfördes den andra delen av litteraturstudien och intervju 1. En slutsats om vilken typ av verktyg som skulle passa Triona bäst kunde dras, och därefter valdes ett verktyg av denna typ ut för praktiska test. För att besvara forskningsfråga 2 genomfördes observationer av praktiska test samt intervjuer.
Intervjuerna handlade om erfarenheter av att använda det utvalda verktyget i andra projekt/förvaltningar inom Triona, och användes för att få en bredare, rikare bild av hur verktyget fungerar i praktiken. Insamlat data analyserades kvalitativt och en slutsats beträffande forskningsfråga 2 kunde dras.
Figur 7. Modell av forskningsprocessen. Inspirerad av Oates (2006).
3.2 Anpassad urvalsprocess
Som beskrivs i inledningen var det första problemet som identifierades att Triona behöver välja ett verktyg för att kunna automatisera regressionstester av C-Load. För att
specificera krav och utvärderingskriterier behövs dock erfarenhet av att använda just AGT-verktyg. För att komma ur detta dilemma följdes i denna studie en anpassad version av den urvalsprocess som presenterades i kapitel 1. Ambitionen med den anpassade processen är inte att hitta det optimala verktyget, utan att testa och utvärdera ett tillräckligt väl lämpat verktyg, som kan användas som referens att jämföra andra verktyg emot. Till vänster i figur 8 visas den i inledningen presenterade processen. Till höger visas den anpassade process som följdes i denna studie. I det följande beskrivs likheter och skillnader mellan den ursprungliga och den anpassade processen.
Stegen “Identifiera problem” och “Definiera krav” behölls oförändrade. I den anpassade processen accepterades att vissa av de identifierade kraven är för oprecisa för att kunna mätas.
Steget “Definiera utvärderingskriterier” ersätts med “Definiera teman för analys och observation”. För att det ska vara meningsfullt att definiera utvärderingskriterier krävs att konkreta, mätbara krav har identifierats och att de praktiska testerna kan göras på ett sådant sätt att det går att mäta i vilken grad kriterierna uppfylls. I denna studie saknas till stor del mätbara krav och de praktiska testerna utfördes av studenter istället för medarbetare på Triona. I brist på kvantitativa utvärderingskriterier gjordes istället en kvalitativ utvärdering. De observationer som gjordes i de praktiska testerna analyserades tillsammans med data insamlat i intervjuerna utifrån definierade teman. Se avsnitt 6.2.
Steget “Identifiera möjliga verktyg” i den ursprungliga processen ersattes med “Identifiera lämplig typ av verktyg” i den anpassade processen. Av den första litteraturstudien framgick att det finns ett antal olika typer av verktyg för AGT och att dessa lämpar sig olika väl beroende på sammanhang. Därav drogs slutsatsen att ett logiskt första steg vore att identifiera vilken typ av verktyg som bäst passar Trionas behov och förutsättningar.
Steget “Identifiera lämplig typ av verktyg” innebär också att forskningsfråga 1 besvaras.
Steget “Välja ut verktyg att testa” behölls. Ett verktyg av den typ som identifierades i steget “Identifiera lämplig typ av verktyg”, se kapitel 5, valdes.
Steget “Praktiska test / demo” ersattes av “Intervjuer och observationer”. Termen observationer används istället för praktiska test eftersom observationer enligt Oates (2006) är den term som inom forskning används för denna typ av datainsamling. Observationerna kompletterades med intervjuer för att få en bredare och rikare bild av hur det fungerar att använda det testade verktyget i praktiken.
Steget “Presentera resultat” behölls och innebär att resultatet av observationer och intervjuer diskuteras för att besvara forskningsfråga 2.
Det sista steget, “Fatta beslut”, ligger utanför studiens avgränsning.
Figur 8. Ursprunglig urvalsprocess och anpassad urvalsprocess. Ursprunglig urvalsprocess baserad på Raulamo-Jurvanen et al. (2017).
Forskningsprocessen och den anpassade urvalsprocessen följdes alltså parallellt genom studien. Figur 9 visar var i forskningsprocessen de olika stegen i den anpassade urvalsprocessen genomfördes, och i vilket kapitel i rapporten respektive steg beskrivs.
Figur 9. Relation mellan forskningsprocess, anpassad urvalsprocess och denna rapports kapitel.
3.3 Forskningsstrategi
Fallstudier innebär enligt Oates (2006) att studera ett fall på djupet med syfte att nå detaljerad insikt. Eftersom forskningsfrågorna handlar om det specifika fallet att använda automatiserad GUI-testning på Triona och eftersom det behövs förståelse för hur de mönster som framkommer i den teoretiska referensramen tar sig uttryck i detta fall, är en fallstudie en lämplig strategi. Björklund och Paulsson (2012) beskriver hur olika typer av studier används beroende på vad målet med studien är. En normativ studie används enligt Björklund och Paulsson när målet är att ge vägledning och föreslå åtgärder, medan en deskriptiv studie används när målet är att beskriva något. Denna studie har en normativ del och en deskriptiv del. Den normativa delen består i att rekommendera vilken typ av AGT-verktyg Triona bör och hur Triona kan gå vidare för att implementera AGT. Den deskriptiva delen består i att beskriva erfarenheter av att använda ett verktyg av denna typ.
3.4 Litteraturstudie
I båda delarna av litteraturstudien användes Högskolan Dalarnas söktjänst Summon och DiVA för att söka litteratur. Både enkel och avancerad sökning i Summon användes. I den första delen användes olika kombinationer och böjningar av söktermerna “GUI”, ”UI,
”test”, “automated”, “regression”, ”practise”, ”tool”. I den andra delen användes dels referenslistorna i redan funna artiklar, dels adderades mer specifika termer som “Record &
Replay”, “Visul GUI testing”. “Model-based testing”, “Page Object Model”. Dessa användes i kombination med de tidigare termerna. Eftersom automatiserad testning är ett område med snabb utveckling avgränsades de flesta sökningar till att omfatta litteratur från 2015 och framåt. Sökningar med snävare avgränsning och vidare avgränsning genomfördes också.
I den första delen av litteraturstudien valdes artiklar som gav en överblick över ämnet AGT. I den andra delen valdes främst artiklar om för- och nackdelar med olika metoder och verktyg. Litteratur som beskriver erfarenheter av att använda olika verktyg i
sammanhang liknande C-Load-förvaltningen söktes också, alltså på en mer detaljerad nivå än de studier som användes för att förstå generella för- och nackdelar med olika metoder.
De studier som hittades var dock för specifikt inriktade på ett område, exempelvis hur testorakel ska utformas.
Den litteratur som hittades om modellbaserad testning handlar om hur modeller skapas och hur testfall genereras, medan litteratur om eventuella skillnader jämfört med andra typer av verktyg i tid, effektivitet etc. när testfallen väl exekveras inte hittades. Den sammanställning av studier om modellbaserad testning som gjordes av Bernardino, Rodrigues, Zorzo & Marchezan (2017) bekräftar att de flesta studier om modellbaserad testning handlar om just hur modell och testfall skapas, snarare än resultatet när testfallen används. Då analysen visade att ett modellbaserat verktyg inte bedöms passa C-Load- förvaltningen undersöktes inte eventuella skillnader vid exekvering närmare.
3.5 Datainsamling
Praktiska test ingår i den ursprungliga urvalsprocessen som beskrivs i avsnitt 1.2 och 3.2 och förespråkas även av Alégroth (2015) och Vos et al. (2012). Att använda observationer av praktiska test som metod för datainsamling framstod därför som tämligen självklart.
Det verktyg som valdes för de praktiska testen var Selenium WebDriver. Motiv till detta ges i avsnitt 3.5.2. Under studien visade det sig att det finns personer inom Triona som använt Selenium WebDriver i andra projekt än C-Load. Möjligheten att ta del av deras erfarenheter och dra paralleller till fallet C-Load uppstod, och beslutet togs att samla in deras erfarenheter med hjälp av intervjuer. Att använda flera metoder för att samla data om samma fenomen kallas metodtriangulering och kan användas för att få fram mer trovärdiga resultat (Oates, 2006).
3.5.1 Intervjuer
Intervjuer kan med fördel användas när man vill ha detaljerad information om ett ämne, när man vill ställa komplexa eller öppna frågor eller ta del av erfarenheter (Oates, 2006).
Då syftet med datainsamlingen var just att ta del av erfarenheter och då det var viktigt att låta respondenterna tala om det de fann viktigt utan att styra samtalet för mycket, passade intervjuer mycket bra. En av nackdelarna med intervjuer är enligt Oates (2006) att de i jämförelse med exempelvis enkäter är tidskrävande Eftersom bara ett fåtal personer med erfarenhet av AGT kunde identifieras inom Triona var tidsåtgången inget problem.
Intervjuer har genomförts med fem medarbetare på Triona, som på olika sätt har intresse i eller har varit involverade i arbete med AGT. Två testledare och tre utvecklare
intervjuades. Samtliga intervjuer var semistrukturerade. I en semistrukturerad intervju har intervjuaren förberett ett eller flera teman och frågor som ska behandlas, men intervjuaren är beredd att anpassa frågorna efter hur intervjun utvecklas (Oates, 2006). Motivet till att göra intervjuerna semistrukturerade var framförallt att inte styra respondenterna för mycket till de områden som kommit fram genom litteraturen, utan att istället se om respondenterna spontant tog upp dessa ämnen. Den intervjuguide som användes redovisas i bilaga 1. I del två av resultatkapitlet redovisas resultatet av intervjuerna först utan analys för att så långt som möjligt undvika att författarnas tolkning förvanskar informationen.
Läsaren ges därigenom större möjlighet att dra egna slutsatser.
3.5.1.1 Urval
Eftersom det inte var kartlagt vilka personer inom Triona som hade erfarenhet av AGT utfördes ett så kallat snöbollsurval. Ett snöbollsurval är en urvalsmetod där forskaren hittar en person som kan något om ämnet och frågar den personen om andra personer som kan vara relevanta att intervjua (Oates, 2006).
Mirajmi Olsson, förvaltingsledare för C-Load, skickade ut ett mail till medarbetare med en förfrågan om vilka som hade erfarenhet av AGT och kunde ställa upp på en intervju. Detta resulterade i kontakt med två personer som i sin tur kunde ge namn på ytterligare personer med erfarenhet av AGT.
3.5.2 Observationer
Enligt Oates (2006) kan observationer användas för att studera beteende hos både människor och döda ting, som mjukvara eller datorstyrda enheter. Det finns ett antal tillvägagångsätt för att utföra observationer. Det går att göra systematiska observationer av fördefinierade händelser eller observera allt som händer. Observatören kan delta i händelseförloppet eller står helt vid sidan om. Händelser kan dokumenteras exempelvis med noteringar, ljudinspelning, kamera eller mjukvara.
I denna studie var det som observerades författarnas egen upplevelse av att använda Selenium WebDriver för att automatisera regressionstester i C-Load, vilket innebär fullständigt deltagande. Observationerna kan kallas semisystematiska, eftersom teman men inte specifika händelser för observation fanns definierade. Dokumentation skedde i form av producerad kod och noteringar.
När det stod klart att ett skript- och komponentbaserat verktyg där koden skrivs manuellt borde passa C-Load-förvaltningens behov och förutsättningar bäst gjordes valet att utvärdera Selenium WebDriver. Motivet till detta var att Selenium Webdriver bedöms
vara det mest använda AGT-verktyget (Vila et al., 2017; Raulamo-Jurvanen et al., 2017), det är sedan 2018 en W3C-rekommendation (W3C, 2018) och betraktas som en de facto- standard för AGT. Det är därför inte troligt att Triona skulle välja ett annat skriptbaserat verktyg utan att först testa Selenium WebDriver.
De praktiska testerna som observerades gick ut på att skapa testskript utifrån ett testfall som Triona annars testar manuellt i regressionstesterna. Testfallet består av fyra delar och utgör huvudflödet i C-Load; att skapa lass, boka lass, lasta lass och lossa lass. Detta är det testfall som har högst prioritet att automatiseras.
Tabell 1 visar vilka faktorer att observera i de praktiska testen som identifierats utifrån de teman för analys som presenteras i avsnitt 3.6
Tabell 1. Faktorer att observera härledda från teman för analys
Tema för analys Faktor att observera i praktiska test
Applicerbarhet För hur många av de fyra stegen kan vi
skriva fungerande testskript?
Vilka svårigheter uppstår?
Webbläsare Vilka webbläsare kan vi testa med?
Kan någon skillnad noteras mellan olika webbläsare?
Exekveringstid Hur lång tid tar det att exekvera skripten jämfört med att genomföra testfall manuellt?
Total tid för testrelaterat arbete Hur lång tid tar det att skapa testskript?
Hur underhållbar bedöms koden vara med och utan Page Object Model?
I vilken utsträckning förekommer att skript inte fungerar konsekvent?
Vilka andra svårigheter uppstår?
Vilken support finns att tillgå?
3.6 Dataanalys
Data kan vara kvantitativ eller kvalitativ. Kvantitativt data är numerisk, medan kvalitativt data är icke numerisk. I denna studie samlas kvalitativt data in och analyseras. Fördelar med kvalitativ dataanalys är att den ger utrymme till alternativa förklaringar och går utöver det som kan mätas i siffror (Oates, 2006). Metoder för kvalitativ dataanalys är dock inte lika exakta och standardiserade som metoder för kvantitativ dataanalys.
Tillvägagångssätt och resultat är till stor del beroende av forskarens idéer och skicklighet Oates (2006). För att så långt som möjligt undvika att något väsentligt försvinner eller förvrängs av författarnas analys redovisas intervjuer och observationer först utan medveten analys. Ett sätt att analysera kvalitativt data är att identifiera teman som är relevanta för forskningsfrågan och göra analysen utifrån dessa teman (Oates, 2006). I denna studie gjordes analysen utifrån C-Load-förvaltningens krav på AGT-verktyg.
Analysen delades upp i två delar. I analys 1 analyseras identifierade krav med hjälp av tidigare forskning om för- och nackdelar med olika typer av verktyg. Analys 1 ligger till grund för diskussion 1, som svarar på vilken typ av verktyg som C-Load-förvaltningen rekommenderas använda för att komma igång med AGT.
I analys 2 analyseras intervjuer och observationer utifrån identifierade krav, samt ytterligare ett tema som i litteraturen och intervjuerna visade sig vara intressant, nämligen teststrategi. Analys 2 ligger till grund för diskussion 2, som svarar på om C-Load- förvaltningens förväntningar på AGT kan uppfyllas av Selenium WebDriver.
Det insamlade datat täckte inte alla teman i båda delarna av analysen, varför vissa teman bara analyseras i den ena delen. Tabell 2 visar hur de identifierade kraven omformulerats till teman, samt vilka teman som analyseras i analys 1 respektive analys 2. Temana har inte en vidare innebörd än kraven, utan är bara enklare sätt att benämna kraven.
Tabell 2. Teman som analyseras i analys 1 och analys 2, samt temanas koppling till identifierade krav.
4 Resultat del 1
I detta kapitel presenteras resultatet av den del av studien som ska besvara
forskningsfråga 1. Kapitlets två första avsnitt motsvarar stegen “Identifiera problem” och
“Definiera krav” i den anpassade urvalsprocessen. I kapitlets tredje avsnitt analyseras de identifierade kraven med hjälp av den teoretiska referensramen.
4.1 Identifiera problem
Steget att identifiera problem krävde ingen insats eftersom det redan gjorts av Triona. Det problem Triona hade identifierat är att regressionstester av C-Load är tidskrävande och repetitiva, vilket innebär risk för misstag. Triona vill därför undersöka möjligheten att helt eller delvis automatisera dessa regressionstester.
4.2 Definiera krav
Innan denna studie startade hade C-Load-förvaltningen inte påbörjat något arbete inriktat på att automatisera regressionstesterna. Konkreta krav hade därför inte tagits fram. För att identifiera krav användes en formell intervju och informell personlig kommunikation. I det följande beskrivs teknik, arbetssätt och förväntningar på AGT inom C-Load- förvaltningen, samt de krav som utifrån detta identifierats.
4.2.1 Teknik
C-Load är en molnbaserad webbtjänst som är byggd med Telerik UI för ASP.NET AJAX.
I nuläget utförs inga enhetstester på grund av hur koden är uppbyggd (A. Josefsson, personlig kommunikation, 6 maj, 2020). Inom C-Load-förvaltningen finns ett antal miljöer: Utveckling, Beta, Acceptans, Produktion, Test och Demo. Regressionstesterna görs främst i Betamiljön. Triona planerar att inom ett par år ha migrerat C-Load webtjänsten till Vue.js, som är ett modernt webbramverk.
4.2.2 Arbetssätt
Användandet av automatiska test varierar mycket mellan förvaltningar inom Triona, eftersom det till stor del styrs av kraven från kund. Det är mindre vanligt att automatisera regressionstester på GUI än andra typer av tester, såsom enhetstester och prestandatester.
C-Load-förvaltningen har tidigare följt en vattenfallsmodell med fyra releaser per år och en testperiod på ca en månad inför varje release. Det senaste året har arbetssättet blivit mer agilt, vilket bland annat innebär att testerna startar tidigare i utvecklingsprocessen.
Testningen börjar med att en kravanalytiker analyserar kraven, vilket är en del av testprocessen. När det är klart börjar utvecklingen, som utgår från testfall. När tester är klara och buggar rättade uppdateras betamiljön och därefter startar regressionstester.
Tester utförs av testare, testledare, utvecklare och produktägare. I regressionstesterna testas hela flödet med speciellt fokus på de delar av systemet som ändrats i releasen.
Regressionstestfallen hämtas ur en regressionstestbank där alla tidigare testfall sparas.
Inga mätetal finns definierade för att bedöma om man testat tillräckligt mycket eller hur effektiva testerna är. Regressionstesterna utförs enbart från GUI:t. I de senaste releaserna
har två-tre ärenden påverkat GUI:t. Större förändringar av GUI:t görs vanligen högst en gång per år (M. Olsson, personlig kommunikation, 6 maj, 2020).
I samband med att C-Load migreras till Vue.js ska C-Load-förvaltningen börja använda Azure Devops, som är en molntjänst för att hantera utvecklingsprojekt från planering och utveckling till test och driftsättning (Microsoft, 2019b). I och med övergången till Azure Devops kommer man att lämna vattenfallsmodellen helt.
4.2.3 Förväntningar på AGT
C-Load-förvaltningens förväntningar på AGT framkom i en intervju med Mirjami Olsson, som är förvaltningsledare och testledare för C-Load. Enligt Olsson (personlig
kommunikation, 6 april, 2020) finns det tre motiv till att automatisera regressionstesterna i C-Load:
Minska tidsåtgången per testfall och därmed hinna köra fler testfall på den tid som finns till förfogande
Öka kvaliteten i testerna genom att låta verktyg ta över repetitiva test, där människor ibland begår misstag.
Minska det totala antalet mantimmar som läggs på testerna, så att tid frigörs till andra aktiviteter.
En risk som Olsson ser med att automatisera regressionstesterna är att ett verktyg inte fullt ut kan ersätta en människa:
Att tappa det mänskliga ögat så att säga, eftersom vi inte har en kund som kör acceptanstester. Flödet fungerar men det ser inte bra ut t.ex. Själva känslan.
(M. Olsson, personlig kommunikation, 6 april, 2020)
Olsson påpekar också att då C-Load är en webservice som Triona säljer till sina kunder är det Triona själva som gör acceptanstester. Regressionstesterna fungerar därför även som acceptanstest, vilket gör det extra viktigt att testerna säkerställer att användarens upplevelse är bra (M. Olsson, personlig kommunikation, 6 april, 2020).
4.2.4 Identifierade krav
Som konstaterats i inledningen är det inte möjligt att med Trionas nuvarande insikt om AGT definiera en uttömmande lista på konkreta, mätbara krav. Utifrån det som framkommit identifieras följande krav:
1. Det ska vara möjligt att automatisera tester av C-Load, en webservice byggd med Telerik UI för ASP.NET AJAX.
2. Det ska vara möjligt att testa i Chrome, Edge, Firefox och Internet Explorer.
3. Det ska gå snabbare att exekvera automatiserade testfall än att genomföra testfallen manuellt.
4. Automatiserade test ska vara effektivare i att hitta fel än manuella test.
5. Det totala antalet mantimmar som läggs på testerna ska minska, så att tid frigörs till andra aktiviteter.
6. Det ska vara möjligt att välja ut testfall att köra i en given omgång av regressionstester.
7. Det ska vara möjligt att kontrollera att GUI:ts utseende är korrekt.
Krav nr 7, att kontrollera att GUI:ts utseende är korrekt, är den del av kundens upplevelse som kan kontrolleras i regressionstesterna. Andra faktorer som påverkar kundens upplevelse testas i användbarhetstester, vilket ligger utanför studiens avgränsning.
Det finns ingen klar strategi för hur det ska hanteras att migrationen av C-Load till Vue.js kan påverka införandet av AGT.
4.3 Analys del 1
Syftet med detta avsnitt är att analysera identifierade krav med hjälp av tidigare forskning om för- och nackdelar med olika typer av AGT-verktyg. Analysen ligger till grund för den diskussion som i kapitel 5 leder fram till svaret på forskningsfråga 1. Som beskrivs i kapitel 3 har de identifierade kraven omformulerats till teman för analys. De teman som här analyseras är exekveringstid, effektivitet i att hitta defekter, total tid för testrelaterat arbete, val av testfall och korrekt GUI.
Exekveringstid
Alégroth (2015) och Dobslaw et al. (2019) visar att skriptbaserade verktyg, både komponentbaserade och visuella, ger snabbare exekvering av testskript än manuella tester.
Dobslaw et al. (2019) och Alégroth et al. (2015) gör jämförelser där komponentbaserade verktyg är fyra respektive tre gånger snabbare än visuella verktyg. Skriptlösa verktyg kan inte direkt jämföras med skriptbaserade eller manuella tester med avseende på snabbhet eftersom testerna inte går till på samma sätt. Aho och Vos (2018) konstaterar dock att skriptlösa test är tidskrävande att utföra.
Effektivitet i att hitta defekter
Alégroth (2015) visar att visuella skriptbaserade verktyg upptäcker defekter lika effektivt eller mer effektivt än manuella test. Alégroth et al. (2015) jämför komponentbaserade och visuella skriptbaserade verktyg och drar slutsatsen att i systemtest är komponentbaserade verktyg mer effektiva än visuella, eftersom testfall som borde passera oftare fallerar med visuella verktyg. I acceptanstest är däremot visuella verktyg enligt Alégroth et al. mer effektiva än komponentbaserade eftersom komponentbaserade verktyg oftare missar defekter, så att testfall som borde fallera ändå passerar. Alégroth et al. (2015) presenterar idén att kombinera komponentbaserade och visuella verktyg för att dra nytta av bådas fördelar. Enligt Alégroth et al. (2015) kan acceptanstest ännu inte automatiseras fullständigt, utan manuella tester behövs också.
De flesta verktyg för skriptlösa test stödjer enligt Aho och Vos (2018) inte manuellt definierade testorakel. Med dessa verktyg går det alltså inte att bestämma vilka fel man vill testa för. Däremot är skriptlösa verktyg enligt Wetzlmaier och Ramler (2017) användbara för att upptäcka gömda fel som inte upptäcks med andra metoder.
Total tid för testrelaterat arbete
Med avseende på tidsåtgång har skriptbaserade verktyg enligt Aho och Vos (2018) en nackdel i att det tar mycket tid att skapa och underhålla testskript. Detta arbete kan bli mindre omfattande om modellbaserade verktyg används (Aho & Vos, 2018). Såväl Aho
och Vos (2018) som Utting et al. (2011) beskriver dock att modellbaserade verktyg kräver speciella kunskaper och att det är svårt att skapa de modeller som krävs för att test med dessa verktyg ska fungera väl.
Letotta et al. (2013) jämför Record & Replay -verktyg med manuellt skriven kod.
Slutsatsen är att det går snabbare att skapa testskript med Record & Replay-verktyg, men att tidsvinsten snabbt äts upp av att underhållet är mer krävande för skript skapade med Record & Replay-verktyg. Aho och Vos (2018) pekar ut just underhåll som den största utmaningen med automatiserade GUI-tester. Debroy et al. (2019) anser att nackdelar med Record and Replay-verktyg är bristen på kontroll och klumpig kod som är svårt att underhålla. Thummalapenta et al. (2012) påpekar att skript skapade med Record &
Replay-verktyg tenderar att sluta fungera redan vid små förändringar i GUI:t, vilket leder till behov av underhåll. Enligt Alégroth och Feldt (2017) är det krävande att underhålla de bilder som behövs i visuella verktyg.
Val av testfall
C-Load-förvaltningen väljer inför varje release ut relevanta regressionstestfall. Med skriptlösa verktyg genereras enligt Wetzlmaier och Ramler (2017) test där verktyget utför handlingar i GUI:t i slumpmässig ordning och med slumpmässig input. Att välja vilka testfall som ska köras är alltså inte möjligt.
Korrekt GUI
Det är viktigt för C-Load-förvaltningen att regressionstesterna säkerställer att det som visas i GUI:t är korrekt. I detta avseende har visuella verktyg en fördel jämfört med komponentbaserade. Visuella verktyg kontrollerar att det som faktiskt visas på skärmen är korrekt, medan komponentbaserade verktyg kontrollerar att den underliggande koden är korrekt (Alégroth, 2015). Alégroth et al. (2015) konstaterar också att visuella verktyg är bättre lämpade för acceptanstester än komponentbaserade verktyg, just för att visuella verktyg upptäcker defekter i GUI:ts utseende som komponentbaserade verktyg missar.
