testverktyg för webbapplikationer1128980/fulltext01.pdf · arbete var ranorex och sencha test....

Testverktyg för webbapplikationer

Analys av testverktyg för regressionstester

Hanna Andersson

Systemvetenskap, kandidat 2017

Luleå tekniska universitet

Institutionen för system- och rymdteknik

2

Sammanfattning

Regressionstester är en viktig del under ett utvecklingsprojekts gång. De används för att kontrollera

att nya versioner av en befintlig programvara fungerar som förväntat och att inga plötsliga fel har

uppstått. Syftet med detta arbete har varit att ta fram utvärderingskriterier för val av ett testverktyg

som ska fungera att använda vid regressionstester av webbaserade systems grafiska användarsnitt.

Arbetet utfördes genom att använda en kvalitativ metod där litteratur och intervjuer användes som

stöd för utformandet av utvärderingskriterierna. De två testverktygen som analyserades i detta

arbete var Ranorex och Sencha Test.

Analys av resultatet av arbetet påvisar att enbart välja ett testverktyg kommer inte att uppfylla alla

de önskemål och krav som finns, utan att det är relevant att kolla på integrerade verktyg som en

helhet för att kunna få ut det maximala av testautomatiseringen. Att välja det verktyg som uppfyller

flest kriterier är inte heller alltid det lämpligaste, utan de utvärderingskriterier som väger tyngst bör

vara i fokus när ett val ska göras. Alla testverktyg har sina egna styrkor och svagheter, valet är

beroende på vad som anses vara viktigast i sammanhanget.

Nyckelord: Regressionstest, automatiserad testning, förutsättningslöst, välja testverktyg,

webbaserade system

3

Abstract

Regression testing is an important part during a development project. These tests are used for

verifying that new versions of the program work as expected and that no sudden error have

occurred. The purpose of this project has been to produce evaluation criteria for selecting a testing

tool used for regression testing of the graphical user interface of web-based systems.

A qualitative method was used during the work and literature and interviews were used to produce

the evaluation criteria. The two testing tools which were analyzed in this project were Ranorex and

Sencha Test.

The analysis of the results shows that only one testing tool won’t meet all wishes and requirements,

instead, it’s more relevant to look at integrated testing tools as a whole unit in order to get as much

as possible out of the testing automation. Choosing the testing tool that meets most of the criteria is

not always the best choice – the most important criteria should be in focus instead when the choice

is made. Every testing tool has its own strengths and weakness, and the choice should depend on

what is considered most important in the context.

Keyword: Regression testing, automated testing, unconditionally, selecting testing tool, web-based

system

4

Innehåll

Sammanfattning ...................................................................................................................................... 1

Abstract ................................................................................................................................................... 3

1 Inledning .......................................................................................................................................... 6

1.1 Bakgrund ................................................................................................................................. 6

1.2 Problemområde....................................................................................................................... 7

1.3 Syfte ......................................................................................................................................... 8

1.3.1 Forskningsfrågor .............................................................................................................. 8

1.4 Avgränsningar .......................................................................................................................... 8

1.5 Definition av begrepp .............................................................................................................. 9

1.6 Tidigare forskning .................................................................................................................. 10

2 Teori ............................................................................................................................................... 11

2.1 Regressionstest...................................................................................................................... 11

2.2 Automatiserad testning ......................................................................................................... 12

2.2.1 Fördelar med testautomatisering ................................................................................. 12

2.2.2 Nackdelar med testautomatisering ............................................................................... 13

2.3 Testfall ................................................................................................................................... 14

2.4 Att välja testverktyg .............................................................................................................. 15

2.5 Kriterium ................................................................................................................................ 17

2.5.1 Selektionskriterier ......................................................................................................... 17

2.5.2 Utvärderingskriterier ..................................................................................................... 19

3 Metod ............................................................................................................................................ 20

3.1 Arbetets framväxt .................................................................................................................. 20

3.2 Fallstudie ............................................................................................................................... 21

3.2.1 Datainsamling ................................................................................................................ 21

3.2.2 Val av litteratur .............................................................................................................. 22

3.2.3 Intervju .......................................................................................................................... 22

3.2.4 Analys av data ................................................................................................................ 23

5

3.2.5 Val av testverktyg .......................................................................................................... 24

3.2.6 Etik ................................................................................................................................. 24

4 Resultat .......................................................................................................................................... 25

4.1 Verksamhetsbeskrivning ....................................................................................................... 25

4.2 Utvärderingskriterier ............................................................................................................. 25

4.3 Testverktyg att undersöka ..................................................................................................... 27

4.3.1 Ranorex 7.0 .................................................................................................................... 28

4.3.2 Sencha Test 2.0 .............................................................................................................. 28

4.4 Val av verktyg ........................................................................................................................ 29

4.4.1 Analys mot utvärderingskriterier .................................................................................. 29

4.5 Implementation av testfall .................................................................................................... 33

4.5.1 Testfall ........................................................................................................................... 33

5 Analys ............................................................................................................................................ 37

5.1 Testautomatisering ............................................................................................................... 37


5.3 Val av verktyg ........................................................................................................................ 39

5.3.1 Jämförelse av testverktygen .......................................................................................... 39

5.3.2 Testverktygens styrkor och svagheter ........................................................................... 42

5.4 Implementationen av testfall ................................................................................................ 43

6 Slutsatser ....................................................................................................................................... 43


6.2 Val av verktyg ........................................................................................................................ 47

6.3 Metoddiskussion ................................................................................................................... 48

7 Referenser ..................................................................................................................................... 50

8 Bilagor ............................................................................................................................................ 52

8.1 Intervjufrågor ........................................................................................................................ 52

6

1 Inledning

Under detta introducerande kapitel kommer bakgrunden och problemområdet som ligger som grund

för arbetet att presenteras. Därefter kommer syftet, forskningsfrågor, avgränsningar, definitioner av

begrepp samt tidigare forskning att beröras.

1.1 Bakgrund

Idag är teknik en väldigt stor del av människors vardag och vi strävar ständigt efter att hitta nya sätt

att förbättra och utveckla den. Vi förlitar oss på att den teknik vi använder ska fungera som förväntat

utan att några problem uppkommer. Detta är en viktig faktor till att tester av program och system

bör genomföras – både när de skapas men även när förändringar i en redan existerande produkt

sker. Enligt Grindal, Offutt och Mellin (2006) brukar i genomsnitt 35% av tiden i ett utvecklingsprojekt

användas till att genomföra tester.

Regressionstester är de testaktiviteter som genomförs när förändringar skett i ett program eller

system. Två exempel på sådana förändringar är bland annat då nya funktioner blivit implementerade

eller om tidigare upptäckta buggar blivit åtgärdade. Syftet med dessa tester är att upptäcka

eventuella buggar och följdfel som kan ha uppstått vid förändringar i programkoden (Eriksson, 2008).

Enligt Eriksson (2008) leder ungefär var tredje ändring till att ett följdfel uppstår. Detta är en

anledning till att det inte räcker med att enbart testa den nya koden – utan även den gamla koden

bör testas. Det är möjligt att utföra dessa tester manuellt, men det är även möjligt att automatisera

dem. Automatisering av testerna innebär bland annat att de testskript som tidigare skapats går att

återanvända vid senare tester. Det kommer då att spara tid när de inte behöver utföras manuellt och

testarna kan istället ägna sig åt andra aktiviteter som ska genomföras (Randhawa & Pandey, 2006),

samtidigt som stor vikt fortfarande läggas på att utföra testerna utan att de riskerar att lämnas åt

sidan på grund av tidsbrist.

För att kunna skapa och utföra automatiska tester kan man ta hjälp av ett testverktyg. När man ska

välja ett verktyg bör man börja med att göra en utvärdering för att utreda vilka behov som finns

rörande testverktyg och automatisering av testerna (Hass, 2008). Olika verksamheter har olika

förutsättningar och därför kommer inte alla testverktyg att vara lämpliga för dem. Vissa

verksamheter kan ha stor nytta av ett verktyg medan en annan verksamhet inte har någon nytta av

just det verktyget överhuvudtaget. Vilket verktyg som är lämpligt kan avgöras genom att upprätta

kriterier som används till att utvärdera GUI-testverktyg. GUI står för graphical user interface – eller

7

grafiskt användargränssnitt på svenska. Syftet med ett GUI är att underlätta interaktion mellan

användaren och programvaran.

De upprättade kriterierna kan delas upp i två kategorier: selektionskriterier och utvärderingskriterier.

Syftet med selektionskriterierna är att välja ut ett antal testverktyg från den totala mängden och

utvärderingskriterier anger vad som bör utvärderas under utvärderingen av de utvalda testverktygen

(Poston & Sexton, 1992).

1.2 Problemområde

Det kan finnas många olika anledningar till att en verksamhet önskar att automatisera sina tester. En

av dessa anledningar är att manuella tester kan vara tidskrävande beroende på hur omfattande det

aktuella systemet är (Randhawa & Pandey, 2006). När ett system fortsätter att utvecklas och nya

funktioner tillkommer så innebär det även att antalet regressionstester som bör genomföras ökar. Då

systemet är nytt och inte inkluderar ett stort antal funktioner kan manuella tester fungera bra – men

när systemet fortsätter att växa tillkommer nya områden som även bör kontrolleras. För varje gång

regressionstesterna ska genomföras så kommer det krävas mer tid och mer resurser.

Andra områden som påverkas av att använda manuella tester är att både mänskliga och tekniska

resurser slösas. Mänskliga resurser innefattar de människor som är inblandade under testningen och

tekniska resurser innefattar den teknologi som används, exempelvis datorer. Den mänskliga faktorn

kan även orsaka att ett misstag sker och att en eller flera tester genomförs felaktigt (Grindal, Offutt &

Mellin, 2006). Detta kan leda till att ett resultat som inte stämmer överens med verkligheten uppstår

– och kan i värsta fall orsaka att en mängd följdfel tillkommer.

Upptäcker man ett problem först under systemtesterna är det mycket svårare att justera felen och

hitta tillbaka till den del i koden som är orsaken till att felet uppstod från första början. Hittas felen

istället redan under komponenttesterna är det enklare att spåra tillbaka till deras uppkomst (Grindal,

Offutt & Mellin, 2006). Genom att återanvända testskript som tidigare blivit skapade vid föregående

testomgångar är det möjligt att köra dessa i samband med utvecklingen för att kunna kontrollera att

det inte dykt upp några följdfel. För att detta ska gå att genomföra bör verksamheten först

implementera ett testverktyg som kan hantera de användningsområden och uppfyller de

formulerade kriterierna.

Att välja ett verktyg kräver noga reflektioner och överväganden för att kunna plocka ut det

verksamheten har mest nytta av ur den mängd som är aktuella på marknaden. Det bör tas i

beaktande hur verksamheten arbetar och vilka kännetecken de har för att kunna avgöra vilka

8

kriterier som bör uppfyllas och vilka förväntningar som finns på verktyget. I detta fall ska verktyget

fungera som ett hjälpmedel som bidrar med funktioner som kan underlätta när regressionstesterna

ska utföras men det ska även kunna bidra till att tidsåtgången för att utföra dessa tester minskar.

1.3 Syfte

Arbetets syfte är att ta fram utvärderingskriterier för att välja ett testverktyg och undersöka hur väl

verktygets egenskaper går att tillämpa vid regressionstester av webbaserade systems GUI. Dessa

utvärderingskriterier ska sedan utvärderas genom att jämföra testverktyg mot dem och sedan

valideras användbarheten av det lämpligaste verktyget i praktiken.

1.3.1 Forskningsfrågor

De frågeställningar som definierats för arbetet är följande:

• Vilka utvärderingskriterier för val av testverktyg kan utvinnas från egenskaper och

kännetecken tillhörande verksamheter som utvecklar webbapplikationer?

