Testverktyg för webbapplikationer
Analys av testverktyg för regressionstester
Hanna Andersson
Systemvetenskap, kandidat 2017
Luleå tekniska universitet Institutionen för system- och rymdteknikSammanfattning
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
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
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 ... 122.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.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.2 Utvärderingskriterier ... 38 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.1 Utvärderingskriterier ... 44 6.2 Val av verktyg ... 47 6.3 Metoddiskussion ... 48 7 Referenser ... 50 8 Bilagor ... 52 8.1 Intervjufrågor ... 52
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
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
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.
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
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.
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).
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).
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
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
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
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?
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).
• 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).
• 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).
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
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:
• 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?
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.
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
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.
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.
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:
Testplanering och översikt
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.
Testexekvering, samt fånga och jämföra resultat
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.
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.
Stöd för buggar samt underhåll
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
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.
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
Testplanering och översikt
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
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
Testexekvering, samt fånga och jämföra resultat
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.
*** 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.
Stöd för buggar samt underhåll
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
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.
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.
Följande testfall beskriver hur en befintlig artikel kan redigeras.
ID 2
Rubrik Redigera artikel
Förberedelser Logga in med administratorbehörighet.
Välj ”Administration”. Välj ”Artikel”.
Teststeg 1. Dubbelklicka på befintlig artikel.
2. Ändra ”Artikelgrupp”. 3. Ändra ”Artikeltyp”. 4. Klicka på ”Spara”.
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
Förberedelser Logga in med administratorbehörighet.
Välj ”Administration”. Välj ”Artikel”.
Teststeg 1. Dubbelklicka på befintlig artikel.
2. Utöka menyn för ”Dimensioner”.
3. Lägg till längd, bredd, höjd, vikt och volym. 4. Klicka på ”Spara”.
Förväntat resultat Artikeln får tillagda dimensioner.
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
Förberedelser Logga in med administratorbehörighet.
Välj ”Administration”. Välj ”Artikel”.
Teststeg 1. Dubbelklicka på befintlig 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.
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
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.
5.2 Utvärderingskriterier
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
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
ö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.
Testplanering och översikt
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.
Testexekvering, samt fånga och jämföra resultat
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
