Testverktyg för webbapplikationer

Transkript

1 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 2

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 3

4 Innehåll Sammanfattning... 1 Abstract Inledning Bakgrund Problemområde Syfte Forskningsfrågor Avgränsningar Definition av begrepp Tidigare forskning Teori Regressionstest Automatiserad testning Fördelar med testautomatisering Nackdelar med testautomatisering Testfall Att välja testverktyg Kriterium Selektionskriterier Utvärderingskriterier Metod Arbetets framväxt Fallstudie Datainsamling Val av litteratur Intervju Analys av data

5 3.2.5 Val av testverktyg Etik Resultat Verksamhetsbeskrivning Utvärderingskriterier Testverktyg att undersöka Ranorex Sencha Test Val av verktyg Analys mot utvärderingskriterier Implementation av testfall Testfall Analys Testautomatisering Utvärderingskriterier Val av verktyg Jämförelse av testverktygen Testverktygens styrkor och svagheter Implementationen av testfall Slutsatser Utvärderingskriterier Val av verktyg Metoddiskussion Referenser Bilagor Intervjufrågor

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 6

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 7

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 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. 8

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 End-to-end Dumb monkey GUI Memory leak Regressionstest Snapshot Testaktivitet Testdata Definition Tester som utförs från början till slut för att exempelvis kontrollera att rätt information skickas vidare mellan olika systemkomponenter. 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. Graphical user interface: Grafiskt användargränssnitt. Tillåter att användare att interagera med elektroniska maskiner genom grafiska ikoner och visuella indikatorer. När ett program inte gör sig av med kasserat minne och orsakar försämrat utförande eller programkrasch. Testaktiviteter som utförs vid förändringar i ett program. En skärmdump tagen från exempelvis den webbapplikation som är under testning. En aktivitet som utförs inom testning, exempelvis de händelser som sker när ett testfall utförs. Data som är speciellt anpassad för att användas under tester. 9

10 Testfall Testverktyg Verktyg Tabell 1 Definitioner av begrepp Ett recept som beskriver hur ett test ska utföras. Ett program som är ett hjälpmedel för att skapa och exekvera tester. Se: Testverktyg 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. 10

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). 11

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 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). 12

13 Fördel Förklaring Referens Återanvända testskript De testskript som skapats går att återvända vid framtida tester. 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 kan råka utföra tester fel, en maskin människor kommer att göra precis som den blivit tillsagd utan avvikelser. Säkerställa kvalitén på Tester genomförs för att kunna kontrollera att programvaror både nya och gamla delar i programmet fungerar som tänkt. Alla har tillgång till Användare med tillgång till testsystemet har testresultatet möjlighet att se vilka resultat testerna fått. Genomföra tester som Det är möjligt att exempelvis genomföra inte går att göra utan prestandatester vars syfte är att kontrollera om verktyg systemet uppfyller uppsatta krav på svarstid. Objektiva bedömningar Testresultaten får objektiva tal. Detta reducerar antaganden och subjektiva uppfattningar. Tabell 2 Fördelar med automatiserad testning. Randhawa & Pandey (2006) Amannejad, Garousi, Irving & Sahaf (2014) Base36 (2013) Eriksson (2008) 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 13

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 Amannejad, Garousi, Irving & Sahaf (2014) att utföra felaktiga tester snabbare. 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å Man kan köra flera hundra tester och inte hitta Eriksson (2008) verktygen några fel då är en risk är att testfallen är dåligt utarbetade eller att de blivit föråldrade. 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). 14

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 15

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? 16

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) 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). 17

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). 18

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) 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). 19

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 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. 20

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: 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 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. 21

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 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 22

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 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. 23

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 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. 24

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: 25

26 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. 26

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. 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 27

28 Katalon Studio Ranorex Screenster Selenium Sencha Test Typ av GUI X X X X X Utformning av X X X X X testskript Integration med andra /* X /** /*** verktyg 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 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: 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: 28

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 Analys mot utvärderingskriterier Testplanering och översikt Kriterium R ST 1. Testverktyget kan användas till specifika applikationsdomäner, exempelvis webbapplikationer. 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 X X 29

30 o Opera X X o Internet Explorer X X o Safari 3. Personliga inställningar för att underlätta för användarna av X X testverktyget. 4. Testverktyget stödjer agila utvecklingsmetoder. X X 5. Testverktyget kan avgöra hur stor del av applikationens kod som X testerna täcker. Summa: 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 X X och utökas. 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 X session. Summa: 7 6 Tabell 8 Implementation 30

31 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 X X testexekveringar. 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 X X ske i deras kod. 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 X X system. 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 X samtidigt. 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. 31

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 X X ett testskripts status. 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 * 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. 32

33 Totalt resultat Avsnitt R ST Testplanering och översikt 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 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. 33

34 Det första testfallet beskriver hur en användare lägger till en ny artikel i databasen. ID 1 Rubrik Förberedelser Teststeg Förväntat resultat Tabell 13 Testfall Ny artikel Ny artikel Logga in med administratorbehörighet. Välj Administration. Välj Artikel. 1. Välj Ny artikel. 2. Ange nummer. 3. Ange benämning. 4. Välj artikelgrupp. 5. Välj artikeltyp. 6. Klicka på Spara. En ny artikel läggs till i listan. 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 34

35 Följande testfall beskriver hur en befintlig artikel kan redigeras. ID 2 Rubrik Förberedelser Teststeg Förväntat resultat Tabell 14 Testfall Redigera artikel Redigera artikel Logga in med administratorbehörighet. Välj Administration. Välj Artikel. 1. Dubbelklicka på befintlig artikel. 2. Ändra Artikelgrupp. 3. Ändra Artikeltyp. 4. Klicka på Spara. Befintlig artikel får uppdaterad information. 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 Förberedelser Teststeg Förväntat resultat Tabell 15 Testfall Lägg till dimensioner Lägg till dimensioner Logga in med administratorbehörighet. Välj Administration. Välj Artikel. 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. Artikeln får tillagda dimensioner. 35

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 Förberedelser Teststeg Förväntat resultat Tabell 16 Testfall Ta bort artikel Ta bort artikel Logga in med administratorbehörighet. Välj Administration. Välj Artikel. 1. Dubbelklicka på befintlig artikel. 2. Klicka på Ta bort. Artikeln försvinner från databasen. Bild 5 beskriver hur testet ser ut efter inspelning samt redigering och finjustering. Bild 5 Ta bort artikel 36

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 37