• Vilket av de undersökta testverktygen uppfyller främst de uppsatta utvärderingskriterierna

och hur väl fungerar det att använda i praktiken vid utförande av regressionstester?

1.4 Avgränsningar

Arbetet kommer att avgränsas till följande punkter för att kunna utföras inom den beräknade

tidsramen:

• Endast automatiserade regressionstester kommer att undersökas, inte de regressionstester

som utförs manuellt.

• Enbart två testverktyg kommer att väljas ut och analyseras under arbetet.

De testverktyg som kommer att undersökas är enbart de som…

• kan arbeta med webbaserade systems GUI.

• går att nyttja vid regressionstester.

• som stödjer ett agilt arbetssätt.

9

Implementation av testfall…

• kommer enbart att ske mot ett webbaserat system.

• kommer enbart ske mot en avgränsad del av systemet.

• kommer att begränsas till 4 stycken testfall.

1.5 Definition av begrepp

Begrepp Definition

End-to-end Tester som utförs från början till slut för att

exempelvis kontrollera att rätt information

skickas vidare mellan olika

systemkomponenter.

Dumb monkey Ett uttryck för en testteknik där testaren inte

har någon information om applikationen eller

dess uppbyggnad. Testerna utförs

slumpmässigt, exempelvis så kan det klickas på

slumpmässiga platser för att upptäcka oväntade

fel.

GUI Graphical user interface: Grafiskt

användargränssnitt. Tillåter att användare att

interagera med elektroniska maskiner genom

grafiska ikoner och visuella indikatorer.

Memory leak När ett program inte gör sig av med kasserat

minne och orsakar försämrat utförande eller

programkrasch.

Regressionstest Testaktiviteter som utförs vid förändringar i ett

program.

Snapshot En skärmdump tagen från exempelvis den

webbapplikation som är under testning.

Testaktivitet En aktivitet som utförs inom testning,

exempelvis de händelser som sker när ett

testfall utförs.

Testdata Data som är speciellt anpassad för att användas

under tester.

10

Testfall Ett ”recept” som beskriver hur ett test ska

utföras.

Testverktyg Ett program som är ett hjälpmedel för att skapa

och exekvera tester.

Verktyg Se: Testverktyg

Tabell 1 Definitioner av begrepp

1.6 Tidigare forskning

Inom detta område har flera tidigare forskningar utförts, både kring vilka metoder som kan användas

vid val av testverktyg och vilka kriterier som kan användas vid utvärdering av verktygen.

Hallnemo (2013) har tagit fram utvärderingskriterier som går att använda när ett testverktyg för

tester av GUI ska väljas ut. Syftet med denna studie var att ta fram ett underlag som kan hjälpa

verksamheter när de ska välja ett testverktyg från det utbud som finns. Dessa kriterier är generella

och täcker stora områden – vilket gör det möjligt för alla verksamheter att använda dem oavsett vilka

sorters testaktiviteter de önskar att utföra kopplade till GUI. Även Illes et al. (2005) har utformat ett

antal utvärderingskriterier som främst är inriktade mot mjukvarutestning. Dessa kriterier är möjliga

att använda vid många olika tester som kan utföras och är inte nödvändigtvis specifika för enbart ett

område.

Tiitinen (2013) lägger fram några rekommendationer inför val av testverktyg som kan vara bra att ta i

beaktande. Dessa rekommendationer kan användas tillsammans med utvärderingskriterier för att

kunna bidra med så bra grund inför valet som möjligt.

Detta arbete kommer att gå djupare och kommer även att fokusera på mer specifika kriterier för

verksamheter som i grunden har liknande kännetecken och egenskaper. Arbetets inriktning är mot

regressionstester av det GUI som webbaserade system har och kommer att bortse från övriga

testaktiviteter och testområden.

De utvärderingskriterier som sammanställts i arbetet kommer att bidra till en mer specificerad

granskning av testverktyg som kan vara lämpliga att använda under regressionstester av

webbaserade systems GUI. Testverktyg som finns på marknaden kommer att analyseras mot de

utvärderingskriterier som blivit sammanställda för att skapa en bredare bild kring hur väl de utvalda

verktygen kan arbeta med regressionstester mot GUI samt vilka funktioner de tillhandahåller.

11

Kort sammanfattat så kommer detta arbete att inrikta sig mot regressionstester av webbaserade

systems GUI och mer specifika utvärderingskriterier anpassade för just detta område kommer att

sammanställas.

2 Teori

Detta kapitel kommer att ta upp de teorier som är relevanta för detta arbete – så som

regressionstest, automatiserad testning, process för att välja testverktyg och vilka kriterier som kan

användas.

2.1 Regressionstest

Definitionen för regressionstester är att de är testaktiviteter som genomförs vid när förändringar

sker i ett redan existerande system. Enligt Eriksson (2008) leder ungefär var tredje ändring i kod till

att ett följdfel uppstår och regressionstesternas syfte är att upptäcka dessa i tid. Risken för att följdfel

uppstår innebär även att det inte enbart är den kod som ändrats som bör testas, utan att även kod

som inte förändrats bör tas i beaktning och ingå i de tester som utförs.

Regressionstester är en viktig del i testprocessen, men de kan även tillföra en väldigt hög kostnad.

Studier som gjorts inom området har visat att kostnaderna kan variera beroende på vilken version av

programmet som ska testas. De tekniker som varit mest kostnadseffektiva under en version behöver

inte alltid vara det mest kostnadseffektiva alternativet under varje version av programmet som

utvecklas (Schwartz & Do, 2016).

Enligt Memon (2002) kan regressionstester som utförs i ett GUI stöta på särskilda utmaningar då

både input och output är beroende på hur de grafiska elementen är upplagda. Förändringar i

layouten, exempelvis om en knapp blivit flyttad eller om en meny ändrats, kan leda till att äldre

testfall inte längre är aktuella.

Regressionstester är särskilt användbara för verksamheter som utvecklar en serie av liknande

produkter där de återanvänder produkter som de utvecklat i ett tidigare skede. Testskript som

skapats i samband med den första produkten kan sedan återanvändas när nästkommande produkt

utvecklas. Regressionstester är även användbara om verksamheten har ett projekt som sträcker sig

under lång tid då de kan användas till att säkerställa att funktioner fortfarande fungerar som de ska

under utvecklingsperioden (Onoma et al. 1998).

12

2.2 Automatiserad testning

Det är möjligt att genomföra regressionstester manuellt, men när programmet växer och fler

funktioner införs kommer det att bli allt mer tidskrävande. Studier har visat att ungefär 35% av tiden i

ett utvecklingsprojekt går åt till att genomföra tester och att tidfördelningen varierar mellan de olika

momenten inom testprocessen – men att majoriteten av testerna genomförs under

systemtestningen (Grindal, Offutt & Mellin, 2006). Istället för att utföra regressionstester manuellt så

går det även att automatisera dem. Definitionen av testautomatisering är den process som äger rum

då en programvara, det vill säga ett testverktyg, används för att utföra tester, kontrollera resultatet

samt rapportera eventuella fel som blivit upptäckta (Eriksson, 2008).

Testautomatisering kan påverka verksamheter både positivt och negativt, vidare i rapporten följer en

sammanfattning av dessa och en förklaring till vad de innebär.

2.2.1 Fördelar med testautomatisering

Automatisering av testerna för med sig flera fördelar, bland annat så blir det mer tidseffektivt och

det kommer reducera verksamhetens utgifter då färre mänskliga resurser behövs för att utföra

testerna. Testskript som blivit skapade tidigare går att återanvända vid nästkommande tester vilket

innebär att testarna inte behöver utföra alla regressionstester manuellt och kan istället fokusera på

övriga arbetsuppgifter (Randhawa & Pandey, 2006).

Testverktyg har även fördelen att de kan utföra tester som är nästintill omöjliga att utföra manuellt.

Prestandatester som utförs för att kontrollera att systemet uppfyller kraven på svarstid är ett

exempel på en sådan test (Eriksson, 2008).

13

Fördel Förklaring Referens

Återanvända testskript De testskript som skapats går att återvända vid

framtida tester.

Randhawa &

Pandey (2006)

Tidssparande Automatiska tester sparar tid och testarna har

tid över till andra arbetsuppgifter.

Minskad kostnad Automatiska tester minskar på antalet testare

som behöver vara närvarande för att utföra

testerna manuellt – samt tidsåtgången som

krävs för att genomföra dem.

Maskiner är pålitligare än

människor

Människor kan råka utföra tester fel, en maskin

kommer att göra precis som den blivit tillsagd

utan avvikelser.

Säkerställa kvalitén på

programvaror

Tester genomförs för att kunna kontrollera att

både nya och gamla delar i programmet

fungerar som tänkt.

Amannejad,

Garousi, Irving &

Sahaf (2014)

Alla har tillgång till

testresultatet

Användare med tillgång till testsystemet har

möjlighet att se vilka resultat testerna fått.

Base36 (2013)

Genomföra tester som

inte går att göra utan

verktyg

Det är möjligt att exempelvis genomföra

prestandatester vars syfte är att kontrollera om

systemet uppfyller uppsatta krav på svarstid.

Eriksson (2008)

Objektiva bedömningar Testresultaten får objektiva tal. Detta reducerar

antaganden och subjektiva uppfattningar.

Tabell 2 Fördelar med automatiserad testning.

2.2.2 Nackdelar med testautomatisering

Finns det fördelar så finns det även nackdelar, samma princip gäller när en verksamhet

implementerar automatiserade tester. Enligt Eriksson (2008) kan felaktig hantering av de nackdelar

testverktyg för med sig orsaka att kvalitén på produkterna försämras. Det är inte enbart nackdelar

med teknisk karaktär man bör se upp med, utan det finns även organisatoriska – exempelvis om ett

införskaffat verktyg slutar användas efter en tid.

För att automatisera testerna bör man införskaffa ett testverktyg, men dessa kan innebära en hög

kostnad för verksamheten. Verktygen har även begränsningar och alla tester kommer inte vara

14

möjliga att göra helt automatiserade. Exempelvis så har testverktygen inte möjlighet att testa fonter

eller färger på bilder (Base36, 2013).

Nackdel Förklaring Referens

Genomföra felaktiga tester

snabbare

Vet man inte vilka delar som är relevanta att

testa eller om någon av testerna är felaktiga

kommer testverktyget enbart att hjälpa till med

att utföra felaktiga tester snabbare.

Amannejad,

Garousi, Irving &

Sahaf (2014)

Testverktyg kan vara dyra Testverktyg kan vara dyra att köpa in. Base36 (2013)

Testverktyg har

begräsningar

Testverktyg kan inte genomföra exakt allt, utan

de har även begräsningar för vad de kan utföra.

Lita för mycket på

verktygen

Man kan köra flera hundra tester och inte hitta

några fel – då är en risk är att testfallen är dåligt

utarbetade eller att de blivit föråldrade.

Eriksson (2008)

Specialkompetens Vissa testskript kräver

programmeringskunskaper, alla testare besitter

inte dessa kunskaper.

Tabell 3 Nackdelar med automatiserad testning.

2.3 Testfall

Ett testfall innehåller information vars syfte är att beskriva hur en test i ett program eller system ska

utföras. Varje enskilt testfall har fokus på en särskild egenskap eller funktion som ska ingå i testerna

(Eriksson, 2008).

Det är möjligt att prioritera vissa utvalda testfall så att de som anses vara mest viktiga blir utförda

först eller i ett tidigare skede av testprocessen (Elbaum, Malishevsky & Rothermel 2002). En viktig

anledning till att denna prioritering används är att större program med flera tusen rader kod kan ta

lång tid att testa om alla regressionstester och nya tester ska genomföras. Prioritering av testfallen

kommer då innebära att de som är viktigast blir genomföra först och upptäckta fel inom de

områdena kan börja åtgärdas snabbare (Rothermel et al. 1999).

