Embed Size (px)
Citation preview
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
I
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
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):
2
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
3
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
4
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.
5
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.
.
6
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
7
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
8
& 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).
9
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
10
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
11
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.
12
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
13
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).
14
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).
15
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.
16
Figur 8. Ursprunglig urvalsprocess och anpassad urvalsprocess. Ursprunglig
urvalsprocess baserad på Raulamo-Jurvanen et al. (2017).
17
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.
18
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).
19
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
20
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.
21
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.
22
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
23
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.
24
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
25
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.
26
5 Diskussion del 1 Detta kapitel motsvarar steget “Identifiera lämplig typ av verktyg” i den anpassade
urvalsprocessen. Baserat på den analys som gjorts av C-Load-förvaltningens krav och
förutsättningar med hjälp av den teoretiska referensramen diskuteras vilken typ av verktyg
som rekommenderas och forskningsfråga 1 besvaras.
I valet mellan skriptbaserade verktyg, modellbaserade verktyg och skriptlösa verktyg
bedömer vi att ett skriptbaserat verktyg borde passa Triona och C-Load bäst. Även om
modellbaserade verktyg har potential att minska arbetet med att skapa och underhålla
testskript testfall är vårt intryck att startsträckan för att komma igång med modellbaserade
test skulle bli orimligt lång för fallet C-Load. Att lyckas med modellbaserade verktyg
kräver kompetens som inte finns inom C-Load-förvaltningen idag. Ett skriptlöst verktyg
vore olämpligt att använda som enda verktyg för regressionstester, eftersom testningen är
slumpmässig och därmed inte passar när man vill genomföra bestämda testfall.
Skriptbaserade verktyg däremot är lämpliga att använda för regressionstester på det sätt
Triona önskar, och C-Load-förvaltningen har den kompetens som behövs.
I valet mellan visuella och komponentbaserade verktyg noterar vi att visuella verktyg har
en fördel i att de kontrollerar att det som faktiskt visas på skärmen är korrekt, vilket gör att
visuella verktyg lämpar sig väl för acceptanstester. Detta är viktigt för C-Load-
förvaltningen. Eftersom underhåll av testfall är en av de största utmaningarna med
automatiserade GUI-tester och det anses särskilt krävande att underhålla de bilder som
behövs i visuella verktyg, tror vi ändå att ett komponentbaserat verktyg är ett mindre
riskabelt val att börja med. Om underhållet blir för krävande kan man tvingas avstå helt
från automatiserade tester, medan problemet att komponentbaserade verktyg missar fel i
GUI:ts utseende kan hanteras genom att komplettera de automatiska testerna med
manuella kontroller. Fullständigt automatiserade GUI-tester verkar ändå inte vara ett
nåbart mål i dagsläget. För komponentbaserade verktyg talar också snabbare exekvering
av testfall jämfört med visuella verktyg. Att kombinera ett komponentbaserat och visuellt
verktyg kan vara intressant när C-Load-förvaltningen kommit igång med AGT.
I valet mellan Record & Replay eller att skriva kod manuellt talar mycket för att manuellt
skriven kod skulle passa C-Load-förvaltningen bättre. Bristen på kontroll över selektorer,
klumpig kod som är svår att underhålla och sköra testskript talar emot Record & Replay-
verktyg. Att skapa testskript kan gå snabbare med Record & Replay-verktyg, men
tidsvinsten äts ganska snart upp av att inspelade skript kräver mer underhåll. Då C-Load-
förvaltningen dessutom har den kompetens som krävs för att skriva kod manuellt anser vi
inte att det finns några starka argument för Record & Replay-verktyg.
27
5.1 Svar på forskningsfråga 1 Svaret på forskningsfråga 1 är att vi rekommenderar C-Load-förvaltningen att i första
hand använda ett skript- och komponentbaserat verktyg där koden i testskripten skrivs
manuellt. Den beskrivna urvalsprocessen illustreras i figur 10.
Figur 10. Beslutsträd för valet av verktygstyp.
28
6 Resultat del 2 I detta kapitel presenteras resultatet av den del av studien som ska besvara
forskningsfråga 2. Kapitlets första avsnitt motsvarar steget “Intervjuer och
observationer” i den anpassade urvalsprocessen. Avsikten är att i första avsnittet redovisa
vad som framkom i intervjuer och observationer utan medveten tolkning av författarna.
Beskrivningen av observationerna har utformats för att beskriva för någon med
begränsad kunskap om AGT vad det innebär att använda Selenium WebDriver. I kapitlets
andra avsnitt analyseras intervjuer och observationer.
6.1 Intervjuer och observationer Syftet med observationerna var att skaffa praktisk erfarenhet av AGT och att göra en
kvalitativ utvärdering av att använda Selenium WebDriver för regressionster av C-Load.
För att öka validiteten kompletterades observationerna med ett antal intervjuer med
Triona-medarbetare som har erfarenhet av att arbeta med Selenium WebDriver i andra
projekt och förvaltningar.
6.1.1 Intervjuer
Fyra personer som hade någon form av erfarenhet av AGT intervjuades. Deras
erfarenheter kom från ett projekt som kallas Transport Data Platform (TDP) och ett
projekt som kallas Rask. TDP är en integrationsplattform för transportdata som knyter
samman Clas Ohlsons affärssystem med butiker, leverantörer, lagersystem,
transportadministrationssystem och logistikaktörer. Rask är ett verksamhetssystem för
hantering av alla aktiviteter kopplade till att avverka och sälja skog. Rask kan sägas vara
både en förvaltning och ett projekt, då systemet är i drift samtidigt som omfattande
utveckling av systemet pågår.
Intervjurespondenter:
Hansi Henningson: Arkitekt och utvecklare i TDP
Pontus Berglund: Utvecklare i TDP
Cecilia Landberg: Testledare och kravanalytiker i Rask
Olle Eriksson: Utvecklare i Rask
Transkriberingar av intervjuerna redovisas i bilaga 3
6.1.1.1 Intervju med arkitekt och utvecklare Hansi Henningson
I intervjun med Hansi Henningson visade det sig att han inte hade direkt erfarenhet av
AGT, däremot av andra typer av automatiserade test, vilka han betraktar som helt
nödvändiga för att kunna leverera kvalitet. Henningson hänvisade till Pontus Berglund för
information om AGT.
6.1.1.2 Intervju med utvecklare Pontus Berglund
Syftet med intervjun var att ta del av en utvecklares praktiska erfarenhet av att använda
Selenium WebDriver. Berglund berättade att behovet av automatiserad GUI-testning
uppstod p.g.a. att ny funktionalitet ofta orsakade fel i GUI:t:
29
Vi insåg att när vi utvecklade så förstördes webinterfacet ibland utan att vi visste
om det. Ändringar i API:et eller nästan var som helst som förstörde gränssnittet
så då tittade jag lite på hur man kunde testa det automatiskt. (P. Berglund,
personlig kommunikation, 4 maj, 2020)
Enligt Berglund valdes Selenium WebDriver för att det är det mest populära verktyget. Att
skapa testskripten visade sig dock inte vara problemfritt. Att hitta bra selektorer, att vänta
in att element finns tillgängliga på sidan och att det krävdes olika metoder för att utföra till
synes samma sak på olika ställen i flödet, upplevdes av Berglund som problematiskt.
Berglund påpekar att det skulle bli betydligt enklare att skapa testskript om man vid
utvecklingen av en applikation såg till att skapa unika ID:n på alla element. Testfallen
innehöll också för mycket kod och logik. Berglund insåg att det skulle behövas ett lager av
abstraktion, som POM, för att göra skripten tydliga och lätta att använda. Tid för att göra
detta saknades dock. När applikationen sedan blev allt mer stabil minskade behovet av
testerna och man beslutade att det inte var mödan värt att göra testskripten användbara.
Testerna kördes inte heller manuellt, utan man klarade sig utan dem.
Berglund är ändå positiv till idén med AGT:
Jag önskar att man hade mer sådana här tester. Det är svårt att testa GUI
grundligt. Vi hade en söksida där man kunde söka på en mängd saker. När man
testar den manuellt är det jobbigt att behöva söka efter sjutton olika saker [...] Det
kan finnas fel som är svåra att upptäcka manuellt när man ska köra en hel “round
trip” genom flödet. (P. Berglund, personlig kommunikation, 4 maj, 2020)
Berglund påpekar att om man vill jobba i korta iterationer och driftsätta ofta, vilket är
vanligt idag, är det nästan ett måste att automatisera regressionstester.
6.1.1.3 Intervju med testare och kravanalytiker Cecilia Landberg
Syftet med intervjun var att ta del av erfarenheter från en testledare som arbetar i ett
projekt där Selenium WebDriver används. Landberg skriver inte själv testskript, men är
med och beslutar om vilka scenarier som är lämpliga att testa med Selenium WebDriver.
Landberg uppskattar att Rask-projektet använder Selenium WebDriver till ca 15% av det
totala antalet regressionstester. Det är mestadels så kallade “happy flows” som
automatiserats, alltså test där användaren använder systemet på det sätt som är avsett.
Landberg berättar att det tar lång tid att köra testerna, men att Rask-projektet ändå
upplever att de tjänar in tid, eftersom det går att köra testerna nattetid. Enligt Landberg är
det ett problem att testerna är känsliga för förändring:
Min erfarenhet av det är det jag fått höra från utvecklarna och det är att det tar
mycket lång tid. Det är därför vi kör på natten. Man tycker att testen är krångliga
att underhålla. I ett projekt i förvaltning fungerar det nog bättre. Vi får ny kod varje
dag och seleniumtesterna som är känsliga för förändring smäller ganska ofta då.
Därför använder vi inte så mycket seleniumtester som vi hade velat. (C. Landberg, personlig kommunikation, 29 april, 2020)
30
6.1.1.4 Intervju med utvecklare Olle Eriksson
Syftet med intervjun var att ta del av en utvecklares praktiska erfarenhet av att använda
Selenium WebDriver. Eriksson berättar att när han använde Selenium WebDriver hade
kunden stort fokus på testautomation. Inte bara GUI-tester utan även enhetstester och
integrationstester automatiserades. Applikationen var en så kallade “Single-Page
Application”, byggd med Angular JS. Enligt Eriksson var det en utmaning att använda
Selenium med Angular JS eftersom Selenium är gjort för äldre, serverbaserad webbteknik.
För att hantera den väntetid som uppstår när klienten gör asynkrona anrop mot ett REST
API var det nödvändigt att skriva specialkod. De metoder för att hantera väntetid som
finns inbyggda i Selenium fungerade inte. Om behovet av specialkod säger Eriksson:
Det går att lösa och hitta sätt runt men inte lika klart och tydligt som vi hade
förväntat oss. [...] Det var ganska tidskrävande att få det fungera stabilt. Vi fick
ibland falska negativa utfall som var knepiga att felsöka. Det här kokar nog ner till
timingen och hur man väntar in saker. (O. Eriksson, personlig kommunikation, 4 maj, 2020)
Eriksson återkommer till svårigheter med att felsöka:
Det är tråkigt med Selenium att man måste hacka fram vissa lösningar. Det är svårt
och tidskrävande att felsöka. Vi fick ofta sätta dom bästa utvecklarna på att felsöka. (O. Eriksson, personlig kommunikation, 4 maj, 2020)
Eriksson säger att eftersom det är krångligt och dyrt att bygga testskripten vore det nog
bäst att vänta med detta tills det mesta av funktionaliteten är på plats:
Vi började nog lite för tidigt i systemet jag var med i. Då lägger man mycket tid på
att ändra testfallen för att GUI:t förändras ofta. Systemet rörde sig fort för vi var
tio utvecklare. Så om någon byggde någon ny knapp så failade allas skript. (O. Eriksson, personlig kommunikation, 4 maj, 2020)
POM användes i projektet. I samband med detta blev det snabbt tydligt att det är bra att ha
id på alla element, eftersom Xpath är ganska skört.
Om valet att använda just Selenium WebDriver säger Eriksson följande:
Det fanns en resurs som kunde Selenium och hade ett ramverk färdigt så vi fick det
lite till oss. Om jag hade gjort det idag så hade jag nog googlat fram lite andra
alternativ. Som C-Load ser ut idag så är nog Selenium bra, men med modern web
så skulle jag nog välja något annat. (O. Eriksson, personlig kommunikation, 4 maj, 2020)
Eriksson har en klar bild av hur han hade gått till väga om han hade fått börja från början
med projektet:
Hade jag gjort det från början så hade jag lagt så mycket det går på att få
enhetstestning så bra som det bara går och så skulle jag lägga en del krut på
integration som testar serverstacken och så skulle jag ha några GUI testfall som
testar centrala flöden när dom är på plats och inte ska förändras så mycket. Att
31
testa hela systemet med Selenium tar för lång tid. (O. Eriksson, personlig
kommunikation, 4 maj, 2020)
För att göra det lättare att komma fram till vad som gått fel när ett test fallerat användes en
lösning där Selenium WebDriver sparade en bild av skärmen så snart något gick fel. Att
kunna titta på dessa bilder var enligt Eriksson till mycket stor hjälp.
6.1.2 Observationer
Det verktyg som valdes för de praktiska testen var Selenium WebDriver. Motivet till detta
beskrivs i kapitel 3. Innan vi började arbeta med Selenium WebDriver deltog vi under en
halv dag i verkliga regressionstester, där vi manuellt genomförde testfall. Det aktuella
testfallet bestod av fyra delar som utgör huvudflödet i C-Load; att skapa lass, boka lass,
lasta lass och lossa lass. Beskrivningen av observationerna delas in i två delar. Först
beskrivs tillvägagångssättet och därefter beskrivs observationer kopplade till de teman
som används i analysen.
6.1.2.1 Tillvägagångssätt
Eftersom C-Load är skrivet i C# använde vi det även i testskripten. Då Selenium
WebDriver bara styr webbläsaren behövde vi också ett testramverk för att kunna skapa
test. De vanligaste ramverken för .NET är MSTest, Xunit och Nunit. Vi valde att använda
NUnit eftersom det verkade mest likt JUnit, vilket vi hade viss erfarenhet av. Vi använde
Visual Studio Enterprise 2019 och skapade där ett Nunit-testprojekt till vilket vi adderade
Selenium Webriver NuGet. För varje webbläsare vi ville testa med behövde vi också
installera en exekverbar fil, kallad driver, som möjliggör kommunikation mellan Selenium
och respektive webbläsare.
Fyra moment utgör grunden för att skapa testskript med Selenium WebDriver:
Identifiera element
Säkerställa att element är tillgängliga
Utföra önskad handling på element
Definiera testorakel. Dvs bestämma vilka villkor som ska gälla för att testet ska gå
igenom.
I det följande beskriver vi våra upplevelser i samband med de olika momenten och hur det
var att använda POM.
Identifiera element Med hjälp av en extension till Firefox kallad ChroPath gick det att hitta möjliga selektorer
till ett givet element. Svårigheten bestod i att vi inte hade kunskap om hur sidorna i C-
Load var uppbyggda. Till en början försökte vi därför ofta att utföra handlingar på element
som låg för djupt i DOM-hierarkin. Exempelvis kunde vi identifiera ett element B som vi
trodde var en textbox där vi skulle kunna skriva text. För att kunna skriva text i textboxen
behövde vi dock i själva verket identifiera ett div-element A som omslöt element B. I
vissa fall ledde detta “bara” till att vår selektor blev en lång XPath när vi istället hade
kunnat använda id:t på ett element högre upp i DOM-hierarkin. I andra fall ledde det till
att vi inte alls kunde utföra avsedd operation. Efter en del trial-and-error förstod vi hur vi
skulle söka efter element på rätt nivå i DOM-hierarkin. C-Load har till stor del unika id:n
32
så det gick oftast att använda det som selektor. I C-Load finns ett antal Telerik UI
komponenter. Det gick att hitta dessa element via deras id, men i till exempel drop-down
menyer var det svårt att identifiera de olika elementen i menyn.
Säkerställa att element är tillgängliga Vid ett par tillfällen lyckades vi inte få skriptet att fungera med vare sig Implicit eller
Explicit Waits, utan vi fick använda en Thread.Sleep, som pausar tråden i angivet antal
millisekunder. Detta är dock inte god praxis. Varför det ibland inte fungerade med varken
implicit eller explicit waits har vi inte hunnit utreda. Att säkerställa att element är
tillgängliga upplevde vi som det vanskligaste momentet med att skriva skripten. När ett
skript inte fungerade som tänkt var det svårt att veta om det berodde på felaktig hantering
av väntan eller något annat.
Utföra önskad handling på element När man har säkerställt att ett element är tillgängligt kan man utföra olika handlingar på
elementet. Det kan till exempel vara att klicka på en knapp, skriva in ett användarnamn i
ett textfält eller trycka på en tangent. Selenium WebDriver har nativt stöd för de
vanligaste handlingarna men när det kommer till vissa “ovanligare” handlingar, som t.ex.
drag & drop, får man antingen skriva en egen hjälpmetod eller använda olika hjälpklasser.
En sådan hjälpklass är Actions som har stöd för till exempel dubbelklick och att peka med
musen på ett element. Till en början var det svårt att veta vilken klass som skulle användas
för att utföra en viss handling, vilket gjorde att utvecklingen av skripten tog längre tid.
Definiera testorakel För att definiera vilka villkor som ska gälla för att testet ska gå igenom används Assert-
klassen i det ramverk för enhetstester som används, i vårt fall NUnit. De testfall som vi
skrev skript för gick ut på att gå igenom hela flödet för de fyra huvuduppgifterna: skapa
lass, boka lass, lasta lass och lossa lass. Eftersom skripten i stort sett bara behövde
verifiera att flödet gick att genomföra, användes Assert bara en gång i själva testet.
Däremot användes Assert flitigt för att felsöka skripten genom att t.ex. kontrollera att
värden på elements attribut var de förväntade. Vi upplevde inga särskilda svårigheter med
detta.
Page Object Model Vi visste från början att vi ville använda POM, men först skrev vi all kod i samma klass
för att lära oss hur vi kunde identifiera element, utföra handlingar på element etc. I bilaga
2 visas exempel på kod före och efter att vi skapade page objects. Som framgår av
exemplen blir koden betydligt enklare att läsa när POM används.
6.1.2.2 Observationer per tema
Som underlag till kommande analys och diskussion beskrivs i detta avsnitt observationer
uppdelade på de teman som kopplats till identifierade krav: applicerbarhet, webbläsare,
exekveringstid och total tid för testrelaterat arbete.
33
Applicerbarhet Det var möjligt att skriva fungerande testskript för alla fyra stegen i det testfall som
användes, men för att identifiera Telerik UI-komponenter användes alternativa lösningar
eftersom Selenium WebDrivers metoder inte fungerade på förväntat sätt.
Webbläsare Vi försökte köra testskripten med Chrome, Edge, Internet Explorer och Firefox. Chrome
och Internet Explorer var de enda webbläsarna där testen fungerade helt utan problem. I
Internet Explorer var man dock tvungen att ändra inställningar för att använda Selenium
WebDriver, inkluderat att stänga av "Enhanced Protected Mode" och göra tillägg i
windowsregistret. När konfigurationen var avklarad uppstod inga ytterligare problem. I
Edge startade webbläsaren när skripten startades, men sedan hände inget mer.
I Firefox kunde vi inte använda vissa metoder ur Actionklassen, det löste vi genom att
göra om våra metoder. Vi kunde ändå inte köra hela flödet med Firefox, då Selenium
WebDriver i ett steg klickar på fel element, trots att elementet identifieras med id. Varför
detta sker har vi inte utrett. Det ska gå att använda äldre versioner av Firefox och
Selenium för undvika problemen med Actionklassen men vi har inte utforskat det
närmare.
Exekveringstid Vi körde det testfall som vi skapat skript för tre gånger vardera i Chrome och Internet
Explorer, manuellt och med Selenium WebDriver. Genomsnittliga tider visas i tabell 3. I
Chrome tog de manuella testerna i genomsnitt 86% längre tid än de automatiserade och i
Internet Explorer 33% längre tid. Syftet med mätningen var bara att få en uppfattning om
skillnaden i tid mellan manuella och automatiserade test och inga långtgående slutsatser
kan dras av resultatet.
Tabell 3. Genomsnittlig exekveringstid manuellt och med Selenium WebDriver.
Total tid för testrelaterat arbete Att installera och lära sig grunderna i Selenium WebDriver samt skriva testskripten tog
cirka tre arbetsveckor. Efter den tiden hade produktiviteten stigit betydligt. När vi väl hade
kommit fram till hur en viss typ av element skulle hanteras gick det för det mesta relativt
snabbt att skriva koden för att hantera ett annat element av samma typ.
Att införa designmönstret POM gjorde stor skillnad för kodens läsbarhet och hur lätt det
bedöms vara att underhålla koden. Bilaga 2 visar exempel på kod före och efter att POM
infördes.
Vi observerade ett fåtal gånger att skript inte fungerade konsekvent, men det var inte
vanligt. För att undersöka detta ordentligt hade det varit nödvändigt att göra systematiska
observationer där fungerande testskript kördes många gånger, vilket inte hanns med. Ett
34
annat problem som inträffade vid ett tillfälle var att Selenium WebDriver konsekvent
klickade på ett extra element som inte ingick i testfallet.
De svårigheter som upplevdes var framförallt att hantera väntetid och att komma fram till
vilka metoder som fungerade för att hantera olika element.
Angående problemlösning och felsökning är vårt samlade intryck att det går snabbt att
hitta många lösningsförslag på till exempel Stackoverflow, men många av dessa är
inaktuella eftersom webbläsare och Selenium ständigt uppdateras. Det går att hitta svar på
allt, men det är ibland tidskrävande.
6.2 Analys del 2 De teman som här analyseras genom att jämföra tidigare forskning och data insamlad i
observationer och intervjuer är applicerbarhet, webbläsare, exekveringstid, total tid för
testrelaterade aktiviteter, samt teststrategi. Angående teman, se kapitel 3.
6.2.1 Applicerbarhet
Det var möjligt att skriva fungerande skript för alla steg i det testfall som användes i
studien. För att kringgå problemet att vissa av Selenium WebDrivers metoder inte
fungerade på Teleriks UI-komponenter användes dock alternativa lösningar som gav
sämre precision i att identifiera element. O. Eriksson (personlig kommunikation, 4 maj,
2020) konstaterar att Selenium WebDriver bör fungera för C-Load så som det är byggt
idag, men att Selenium WebDriver förmodligen inte är det bästa valet i moderna
webramverk.
6.2.2 Webbläsare
C-Load-förvaltningen har behov av att testa i Google Chrome, Microsoft Edge, Mozilla
Firefox och Internet Explorer. Enligt Selenium (2020a) stödjer Selenium WebDriver dessa
webbläsare. I observationerna testades samtliga, men Chrome och Explorer var de enda
webbläsarna där testen fungerade helt utan problem. Beskrivningar av den typ av problem
som observerades med webbläsare har inte hittats i tidigare forskning. Av diskussioner på
forum och dylikt framgår att denna typ av problem kan bero på vilka versioner av
Selenium WebDriver, webbläsare, driver och operativsystem som används.
6.2.3 Exekveringstid
Angående tiden det tar att exekvera testfallen konstaterar Aho och Vos (2018) att GUI-
tester, även om de automatiseras, tar betydligt längre tid att köra än enhetstestereftersom
man måste invänta att GUI:t ska uppdateras. C. Landberg (personlig kommunikation, 29
april, 2020) berättar att Seleniumtesterna i Rask-projektet körs nattetid eftersom det tar så
lång tid. I våra observationer, se avsnitt 6.1.2.2, tog de manuella testerna ca 86% längre tid
än de automatiserade i Chrome och ca 33% längre tid i Internet Explorer. De observerade
tiderna avser bara tiden för att exekvera ett testfall en gång och visar inte skillnaden
mellan manuella och automatiserade test när en hel svit av testfall exekveras.
35
6.2.4 Total tid för testrelaterat arbete
Den totala arbetstiden som läggs på AGT beror främst på arbetsbördan med att skapa och
underhålla testskript. Förekomst av opålitliga testskript påverkar båda dessa faktorer och
även tid för felsökning under test.
6.2.4.1 Arbetsbörda med att skapa testskript
Enligt Aho och Vos (2018) och Dobslaw et al. (2019) är arbetet som krävs för att skapa
testskript omfattande. Detta framkommer också i våra intervjuer. I TDP-projektet
avslutades försöket med automatiska GUI-tester p.g.a. den arbetsinsats som krävdes var
för stor i förhållande till nyttan med att köra testerna (P. Berglund, personlig
kommunikation, 4 maj, 2020). Även i Rask-projektet upplevdes arbetet med att skriva
testskript som omfattande (O. Eriksson, personlig kommunikation, 4 maj, 2020).
Utvecklingen av testskript försvårades här av att applikationen i fråga var en så kallad
Single Page Application, en teknik som enligt O. Eriksson (personlig kommunikation, 4
maj, 2020) gör att det krävs en extra utvecklingsinsats för att kunna använda Selenium
WebDriver. Våra observationer visar också att processen för att skapa testskripten
innehöll svårigheter framförallt med att säkerställa att element är tillgängliga, att hitta
lämpliga metoder för att hantera element och att testskript inte fungerade i alla
webbläsare.
6.2.4.2 Arbetsbörda med att underhålla testskript
Aho och Vos (2018) hävdar att det arbete som krävs för att underhålla testskript är den
största utmaningen med att använda skriptbaserad GUI-testning. Enligt Dobslaw et al.
(2019) beror kostnaden för att underhålla testskripten på storlek och frekvens av
förändringar i GUI:t. Intervjurespondenterna vittnar också om att i ett system där
förändringar är frekventa klarar man inte att uppdatera testskripten i samma takt som
systemet förändras, vilket leder till att test fallerar (C. Landberg, personlig kommunikation
29 april; O. Eriksson, personlig kommunikation, 4 maj, 2020).
Omfattningen av arbetet med att underhålla testskript kan enligt Debroy et al. (2018) m.fl.
minska genom att använda designmönstret POM. Av intervjuerna framgår att man i TDP-
projektet utvecklade testskripten utan POM, vilket ledde till att skripten innehöll för
mycket logik (P. Berglund, personlig kommunikation, 4 maj, 2020). I Rask-projektet
användes POM. I våra observationer såg vi också att koden blev mer lättläst och enklare
att ändra när vi gick över till POM. Se bilaga 2.
6.2.4.3 Opålitliga testskript
Mascheroni och Irrazábal (2018), Debroy et al. (2018) och Presler-Marshall et al. (2019)
beskriver att opålitliga test, som inte ger konsekventa resultat, är en stor utmaning i
automatiserade test. En vanlig orsak är enligt Mascheroni och Irrazábal (2018) att
testskript försöker hitta element innan sidan har laddat klart. Detta problem uppkom både
i TDP-projektet och Rask-projektet (O. Eriksson, personlig kommunikation, 4 maj 2020;
P. Berglund, personlig kommunikation, 4 maj, 2020). I Rask-projektet försvårades
problemet p.g.a. den webbteknik som användes. Att få till stabila testskript i Rask-
projektet var enligt O. Eriksson (personlig kommunikation, 4 maj, 2020) därför extra
tidskrävande.
36
O. Eriksson (personlig kommunikation 4 maj, 2020) påpekar att opålitliga test bidrar till
att betydande resurser används för att felsöka testskripten istället för att förbättra
applikationer. I våra observationer tyckte vi också att det svåraste var att invänta element
på rätt sätt, men att fungerande testskript plötsligt inte fungerade hände bara ett fåtal
gånger.
6.2.5 Teststrategi
En bra teststrategi ska enligt Berner et al. (2005) och Alégroth et al. (2015) innehålla en
kombination av tester på olika nivåer: enhetstester, integrationstester och systemtest.
Garousi och Yidirim (2018) menar att ett större antal testfall bör automatiseras på lägre
nivåer och ett mindre antal på högre nivåer. O. Eriksson (personlig kommunikation, 4 maj
2020) beskriver sin vision av automatiserad testning på just det viset. På grund av
webbtjänstens uppbyggnad kan enhetstester idag inte göras i C-Load. Detta kommer att
ändras när C-Load migreras till Vue.js.
.
37
7 Diskussion del 2 Detta kapitel motsvarar steget “Presentera resultat” i den anpassade urvalsprocessen.
Resultatet av intervjuer och observationer diskuteras och forskningsfråga 2 besvaras.
Diskussionen delas in efter de teman som härrör från identifierade krav. Kapitlet avslutas
med metodkritik och förslag till vidare forskning.
Applicerbarhet Studien visar att det åtminstone i Chrome och Internet Explorer fungerar att med hjälp av
Selenium WebDriver automatisera det grundläggande flödet i C-Load: att skapa lass, boka
lass, lasta lass och lossa lass. Dock kan Selenium WebDrivers metoder inte alltid hantera
Teleriks UI-komponenter på önskat sätt. I det testfall som användes i studien kunde
alternativa lösningar med sämre precision användas, men det finns förmodligen testfall där
detta orsakar större problem.
Enligt de erfarenheter som gjordes i Rask-projektet fungerar inte Selenium WebDrivers
inbyggda metoder för att hantera väntetid i moderna webbramverk, där
applikationslogiken till stor del hanteras i webbläsaren och asynkrona anrop görs mot
servern. I Rask-projektet ledde detta till betydande merarbete. Då Vue.js också är ett
modernt ramverk uppstår sannolikt samma problem om Selenium WebDriver används när
C-Load migreras till Vue.js.
Slutsats: Det är möjligt att automatisera regressionstester av C-Load med Selenium
WebDriver, men potentiella problem finns på två områden:
Att hantera Teleriks UI-komponenter när mer komplicerade testfall ska automatiseras.
Att skapa stabila testskript när C-Load migreras till Vue.js
Webbläsare Testskripten som skapades i studien fungerade i Chrome och Internet Explorer. I Firefox
fungerade skripten delvis och i Edge inte alls. Hur de olika drivers som behövs för att testa
i olika webbläsare ska installeras, vilka versioner som fungerar tillsammans och vilka
inställningar som behöver göras är inte helt tydligt. Vi tror därför att problemen med
Firefox och Edge går att lösa om man undersöker detta närmare.
Slutsats: Studien har inte kunnat visa att förväntningarna beträffande vilka webbläsare
som kan användas för att testa C-Load med Selenium WebDriver uppfylls till mer än
hälften. Det är förmodligen möjligt att lösa problemen med Edge och Firefox, men att
problemen alls uppstår ökar den arbetsinsats som krävs för att automatisera GUI-test.
Exekveringstid I det mycket begränsade test som gjordes för att kontrollera skillnaden i tid mellan att köra
testen manuellt och med Selenium WebDriver tog det manuella testet i Internet Explorer
endast 33% längre tid än det automatiserade. Som sagt ska inga långtgående slutsatser
dras av detta, och det är säkert möjligt att förbättra testskripten så att denna skillnad blir
större. Även tidigare forskning visar dock att GUI-tester är tidskrävande även om de
automatiseras. Tidsvinsten ligger till stor del i att automatiserade tester kan köras
kontinuerligt under lång tid och även på nätterna. Det är också på det viset automatiserade
GUI-test körs i Rask-projektet. För att kunna köra testen oövervakade behövs väl
fungerande rapportering och att testerna förses med data på ett effektivt sätt. För att GUI-
38
test inte ska ta för lång tid behövs en teststrategi där merparten av testen körs på lägre
nivåer, så att antalet testfall på GUI-nivå inte blir så stort.
Slutsats: Det skulle gå snabbare att köra regressionstestfallen om Selenium WebDriver
användes. Dock behöver ett mer komplett testramverk skapas och på sikt behövs en
teststrategi som säkrar att antalet GUI-test inte blir för stort.
Effektivitet i att hitta defekter Tidigare forskning visar att komponentbaserade verktyg är effektiva i att hitta defekter i
funktionalitet. Observationer för att bekräfta eller förkasta att detta gäller när Selenium
WebDriver används för att testa C-Load kunde som tidigare nämnts inte göras i denna
studie. Att Selenium WebDriver är ett komponentbaserat verktyg medför att verktyget inte
kan kontrollera att GUI:ts utseende är korrekt. Detta är en betydande nackdel då
regressionstesterna av C-Load också fungerar som acceptanstest. För att underlätta
manuell kontroll av att GUI:t ser korrekt ut vore en möjlighet att låta Selenium WebDriver
ta skärmbilder vid utvalda steg i automatiserade testfall.
Slutsats: Selenium WebDriver är förmodligen effektivt i att hitta defekter i funktionalitet i
C-Load, men detta behöver verifieras innan Triona eventuellt fattar beslut om att använda
verktyget. Selenium WebDriver kan däremot inte upptäcka defekter i hur GUI:t ser ut,
vilket begränsar dess nytta i acceptanstester.
Total tid för testrelaterat arbete Studien visar att de nackdelar med automatisk GUI-testning som beskrivs i litteraturen
också upplevs när Selenium WebDriver används inom Triona. Att utveckla testskript är
tidskrävande även för erfarna utvecklare. Speciellt gäller det moderna webbramverk där
Selenium WebDrivers inbyggda metoder för att hantera väntetid inte fungerar.
En styrka hos C-Load-förvaltningen är att test och utveckling är integrerat, vilket innebär
att det i test-teamet finns kompetens för att skapa och underhålla testskript. Tack vare
denna styrka och att GUI:t i C-Load är stabilt tror vi att arbetet med att underhålla skript
skulle vara överkomligt, förutsatt att POM eller liknande designmönster används. Även
om teorin säger att det är underhållet som är den största utmaningen tror vi att det i fallet
C-Load snarare är det arbete som krävs för att komma igång som kan vara ett hinder.
Detta speciellt eftersom C-Load inom ett par år ska flyttas över till Vue.js och testskripten
då behöver skrivas om.
Slutsats: Automatisering med Selenium WebDriver kan på sikt leda till att den totala
arbetstiden för att genomföra regressionstester i C-Load minskar. Dock är det tveksamt
om det är värt att göra det arbete som krävs för att komma igång, eftersom C-Load inom
ett par år har migrerats till Vue.js
Val av testfall Slutsats: Med ett skriptbaserat verktyg som Selenium WebDriver skulle det gå bra att på
samma sätt som idag välja ut testfall att köra från en bank av regressionstestfall.
Korrekt GUI Att Selenium WebDriver inte kan kontrollera att GUI:ts utseende är korrekt är en
betydande nackdel. För att underlätta manuell kontroll skulle Selenium WebDrivers
funktion för att ta skärmbilder kunna användas på valda ställen i testskripten. Då behöver
39
inte hela testfall gås igenom manuellt, utan skärmbilderna som sparats kan kontrolleras i
efterhand. En mer avancerad lösning kan vara att kombinera Selenium WebDriver, eller
annat komponentbaserat verktyg, med ett visuellt verktyg, så som Alégroth et al. (2015)
föreslår.
Slutsats: Selenium WebDriver uppfyller inte kravet att säkerställa att GUI:ts utseende är
korrekt, men genom att ta skärmbilder skulle verktyget kunna användas för att underlätta
den manuella kontrollen.
7.1 Svar på forskningsfråga 2 Forskningsfråga 2 lyder: Kan C-Load-förvaltningens förväntningar på AGT uppfyllas med
Selenium WebDriver? Det korta svaret är “delvis”. Det är möjligt att automatisera
regressionstester av C-Load med Selenium WebDriver och på sikt kan tid frigöras.
Problem med att hantera Telerik UI-komponenter skapar dock frågetecken kring om mer
komplicerade testfall kan automatiseras. En betydande arbetsinsats skulle krävas för att
börja använda Selenium WebDriver i skarpa test. Studien har inte kunnat visa att tester
kan ske i alla önskade webbläsare och Selenium WebDriver kan inte kontrollera att GUI:ts
utseende är korrekt.
7.2 Nästa steg Om C-Load-förvaltningen vill använda Selenium WebDriver i skarpa test på ett effektivt
sätt återstår en hel del arbete. För det första behöver problemen med Firefox och Edge
lösas och koden behöver ses över för att eventuellt göra selektorer mer träffsäkra och
förbättra hanteringen av väntetid. Skript bör också köras mot en version av C-Load med
kända fel för att verifiera att felen hittas. Ett ramverk för rapportering behöver läggas till
och man behöver se över hur testerna ska förses med data. Ytterligare testskript behöver
också skrivas.
Givet de problem och frågetecken som finns kring hur Selenium WebDriver uppfyller C-
Load-förvaltningens förväntningar på AGT anser vi att Triona bör undersöka alternativ
innan beslut om verktyg fattas. De erfarenheter som den här studien bidragit med gör det
förhoppningsvis lättare för C-Load-förvaltningen att specificera krav och att bedöma
möjliga verktyg. Någon uttömmande inventering av möjliga verktyg har inte gjorts, men
ett par som kan vara intressanta att utvärdera är Cypress, som enligt företagets egen
beskrivning eliminerar behovet av att hantera väntetid, och Telerik Testing framework,
som har stöd för de Telerik UI-komponenter som visade sig svåra att hantera med
Selenium WebDriver. För att välja verktyg behöver C-Load-förvaltningen ta ställning till
om det är viktigast att så snabbt som möjligt komma igång med ett verktyg som fungerar
idag, eller om det är viktigare att valt verktyg fungerar väl efter migreringen av C-Load till
Vue.js.
Studien visar att för system som är under snabb utveckling är det svårt att hinna med att
underhålla testskripten. Detta leder till att tester fallerar, vilket i sin tur leder till att mycket
tid måste läggas på att utreda om den testade applikationen eller testskriptet är defekt. Det
finns alltså en konflikt i att med hög utvecklingstakt och korta utvecklingscykler är
behovet av automatiserade tester stort, men samtidigt är det då som svårast att hantera
underhåll av testskripten. Vi ser inte hur detta problem till fullo kan lösas. Det som kan
minska problemet tror vi är att göra det tydligt att utvecklare ansvarar för att uppdatera
40
testskript när kod ändras, att använda POM eller liknande designmönster, och att ha en
teststrategi där merparten av testen körs på lägre nivåer, så att antalet testfall på GUI-nivå
inte blir så stort. Att begränsa antalet GUI-test är också nödvändigt ur en ren tidsaspekt, då
det tar ganska lång tid att köra även automatiserade GUI-test.
7.3 Förankring och generalisering Studiens primära syfte var 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. En kvalitativ
utvärdering av i vilken mån Selenium WebDriver kan uppfylla identifierade krav har
gjorts och rekommendationer för C-Load-förvaltningens nästa steg mot att införa AGT har
givits. Syftet anses därför vara uppfyllt.
Ett sekundärt syfte med studien var 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. Då tillvägagångssätt och problem vid de praktiska testen redovisas på en
relativt detaljerad nivå anses även detta syfte vara uppfyllt.
Det som framkom av intervjuer och observationer stämmer väl överens med de
beskrivningar av AGT som ges av tidigare forskning, vilket styrker att resultaten kan
generaliseras till andra fall än C-Load-förvaltningen. Andra organisationer som också står
inför att introducera AGT kan använda den anpassade urvalsprocessen,
sammanställningen av tidigare forskning om för- och nackdelar med olika typer av
verktyg och beskrivningen av tillvägagångssätt vid praktiska test med Selenium
WebDriver. Flera av de rekommendationer som ges är också relevanta i andra fall,
exempelvis att implementera en teststrategi som begränsar antalet automatiserade GUI-
test och att vara uppmärksam på att Selenium WebDriver har begränsningar i förhållande
till moderna webramverk.
7.4 Metodkritik Det största hotet mot studiens reliabilitet är att de praktiska testerna med Selenium
WebDriver utfördes av författarna själva, som är oerfarna utvecklare och inte hade
kunskap om hur koden i C-Load är uppbyggd. Om istället erfarna utvecklare hade gjort
testerna hade resultatet med stor sannolikhet sett annorlunda ut. Analysen visar dock att
även erfarna utvecklare har haft samma typ av problem, så den största skillnaden kan vara
att erfarna utvecklare skulle ha skrivit skripten och löst problem snabbare.
Antalet intervjuer med personer som hade erfarenhet av AGT var färre än önskat. Detta
berodde på att fler personer med erfarenhet av AGT inte hittades inom Triona.
På grund av att arbetet utfördes under Coronapandemin 2020 arbetade många på Triona
hemifrån, vilket medförde att tre av de fem intervjuerna utfördes via webbmöte. Endast
Mirjami Olsson och Cecilia Landberg intervjuades öga mot öga. Även om vi såg övriga
respondenter på skärm kan kvaliteten på intervjuerna ha påverkats negativt av att vi inte
kunde läsa deras kroppsspråk etc. Dock upplevde vi det inte som ett problem, då ämnet
som behandlades inte var känsligt.
41
En svaghet i testerna av Selenium WebDriver var att vi inte hade tillgång till en version av
C-Load med kända fel. Därför kunde Selenium WebDrivers förmåga att hitta defekter inte
observeras. Att sätta upp en separat testmiljö för denna studie ansågs inte befogat, då
syftet inte var att undersöka förmågan att upptäcka defekter i detalj. Dessutom gav varken
litteraturen eller information funnen i bloggar och forum ingen anledning att misstänka att
förmågan att hitta defekter skulle vara ett problem.
7.5 Vidare forskning Av studiens resultat framgår att en stor utmaning när man skriver testskript för AGT är att
hantera väntan på att element ska finnas tillgängliga på sidan innan man försöker utföra
operationer på elementet. Det framkom också i studien att detta problem är än större i
applikationer byggda med moderna webbramverk. Cypress är liksom Selenium
WebDriver byggt i öppen källkod, men fungerar enligt en annan princip. Istället för att
skicka kommandon till webbläsaren agerar Cypress istället “inuti” webbläsaren (Cypress,
2020). Detta gör enligt Cypress (2020) att verktyget ”vet” när element finns tillgängliga på
sidan och utvecklare behöver inte bekymra sig om att definiera väntetider i skripten.
Studier som beskriver hur Cypress fungerar i praktiken och hur verktyget presterar jämfört
med Selenium WebDriver vore mycket intressanta.
42
8 Slutsatser Här ges en resumé av studien och de viktigaste slutsatserna av diskussionen presenteras.
Denna studie handlar om för- och nackdelar med olika typer av. verktyg för
automatiserade GUI-test och hur automatiserade GUI-tester med Selenium WebDriver
fungerar i praktiken. Triona ville undersöka möjligheterna att automatisera
regressionstester av sin produkt C-Load, en molnbaserad webbtjänst för avtalsbaserad
transportbokning. Regressionstesterna görs från GUI:t, vilket kräver särskilda verktyg.
Det primära syftet med studien ä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.
Baserat på tidigare forskning gjordes bedömningen att ett skript- och komponentbaserat
verktyg där koden skrivs manuellt bäst uppfyller Trionas krav och förutsättningar. Detta
eftersom det är komplicerat att skapa de modeller som används i modellbaserade verktyg,
medan skriptlösa verktyg bör användas som ett komplement, inte som det enda verktyget.
Att använda ett komponentbaserat verktyg där koden skrivs manuellt motiveras främst av
att detta bedöms minimera arbetet med att underhålla testskript. När C-Load-förvaltningen
kommit igång med AGT kan det vara intressant att kombinera komponentbaserade med
visuella test, för att kunna verifiera GUI:ts utseende.
Det verktyg som utvärderades var det i industrin mest använda skriptbaserade verktyget,
Selenium WebDriver. Genom observationer och intervjuer kunde slutsatsen dras att det
vore möjligt att automatisera regressionstester av C-Load med hjälp av Selenium
WebDriver, och att det på sikt kan frigöra tid. Initialt skulle dock en betydande insats
krävas för att implementera automatiserade tester. Selenium WebDriver uppfyller bara
delvis C-Load-förvaltningens förväntningar på AGT och Triona bör utvärdera andra
verktyg innan beslut fattas.
Något som bör beaktas vid valet av verktyg för AGT är att Selenium WebDriver är skapat
för serverbaserad webbteknik. Att skapa testskript för applikationer byggda med moderna
webramverk, där applikationslogiken till stor del hanteras i webbläsaren och asynkrona
anrop görs mot servern, kräver en större utvecklingsinsats.
Att Selenium WebDriver inte fullt ut kan uppfylla C-Load-förvaltningens förväntningar
ska inte tolkas som att verktyget ska uteslutas, eller att AGT är fel väg att gå. Det samlade
intrycket är att AGT allmänt ses som mer eller mindre nödvändigt, men oavsett vilket
verktyg som används lever AGT ofta inte riktigt upp till förväntningarna, då
arbetsinsatsen som krävs för att skapa och underhålla tester lätt underskattas. Det finns en
konflikt i att med hög utvecklingstakt och korta utvecklingscykler är behovet av
automatiserade tester stort, men samtidigt är det då som svårast att hantera underhåll av
testskripten. Någon direkt lösning på detta dilemma verkar inte finnas, men problemet kan
minskas genom att ha en teststrategi där merparten av testen körs på lägre nivåer, så att
antalet testfall på GUI-nivå inte blir så stort
43
Källförteckning Aho, P., Vos, T. (2018). Challenges in Automated Testing Through Graphical User
Interface. 2018 IEEE International Conference on Software Testing, Verification and
Validation Workshops (ICSTW), Västerås. Hämtad från
https://doi/10.1109/ICSTW.2018.00038
Alégroth, E. (2015). Visual GUI Testing: Automating High-level Software Testing in
Industrial Practice. Doktorsavhandling, Chalmers tekniska högskola, Göteborg). Hämtad
från https://research.chalmers.se/publication/221145
Alégroth, E., Feldt, R. (2017). On the long-term use of visual GUI testing in industrial
practice: a case study. Empirical Software Engineering 22, 2937–2971. Hämtad från
https://doi.org/10.1007/s10664-016-9497-6
Alegroth, E., Gao, Z., Oliveira, R., & Memon, A. (2015). Conceptualization and
Evaluation of Component-Based Testing Unified with Visual GUI Testing: An Empirical
Study. 2015 IEEE 8th International Conference on Software Testing, Verification and
Validation (ICST), Graz. DOI: 10.1109/ICST.2015.7102584.
Bernardino, M., Rodrigues, E.M., Zorzo, A.F. & Marchezan, L. (2017).
Systematic mapping study on MBT: tools and models. IET Software, 11(4). doi:
10.1049/iet-sen.2015.0154
Berner. S., Weber. R., & Keller. R. K. (2005). Observations and lessons learned from
automated testing. In Proceedings of the 27th international conference on Software
engineering (ICSE ’05). Association for Computing Machinery, New York, NY, USA,
571–579. Hämtad från https://doi-org.www.bibproxy.du.se/10.1145/1062455.1062556
Bhargava, S., & Jain, P. B. (2018). Testing connect automated technologies. I-Manager's
Journal on Software Engineering, 13(2), 18-24. Hämtad från
http://dx.doi.org/10.26634/jse.13.2.15225
Björklund, M. & Paulsson, U. (2012). Seminarieboken – Att skriva, presentera och
opponera. Lund: Studentlitteratur.
Cypress. (2020). The web has evolved. Finally, testing has too.
Hämtad 2020-05-02 från https://www.cypress.io/
Debroy, V., Brimble, L., Yost, M., & Erry, A. (2018, 9-13 april). Automating Web
Application Testing from the Ground Up: Experiences and Lessons Learned in an
Industrial Setting. 2018 IEEE 11th International Conference on Software Testing,
Verification and Validation (ICST), Västerås. Hämtad från
https://doi.org/10.1109/ICST.2018.00042
Dobslaw. F., Feldt. R., Michaëlsson. D., Haar. P., Gomes de Oliveira Neto F., & Torkar.
R. (2019). Estimating Return on Investment for GUI Test Automation Frameworks. 2019
EEE 30th International Symposium on Software Reliability Engineering (ISSRE), Berlin.
Hämtad från https://doi/10.1109/ISSRE.2019.00035
Ellims, M., Bridges, J. & Ince, D.C. (2006). The Economics of Unit Testing. Empirical
Software Engineering 11, 5–31. Hämtad från https://doi.org/10.1007/s10664-006-5964-9
Eriksson, U. (2008). Test och kvalitetssäkring av IT-system. Lund: Studentlitteratur.
44
Fowler, M. (2018, 26 feb). The Practical Test Pyramid [Blogginlägg]. Hämtad från
https://martinfowler.com/articles/practical-test-pyramid.html
Garousi. V., & Yildirim. E. (2018). Introducing Automated GUI Testing and Observing Its
Benefits: An Industrial Case Study in the Context of Law-Practice Management Software.
2018 IEEE International Conference on Software Testing, Verification and Validation
Workshops (ICSTW), Vasterås. Hämtad från https://doi/10.1109/ICSTW.2018.00042
Garousi, V. &. Mäntylä, M. (2016). A systematic literature review of literature reviews in
software testing. Information and Software Technology, 80, 195- 216. Hämtad från
https://doi.org/10.1016/j.infsof.2016.09.002.
IEEE (1994) Guide for Software Verification and Validation Plans," in IEEE Std 1059-
1993, vol., no., pp.1-87, 28 April 1994, doi: 10.1109/IEEESTD.1994.121430. Hämtad
från https://ieeexplore.ieee.org/document/838043
Janicki, M., Katara, M., & Pääkkönen, T. (2012). Obstacles and opportunities in
deploying model‐based GUI testing of mobile software: a survey. Software Testing,
Verification and Reliability, 22(5), 313-341. Hämtad från https://doi.org/10.1002/stvr.460
Leotta. M., Clerissi. D., Ricca. F., & Tonella P. (2013). Capture-replay vs. programmable
web testing: An empirical assessment during test case evolution. 2013 20th Working
Conference on Reverse Engineering (WCRE), Koblenz. Hämtad från
https://sepl.dibris.unige.it/publications/2013-leotta-WCRE.pdf
Mascheroni, M. A., & Irrazábal, E. (2018). Continuous testing and solutions for testing
problems in continuous delivery: A systematic literature review. Computación y Sistemas,
22(3), 1009-1038. Hämtad från http://www.scielo.org.mx/scielo.php?pid=S1405-
55462018000301009&script=sci_arttext
Microsoft. (2019a). An introduction to NuGets. Hämtad 2020-04-29 från
https://docs.microsoft.com/en-us/nuget/what-is-nuget
Microsoft. (2019b). What features and services do I get with Azure DevOps? Hämtad
2020-05-14 från https://docs.microsoft.com/en-us/azure/devops/user-guide/services?view=azure-devops
Nguyen, B.N., Robbins, B., Banerjee, I., Memon, A. (2014). GUITAR: an innovative tool
for automated testing of GUI-driven software. Automated Software Engineering 21, 65–
105. https://doi.org/10.1007/s10515-013-0128-9
Oates, J. B. (2006). Researching Information Systems and Computing. London: SAGE.
Orakel (2020). Ord och uttryck i it-branschen. Hämtad 11 maj 2020 från https://it-
ord.idg.se/ord/orakel/
Prabhu, J., Malmurugan, N. (2013). A Model for GUI Automated Testing Framework.
Software System. International Journal of Computer Applications, 64(15), 16-20. Hämtad
från https://doi/10.5120/10710-5674
Presler-Marshall, K., Horton, E., Heckman, S., & Stolee, K. (2019, May). Wait, Wait. No,
Tell Me. Analyzing Selenium Configuration Effects on Test Flakiness. 2019 IEEE/ACM
45
14th International Workshop on Automation of Software Test (AST). IEEE. Hämtad från
https://doi/10.1109/AST.2019.000-1
Xie, Q. Memon, A. M. (2007). Designing and comparing automated test oracles for GUI-
based software applications. ACM Transactions on software engineering and
methodology, 16 (1). DOI:https://doi.org/10.1145/1189748.1189752
Raulamo-Jurvanen, P., Mäntylä. M., & Garousi. V (2017). Choosing the Right Test
Automation Tool: a Grey Literature Review of Practitioner Sources. In Proceedings of the
21st International Conference on Evaluation and Assessment in Software Engineering
(EASE’17). Association for Computing Machinery, New York, NY, USA, 21–30. Hämtad
från https://doi.org/10.1145/3084226.3084252
Selenium. (2020a). The Selenium Browser Automation Project. Hämtad 2020-05-02 från
https://www.selenium.dev/documentation/en/
Selenium. (2020b). Page object model. Hämtad 2020-05-26 från
https://www.selenium.dev/documentation/en/guidelines_and_recommendations/page_obje
ct_models/
Thummalapenta. S., Sinha. S., Singhania. N., & Chandra. S. (2012). Automating test
automation. In Proceedings of the 34th International Conference on Software Engineering
(ICSE ’12). IEEE Press, 881–891. Hämtad från
https://dl.acm.org/doi/10.5555/2337223.2337327
Utting, M., Pretschner, A., & Legeard, B. (2012). A taxonomy of model‐based testing
approaches. Software testing, verification and reliability, 22(5), 297-312. Hämtad från
https://doi.org/10.1002/stvr.456
Vila, E., Novakova, G., & Todorova, D. (2017). Automation testing framework for web
applications with selenium WebDriver: Opportunities and threats. International
Conference on Advances in Image Processing. Hämtad från
https://doi/10.1145/3133264.3133300
Vos. T. E. J., Marín. B., Escalona. M. J., & Marchetto. A. (2012). A Methodological
Framework for Evaluating Software Testing Techniques and Tools. 12th International
Conference on Quality Software, Xi'an, Shaanxi. Hämtad från
https://doi/10.1109/QSIC.2012.16
W3C (2018) W3C Recommendation 05 June 2018 Hämtad från
https://www.w3.org/TR/2018/REC-webdriver1-20180605/
W3C (u, å) About W3C. Hämtad från https://www.w3.org/Consortium/
Wetzlmaier. T., & Ramler, R. (2017). Hybrid monkey testing: enhancing automated GUI
tests with random test generation. In Proceedings of the 8th ACM SIGSOFT International
Workshop on Automated Software Testing (pp. 5-10). Hämtad från
https://dl.acm.org/doi/abs/10.1145/3121245.3121247
Zeng. Y. (2014). Relationships between different versions of Selenium [Blogginlägg].
Hämtad från https://yizeng.me/2014/04/25/relationships-between-different-versions-of-
selenium/
1
Bilaga 1: Intervjuguide
Frågor till Mirjami Olsson, förvaltningsledare och testledare C-Load
Arbetssätt
Hur är arbetet med olika produkter och projekt organiserat?
Är både utvecklare och testare knutna till specifika produkter och/eller projekt eller är det
mer rörligt?
Jobbar man på samma sätt med test i hela organisationen eller varierar det?
Test
Hur använder Triona automatiserade test i andra sammanhang än just regressionstester av
GUI?
Använder Triona automatiserade regressionstester av GUI i andra produkter/projekt?
C-Load Hur ser arkitekturen för C-Load ut?
Byggt med ASP.NET Core eller annat?
Test av C-Load Hur går testningen av C-Load till idag?
Verktyg? NUnit? xUnit? Annat?
Miljöer?
Regressionstester C-Load Hur ofta sker regressionstester av C-Load?
Hur lång tid tar det?
Hur mycket av regressionstesterna är redan automatiserade?
Vilka testfall körs för GUI regressionstester/Hur avgörs vilka testfall som ska köras?
Är tiden för test eller antalet testfall som körs variabelt?
Körs tillräckligt antal testfall eller skulle man behöva testa mer?
Hur rapporteras och sammanställs resultatet?
Frågor till övriga respondenter Från vilket/vilka projekt/produkter har du erfarenhet av automatiserad GUI-testning?
Vilken roll hade du?
Varifrån kom initiativet att använda automatiserade GUI-test?
Vilka motiv fanns för att automatisera? / Vilka förväntningar fanns?
Vilket testverktyg användes?
Bakgrund till att testverktyget ni använde valdes? Vilken typ av system handlade det om?
(Web service? Desktop app?)
Framework och språk för detta system?
I vilka test användes automatisering?
Motiv till att automatisera just dessa test?
Hur gick arbetet med automatiseringen till?
Fördelar jämfört med manuella tester?
Nackdelar jämfört med manuella tester?
Uppfylldes förväntningarna?
1
Bilaga 2: Kodexempel Page Object Model (POM)
I den första bilden utförs en inloggning på en loginsida och sedan navigerar skriptet till
knappen för att lägga till ett nytt lass. I bild 1 finns all logik samlad i samma klass. Hur vi
identifierar elementen, utför handlingar och hanterar waits. I bild 1 används långa Xpaths.
I bild 2 och 3 har vi implementerat POM och brutit ur logiken för att identifiera element
och utföra handlingar till en LoginPage (Page Object) som innehåller metoder för
identifiering och alla händelser. Här används ID selektorer istället för Xpath. I bild 3
använder vi bara metoderna från respektive page object. Allt som sker i bild 1 sker i bild 3
på de fyra första raderna av skriptet.
1.
2.
2
3.
1
Bilaga 3: Transkriberingar av intervjuer
Intervju 1 med Mirjami Olsson, förvaltningsledare och testledare
Fråga: Är både utvecklare och testare knutna till specifika produkter eller är det
mer rörligt?
Svar: Det är definitivt mer rörligt. En del sitter heltid i ett projekt medans andra
sitter deltid i flera projekt.
Fråga: Kallas alla produkter för projekt?
Svar: Det korrekta namnet är förvaltning.
Fråga: Du nämnde att C-Load fått en anmärkning på att ni inte använder
automatiska enhetstester, vad innebär det?
Svar: Det är på grund av en ny kartläggning som vår CFO har gjort på hur det ser
ut i de olika förvaltningarna. Där fick man en grön om det var okej, gul om en
person har en viss kompetens eller röd om det saknas. Det fungerade som notiser
till förvaltningar. T.ex för oss så fick vi en notis om att vi ska titta på ramverk för
automatiserade enhetstester. En hälsokontroll som följs upp årligen.
Fråga: Om vi sätter upp skript för att prova med Selenium så kommer vi använda
ett testframework, är det viktigt att vi väljer ett som ni tänker använda sen eller
spelar det ingen roll?
Svar: Detta arbete har inte påbörjat från vårt håll, däremot har nog Thomas redan
koll på vilket ramverk som är tänkt att användas. Det spelar nog inte så stor roll.
Fråga: Används automatiska tester i andra sammanhang än GUI?
Svar: Det varierar mycket mellan förvaltningar. Det är styrt av kraven.
Regressions tester på GUI är mindre vanliga än andra typer av tester.
Fråga: Kan du berätta lite allmänt om testning av C-Load?
Svar: Vi har en teststrategi i C-Load som säger hur och när vi ska testa, för
kvalitetssäkringen och hur hela processen ser ut. Jag har valt som testledare att inte
uppdatera den nu eftersom vi ska gå över till azure devops och då kommer vår test
process förändras, vi går ifrån den klassiska vattenfallsmetoden till att ha mer
scrumliknande testning och dels testa mycket tidigare och måste göra om strategin
mer, därför är strategin lite eftersläpande. Testen börjar när vi kravar ett ärande
och då analyser, kravinsamlare, krav är en del av test. När det är klart och vi är
nöjda, då går det över till “färdigt” eller definition of ready, då utveckling kan
börja, vi kör med testdriven utveckling så när utvecklarna börjar så startar dom
med ett testfall. Jag verifier att dessa stämmer överens med kraven så att vi har sett
kraven på samma sätt. När det är utvecklat så kan ärenden läggs ut på betamiljön
och testas där. Vi jobbar med ganska hårda datum där vi följer en
utvecklingsperiod nu till sista februari kodstop och mars testperiod och driftsätter
första april. När alla tester är gjorda och alla buggar är rättade uppdateras miljön
till senaste versionen och då kan regressionstesterna börja och testar vi inte bara
det som är ändrat utan hela flödet med speciellt fokus på det som är ändrat.
Regressionstestfallen hämtas ur en regressionstestbank där alla tidigare versioner
sparas och kan plockas fram och ändrade till aktuell release.
Fråga: Vem är det som testar?
Svar: Som vi som är ett litet team så är jag både testledare och testare men jag kan
inte sitta och testa själv allting, det skulle jag inte hinna så då så har vi en som är
med och testar och en som är supportpersonal som också testar. Även utvecklare
och produktägare sitter med och testar. Så lite beroende på hur stor release det är
2
så fördelar vi tester till olika personer inom förvaltningen. Så alla får mer eller
mindre ta på sig en testhatt.
Fråga: Hur ofta testar ni?
Svar: Det är fyra planerade releaser, en per kvartal, så det är fyra gånger per år
som vi har testperioder där vi regressionstester nya releases. Men däremellan
kommer oplanerade och planerade patcher som behöver testas. Ibland väljer vi
också att dela upp en release i två mindre. Test kan ske hela tiden men minst under
dessa perioder. Innan man börjar testa så har man gjort en testplanering där man
tar fram fall, testar dom, fylla med testdata, planering och genomförande. Varje
release har en testplan med arbetsfördelning och vad som ska testas.
Fråga: Vilka miljöer finns?
Svar: Vi har en produktionsmiljö, en betamiljö med en produktionsdatabas, en
acceptanstestmiljö, en demomiljö och en testmiljö med en testdatabas.
Fråga: Hur lång tid brukar det ta?
Svar: Det är sällan vi har mer än en vecka på att regressionstesta. Om man räknar
in dokumentation, skriva användarhandledning, release notes och planering så är
det är en längre period men själva testningen är en kort period.
Fråga: Hur väljer du vilka testfall som ska testas?
Svar: Vi har alltid en bas som testas och sen går jag igenom versionen vi har
jobbat med och ser vad som behöver testas. Sen går man på erfarenhet vad man vet
brukar behöva testas.
Fråga: När ni ska testa, har ni en viss tid på er och vad händer om ni inte hinner?
Stryker ni test eller flyttas tiden?
Svar: Det är testledaren som sitter på det beslutet, är systemet tillräckligt bra för
att driftsättas? Senaste releasen fick vi flytta fram releasen två veckor t.ex, det
gjorde vi dock innan testperioden började men såg direkt att det inte skulle hinnas
med. Det har behövts göra ibland.
Fråga: Varför vill man automatisera?
Svar: För att spara tid och för att datorer ibland är mer att lita på än människor.
Speciellt för repetitiva uppgifter. För att se till att ett flöde fungerar som det ska
och kunna täcka in fler test på samma tid.
Fråga: I de test case som vi har fått tilldelade, det viktiga är alltså att flödena
fungerar från början till slut?
Svar: Ja precis, i de vanligaste webbläsarna.
Fråga: Är det viktigt att tiden man lägger totalt ska bli mindre för att få en bra
ROI?
Svar: Det ska definitivt inte ta mer timmar för då är det inte värt utan någonstans
vet vi att det är tidskrävande att testa och vi skulle genom att frigöra tid att
utvecklaren kan börja på nästa release och jobba på en annan branch så målet är att
det tar färre mantimmar på det hela. Men det är en avvägning på att det ska ta lite
tid och ha en bra testtäckning så det är en avvägning man får göra men helt klart
att det inte ska ta två heldagar att gå igenom flödet varje gång.
Fråga: Är det något som ni ser som en potentiell risk?
Svar: 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.
Intervju 2 med Hansi / Utvecklare
Fråga: Vilken roll har du haft i tidigare projekt som använt sig utav automatiserad
testning?
3
Svar: Utvecklare och delade arkitektrollen med några andra.
Fråga: Vad var det ni gjorde?
Svar: Vi byggde ett system som bara kommunicerar med andra system.
Huvuddelen ligger på integration.
Fråga: Använde automatiska tester i delen av projektet du var en del va?
Svar: Absolut, enhetstester. Det är en kvalitetsfråga, vi bygger ingenting utan
automatiska tester. I det projektet jag sitter i nu på ABB, det är en desktop
application med CAD. Otroligt komplext med många år på nacken, det är svårt att
leverera med kvalitet. Vi är beroende av att helt test team i Indien som kör
regressionstester osv. på det och dom fångar inte allt som vi behöver få fångat. så
automatisk testning är en förutsättning för att kunna leverera med kvalitet.
Fråga: Vad använder ni för verktyg/framework för enhetstestning
Svar: Vi körde med Visual Studio, TFS och C# framförallt men också Typescript
och även .NET och .NET Core. Själva testerna kördes med Xunit och lite
tilläggsprodukter.
Fråga: Har du erfarenhet av andra verktyg som Nunit t.ex?
Svar: Ja, jag har använt Nunit också och det är snarlikt med Xunit. Ingen större
skillnad.
Fråga: Har du några tips som man bör tänka på när man skriver tester?
Svar: Det viktigaste är att man skriver testerna från början. Att första skriva kod
och sedan lägga på tester är ingen bra idé. Men följer man SOLID mönstret så är
man ganska hemma redan.
Fråga: Stötte ni på några svårigheter när ni arbetade med automatiserade tester?
Svar: Om man kikar på låg nivå, dvs klassnivå så är ganska enkelt och rättframt
om man följer SOLID. När man kommer upp på flödestester där man är beroende
av större datamängder och när en viss konfiguration ska gälla. Då blir det svårt.
Det svåra är att hitta bra avgränsningar för testerna. Det är inte själva tekniken som
är svår utan design- och arkitekturmässigt.
Intervju 3 med Cecilia Landberg, Testledare och kravanalytiker
Fråga: Hur har du jobbat med GUI-tester?
Svar: Jag är kodar ingenting utan har varit testledare och kravanalytiker, varit med
och tagit fram scenarios där vi använt Seleniumtester. Vi jobbar mycket med
devops, i vår testmiljö så deployar vi till den minst två gånger per dygn och
nattetid kör vi igenom seleniumtesterna. Min erfarenhet av det är det jag fått höra
från utvecklarna och det är att det tar mycket lång tid. Det är därför vi kör på
natten. Man tycker att testen är krångliga att underhålla. I ett projekt i förvaltning
fungerar det nog bättre. Vi får ny kod varje dag och seleniumtesterna som är
känsliga för förändring smäller ganska ofta då. Därför använder vi inte så mycket
seleniumtester som vi hade velat.
Fråga: Hur stor del av regressionstesterna täcker Selenium nu för er?
Svar: Just nu kanske vi testar 15% av gränssnittet men det är mest happy flows.
Fråga: Upplever du att Selenium är ett bra komplement till manuella tester?
4
Svar: Ja det är det och har man ett system som är mer stabilt eller är i förvaltning
så är det säkert mer värdefullt. När man är mitt i utveckling så måste man ändra
fallen hela tiden.
Fråga: Hade det gått snabbare om man utförde testerna manuellt?
Svar: Nej, även om det går långsamt så upplever vi att vi tjänar in tid, dom körs ju
på nätterna så om det uppstår något fel så kan vi ta tag i det dagen efter.
Intervju 3 med Berglund Berglund, Utvecklare
Fråga: Vad hade du för roll i projektet som använde automatiserade tester?
Svar: Utvecklare
Fråga: Varifrån kom initiativet att använda just Selenium?
Svar: Vi insåg att när vi utvecklade så förstördes web interfacet ibland utan att vi
visste om det. Ändringar i APIet eller nästan vart som helst som förstörde
gränssnittet så då tittade jag lite på hur man kunde testa det automatiskt. Vi valde
helt enkelt det mest populära för att fjärrkontrollera en browser. Vi kom fram till
att det krävdes mer arbete än vi hade tid med för att få en bra grund på plats.
Fråga: Var tog det stopp och hur långt kom ni?
Svar: Vi har tester som testar en sida nu sen kör vi TFS(Team foundation server)
med ett byggsystem där vi får en rapport om testerna inte går inte igenom. Jag kom
dit där jag började skriva testen och insåg att för att göra de moment som krävs så
måste man kunna adressera en textbox t.ex för att spara data och det var inte alltid
som det fanns bra ID’n att använda utan fick använda Xpath. Jag började med att
skriva lite hjälpmetoder för ibland måste man även vänta på att element dyker upp
i dokumentet. I ett bra test så vill man kunna t.ex skriva in användarnamn och
lösenord, trycka på login och få tillbaka resultatet. Jag insåg att det blev alla
möjliga olika selektorer, vänta på element som blev krångligt. Jag insåg att det
behövdes ett lager abstraktion till. T.ex page object model. Något sånt hade vi
behövt för att skriva bra tester och kunna fokusera på testerna. Istället för att
fokusera på det så bestämde vi att testerna inte var viktiga nog. Det är nog där
problemet ligger, man behöver en bra abstraktion ovanpå Selenium för att skriva
bra tester. Istället för att ha massa logik i testen. Man måste känna till hur appen
ser ut i browsern och hur det förändras för att kunna göra det bra.
Fråga: Var du ensam med att utveckla testerna?
Svar: Ja. Vi kom inte jättelångt, vi testade en söksida som är central för just det
projektet. Vi ville se vad man kunde göra.
Fråga: Med abstraktion, var det för att testerna snabbt gick sönder?
Svar: Nej inte riktigt, mer för att det kändes som att testerna innehöll för mycket
logik och kod för att hitta element och vänta på rätt ställe, det blev olika sätt att
sätta värden, ibland körde men setText och ibland sendKeys osv. Med en page
object model skulle vi ha interfaces som har den logiken så man kan sätta
username och läs ut osv. Ett annat problem jag upptäckte var att det fanns inte
alltid bra idn för css selectors, oftast när man skriver en sida så slänger man på
samma klass på allt för att få utseenden men inget id för t.ex en knapp. Inget som
är unikt. Gör man en webb app mest test i tanken så kan man lägga tid på att sätta
unika idn så blir saker och ting mycket lättare. Även om xpath är kraftfullt så är
det lätt att det förstörs.
Fråga: Ditt samlade intryck i efterhand av det här, vill du köra selenium någon
mer gång?
5
Svar: Jag önskar att man hade mer sådana här tester. Det är svårt att testa GUI
grundligt. Vi hade en söksida där man kunde söka på en mängd saker. När man
testar den manuellt är det jobbigt att behöva söka efter sjutton olika saker. Då är
det en jättebra grej med automatiserade tester. Det kan finnas fel som är svåra att
upptäcka manuellt när man ska köra en hel “round trip” genom flödet. Tester an
GUI har inte setts som så viktiga i alla projekt men det är helt klart en bra grej att
lägga energi på. Det jag tror behövs är erfarenhet av att skapa en sån här page
object model för att göra det smidigare.
Fråga: Ni kom ju inte så långt som ni hade tänkt, struntar ni i testerna eller gjorde
ni dom manuellt istället?
Svar: Precis, vi la ner det och tänkte att vi kanske göra någon gång i framtiden om
vi får tid. Sen så har ju systemet blivit så pass stabilt så vi hamnar aldrig där vi
förstör grundläggande funktioner så behovet har försvunnit lite. Många vill ju gå
mot att driftsätta ofta i mindre iterationer och då är den här typen av tester ett
måste nästan för då finns inte tiden att sitta och testa igenom.
Intervju 4 med Olle Eriksson, Utvecklare
Fråga: Kan du berätta lite om ditt projekt?
Svar: Sveaskog var kunden, för typ 5 år sedan så drog dom igång ett projekt för att
förnya sitt centrala tekniska verksamhetsstöd, då vill man göra det med modern
webb och hade stort fokus på testautomation. Det var inte bara GUI baserade tester
utan enhetstester och integrationstester och längst upp GUI tester där användes
selenium som ramverk för dessa gui tester så vi hjälpte dom att sätta ihop
ramverket. Det som var svårt var att jobba med single page application.
Fråga: Kan du berätta mer om hur du gick tillväga och tekniken kring det?
Svar: Vi byggde med med angularJS som är ett ramverk för att bygga
webbapplikationer på ett strukturerat sätt. En av utmaningarna med selenium är att
det är ramverk som funnits länge som säkert grundas i en äldre typ av teknologi
där man förväntar sig callbacks. Alltså serverbaserade som typ PHP. Då passar
selenium bra för då har man tydliga gränser med interaktionen med servern.
Iochmed paradigmskiftet där man bygger webblösningar med t.ex ett REST API
då har man en server som inte känner av javascript osv. Det innebär att det är en
fristående klient som bara gör anrop med REST API då har selenium svårare. Man
får inte samma tydliga callbacks som går att fånga. Vi hade problem när klienten
gjorde asynkrona anrop, kanske en vänte snurra som väntade på att tre anrop skulle
gå klara, då fick vi göra massa specialkod för att få det att fungera med att t.ex
hämta ett värde.
Fråga: dom inbyggda waitsen i selenium funkade inte?
Svar: Nej dom bygger ju på den gamla tydliga tekniken, men det går att lösa och
hitta sätt runt men inte lika klart och tydligt som vi hade förväntat oss. Det kanske
har hänt en del nu, det var några år sedan som jag jobbade med detta. Det var
ganska tidskrävande att få det fungera stabilt. Vi fick ibland falska negativa utfall
som var knepiga att felsöka. Det här kokar nog ner till timingen och hur man
väntar in saker. Vi jobbade med continuous delivery, man checkar in kod och
automatiskt trycker ut den senaste koden till ett testsystem och vår strategi med
selenium var att vi inte gick mot ett sånt system utan vi satte upp en instans av ett
helt nytt system innan selenium körde sina tester så vi visste att vi hade en ren
installation av systemet och då måste man seeda in data för att kunna lägga upp en
order t.ex och det där var tidskrävande. Ganska långsamt att initiera systemet för
6
att börja köra gui testerna. Vi körde det under nätterna för det tog timmar att köra
testerna.
Fråga: Continuous delivery?
Svar: När man sätter igång med ett projekt idag och har råd så satsar man ofta på
continous delivery vilket går ut på att alltid kunna automatiskt installera ett system
på en målmiljö så hela testsviten körs så får det sker en ändring i koden.
Svar: Hur som helst, jag berättar vidare vad jag kommer ihåg, en grej vi gjorde var
att så fort vi fick ett fel så gick det att få en skärmbild hur det såg ut vid felet.
Eftersom vi använde devops så fick en bifogad bild vi kunde kika på vilket var
kraftfullt för att ta reda på varför något att failat. Loggar fick vi också bifogade.
Det är krångligt och dyrt att bygga dom här testfallen så det är nog bäst att bygga
dom när systemet är ganska satt och man har funktionen på plats. Vi började nog
lite för tidigt i systemet jag var med i. Då lägger man mycket tid på att ändra
testfallen för att guit man utvecklar förändras ofta. Systemet rörde sig fort för vi
var tio utvecklare. Så om någon byggde någon ny knapp så failade allas skript. Så
det är bättre att köra selenium när det är mer klart.
Fråga: Har ni använt page object model något?
Svar: Ja vi byggde page objects och vi märkte snabbt att det är bra att ha ID på
alla element, xpath är ganska fragilt. Att försöka få in den vanan i utvecklingen att
alltid tagga element med ID är nog väldigt viktigt. En bra grej vi gjorde några
gånger var att använda en testresurs som tog fram testfall så utvecklaren kunde
fokusera på själva kodningen och inte hur testet skulle se ut.
Fråga: Kom initiativet från kunden?
Svar: Kunden ville ha god testtäckning och så bra förutsättningar som möjligt för
enkel deploy, fokus låg på continuous delivery och då kom det som ett behov
Fråga: Varför just selenium?
Svar: Det fanns en resurs som kunde selenium och hade ett ramverk färdigt så vi
fick det lite till oss. Om jag hade gjort det idag så hade jag nog googlat fram lite
andra alternativ. Som C-Load ser ut idag så är nog Selenium bra men med modern
web så skulle jag nog välja något annat. Det är tråkigt med selenium att man måste
hacka fram vissa lösningar. Det är svårt och tidskrävande att felsöka. Vi fick ofta
sätta dom bästa utvecklarna på att felsöka.
Fråga: Fel i systemet eller fel i testen?
Svar: Lite hälften av gångerna faktiskt, ibland failar test 1 gång av 5 även fast de
inte borde ha gjort det. Det kändes som bortslösad tid.
Fråga: sammantaget, kostade det mer än smakade?
Svar: Jag ser det som ett av många verktyg som finns att tillgå, hade jag gjort det
från början så hade jag lagt så mycket det går på att få enhetstestning så bra som
det bara går och så skulle jag lägga en del krut på integration som testar server
stacken och så skulle jag ha några GUI testfall som testar centrala flöden när dom
är på plats och inte ska förändras så mycket. Att testa hela systemet med selenium
tar för lång tid.
![[Rakuten TechConf2014] [Osaka] Introducing Selenium 2 WebDriver](https://img.pdfslide.net/doc/110x75/5595a01a1a28ab0f448b460d/rakuten-techconf2014-osaka-introducing-selenium-2-webdriver.jpg)