15

ID 14

Rubrik Spara kund

Förberedelser Logga in med säljarbehörighet

Teststeg 1. Välj kundmodulen.

2. Ange kunduppgifter.

3. Klicka på knappen ”Spara”.

Förväntat resultat Ett meddelande visas i programmets statusrad.

Meddelandet lyder: ”Kunden är sparad.”

Tabell 4 Exempel på ett testfall från Eriksson (2008, s.124).

2.4 Att välja testverktyg

Ett testverktyg är ett hjälpmedel som bland annat används vid automatiserade tester. Det går inte att

ta första bästa verktyg på marknaden, utan det bör genomföras en utredning för att ta reda på vilka

behov verksamheten har av att införskaffa ett verktyg. Eriksson (2008) lägger fram följande process

för att välja testverktyg som förslag:

Bild 1 Process för att välja testverktyg från Eriksson (2008, s.317).

1. Analysera grundläggande behov

Det första steget i processen är att analysera de grundläggande behoven som finns. Här

definieras syftet, målet, budget, samt den övergripande aktivitetsplanen – alltså inom vilka

ramar testverktyget bör befinna sig. Det är även lämpligt att framställa en lista som

innehåller de krav verksamheten har på verktyget, exempelvis vem som ska kunna använda

och dra nytta av det. Slutligen bör verksamheten fråga sig om deras testprocess är tillräckligt

16

stabil för att de ska ha någon nytta av att införskaffa ett verktyg eller om de inte ännu hunnit

bli mogna för det.

2. Definiera och inventera

I det andra steget ska de krav på testverktyget som framställts definieras och inventeras, här

går det djupare in på detalj och det är läge att prioritera kraven. Här är det relevant att

inkludera både de tekniska egenskaperna men även mjukare faktorer. Införskaffas ett

testverktyg kommer det att innebära långvarig kontakt med leverantören – vilket är en viktig

anledning till att kontrollera att deras support fungerar på ett bra sätt. Det är ännu inte läge

att börja göra några praktiska tester, men det är lämpligt att börja undersöka vilka kostnader

förutom anskaffningskostnaden som tillkommer för exempelvis utbildning, uppgraderingar

och support.

3. Hinder

Det tredje steget handlar om att identifiera de hinder ett testverktyg kan föra med sig. Ett

exempel på ett hinder är att olika verktyg inte alltid går att integrera med varandra eller att

integrationen mellan dem är bristfällig.

4. Avgränsa och föreslå

Det fjärde steget är att avgränsa och föreslå, alltså att skapa en utvärdering av de intressanta

testverktygen och sedan välja ut det som verkar mest lämpligt för verksamheten. Här gäller

det att ta fram verktygens svagheter och styrkor för att kunna jämföra dem.

5. Fatta beslut

Det sista steget är att ta ett beslut om ett testverktyg ska införskaffas eller inte. En rapport

innehållande en rekommendation lämnas in åt den eller de personer som är ansvariga för att

ta beslutet.

Ett antal liknande frågor har tagits fram av Software Testing Help (2016) som kan användas som

grund innan ett testverktyg ska väljas ut. Först sammanställer de några kriterier som kan användas

för att avgöra om verksamheten är mogen att införa automatiserad testning. Några av dessa kriterier

är bland annat om det finns många tester som repeteras och om det sker många iterationer av

regressionstester.

Följande frågeställningar har blivit sammanställda av Software Testing Help (2016) för att kunna

underlätta vid valet av verktyg:

1. Har verksamheten de resurser som krävs för att fördela uppgifter inom automatiseringen?

2. Vilken budget har verksamheten tillgänglig till införskaffandet av ett testverktyg?

17

3. Uppfyller testverktyget de behov verksamheten har inom testning och fungerar verktyget

med de miljöer och tekniker som används?

4. Finns det en gratis testversion av testverktyget och är alla funktioner tillgängliga i den?

5. Är testverktyget stabilt och har leverantören bra kundsupport?

6. Hur lätt är det att lära sig verktyget, har verksamheten tiden till detta?

7. Ska testverktyget enbart användas till ett projekt eller ska det fungera för alla verksamhetens

projekt?

8. Vilka typer av tester inriktar sig testverktyget mot? (Exempelvis regressionstester etc.)

9. Tillhandahåller verktyget ett interface som underlättar vid skapandet och underhållandet av

testskript?

10. Hur enkelt är det att lägga till testdata eller ladda tidigare tester?

11. Går testverktyget att integrera med andra testverktyg och fungerar integration mellan dem

bra?

2.5 Kriterium

När man ska välja ett testverktyg är det lämpligt att sätta upp olika kriterier som används vid

selektion och utvärdering. De kriterier som används vid selektion tillämpas för att kunna välja ut ett

antal testverktyg från den totala mängden och utvärderingskriterierna tillämpas för att fastställa vad

som bör finnas med i utvärderingen av de utvalda verktygen (Poston & Sexton, 1992).

2.5.1 Selektionskriterier

Selektionskriteriernas har en betydande roll vid val av testverktyg. De används för att avgöra om ett

testverktyg kommer att uppfylla de krav som ställs på det eller om det kan väljas bort direkt (Poston

& Sexton, 1992). Dessa kriterier kan delas in i olika grupper: funktionalitet, pålitlighet, användbarhet,

resursutnyttjande, underhållbarhet, flyttbarhet (Behkamal, Kahani & Akbari, 2009), kostnad,

leverantörkvalifikationer samt support (Carvallo & Franch, 2006).

Funktionalitet

• Typer av GUI som testverktyget har möjlighet att utföra tester på, exempelvis mobil- och

webbapplikationer (Lewis, 2005).

18

• Tillvägagångssätt för att utforma testskript, exempelvis inspelning och redigering (Börjesson

& Feldt, 2012).

• Testverktyget kan interagera med specificerade system (Behkamal, Kahani & Akbari, 2009).

Pålitlighet

• Återställning av data vid eventuell krasch i systemet (Behkamal, Kahani & Akbari, 2009).

• Hur ofta plötsliga fel uppstår (Behkamal, Kahani & Akbari, 2009).

Användbarhet

• Testverktyget tillåter att automatiserade tester återanvänds (Randhawa & Pandey, 2006).

• Testfall kan skapas utifrån de erfordrade testnivåerna, exempelvis regressionstest och

integration (Illes et al. 2005).

Resursutnyttjande

• De systemkrav testverktyget har bör framgå (Behkamal, Kahani & Akbari, 2009).

• Hur tidseffektivt testverktyget är (Börjesson & Feldt, 2012).

• Vilka resurser som krävs för att genomföra tester (Behkamal, Kahani & Akbari, 2009).

Underhållbarhet

• Väldokumenterat testverktyg underlättar möjligheten att genomföra analyser (Heitlager,

Kuipers & Visser, 2007).

• Enkelt att uppdatera testskript vid nya versioner och uppdateringar av programmet som ska

testas (Randhawa & Pandey, 2006).

Flyttbarhet

• Vilka plattformar som testverktyget fungerar att använda på (Poston & Sexton, 1992).

• Testverktyget kan integreras med andra test- och utvecklingsverktyg som används (Poston &

Sexton, 1992).

• Tester kan utföras från olika maskiner under samma tidpunkt (Randhawa & Pandey, 2006).

• Testverktygets förmåga att enkelt anpassas till olika miljöer (Behkamal, Kahani & Akbari,

2009).

Kostnad och licens

• Hur ägandeskapet för införskaffat testverktyg är definierat (Carvallo & Franch, 2006).

• De garantier som medföljer testverktyget (Carvallo & Franch, 2006).

19

• Testverktyget håller sig inom ramarna för angiven budget (Poston & Sexton, 1992).

Leverantörskvalifikation och support

• Ryktet leverantören har (Carvallo & Franch, 2006).

• Erbjuden support från leverantören (Carvallo & Franch, 2006).

2.5.2 Utvärderingskriterier

Utvärderingskriterier används för att utvärdera de testverktyg som blivit utvalda och kontrollerar om

de uppfyller de uppsatta kriterierna eller inte (Poston & Sexton, 1992). Det går att dela in dessa

kriterier i följande grupper: testplanering och översikt, analys och design, implementation,

testexekvering samt fånga och jämföra resultat, testrapportering, stöd för buggar och underhållsstöd

(Illes et al. 2005).

Testplanering och översikt

1) Testverktyget kan användas till specifika applikationsdomäner, exempelvis

webbapplikationer (Illes et al. 2005).

2) Personliga inställningar för att underlätta för användarna av testverktyget (Behkamal, Kahani

& Akbari, 2009).

Analys och design

1) Testfall kan designas för önskad testnivå, exempelvis enhetstest (Illes et al. 2005).

2) Testfall kan designas för att kunna testa applikationens kvalité (Illes et al. 2005).

3) Oanvändbara testfall kan automatiskt repareras (Memon, 2008).

Implementation

1) Testfall kan spelas in (Illes et al. 2005).

2) Skapade testskript kan redigeras (Illes et al. 2005).

3) Dynamiska komponenter kan hanteras (Börjesson & Feldt, 2012).

4) Tester kan utföras via fjärrdatorer (Börjesson & Feldt, 2012).

Testexekvering, samt fånga och jämföra resultat

1) Testverktyget stödjer regressionstester (Illes et al. 2005).

2) Testexekveringar kan pausas och sedan återupptas igen (Randhawa & Pandey, 2006).

20

3) Testscenarion kan väljas ut för att skapa mer målinriktade testexekveringar (Randhawa &

Pandey, 2006).

4) Testfall kan prioriteras, med andra ord rangordnas (Illes et al. 2005).

5) Misslyckas exekveringen av testfall finns det möjlighet för rollback (Illes et al. 2005).

6) Testfall som spelats in eller redigerats kan exekveras (Illes et al. 2005).

7) Testskript kan utföras i olika miljöer utan att förändringar måste ske i deras kod (Randhawa

& Pandey, 2006).

8) Testskripten kan köras utan att manuella ingripanden behöver ske (Randhawa & Pandey,

2006).

9) Förväntat resultat och faktiskt resultat kan jämföras (Illes, et al. 2005).

Testrapportering

1) Testresultat redovisas på ett sådant sätt att det är enkelt att avgöra ett testskripts status

(Randhawa & Pandey, 2006).

2) Felrapporter inkluderar felmeddelanden och snapshots (Randhawa & Pandey, 2006).

3) Logginformation för exekverade testfall kan sammanställas (Illes et al. 2005).

4) Testresultat kan sparas till en testrapport (Illes et al. 2005).

5) Statisk information om testkörningar finns tillgängligt (Illes et al. 2005.

Stöd för buggar samt underhåll

1) Upptäckta fel kan prioriteras (Illes et al. 2005).

2) Användaren blir notifierad om ett fel uppstår (Illes et al. 2005).

3) Fel som upptäckts kan spåras (Illes et al. 2005).

3 Metod

Detta kapitel behandlar hur arbetet växte fram och genomfördes, samt vilken metod som används

och hur insamlat data bearbetats.

3.1 Arbetets framväxt

Tester är en viktig del under utvecklingsprocessen för att kunna säkerställa en produkts kvalité.

Regressionstester är ett aktuellt ämne i dagsläget och det finns många verksamheter som strävar

efter att förbättra och utveckla sin testprocess. Detta är även ett område författaren av arbetet

finner väldigt intressant och anser vara nödvändigt att granska ytterligare.

21

När författaren bestämde sig för att inrikta arbetet mot testning så kontaktades en lokal verksamhet

inom IT-branschen för att höra om de var intresserade av att vara delaktiga. Verksamheten erbjöd

författaren ett uppdrag rörande automatiserade regressionstester med hjälp av testverktyg som

författaren tackade ja till. Detta la grunden till vad syftet med arbetet är:

” Arbetets syfte är att ta fram utvärderingskriterier för att välja ett testverktyg och undersöka hur väl

verktygets egenskaper går att tillämpa vid regressionstester av webbaserade systems GUI. Dessa

utvärderingskriterier ska sedan utvärderas genom att jämföra testverktyg mot dem och sedan

valideras användbarheten av det lämpligaste verktyget i praktiken.”

Från syftet skapades sedan frågeställningarna:





Som förberedelse inför arbetet analyserades relevant litteratur inom området som hittades bland

annat via internet med hjälp av sökord som: regressionstest, automatiska tester, testverktyg,

testautomatisering och deras motsvarigheter på engelska.

3.2 Fallstudie

Fallstudien utfördes på en verksamhet och utifrån analysen och kartläggningen valdes det testverktyg

som uppfyllde störst antal utvärderingskriterier ut. Detta verktyg användes till att implementera ett

antal testfall mot ett av de system som verksamheten utvecklar.

3.2.1 Datainsamling

Då detta arbete är ute efter att skapa en tydlig helhetsbild kring ämnet användes ett kvalitativt

arbetssätt. Kvalitativa metoder går mer på djupet för att skapa förståelse och intresserar sig av

sammanhang och strukturer. Detta metodval innebär att arbetet är flexibelt och det finns utrymme

för förändringar under tidens gång. Det intresserar sig även för de sammanhang och strukturer som

finns närvarande under arbetet (Holme & Krohn Solvang, 1997). En kvalitativ metod gör det möjligt

att fånga de väsentliga egenskaperna hos en verksamhet och analysera testverktyg utifrån dem för

att kunna välja ut det verktyg som bäst uppfyller de kriterierna. För att samla in data till arbetet

användes både intervjuer och en litteraturstudie.

22

3.2.2 Val av litteratur

Litteraturen som användes som teoretiskt stöd i detta arbete har hittats genom sökningar i olika

databaser så som IEEE Xplore, ACM Digital Library och Google Scholar. Sökord som användes var

bland annat regressionstest, automatiska tester, testverktyg, testautomatisering, GUI-testning, deras

motsvarigheter på engelska samt olika kombinationer av dem.

Denna granskning utfördes i fyra olika faser; observation, ursprung, tolkning och användbarhet

(Holme & Krohn Solvang, 1997).

Under observationen var fokuset att hitta källor som kan vara lämpliga och som kan tillföra något till

arbetet. När litteratur som verkade intressant hittades lästes först abstrakten för att kunna välja bort

de som inte innehåller någon information som är relevant för detta arbete. De som tog sig förbi den

första utsållningen granskades sedan noggrannare för att kunna avgöra om litteraturen var pålitlig

eller inte.

I nästa fas, ursprunget, granskades källans upphov – det vill säga varifrån källan kommer. Här

kontrollerades det om källan är pålitlig eller inte. En metod som användes här var att kontrollera om

det fanns källor som är oberoende av varandra men ändå säger samma saker inom det berörda

området. Det kontrollerades även varifrån källorna kommer, om utgivaren kan anses vara pålitlig

eller inte och om källan är en förstahandskälla eller en andrahandskälla.

Sedan tolkades källan och dess användbarhet för detta arbete granskades. Innehållet i källan

kontrollerades noggrant för att avgöra om den innehåller någon information som kan användas i det

aktuella arbetet. Att en källa är helt skräddarsydd för den frågeställning arbetet har lär inte hända

(Holme & Krohn Solvang, 1997), därför granskades flera källor samtidigt för att kunna hitta

information från flera av dem för att kunna skapa en grund för det område detta arbete bygger på.

Litteraturen användes för att skapa en grund för de utvärderingskriterier som ska användas. De togs

fram utan förutsättningar för vilka funktioner och egenskaper som önskas av testverktygen, utan

fokuseras istället på sådant som ansågs vara relevant för ett testverktyg som ska kunna utföra

regressionstester i ett webbaserat system.

3.2.3 Intervju

Intervjuerna användes som underlag för de kriterier som definierades och för att avgöra vad som

förväntades av testverktyget. Anledningen till att det var just intervjuer som genomfördes var för att

få en djupare förståelse för vad verktyget ska användas till och även få en djupare insikt i

23

problemområdet. Visserligen är intervjuer mer tidskrävande men de tillåter att eventuella följdfrågor

som tillkommer kan ställas direkt.

Inför intervjuerna förbereddes ett antal frågeställningar som användes som stöd, det vill säga en

slags manual för att se till att de viktigaste delarna kommer med (Holme & Krohn Solvang, 1997).

Respondenterna har möjligheten att svara fritt på frågorna och det finns utrymme för följdfrågor

som kan vara relevanta i sammanhanget. Intervjuerna utfördes ansikte mot ansikte och för att

dokumentera svaren fördes anteckningar. Respondenterna var anställda på verksamheten som

kommer att påverkas av automatiserade tester.

3.2.4 Analys av data

Insamlat data analyserades för att kunna användas i arbetet och för att de skulle hjälpa till med att

besvara de formulerade forskningsfrågorna. All information som blivit insamlad användes till att få

förståelse för arbetet och hur det bör utföras för att få ut det maximala av det.

Data insamlat via intervjuer analyserades för att kunna användas som grund för kriterierna som ska

uppfyllas och vad testverktyget förväntas bidra med för funktioner. Från intervjuerna analyserades

behovet av testverktyg och det gav även insikt i de miljöer där verktyget skulle användas.

Litteraturen analyserades genom att de intressanta delarna plockades ut och sammanställdes

tillsammans med övriga källor för att skapa en helhetsbild kring de berörda områdena. Den användes

även som grund för några av de relevanta kriterierna som är möjliga att reflektera över vid val av

verktyg. Litteraturen användes även som grund för att framställa vilka för- och nackdelar som finns

med testautomatisering. Information om hur testverktyg bör väljas och vad som är viktig att tänka på

analyserades för att skapa ytterligare mer förståelse kring området och för att det slutgiltiga valet

skulle bli så bra som möjligt.

Det insamlade data hjälpte till med att besvara forskningsfrågorna genom att det bidrog med

kunskap och förståelse kring ämnet. Intervjuerna hjälpte till med att skapa förståelse kring vilka

behov som fanns och vilka förväntningar som fanns på testverktyget för att kunna besvara den första

forskningsfrågan. Den andra forskningsfrågan kunde besvaras med hjälp av den litteratur som

använts för att dels beskriva hur ett val bör gå till och de tidigare definierade kriterierna, men även

den implementation av ett antal testfall som genomfördes.

24

3.2.5 Val av testverktyg

För att välja ut testverktyg att använda under valideringen så valdes några av de selektionskriterierna

ut i samtycke med verksamheten. Testverktygen jämfördes sedan mot dessa kriterier för att de minst

lämpliga skulle kunna sållas bort direkt, sedan bedömdes de kvarstående verktygen mot de mer

specifika kriterierna för att det mest lämpade verktyget skulle kunna plockas ut. Kriterierna

plockades ut genom en litteraturstudie och från den information som uppgavs under intervjuerna för

att de skulle kunna anpassas till de kännetecken och egenskaper som finns.

Testverktygen undersöktes mot kriterierna och en sammanställning på vilka områden de uppfyllde

gjordes för att de skulle kunna jämföras med varandra. Undersökningen av verktygen genomfördes

genom att dels använda dem och testa de funktioner de tillhandahåller och genom att söka

information om dem på internet. Båda testverktygen analyserades och både deras starka sidor och

deras svagare sidor lades fram för att en rättvis jämförelse kunde genomföras. Det testverktyg som

uppfyllde flest antal kriterier testas sedan i praktiken genom att implementera ett antal testfall mot

ett webbaserat system.

Testfallen skapades mot en del av systemet som hanterar artiklar i en databas. Fyra stycken

funktioner som ansågs vara grundläggande och bör prioriteras valdes ut och varsitt testfall som

beskriver deras respektive testprocess skapades. Slutligen användes det valda testverktyget för att

kunna återskapa en test som går att exekvera automatiskt inom testverktyget. Testen skapades

genom användning av testverktygets inspelningsfunktion och sedan manuell redigering. Detta

genomfördes för att se om testverktyget fungerar att använda inom detta område för att kunna

avgöra om kriterierna bidragit till att utföra ett passande val av verktyg eller inte.

3.2.6 Etik

När ett arbete utförs är det viktigt att ta hänsyn till eventuella etiska aspekter. Enligt Holme och

Krohn Solvang (1997) finns det olika krav som måste tas i beaktning. Det första kravet är att personer

som ingår i en undersökning måste vara medvetna om det. Personen måste ha frivilligt ha givit till

samtycke till att delta i undersökningen och den har även rätt till att själva avgöra vilken information

de vill dela med sig av.

Ett annat krav berör diskretion. Sådan information som deltagande respondenter inte vill att

utomstående ska få åtkomst till måste behandlas på lämpligt sätt. Inom detta krav ingår anonymitet,

konfidentialitet och tystnadsplikt.

25

Detta arbete kommer inte att innehålla känsliga uppgifter från intervjuer och övriga

informationskällor. Data som används vid implementation och exekvering av testfall kommer att

krypteras för att inte känsliga uppgifter ska läcka ut och eventuella skärmdumpar kommer att

censureras vid behov.

4 Resultat

Detta avsnitt ges en kort beskrivning av verksamheten samt en sammanställning av arbetets resultat

och vilket verktyg som valdes ut.

4.1 Verksamhetsbeskrivning

I detta arbete ingick en verksamhet som är intresserade av att automatisera sina regressionstester till

ett av de webbaserade system som de utvecklar. Verksamhetens egenskaper och kännetecken

generaliserades och låg som grund för de definierade kriterierna som testverktygen skulle uppfylla i

detta arbete.

De är intresserade av att kunna utföra fler tester under kortare tid och på så sätt kunna få mer tid

över till övriga aktiviteter. Samtidigt hoppas de på att det ska kunna öka kvalitén på deras produkter

och att det ska bli enklare att upptäcka eventuella fel som uppstått under utvecklingsprocessen.

Verksamheten består av ca 25 anställda och de använder sig av svenska i både skrift och tal. Deras

testprocess är från början helt manuell men deras önskan är att ta ett steg närmare helt

automatiserade processer. De försöker att arbeta agilt och använda sig av iterationer men de följer

ingen agil metod fullt ut. Längden på de projekt de har är väldigt variabla – några projekt pågår under

en månad medan andra projekt kan pågå under flera år. I dagsläget går ungefär 10% av tiden åt till

den manuella testningen de utför och att det är främst nya funktioner som testas i dagsläget.

Under planeringen inför sina projekt skapar de user stories och de utvecklingsmiljöer de använder

under utvecklingen är bland annat Visual Studio, GIT, Microsoft SQL och Sencha Ext JS. Genomförda

tester dokumenteras främst genom att det noteras om de blivit godkända vid utförandet.

4.2 Utvärderingskriterier

Från intervjuer utformades ytterligare kriterier som kan vara relevanta att undersöka förutom de

kriterier som definierats inom teorin. Utvärderingskriterierna ser ut som följande:

26


1) Testverktyget stödjer miljöerna

a. Visual Studio

b. Ext JS

c. SQL

d. GIT

e. Webbläsare

i. Chrome

ii. Firefox

iii. Edge

iv. Opera

v. Internet Explorer

vi. Safari

2) Testverktyget stödjer agila utvecklingsmetoder.

3) Testverktyget kan avgöra hur stor del av applikationens kod som testerna täcker.

Analys och design

1) Inspelningar av tidigare testfall kan återupptas vid senare skede och utökas.

Implementation

1) Tester kan köras mot testdata.

2) Starttid för utvalda testexekveringar kan anges.

3) Testfall kan skapas manuellt.

4) Inspelning av tester kan pausas och sedan återupptas inom samma session.


1) Testverktyget kan hantera tester som berör hela eller delar av ett system.

2) Prestandatest kan utföras.

3) Inmatningstester kan utföras.

4) Dumb monkey-tester kan utföras.

5) Säkerhetstester kan utföras.

6) Tester för att upptäcka memory leak kan utföras.

7) Antalet iterationer för ett testfall kan anges.

8) Testfallens uppspelningshastighet kan anges.

9) Testverktyget har en bildigenkännings-funktion.

27

10) Testverktyget kan spela upp tester på flera olika webbläsare samtidigt.

Testrapportering

1) Statistik för hur stor del av testningen som utförts finns tillgängligt.


1) Funktion för att enkelt kunna manövrera mellan skapade testfall finns.

4.3 Testverktyg att undersöka

I detta arbete kommer två testverktyg att analyseras och undersökas utifrån de definierade

selektions- och utvärderingskriterierna. Med information från både litteraturstudien och genomförda

intervjuer som underlag valdes följande selektionskriterier ut:

• Typ av GUI: Testverktyget ska ha möjligheten att testa webbapplikationer.

• Utformning av testskript: Testskript ska gå att spela in med hjälp av en inspelningsfunktion

och de ska även kunna redigeras i efterhand.

• Integration med andra verktyg: Det är bra om testverktyget kan samarbeta med Visual

Studio, SQL och GIT.

• Testaktiviteter: Det ska finnas stöd för regressionstest och GUI-test.

De testverktyg som undersöktes utifrån dessa selektionskriterier var:

• BrowserStack

• Katalon Studio

• Ranorex

• Screenster

• Selenium

• Sencha Test

28

Katalon Studio Ranorex Screenster Selenium Sencha Test

Typ av GUI X X X X X

Utformning av

testskript

X X X X X

Integration med andra

verktyg

/* X /** /***

Testaktiviteter X X X X X

Tabell 5 Jämförelse mot selektionskriterier

* Stödjer SQL och GIT.

** Stödjer Visual Studio.

*** Stödjer Visual Studio och GIT.

Av de verktyg som jämfördes mot selektionskriterierna så valdes Ranorex och Sencha Test ut.

Anledningen till detta var att Ranorex uppfyllde alla kriterier och Sencha Test uppfyllde de som

ansågs vara mest relevanta. I detta fall valdes Sencha Test framför Katalon Studio då det stödjer

integration med SQL och GIT som ansågs vara viktigare än stödet för integration med Visual Studio

och GIT.

4.3.1 Ranorex 7.0

Ranorex är ett ramverk med inriktning på testautomatisering av GUI tillhörande webbaserade och

mobilapplikationer. Verktyget använder sig av C# och Visual Basic .NET som skriptspråk och även

möjligheten för att spela in testskript finns.

För mer information, se: http://www.ranorex.com/

4.3.2 Sencha Test 2.0

Sencha Test är ett testverktyg som bidrar med omfattande enhets- och ”end-to-end”-tester speciellt

anpassade för applikationer skapade med Ext JS. Det är går att utföra tester som skapas på flera olika

webbläsare samtidigt. De inkluderar ett Jasmine-ramverk som gör det möjligt att skapa egna tester i

skriptspråk JavaScript och integration med WebDriver tillåter att ”end-to-end”-tester som härmar

verkligt användarbeteende utförs.

För mer information, se: https://www.sencha.com/products/test/

http://www.ranorex.com/

https://www.sencha.com/products/test/

29

4.4 Val av verktyg

Under följande avsnitt presenteras analysen av de två testverktygen mot de utvärderingskriterier

som blivit sammanställda. Resultatet presenteras genom att antingen uppfyller verktyget kriteriet,

uppfyller inte kriterier eller så uppfyller det kriteriet delvis.

Definitioner:

• R: Ranorex

• ST: Sencha Test

Betygsskala:

• Verktyget uppfyller kriteriet: X

o 1 poäng

• Verktyget uppfyller delvis kriteriet: /

o 0,5 poäng

• Verktyget uppfyller inte kriteriet: tom ruta

o 0 poäng

4.4.1 Analys mot utvärderingskriterier


Kriterium R ST

1. Testverktyget kan användas till specifika applikationsdomäner,

exempelvis webbapplikationer.

X X

2. Testverktyget stödjer miljöerna

• Visual Studio

• Ext JS

• SQL

• GIT

• Webbläsare

o Chrome

o Firefox

o Edge

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

30

o Opera

o Internet Explorer

o Safari

X

X

X

X

3. Personliga inställningar för att underlätta för användarna av

testverktyget.

X X

4. Testverktyget stödjer agila utvecklingsmetoder. X X

5. Testverktyget kan avgöra hur stor del av applikationens kod som

testerna täcker.

X

Summa: 13 14

Tabell 6 Testplanering och översikt

Analys och design

Kriterium R ST

1. Testfall kan designas för önskad testnivå, exempelvis enhetstest. X X

2. Inspelningar av tidigare testfall kan återupptas vid senare skede

och utökas.

X X

3. Testfall kan designas för att kunna testa applikationens kvalité. X X

4. Oanvändbara testfall kan automatiskt repareras.

Summa: 3 3

Tabell 7 Analys och design

Implementation

Kriterium R ST

1. Testfall kan spelas in. X X

2. Skapade testskript kan redigeras. X X

3. Testfall kan skapas manuellt. X X

4. Dynamiska komponenter kan hanteras. X X

5. Tester kan köras mot testdata. X X

6. Tester kan utföras via fjärrdatorer. X X

7. Starttid för utvalda testexekveringar kan anges.

8. Inspelning av tester kan pausas och sedan återupptas inom samma

session.

X

Summa: 7 6

Tabell 8 Implementation

31


Kriterium R ST

1. Testverktyget stödjer regressionstester. X X

2. Testexekveringar kan pausas och sedan återupptas igen. X

3. Testfall kan prioriteras. /* /****

4. Testscenarion kan väljas ut för att skapa mer målinriktade

testexekveringar.

X X

5. Prestandatester kan utföras. **

6. Misslyckad exekvering av testfall finns det möjlighet för rollback. X

7. Testfall som spelas in eller redigerats kan exekveras. X X

8. Testskript kan utföras i olika miljöer utan att förändringar måste

ske i deras kod.

X X

9. Testskripten kan köras utan att manuella ingripanden behöver ske. X X

10. Testverktyget kan hantera tester som berör hela eller delar av ett

system.

X X

11. Inmatningstester kan utföras.

12. Dumb monkey-tester kan utföras.

13. Säkerhetstester kan utföras.

14. Tester för att upptäcka memory leak kan utföras. /***

15. Antalet iterationer för ett testfall kan anges. X

16. Testfallens uppspelningshastighet kan anges. X

17. Förväntat resultat och faktiskt resultat kan jämföras. X X

18. Testverktyget har en bildigenkännings-funktion. X X

19. Testverktyget kan spela upp tester på flera olika webbläsare

samtidigt.

X

Summa: 13 9,5

Tabell 9 Textexekvering, samt fånga och jämföra resultat

* Ranorex har ingen funktion som tillåter att användaren prioriterar sina testfall. Däremot kan testfall

sättas in i olika test suits och från dem kan användaren sedan avgöra vad som ska ingå i den aktuella

testkörningen.

** Ranorex har ingen implementerad metod för att utföra prestandatester. Däremot är det möjligt

att kombinera Ranorex med ett annat testverktyg, exempelvis NeoLoad, för att göra det möjligt att

utföra dessa tester.

32

*** Ranorex har ingen implementerad metod för att genomföra tester som kontrollerar om memory

leak sker. Däremot går det att producera en sträng av handlingar som återupprepas och sedan

kontrollera ur systemet påverkats.

**** Sencha Test har ingen funktion som tillåter att användaren prioriterar sina testfall. Däremot kan

testfall sättas in i olika testscenarion där de tester som är intressanta att använda i den aktuella

testkörningen kan markeras.

Testrapportering

Kriterium R ST

1. Testresultat redovisas på ett sådant sätt att det är enkelt att avgöra

ett testskripts status.

X X

2. Felrapporter inkluderar felmeddelanden och snapshots. X /*

3. Logginformation för exekverade testfall kan sammanställas. X

4. Testresultat kan skapas till en testrapport. X X

5. Statisk information om testkörningar finns tillgängligt. X

6. Statistik för hur stor del av testningen som utförts finns tillgängligt. X X

Summa: 5 4,5

Tabell 10 Testrapportering

* Sencha Tests felrapport inkluderar felmeddelande men inte snapshot.


Kriterium R ST

1. Upptäckta fel kan prioriteras.

2. Användaren blir notifierad om ett fel uppstår. X X

3. Fel som upptäckts kan spåras.

4. Funktion för att enkelt kunna manövrera mellan skapade testfall

finns.

/*

Summa: 1,5 1

Tabell 11 Stöd för buggar samt underhåll

* Det är möjligt att söka efter sökord i skapade test suits vilket kommer visa alla beståndsdelar som

innehåller det valda sökordet.

33

Totalt resultat

Avsnitt R ST

Testplanering och översikt 13 14

Analys och design 3 3

Implementation 7 6

Testexekvering, samt fånga och jämföra resultat 13 9,5

Testrapportering 5 4,5

Stöd för buggar samt underhåll 1,5 1

Summa: 42,5 38

Tabell 12 Totalt resultat

Ranorex är det testverktyg som uppfyller störst antal av de uppsatta kriterierna med 42,5 poäng och

Sencha Test uppfyller 38 poäng av totalt 56 möjliga poäng. Då Ranorex är det verktyg som uppfyller

flest kriterier kommer det användas för att implementera ett antal testfall.

4.5 Implementation av testfall

Testverktyget Ranorex användes för att implementera ett antal testfall mot ett av verksamhetens

webbaserade system. Den del av systemet som användes som utgångsläge behandlar hanteringen av

artiklar som sparats i en databas.

Totalt så skapades fyra stycken tester genom att använda testverktygets inbyggda

inspelningsfunktion och sedan redigera den skapade testen.

4.5.1 Testfall

Alla testfall innehåller en beskrivning om vilka förberedelser som krävs och sedan hur testen bör gå

till för att det förväntade resultatet ska uppnås. De tester som sedan skapades utifrån testfallen

påbörjas från första teststeget och tar för givet att förberedelserna redan blivit utförda.

34

Det första testfallet beskriver hur en användare lägger till en ny artikel i databasen.

ID 1

Rubrik Ny artikel

Förberedelser Logga in med administratorbehörighet.

Välj ”Administration”.

Välj ”Artikel”.

Teststeg 1. Välj ”Ny artikel”.

2. Ange nummer.

3. Ange benämning.

4. Välj artikelgrupp.

5. Välj artikeltyp.

6. Klicka på ”Spara”.

Förväntat resultat En ny artikel läggs till i listan.

Tabell 13 Testfall – Ny artikel

Testfallet som beskriver hur en ny artikel läggs till användes sedan som grund för att spela in en test

som sedan kan utföra detta test automatiskt. Inspelningen som utfördes med testverktyget Ranorex

skapar sedan en sekvens av de händelser som utförts. Bild 2 visar hur inspelningen av det skapade

testet ser ut efter finjustering och redigering.

Bild 2 Ny artikel

35

Följande testfall beskriver hur en befintlig artikel kan redigeras.

ID 2

Rubrik Redigera artikel




Teststeg 1. Dubbelklicka på befintlig artikel.

2. Ändra ”Artikelgrupp”.

3. Ändra ”Artikeltyp”.


Förväntat resultat Befintlig artikel får uppdaterad information.

Tabell 14 Testfall – Redigera artikel

Bild 3 visar hur testet ser ut efter inspelning samt finjustering och redigering.

Bild 3 Redigera artikel

Det tredje testfallet beskriver hur värden på dimensioner kan läggas till på en befintlig artikel.

ID 3

Rubrik Lägg till dimensioner





2. Utöka menyn för ”Dimensioner”.

3. Lägg till längd, bredd, höjd, vikt och volym.


Förväntat resultat Artikeln får tillagda dimensioner.

Tabell 15 Testfall – Lägg till dimensioner

36

Bild 4 beskriver hur testet ser ut efter inspelning samt redigering och finjustering.

Bild 4 Lägg till dimensioner

Det fjärde testfallet som skapades beskriver hur en befintlig artikel kan tas bort ur databasen.

ID 4

Rubrik Ta bort artikel





2. Klicka på ”Ta bort”.

Förväntat resultat Artikeln försvinner från databasen.

Tabell 16 Testfall – Ta bort artikel

Bild 5 beskriver hur testet ser ut efter inspelning samt redigering och finjustering.

Bild 5 Ta bort artikel

37

De skapade testerna lades sedan in i en test suite som är indelad i olika undernivåer. Varje nivå

innehåller inspelade tester som berör just det området för att kunna skapa en tydlig överblick över

de tester som finns tillgängliga. Bild 6 visar hur denna test suite ser ut.

Bild 6 Test suite

5 Analys

Under detta avsnitt kommer en analys av arbetets slutgiltiga resultat att presenteras. Resultatet

kommer att analyseras utifrån de forskningsfrågor som ställts och även sambandet mellan teori och

resultat kommer att analyseras.

5.1 Testautomatisering

Då ungefär var tredje förändring i koden under utvecklingsprocessen leder till att ett följdfel uppstår

(Eriksson, 2008) så är det viktigt att regressionstester genomförs inför varje ny version av ett

program. Tidigare studier har visat att ungefär 35% av tiden går åt till att utföra tester (Grindal, Offutt

& Mellin, 2006) och i detta arbete framkom det att ungefär 10% av tiden används till att utföra

manuella tester i den verksamhet som användes som grund. Detta ligger under det beräknade

medelvärdet, men med tanke på att inga verksamheter ser exakt likadana ut är det möjligt att

avvikelser förekommer.

Automatiserad testning för med sig en mängd fördelar men även nackdelar som är viktiga att

överväga vid införskaffning av testverktyg. Från de intervjuer som genomfördes hos en verksamhet

38

som är intresserade av att automatisera sina regressionstester framkom det att de tyngsta faktorerna

som gör att de vill införskaffa testverktyg för att kunna uppnå detta är:

• Möjligheten att spara tid men ändå kunna utföra ordentliga regressionstester.

• Ökad kvalité på de produkter de utvecklar.

• Göra det enklare att upptäcka eventuella fel.

• Göra testprocessen effektivare än vad den är i dagsläget.

Dessa faktorer stämmer överens med några av de fördelar som testautomatisering för med sig. Bland

annat så kan automatiska tester spara tid och de tillåter även att testskript återanvänds (Randhawa &

Pandey, 2006) vilket bidrar till att testprocessen blir effektivare och även tidssparande då testerna

inte behöver utföras manuellt eller skapas igen för varje testomgång. Automatiserade

regressionstester kan även hjälpa till med att kontrollera att både nya och gamla delar i ett program

fungerar som väntat (Amannejad et al. 2014) vilket bidrar med att säkerställa och öka kvalitén på den

utvecklade produkten.


Ett testverktyg är som nämnt ett hjälpmedel när automatiserade tester ska implementeras i en

verksamhets testprocess. Enligt Eriksson (2008) är det första steget mot att införskaffa ett

testverktyg att analysera vilka behov som finns och vad som förväntas av verktyget. De förväntningar

på testverktyget och dess funktioner som fanns framkom under de genomförda intervjuerna – de

flesta av dessa var generella funktioner som var definierade i den teoretiska så som att det finns

möjlighet att spela in testfall (Illes et al. 2005) och att felmeddelanden inkluderar snapshots

(Randhawa & Pandey, 2006).

Utvärderingskriterierna som kunde utvinnas under arbetets gång överensstämde till viss del med de

utvärderingskriterier som togs fram under teorin. Främst var dessa kriterier de som är generella för

utvärdering av testverktyg för alla olika sorters miljöer och tester, så som att testresultat kan sparas

till en testrapport (Illes et al. 2005). Sådana kriterier går att tillämpa oavsett vilka typer av tester som

ska utföras och är inte specifika för just automatiserade regressionstester av webbaserade systems

GUI.

De intervjuer som utfördes inom verksamheten som arbetar inom detta område användes som

grund för att kunna ta fram mer specialiserade kriterier. Dessa kriterier som tagits fram går både att

tillämpa vid övriga utvärderingar, men några av dem är specifika för just detta område – exempelvis

kriteriet som beskriver vilka webbläsare som bör kunna testas, detta kriterium är inte relevant för en

39

verksamhet som inte utvecklar webbaserade system. Då de framtagna kriterierna inte är specifika för

just en enda verksamhet inom branschen går de att använda av alla verksamheter som utvecklar

webbaserade system. Mindre förändringar kan behöva göras då bland annat då utvecklingsmiljöerna

kan variera.

5.3 Val av verktyg

När ett testverktyg ska väljas ut finns det en mängd olika metoder som beskriver hur man kan gå

tillväga för att välja ett verktyg som uppfyller de behov och krav som finns. Eriksson (2008) beskriver

en process som innehåller flera steg som kan fungera som stöd under valet av testverktyg och

frågeställningar som kan användas under processens gång har blivit sammanställda av Software

Testing Help (2016).

Under arbetets gång har några aspekter blivit framhävda som kan vara relevanta att ha i åtanke när

automatiserad testning ska införas och det är läge att välja ut det verktyg som ska användas. Det har

framkommit att enbart ett testverktyg kan inte uppfylla alla de kriterier och önskemål som finns –

utan för att kunna få ut det mesta av testverktyget kan det vara relevant att kombinera det

tillsammans med ett annat verktyg som uppfyller andra funktioner. Att hitta ett enda verktyg som

uppfyller allt som önskas är nästintill omöjligt, inga testverktyg är skapta för precis just de behov en

verksamhet har. Som förslag som ett ytterligare tillägg till de metoder som finns är att inte kolla på

enbart det verktyg som ensamstående uppfyller flest krav och önskemål, utan istället kolla på

helheten och undersöka hur stor del av kraven som uppfylls av flera integrerade testverktyg. Att

använda flera verktyg kan vara relevant för att kunna få ut så mycket som möjligt av dem, med andra

ord för att kunna få ut det maximala av de tester som ska automatiseras.

5.3.1 Jämförelse av testverktygen

Under följande del jämförs Ranorex och Sencha Test mer utförligt kring de olika kategorierna som

utvärderingskriterierna varit indelade i.

Båda de utvalda testverktygen Ranorex och Sencha Test jämfördes mot de utvärderingskriterier som

blivit sammanställda. Utvärderingskriterierna i detta arbete har varit indelade i fem kategorier:

testplanering och översikt, analys och design, implementation, textexekvering samt fånga och

jämföra resultat, testrapportering och stöd för buggar samt underhåll. Dessa utvärderingskriterier

har antingen varit uppfyllda eller så har de inte varit det – med undantag för de punkter där

alternativa vägar kan uppfylla kriteriet. Ett poängsystem användes för att kunna skapa en enklare

40

överblick över testverktygens antal uppfyllda kriterier. Ett kriterium som var helt uppfyllt gav ett

poäng, ett delvis uppfyllt kriterium gav ett halvt poäng och ett kriterium som inte uppfylldes gav noll

poäng. Under detta arbete framkom det att Ranorex var det testverktyg som uppfyllde flest antal

kriterier.


Under avsnittet för testplanering och översikt presterade båda testverktygen nästintill likvärdigt.

Båda testverktygen går att använda vid test av webbapplikationer, vilket är ett grundläggande

kriterium för detta arbete. Ranorex uppfyllde alla kriterier för de utvecklingsmiljöer som används och

nästintill alla webbläsare förutom Opera. Sencha Test kan i sin tur använda alla olika webbläsare,

men har istället inget implementerat stöd för att arbeta tillsammans med SQL. Båda testverktygen

stödjer personliga inställningar för underlättande av användandet och de går att bruka vid agila

arbetsmetoder. Då Sencha Test stödjer Ext JS då det har samma utgivare som Sencha, vilket

använder sig av denna utvecklingsmiljö, har dessa två program möjlighet att integreras. Detta tillåter

att användaren ser hur stor del av koden som faktiskt ingår i de skapade testerna och vilka delar av

koden som inte är täckta. Detta är en funktion som inte finns implementerad i Ranorex.

Analys och design

Avsnittet för analys och design visade att båda testverktygen är likvärdiga. Båda testverktygen

erbjuder funktioner för att designa testfall för önskad testnivå, utökning av tidigare inspelade testfall

och kontroll av applikationens kvalité. Däremot kan testverktygen inte reparera oanvändbara testfall

automatiskt utan detta måste göras manuellt.

Implementation

Inom avsnittet för implementation finns det en skillnad, med Ranorex kan inspelning av tester pausas

och sedan återupptas utan att hela inspelningen behöver stoppas – denna funktion finns inte hos

Sencha Test. Förutom den skillnaden är båda testverktygen likvärdiga under denna kategori. Båda

verktygen tillåter inspelning av tester och att tester skapas manuellt, de skapade testerna kan sedan

redigeras vid ett senare skede. De kan hantera dynamiska komponenter, köra tester mot testdata

och utföra tester via en fjärrdator. Däremot kan inget av testverktygen starta testexekveringar på en

bestämd tidpunkt automatiskt, utan testerna måste startas manuellt.


Gällande testexekvering samt fånga och jämföra resultat så finns det betydligt fler skillnader mellan

de båda testverktygen. De områden där verktygen var likvärdiga inom uppfyllda kriterier är att bägge

41

stödjer regressionstester. Det är möjligt att välja ut testscenarion för att på så vis kunna skapa mer

målinriktade testexekveringar och det förväntade och det faktiska resultatet kan jämföras. Båda

tillåter att skapade testfall kan exekveras och de kan köras utan att manuella ingripanden behöver

ske. De går att utföra i olika miljöer utan att de behöver förändras och de kan hela eller delar av ett

system. Det finns även en bildigenkännings-funktion hos båda verktygen.

Enbart Ranorex stödjer att testexekveringar pausas och sedan återupptas igen, denna funktion finns

inte i Sencha Test. Om fel vid testexekvering uppstår kan en rollback utföras inom Ranorex, denna

funktion finns inte tillgänglig i Sencha Test. Ranorex tillåter att användaren anger antalet iterationer

för ett testfall samt vilken uppspelningshastighet de ska ha, detta har Sencha Test inga

implementerade funktioner för. Sencha Test tillåter att tester utförs på flera olika webbläsare

samtidigt, vilket Ranorex inte har möjlighet att utföra.

Av de krav som delvis är uppfyllda kan både Ranorex och Sencha Test prioritera testfall genom att

placera dem i olika test suits eller testscenarion. De har ingen implementerad funktion för att enkelt

kunna prioritera testfallen, men däremot går det att välja vilka som ska köras under testomgången

och på så sätt exekvera de som är relevanta för tillfället. Ranorex kan delvis testa om memory leak

sker genom att en sträng av handlingar som upprepas skapas, dock finns det ingen enkel metod

implementerad för att utföra detta. Sencha Test innehåller inte heller en funktion som stödjer dessa

tester.

Varken Ranorex eller Sencha Test kan utföra prestandatester. Dock är det möjligt att kombinera

Ranorex med ett utomstående testverktyg som hanterar den sortens tester och på så vis göra det

möjligt att utföra dem via Ranorex. Sencha Test stödjer ingen sådan funktion. Varken Ranorex eller

Sencha Test kan utföra inmatningstester, dumb monkey-tester eller säkerhetstester.

Testrapportering

Under kategorin för testrapportering är testverktygen nästintill likvärdiga. Båda verktygen kan skapa

en testrapport från testresultaten, de redovisar testresultaten på så sätt att det är enkelt att avgöra

ett testfalls status och det finns tillgång till statistik för hur stor del av testerna som blivit utförda

under testexekveringen. Ranorex tillhandahåller både felmeddelande och snapshot i de felrapporter

som skapas medan Sencha Test enbart tillhandahåller felmeddelanden men inga snapshots. Med

Ranorex går det att sammanställa logginformation om de exekverade testfallen, vilket Sencha Test

inte har någon implementerad funktion för. Sencha Test kan visa statisk information om de

testkörningar som är pågående medan Ranorex inte tillhandahåller en sådan funktion.

42

Gällande stödet för buggar samt underhåll så skiljer det inte mycket mellan de två testverktygen.

Både Ranorex och Sencha Test kan notifiera användaren när ett fel uppstår. Ranorex tillhandahåller

en sökfunktion som delvis gör det enklare att manövrera mellan skapade testfall varav gör att det

delvis uppfyller kriteriet, Sencha Test har ingen sådan implementerad funktion. Inget av verktygen

tillåter att upptäckta fel prioriteras eller att de fel som upptäcks kan spåras till deras uppkomst

kodmässigt.

5.3.2 Testverktygens styrkor och svagheter

Både Ranorex och Sencha Test har områden som är deras starka sida och de har områden som är

svagare. Ranorex uppfyller betydligt fler kriterier under kategorin för testexekvering samt fånga och

jämföra resultat. Verktyget har många funktioner som gör det enkelt att anpassa de skapade

testerna efter eget behov och tycke. Ytterligare en stark sida är att det går att pausa en pågående

inspelning för att göra förändringar i webbläsaren och sedan återuppta inspelningen igen, detta

innebär att inspelningen inte behöver stoppas helt och sedan behöver påbörjas på nytt. De

inspelningar som skapats presenteras i en tabell där det går att dra och släppa de olika händelserna

på valfri plats. Detta gör att skapade tester kan redigeras även om användaren inte besitter några

programmeringskunskaper. De olika händelserna innehåller även ett snapshot som visar exakt var

något utförs i webbläsare, exempelvis vilken knapp som trycks på under just det ögonblicket.

De svagheter som Ranorex har är att det inte finns stöd för att utföra tester på alla webbläsare, den

webbläsare som inte stödjs är Opera. När testexekveringar utförs är det inte möjligt att minimera

webbläsaren på den dator där testerna blir utförda. Detta gör att en dator kommer att vara obrukbar

till något annat så länge som testerna är pågående. Koden som skapas till de inspelade testerna kan

anses vara komplicerad för de användare med minde kunskap inom programmering vilket gör att

testfallen kan bli svårare att redigera manuellt.

De starka sidor som Sencha Test har är bland annat att de tillåter att tester utförs på flera webbläsare

samtidigt och det är även möjligt att ha webbläsaren i bakgrunden utan att testerna avbryts vilket

inte låser datorn till att enbart utföra tester. Detta tillåter att testexekveringarna blir så effektiva som

möjligt. Den kod som skapas från inspelade tester är enkelt uppbyggd och dess enkla utformning

underlättar manuell redigering för användare med bristande programmeringskunskaper.

Däremot så finns det brister inom kategorin för testexekveringar samt fånga och jämföra resultat.

Sencha Test har färre implementerade funktioner för anpassandet och skapandet av tester på ett

enkelt sätt med stöd från verktyget. De inspelningar som skapas presenteras enbart i kodformat

43

vilket kan bli mer tidskrävande då de ska redigeras manuellt. Sencha Test tillhandahåller inte heller

några snapshots som visar var ett fel skedde under testexekveringarna.

5.4 Implementationen av testfall

Vilket av de undersökta testverktygen uppfyller främst de uppsatta utvärderingskriterierna och hur

väl fungerar det att använda i praktiken vid utförande av regressionstester?

Som tidigare nämnt var Ranorex det testverktyg som uppfyllde störst antal av de sammanställda

kriterierna och därför användes det verktyget till att implementera fyra stycken testfall mot ett

webbaserat system. Fyra grundläggande funktioner för hantering av artiklar valdes ut för att de

ansågs vara relevanta att prioritera och bör utföras under ett tidigt skede av testprocessen (Elbaum,

Malishevsky & Rothermel, 2002).

Inspelningsfunktionen som Ranorex tillhandahåller är enkel och förståelig vid användning och att

redigera de testfall som skapats är också på relativ simpel nivå. Exekvering av skapade tester kan

utföras utan att användaren behöver ingripa manuellt men den dator som utför testerna kommer

inte att kunna brukas till annat under tiden. Testfallen som skapas kan återanvändas under

kommande tester och de behöver inte återskapas eller redigeras för varje gång – under förutsättning

att ingen layout eller uppbyggnad förändrats på webbapplikationen.

Exekveringen fortsätter kontinuerligt så länge testerna blir godkända och genomförda, däremot kan

hinder uppstå om ett testfall delvis blivit genomförd men sedan misslyckas. Testkörningen kommer

då att fortsätta från det utgångsläge där den senaste testen avbröts – vilket kanske inte alls passar i

ihop med de följande testerna som även då kommer att anses vara misslyckade då de inte hittade

rätt startläge för att kunna utföras. Denna del kräver att användarna tänker till när tester skapas och

har i åtanke vad som bör hända om testfallet misslyckas och hur testerna ska kunna gå vidare från

rätt startläge.

6 Slutsatser

Detta avsnitt berör de slutsatser som dragits rörande arbetets syfte och frågeställningar.

Arbetets syfte var att ta fram utvärderingskriterier för att välja ett testverktyg som går att tillämpa

vid genomförandet av regressionstester av webbaserade systems GUI. Dessa kriterier utvärderades

sedan genom att analysera två testverktyg mot dem och välja ut det verktyg som uppfyllde flest antal

kriterier för att sedan implementera ett antal testfall mot ett webbaserat system. Arbetet utfördes

44

för att öka kunskap inom området och för att kunna lägga fram ett förslag på ett underlag på

utvärderingskriterier som går att bruka vid val av testverktyg som fokuserar på regressionstester av

GUI.


De utvärderingskriterier som framtogs under detta arbete från de egenskaper och kännetecken

tillhörande verksamheter vars fokus är att utveckla webbapplikationer är indelade i olika kategorier

beroende på vilken funktion de uppfyller.



Inom den första kategorien, testplanering och översikt, framtogs tre kriterier:

• Testverktyget stödjer miljöerna…

• Testverktyget stödjer agila metoder.

• Testverktyget kan avgöra hur stor del av applikationens kod som testerna täcker.

Dessa utvärderingskriterier bidrar till valet av testverktyg genom att de två första kriterierna kollar

om verktyget stödjer den metod och de miljöer som verksamheten använder. Att veta om ett verktyg

har möjligheten att stödja sådant som redan är aktivt och används inom verksamheten kan vara en

viktig del under beslutet. Stödjer inte testverktyget något av detta kommer förändringar att behöva

ske inom verksamheten och sådant bör tas i beaktande om det blir aktuellt.

Det tredje utvärderingskriteriet underlättar om verksamheten är intresserade av att täcka alla delar

ur den webbapplikation som ska testas med automatiserade tester. Kan testverktyget jämföra de

tester som skapats mot vilka delar ur koden som de täcker så blir det enklare att upptäcka sådant

som kan ha glömts bort eller missats.

Den andra kategorin, analys och design, innehåller ett kriterium:

• Inspelningar av tidigare testfall kan återupptas vid senare skede och utökas.

Detta kriterium kontrollerar om testfall som spelats in vid ett tidigare skede enkelt kan utökas genom

att återuppta inspelningen vid ett senare skede. Det kan hjälpa verksamheten att enkelt utöka och

förändra de testfall som de skapat utan att de behöver redigeras manuellt eller spelas in helt från

början igen – vilket bidrar till hur enkelt det är att underhålla skapade testfall och tester.

Tredje kategorin, implementation, innehåller fyra kriterier:

45

• Tester kan köras mot testdata.

• Starttid för utvalda testexekveringar kan anges.

• Testfall kan skapas manuellt.

• Inspelning av tester kan pausas och sedan återupptas inom samma session.

Utvärderingskriterierna inom denna kategori beskriver främst sådant som är önskvärt av ett

testverktyg och som underlättar när det ska användas. Att tester kan köras mot testdata och att

skapa testfall manuellt tillåter att mer målinriktade tester kan utformas och det ger även

verksamheten större frihet att anpassa testerna som de själva önskar. Starttid och paus av inspelning

är två funktioner som underlättar för verksamheten när de ska använda verktyget.

Fjärde kategorin, testexekvering samt fånga och jämföra resultat, innehåller tio utvärderingskriterier:

• Testverktyget kan hantera tester som berör hela eller delar av ett system.

• Prestandatest kan utföras.

• Inmatningstester kan utföras.

• Dumb monkey-tester kan utföras.

• Säkerhetstester kan utföras.

• Tester för att upptäcka memory leak kan utföras.

• Antalet iterationer för ett testfall kan anges.

• Testfallens uppspelningshastighet kan anges.

• Testverktyget har en bildigenkännings-funktion.

• Testverktyget kan spela upp tester på flera olika webbläsare samtidigt.

För att kunna utvärdera hur väl applikationen fungerar i praktiken är det även viktigt att testa andra

saker än att bara kontrollera att implementerade funktioner fungerar som förväntat. En

webbapplikation blir inte automatiskt bra för att dess funktioner fungerar som förväntat, utan det

finns andra aspekter som inverkar på hur bra kvalité en webbapplikation egentligen har. Därför kan

det vara relevant att ha möjligheten att utföra prestandatester, inmatningstester, dumb monkey-

tester, säkerhetstester och tester för att upptäcka eventuell memory leak som kan uppstå.

Genomförandet av testerna bör fungera smidigt och det är önskvärt om de är så tidseffektiva som

möjligt. Kan ett testverktyg utföra tester på flera olika webbläsare samtidigt kommer det att spara

mycket mer tid än om testerna ska utföras på en webbläsare åt gången. Testerna kan fungera felfritt

på en webbläsare – men det är samtidigt möjligt att de inte alls fungerar på en annan webbläsare

vilket gör det viktigt att tester utförs på ett stort antal webbläsare. Något som även kan vara

intressant under testningen är att kunna hantera tester som antingen berör hela eller delar av ett

46

system för att på så sätt enkelt kunna avgöra vad som är relevant att köra under den aktuella

testkörningen istället för att köra genom alla existerande tester för varje omgång.

Övriga funktioner som kan bidra till att enklare kunna skapa anpassade tester är om verktyget stödjer

inställningar för hur många gånger ett testfall ska spelas upp, vilken uppspelningshastighet det har

och om testverktyget innehåller en funktion som kan känna igen bilder.

Den femte kategorin, testrapportering, innehåller ett kriterium:

• Statistik för hur stor del av testningen som utförts finns tillgänglig.

För att enkelt kunna avgöra hur stor del av testerna som utfördes och vad som är kvar är statistik för

testerna en funktion som bidrar till enklare hantering av testkörningarna. Det är svårt att avgöra

testers faktiska status om man inte vet om de blivit utförda eller inte under testexekveringen.

Den sjätte och sista kategorin, stöd för buggar samt underhåll, innehåller ett kriterium:

• Funktion för att enkelt kunna manövrera mellan skapade testfall finns.

Stora projekt kan innebära att stora mängder av testfall skapas. För att enkelt hitta och kunna

underhålla dessa testfall kan en funktion som tillåter användaren att enkelt manövrera mellan dem

vara till stor nytta. Bland flera hundratals skapade testfall är det inte alltid det lättaste att hitta ett

specifikt testfall om man inte känner till dess placering.

Flera av de utvärderingskriterier som blivit framtagna är inte kritiska för att testverktyget ska gå att

använda, utan de är snarare sådana som kan vara bra att ha. De kan underlätta vid skapandet och

exekveringar av tester för att göra hela processen så smidig och tidseffektiv som möjligt – vilket är en

av anledningarna till att manuell testning byts ut mot automatiserad testning från första början.

Innehåller inte testverktyget sådana funktioner som bidrar till enkelt användande kan det istället

vara mer komplicerad och tidskrävande att använda verktyget än att utföra testerna manuellt. Dessa

utvärderingskriterier är nödvändiga för att kontrollera om de testverktyg som undersöks kan tillföra

något till testprocessen och om de gör det möjligt för verksamheten att utveckla sin testprocess

samtidigt som den även förenklas.

Den lösning som tagits fram i detta arbete är inte enbart begränsad till den verksamhet som

testverktygen användes hos. De kriterier som definierat och tagits ut går även att använda för andra

verksamheter och kan ses som riktlinjer och stöd då ett testverktyg ska väljas. Kriterierna har även

generaliserats och fler aspekter än de som blivit nämnda under intervjuerna har tagits fram, som

exempel vilka webbläsare testverktyget har stöd för att utföra tester i.

47

Vissa kriterier som berör exempelvis vilka miljöer som används kan behöva förändras för att bli

bättre anpassade till verksamheter som arbetar på ett annorlunda sätt. Dock går de flesta av

kriterierna att användas precis som de är just nu då de bara kan ha värdena uppfyllt och inte uppfyllt.

De delar som inte är relevanta för andra verksamheter går enkelt att bortse från, exempelvis om de

använder annorlunda miljöer under deras utvecklingsprocess går dessa enkelt att byta ut mot de

miljöer den aktuella verksamheten är intresserade av – eller om verksamheten är öppen för

förändringar och byten av verktyg.

6.2 Val av verktyg

Under arbetets gång har det framkommit att båda de undersöka testverktygen Ranorex och Sencha

Test har olika styrkor och svagheter.



Ranorex var det verktyg som uppfyllde flest antal kriterier och var därför det testverktyg som valdes

ut till att testa ytterligare i praktiken.

Slutsatserna som tagits kring detta arbete är att båda testverktygen har framhävande styrkor och

svagheter. Det testverktyg som uppfyller flest antal kriterier behöver inte vara det som är det mest

lämpliga – istället kan det vara relevant att se på vilka kriterier som är uppfyllda och vilket verktyg

som uppfyller de utvärderingskriterier som väger tyngst. Ranorex uppfyllde flest antal

utvärderingskriterier men detta testverktyg har samtidigt svagheter där Sencha Test istället uppvisar

styrkor och även vise versa.

Slutsatsen för detta arbete är att bägge testverktygen fungerar väl vid användande i praktiken, men

att valet som görs bör vara beroende på vilka kriterier som väger tyngst och anses vara viktiga – men

även att det är relevant att se på integrerade testverktyg som en helhet för att kunna utnyttja de

funktioner de tillsammans erbjuder fullt ut. Ett enda testverktyg kommer inte att uppfylla exakt alla

önskemål och krav som ställs på det för inget testverktyg är specialanpassat på alla sätt för just den

enda verksamheten som behöver det. Istället är det relevant att se på verktyg som kan integreras

och tillsammans arbeta mot ett gemensamt mål. Detta kan liknas med de verktyg som används när

hantverkare tillverkar en produkt. De har flera olika verktyg som hjälper till under processen,

exempelvis en såg och en hammare, båda dessa verktyg har olika egenskaper och funktioner – men

de används tillsammans under samma projekt för att tillsammans nå ett mål. Endast ett av dessa

verktyg kan inte utföra allt som behöver göras och ensam nå målet, en hammare kan inte såga av en

48

bräda. På samma sätt kan inte testverktyg ensamma utföra alla funktioner, men tillsammans kan de

utföra många fler funktioner - vilket är en anledning till att integration av testverktyg är relevant att

ha i åtanke.

Alla deras sammanlagda funktioner kommer gå att nyttja vilket ökar antalet uppfyllda kriterier –

därför har slutsatsen att metoder som enbart kollar på ett verktyg inte håller i längden. Istället måste

det finnas i åtanke att flera olika verktyg bör finnas med i undersökningen som ett och samma objekt,

en mängd verktyg som arbetar tillsammans.

De framtagna utvärderingskriterierna går att kombinera med sådana som sammanställts under

tidigare forskningar. Utvärderingskriterierna i detta arbete är inte framtagna för att ersätta tidigare

kriterier, utan de är tänkta att fungera som komplement för verksamheter som utvecklar

webbaserade system och som vill hitta testverktyg som har funktioner som passar deras behov.

6.3 Arbetets framtida relevans

Detta arbete kommer även att fungera att använda som underlag flera år framåt i tiden. Alla de

kriterier som tagits fram är inte uppfyllda då det inte finns testverktyg med sådana implementerade

funktioner i dagsläget. Dessa kriterier kommer att vara relevanta längre fram i tiden då det är sådana

funktioner som kan underlätta vid skapandet och utförandet av tester. Människor strävar efter att

förbättra och hitta nya lösningar på problem som kan bidra till en enklare användning av en produkt,

vilket även innebär att sådant som i dagsläget är manuellt kan i framtiden istället bli automatiskt. Då

kommer de framtagna utvärderingskriterierna att bli mer aktuella och eventuellt uppfyllda, just för

att människor strävar efter förbättring, förenkling och nya lösningar som gör att olika uppgifter kan

lösas på ett så smidigt sätt som möjligt.

6.4 Metoddiskussion

Till detta arbete valdes en kvalitativ metod för att den ansågs kunna bidra till ett bättre resultat än

vad en kvantitativ metod skulle åstadkomma. Utvärderingskriterierna är nu begränsade till sådana

som känts relevanta och är brukbara för att undersöka testverktyg inom detta område. En kvalitativ

metod går mer på djupet och intresserad sig för sammanhang och strukturer (Holme & Krohn

Solvang, 1997). En kvantitativ metod kunde istället ha tagit fram betydligt fler utvärderingskriterier,

men istället skulle deras relevans inte vara lika betydande för det mål som de ska uppfylla.

För att kunna få ett bättre resultat hade det varit relevant att intervjua fler personer från andra

verksamheter inom samma område för att kunna skapa en bredare bild. Då inga verksamheter

49

fungerar likadant hade de kunnat ge annorlunda input som kunde bidra till fler och annorlunda

utvärderingskriterier. Istället för enbart intervjuer kunde de kombinerats med enkäter. På så sätt

skulle en djupare inblick kunnat fås samtidigt som fler aspekter kunnat samlas in via enkätsvaren.

Resultatet hade även kunnat bli bättre och tydligare om fler än ett testverktyg hade testats i

praktiken för att kontrollera att utvärderingskriterierna är relevanta och fungerar som tänkt. Det

hade bidragit med en bredare bild samt fler aspekter som hade styrkt de framtagna kriterierna och

påvisat att de är viktiga att ha i åtanke vid val av testverktyg.

50

7 Referenser

Amannejad, Y., Garousi, V., Irving, R. & Sahaf, Z. (2014) A Search-based Approach for Cost-Effective

Software Test Automation Decision Support and an Industrial Case Study.

Base36 (2013). Automated vs. Manual Testing: The Pros and Cons of Each. Hämtad 2017-02-25, från:

http://www.base36.com/2013/03/automated-vs-manual-testing-the-pros-and-cons-of-each/

Behkamal, B., Kahani, M. & Akbari, M. K. (2009) Customizing ISO 9126 quality model for evaluation of

B2B applications.

Börjesson, E. & Feldt, R. (2012) Automated System Testing using Visual GUI Testing Tools: A

Comparative Study in Industry.

Carvallo, J. P. & Franch, X. (2006) Extending the ISO/IEC 9126-1 Quality Model with Non-Technical

Factors for COTS Components Selections.

Elbaum, S., Malishevsky, A. G. & Rothermel, G. (2002) Test Case Prioritization: A Family of Empirical

Studies.

Eriksson, U. (2008) Test och kvalitetssäkring av IT-system. Lund: Studentlitteratur.

Grindal, M., Offutt, J. & Mellin, J. (2006) On the Testing Maturity of Software Producing

Organizations.

Hallnemo, M. (2013) Processen att välja ett verktyg för automatiserad GUI-testning: En fallstudie.

(Kandidatuppsats) Skövde: Institutionen för kommunikation och information, Högskolan i Skövde

Tillgänglig: http://his.diva-portal.org/smash/record.jsf?pid=diva2%3A630602&dswid=-4768

Hass, A. M. J. (2008) Guide to Advanced Software Testing. Noorwood: Artech House.

Heitlager, I., Kuipers, T. & Visser, J. (2007) A Practical Model for Measuring Maintainability.

Holme, I. M. & Krohn Solvang, B. (1997) Forskningsmetodik. Lund: Studentlitteratur.

Illes, T., Herrmann, A., Paech, B. & Rückert, J. (2005) Criteria for Software Testing Tool Evaluation – A

Task for Oriented View.

Konsultbolag1 (2011) Att lyckas med Testautomatisering. Hämtad 2017-03-03, från:

https://konsultbolag1.se/bloggen/att-lyckas-med-testautomatisering

Lewis, W. E. (2005) Software Testing and Continuous Quality Improvement. Boca Raton: Auerbach

Publications.

http://www.base36.com/2013/03/automated-vs-manual-testing-the-pros-and-cons-of-each/

http://his.diva-portal.org/smash/record.jsf?pid=diva2%3A630602&dswid=-4768

https://konsultbolag1.se/bloggen/att-lyckas-med-testautomatisering

51

Memon, A. M. (2002) GUI Testing: Pitfalls and Process.

Memon, A. M. (2008) Automatically Repairing Event Sequence-Based GUI Test Suites for Regression

Testing.

Onoma, A. K., Tsai, W-K., Poonawala, M. H. & Suganuma, H. (1998) Regression Testing in an Industrial

Environment.

Poston, R. M. & Sexton, M. P. (1992) Evaluating and Selecting Testing Tools.

Randhawa, R. & Pandey, L. (2006) Automated Regression Testing Framework using Keyword Driven

Approach.

Rothermel, G., Untch, R. H., Chu, C. & Harrold, M. J. (1999) Test Case Prioritization: An Empirical

Study.

Software Testing Help (2016) Automated Testing – How to Choose the Best Automation Testing Tool.

Hämtad 2017-03-02, från:

http://www.softwaretestinghelp.com/choosing-automation-tool-for-your-organization/

Tiitinen, M. (2013) Key Factors for Selecting Software Testing Tools.

http://www.softwaretestinghelp.com/choosing-automation-tool-for-your-organization/

52

8 Bilagor

8.1 Intervjufrågor

Verksamhet

1) Varför vill ni införa automatiserade tester?

2) Hur arbetas testning med i dagsläget, vem har ansvaret för att utföra den?

3) Hur mycket tid läggs på testningen?

4) Av den testning som genomförs nu, hur stor del av den är återkommande?

5) Dokumenteras de tester som genomförs nu? Om ja; hur?

6) Vad förväntas testverktyget kunna bidra med?

7) Hur ser utvecklingsprocessen ut i dagsläget?

8) Vilka miljöer används under utvecklingsprocessen?

Testverktyg

1) Vilka typer av tester bör verktyget ha stöd för att utföra?

2) Vilka funktioner och egenskaper vill ni att testverktyget ska kunna bidra med?

3) Ska testverktyget kunna samarbeta med andra verktyg? Om ja; vilka?

4) Vilka metoder bör kunna användas för att skapa testfall?

5) Hur bör skapade testfall kunna hanteras?

testverktyg för webbapplikationer1128980/fulltext01.pdf · arbete var ranorex och sencha test....

Documents