• No results found

Modell-Baserad Testning

N/A
N/A
Protected

Academic year: 2021

Share "Modell-Baserad Testning"

Copied!
46
0
0

Loading.... (view fulltext now)

Full text

(1)

Examensarbete 15 högskolepoäng, grundnivå

Modell-Baserad Testning

Model-Based Testing

Jack Mao

Michael Ong

Examen:Högskoleingenjörsexamen 180 hp

Huvudområde:Datavetenskap Handledare:Magnus Krampell

Program:Datateknik och Mobil IT Examinator:Ivan Kruzela

(2)

Sammanfattning

Under två decennier har utvecklare inom mjukvarutestning utvecklat testtekniken Modell-baserad testning. Tekniken bygger på att man genererar testfall från en modell (tex i UML), istället för att manuallet skriva testfall. Detta kan göra testprocessen mer effektiv, vilket leder till att mer arbeten kan göras på kortare tid. Det kan också ses som en ekonomiskt fördel för företag där testning är huvudområdet. Modell-baserad testning har goda omdömen och teorin för tekniken är väl dokumenterad i artiklar, arbeten samt böcker. Mycket tyder på att tekniken rent teore-tiskt är användbar i praktiken dessutom finns det väldigt lite kritik mot tekniken. Men trots allt detta har Modell-baserad testning inte blomstrat inom IT-industrin.

Syftet med detta arbete är att ta reda på vad anledningarna skulle kunna vara till att MBT inte lyckats bättre inom industrin. I arbetet används tre olika MBT-verktyg för att testa och sedan jämföra om resultatet i praktiken blir som teorin beskriver tekniken. Studiens resultat pekar på att tekniken fortfarande är omogen och många brister kring Modell-baserad testning stöts på.

(3)
(4)

Abstract

For two decades, software testing developers have developed the Model-based testing technique. The technology is based on generating test cases from a model (e.g. in UML) instead of manu-ally writing test cases. This can make the test process more efficient, which leads to more work can be done in less time. It can also be seen as an economic benefit for companies where testing is the main area. Model-based testing has good reviews and the theory of the technique is well documented in articles, works and books. There are many indications that the technology is theoretically useful in practice, with a very few criticisms of the technology. Despite all this, Model-based testing has not expanded in the IT industry.

The purpose of this study is to find out what the reasons could be to the fact that MBT did not succeed better in the industry. In this thesis, three different MBT tools are used to test and then compare whether the result in practice becomes as the theory describes the tech-nique. The result of the study indicates the opposite direction and many shortcomings regarding Model-based testing come across.

(5)
(6)

Förord

Vi vill framföra ett stort tack till vår handledare Magnus Krampell som hjälpt oss genom arbetet. Vi vill även tacka vår examinator Ivan Kurzela för konstruktiv kritik och hans granskning av uppsatsen. Sist men inte minst, på ett mer personligt plan, vill vi tacka familj och vänner för att ni lyssnat, stöttat och alltid funnits där för oss under dessa hektiska veckor.

(7)
(8)

Ordlista

MBT -Modell-baserad testning

SUT -System Under Test

UAT -User acceptance testning

(9)

Innehåll

1 Introduktion 1 1.1 Bakgrund . . . 1 1.2 Problemdomän . . . 2 1.3 Frågeställningar . . . 2 1.4 Avgränsningar . . . 2 2 Teknik 4 2.1 Mjukvarutestning . . . 4 2.1.1 Manuell testning . . . 4 2.1.2 Modell-Baserad Testning . . . 5

2.1.3 Unified Modeling Language . . . 6

2.1.4 JUnit . . . 7

3 Relaterat arbete 8 3.1 M.Utting och B.Legeard – Practical model-based testing: a tools approach [10] . 8 3.2 A. Kramer och B. Legeard – Model-based testing essentials: guide to ISTQB certified model-based tester foundation level [11] . . . 9

3.3 M. Blackburn, R. Busser och A. Nauman – Why Model-Based Test Automation is Different and What You Should Know to Get Started, Software Productivity Consortium NFP [5] . . . 10

3.4 E.Bernard, F.Ambert, B.Legeard och A.Bouzy – Lightweight Model-Based Tes-ting for Enterprise IT [15] . . . 10

4 Metod 12 4.1 Val av metod . . . 13 4.2 Litteratursökning . . . 13 4.3 Modell skapandet . . . 13 4.4 Val av MBT verktyg . . . 13 4.5 Testning i JUnit . . . 13 4.6 Testning av MBT-verktyg . . . 14

(10)

5 Resultat och Analys 15 5.1 Modellen . . . 15 5.2 Resultat litteratursökning . . . 16 5.3 JUnit . . . 17 5.3.1 Bakgrund . . . 17 5.3.2 Resultat . . . 17

5.4 Test av olika verktyg . . . 18

5.4.1 Cameo Enterprise Architecture . . . 18

5.4.2 MBTSuite och Enterprise Architect . . . 19

5.4.2.1 Resultat av MBTSuite och Enterprise Architect . . . 20

5.4.3 GraphWalker . . . 22

5.4.3.1 Resultat . . . 23

5.4.3.2 Bro mellan SUT och testfall . . . 27

5.4.3.3 Ytterligare tester . . . 27 5.4.3.4 Intervju . . . 28 6 Diskussion 30 6.1 Relaterat arbete . . . 30 6.2 Metod . . . 30 6.3 Resultat . . . 31 7 Slutsatser 32 7.1 Frågeställningar . . . 32

7.1.1 Vad skulle kunna vara anledningen till att MBT inte lyckats i industrin? . 32 7.1.2 Vilka MBT verktyg som använder UML finns tillgängliga för akademiskt syfte, dvs gratis att använda? . . . 33

7.1.3 Vad skiljer teorin från praktiken vid användning av MBT-verktyg? . . . . 33

7.2 Framtida arbete . . . 33

(11)
(12)

1.

Introduktion

I detta kapitel kommer bakgrunden av arbetet och problemdomänen att introduceras. Sedan kommer frågeställningarna och avgränsningarna som hela arbetet styrs av att tas upp.

1.1

Bakgrund

Antalet mjukvaruprogram i dagens teknikindustri ökar ständigt [1]. Under en tid fördubblades antalet mjukvaruprogram på cirka 18 månader [1]. Förutom ökningen av mjukvaruprogram, utvecklas också de redan befintliga mjukvaruprogrammen där de nya tilläggen har en potential att leda till fler problem än vad de löser. Denna ökningen av mjukvaruprogram och utvecklingen av nya tillägg till mjukvaruprogram innebär att mängden mjukvarutester också måste bli fler och bättre, för att industrin hela tiden ska vara redo för att kunna testa alla mjukvaruprogram och tillägg som utvecklas [1]. Utvecklingen innebär att mängden mjukvarutester också måste bli fler och bättre så att industrin hela tiden är redo för alla mjukvaruprogram som utvecklas [1]. Mjukvarutestning är ett arbete som innebär att man kontrollerar att systemets resultat matchar det förväntade resultatet [2]. Denna process utförs för att kunna försäkra att systemet fungerar som det är tänkt och inte visar andra beteenden som inte skall finnas. Manuell och automatise-rad testning är två av de vanligare teknikerna inom testning.

Modell-baserad testning (MBT) är en modern teknik för att utföra testning inom mjukvara. Till skillnad från de traditionella testnings-teknikerna som manuell och automatiserad testning, behöver MBT mindre programmering eftersom MBT handlar om att arbeta visuellt med mo-deller. MBT utvecklades främst för att minska kostnaderna inom testnings industrin genom att göra arbetet effektivare. Tekniken gör det möjligt att snabbt massproducera testfall med hjälp av modeller.

Under 1997 släpptes den första versionen av UML som utvecklades av Grady Booch, Ivar Jacob-son och James Rumbaugh [3]. UML är ett objektorienterat generellt språk som skapades för att standardisera de olika sätten att visuellt beskriva ett system. Språket UML gör det möjligt att skapa modeller av ett system som skall konstrueras och därmed göra det enklare att förstå och utveckla. UML gör det möjligt och är grunden för utvecklingen av MBT [4].

(13)

1.2

Problemdomän

Utmaningen i industrin för testning blir hela tiden större i takt med den enorma utvecklingen av mjukvaruprogram och nya system. Kort tid mellan testningen och utgivningsdatum gör att produkter ibland släpps med fel då det anses viktigare att leverera utlovade funktioner än felfria produkter [5][6]. Förutom bristen på tid är även de stora kostnaderna som finns inom testning ett stort problem. Hela 80 procent av kostnaderna för en kommersiell programutveckling går åt testningen av produkten [6].

I början av 2000-talet hade USA en kostnad på 550 miljarder kronor årligen som gick till att korrigera defekter i datorprogram [7]. Även om det snart är 20 år sedan dessa siffror togs fram är det fortfarande relevant [8]. Många företag har de senaste tre åren (2016-2018) använt cirka 26 procent av hela sin IT budget till att försäkra kvalité och testningsmetoder [9].

Trots att sättet som mjukvara utvecklas på har förändrats i takt med all ny teknik som utveck-las, är det mycket som är samma i sättet man arbetar på. Sedan år 2000 har mycket utveckling kring olika testmetoder [4] gjorts men trots detta är majoriteten av testningsmetoderna som används i dagens industri samma metoder som användes för 20 år sedan.

En teknik som utvecklades i början av 2000-talet är MBT och som på den tiden ansågs som en teknik som skulle ta över testning i industrin och mycket fokus fanns på tekniken. I en under-sökning från år 2017 som gjordes av Techwell Community visade att endast 14% av deltagarna (som är yrkesverksamma testare) använt sig av MBT vilket tyder på att MBT inte blivit stort som det hade potential till [15].

1.3

Frågeställningar

Syftet med detta arbete är att försöka hitta möjliga anledningar till varför tekniken MBT inte lyckats bättre i industrin. Undersökningen utförs med hjälp av litteratursökning och experiment där olika MBT verktyg testas. I arbetet har också en automatiserad testning gjorts för att få ett perspektiv på vad som MBT egentligen skulle ha ersatt. Frågeställningarna är angivna nedan:

• RQ1: Vad skulle kunna vara anledningen till att MBT inte lyckats bättre i industrin? • RQ2: Vilka MBT verktyg som använder sig av UML finns tillgängliga kostnadsfritt? • RQ3: Vad skiljer teorin från praktiken då man använder MBT-verktyg?

1.4

Avgränsningar

• MBT-verktyg som använder UML tillståndsdiagram

• MBT-verktygen ska vara utvecklade för operativsystemet Windows • Verktygen som ska användas ska vara gratis eller ha en gratis version

(14)

• Verktyget ska vara aktivt projekt med pågående utveckling • Verktyget ska använda ett eget användargränssnitt

• Endast verktyget JUnit för den automatiserade mjukvarutestning kommer att användas • Modellen som används i arbetet är en modell av en tvättmaskin och de funktioner som

(15)

2.

Teknik

2.1

Mjukvarutestning

Testning är en viktig aktivitet i programutvecklingen. Ibland schemaläggs testningsaktiviteten väldigt nära intill lanseringsdatumet, vilket gör att det blir en utmaning att utföra flera testfall under en kort period [5].

Anledningen till att mjukvarutestning utförs är för att säkerställa kvaliteten på programva-ran, undersöka programmens beteende och försöka hitta så många defekter som möjligt innan lanseringen. Varje defekt som upptäcks i efterhand kan bli väldigt kostsam att reparera och kan påverka programmets utveckling negativt. Ett av industrins problem med testning är att den är schemalagt sent i projektet, vilket gör att vissa testfall aldrig kommer att hinna testas till lanseringsdatumet. Detta gör att testare försöker hitta nya metoder som kan göra testningen effektivare och lönsammare [5].

2.1.1

Manuell testning

Det som kännetecknar en manuell testning är att det krävs mänskligt utförande av testning under hela processen. Därför skapas och testkörs testfallen manuellt av en testare [10]. Varje testfall som utförs ger ett resultat som sedan jämförs med det förväntade resultatet. Genom att jämföra resultaten med varandra, kan en testare verifiera om System Under Test (SUT) beter sig som det ska [10].

För varje manuellt testfall som ska utföras på ett SUT repeteras några moment av testnings-processen och dessa moment är Test Execution och Test Reporting (se Figur 2.1). Detta är en repeterande arbetsuppgift och det blir en tidskrävande process som även leder till att processen för varje testfall blir mer kostsam att utföra. På grund av kostnaden tas de lägre prioriterade testfall bort för att kunna hålla ner budgeten. Därmed blir mjukvaran ofullständig testad vilket leder till frågeställning kring mjukvarans stabilitet, produktmognad och robusthet [10].

(16)

Figur 2.1: Manuell testningsprocess [10]

2.1.2

Modell-Baserad Testning

Idén med MBT är att på ett snabbt sätt ska kunna skapa testfall. Författarna till boken ”Model-based testing essentials: guide to ISTQB certified model-”Model-based tester foundation level” samman-fattar boken med detta citat ”Draw pictures whenever possible to explain what you are doing or going to do, and use it to create and maintain your testware.” [11].

När en programmerare ska förklara hur förhållandet mellan olika element hör till varandra i ett stort system ritas ett klassdiagram. Om en programmerare ska förklara hur en avancerad process fungerar ritas ett flowchart. Att rita ett klassdiagram eller ett flowchart hjälper att strukturera och ge en visuell förståelse för programmet [11].

Med ett MBT-verktyg ska en testare kunna, med hjälp av en modell, generera och skapa testfall för SUT som är anpassade enligt testdesigners krav. Fördelarna med att använda MBT är att kunna skapa en enkel version av SUT genom en modell och testa modellens beteende samt re-lationen mellan olika tillstånd. Detta gör att testningsarbetet redan kan påbörjas i tidigt stadie i ett projekt, vilket löser delar av industrins problem med tidsbrist [11].

MBT processen är uppdelad i fem steg (se Figur 2.2): 1. Model the SUT and/or its environment.

2. Generate abstract tests from the model.

(17)

Figur 2.2: MBT process [11]

2.1.3

Unified Modeling Language

UML är ett objektorienterat språk för diagram. Språket används ofta inom IT-världen för att beskriva ett SUT. Genom att konstruera en modell av SUT blir det enklare att förstå upp-byggnaden av systemet. UML består av 14 olika diagram (se Figur 2.3) som kan väljas för att beskriva strukturen och beteendet beroende på vilket område (system, livsvillkor och test) som ska beskrivas. Alla dessa 14 diagram presenteras i en grafisk form [11]. I detta arbetet används ”State machine” som är en av de 14 diagramen.

(18)

Figur 2.3: De 14 olika diagramtyperna av UML [13]

2.1.4

JUnit

JUnit är ett öppen källkods-ramverk som är designad för programmeringsspråket Java. JUnit är skapad av Erich Gamma och Kent Beck och namnet JUnit kommer ifrån Java och Unit test vilket är den sorten tester som utförs. Konceptet med Unit testing är att kunna ge möjlighet för en testare att kunna testa olika delar av koden som programmeraren har kodat och vill kontrollera [16]. JUnit har ett grafiskt användargränssnitt, vilket gör det lättare för användaren att följa testerna samtidigt som de genomförs. Ett testfall skapas i JUnit genom att man markerar en metod i koden igenom att skriva @test ovanför metoden. Sedan kan denna metod designas och utformas till den sorts test som behövs. När testfallet sedan körs på datorn kommer JUnits ”testrunner” markera metoden röd eller grön på skärmen beroende på om det är ett lyckat eller ett misslyckat test.

(19)

3.

Relaterat arbete

Detta kapitel handlar om böcker och artiklar som är relaterade till detta arbetet. Främst kommer dessa böcker och artiklar vara underlagen till teorin och metoderna som nämns samt beskrivs i detta arbete.

3.1

M.Utting och B.Legeard – Practical model-based

tes-ting: a tools approach [10]

Boken innehåller enkla exempel vad MBT är och vilka metoder som kan användas för att gene-rera testfall. I boken presenterar författarna vanliga misstag som förekommer och hur strukturen ska vara för att förbättra användningen av MBT.

I kapitel 1 beskriver författarna vad MBT kan göra, genom att använda sig av testning av Smartkort som exempel. Författarna använde ett UML-diagram för att beskriva hur Smartkort fungerar. UML-modellen av systemet beskriver bara hur strukturen är och inte beteendet av sy-stemet. För att ge information till UML-modellen om hur systemet beter sig behövs detaljer av systemet implementeras till UML-modellen. Hur implementationen sker mellan UML-modellen och systemet refererar författarna till kapitel 3 i boken.

I kapitel 2 presenteras hur manuell testning och MBT process fungerar. I ett av avsnitten be-skrivs klassificering av mognadsgraden inom modellering i företag. Den innehåller 6 olika nivåer av modell mognadsgrad och de finns beskrivna i Figur 3.1.

(20)

Figur 3.1: Modellerings mognadsgrad[10]

Enligt författarna ska företag som jobbar med MBT ligga i nivå 3 och 4, men många av företagen som jobbar med MBT ligger på nivå 1 samt 2. Detta ledder till att företagen har svårigheter med att kunna skapa exakta testmodeller.

3.2

A. Kramer och B. Legeard – Model-based testing

es-sentials: guide to ISTQB certified model-based tester

foundation level [11]

I denna bok så har författarna valt att bara använda modellspråket UML. UML består av 14 oli-ka typer av UML-diagram som nämns i avsnitt 2.1.3 ”Unified Modeling Language”. Författarna har av de 14 olika typer av UML-diagram valt att använda aktivitetsdiagram och tillståndsdia-gram (se Figur 2.3).

I kapitel 3 presenterar författarna vilka roller som finns i en MBT process. De är testmanager som har hand om testplaneringen, testanalytiker som jobbar med testanalys, affärsanalytiker har i uppgift att klargöra för testare vilka tester som har efterfrågats av kunden och den sista rollen i en MBT process är testare som ansvarar för utförandet av testningen. I kapitel 3 beskrivs också olika MBT testtyper som finns. De olika MBT-testtyperna är Integration testing, System testing, System integration testing, UAT, MBT for regression testing och MBT for end-to-end testing.

I kapitel 9 förklarar författarna kraven som krävs för att kunna koppla samman MBT-testfall och SUT. Hur bra kopplingen mellan testfallen och SUT är beror på om testaren ha fått

(21)

tillräck-testfall i förhållande till hur SUT beter sig. Konceptet med MBT är att kunna påbörja testnings-processen innan SUT börjar kodas. Detta gör att det finns möjlighet att detaljinformation om SUT brister, vilket ledder till att testaren även kommer att ha bristande detaljer gällande SUT. Men situationen är redan inkluderad i MBT-konceptet. På grund av att konceptet är tänkt att en testare när som helst ska kunna lägga till och ändra detaljerna för SUT utan att påverka testfallet.

3.3

M. Blackburn, R. Busser och A. Nauman – Why

Model-Based Test Automation is Different and What You Should

Know to Get Started, Software Productivity

Consorti-um NFP [5]

I denna artikel jämför författarna MBT med tre andra automatiserade testgenerationer och de är capture/playback approach, test abstraction och data driven approach. Författarna nämner också att MBT har potential att blir nästa generationen av automatiserat testning. Författarna nämner också hur automatiserade testmodeller eliminerar manuella testdesign. Författarna vill belysa att automatiserad testning inte kan eliminera manuell testning, på grund av att mänsklig intelligens inom testning kommer alltid att behövs. Däremot behövs automatiserad testning för att underlätta testarnas arbete. Författarna skriver också om hur de rekommenderar att starta och organisera ett projekt med MBT. Syftet med artikeln är att lyfta fram hur MBT skiljer sig från de andra automatiserade testgenerationerna.

Det som MBT skiljer från de andra automatiserade testgenerationerna är att kunna verifie-ra SUT innan den börjar kodas, för att kunna utföverifie-ra detta arbete skapas en modell från kverifie-raven på SUT. Genom att testa en modell med kraven för SUT ger det möjlighet att kunna eliminera defekter innan kodningen av SUT, samt möjlighet att kunna påbörja testningsprocessen innan ett projekt har börjat med kodningen av SUT. Genom att i ett tidigt stadiet kunna eliminera defekter av SUT, leder det till kostnadsbesparingar och högre kvalitet.

3.4

E.Bernard, F.Ambert, B.Legeard och A.Bouzy – Lightweight

Model-Based Testing for Enterprise IT [15]

Artikeln presenterar tekniken MBT och hur tekniken ligger till i IT-industrin. Författarna skri-ver om hur långsamt MBT växer och refererar till en undersökning som konstaterar att endast 14 procent av de svarande använder MBT i sina projekt. Författarnas erfarenhet som presente-ras i artikeln, visar att komplexiteten i användning av de nuvarande MBT verktygen är orsaken till den låga spridningen av tekniken. Syftet med arbetet i artikeln är att undersöka frågan om MBTs framtid och hur tekniken måste förenklas och samtidigt anpassas för de avsedda använ-darna. Författarna presenterar två mål som är:

(22)

2. Förbättra inlärnings-processen för MBT verktygen och anpassa verktygen för användaren. Genom att lyfta fram verktyget Yest, vill författarna bidra till att sprida tekniken och även arbeta mot att nå de nämnda målen. Yest är ett grafiskt verktyg, framtagen av företaget Smar-testning, för att utveckla och implementera testfall. Verktyget har utformats för att testa affärs-processer och företagsregler för företags IT-applikationer, med en mycket kort inlärningskurva. I Yest är tillvägagångssättet att representera arbetsflödet som ska testas och för att hålla det så enkelt som möjligt beroende på företags testmål.

Resultatet visade att de första erfarenheterna av stora företags IT-projekt med flera testteam var att de två målen ovan tenderar att vara tillfredsställda av de föreslagna metod och verktyg. Författarna tror att omformat MBT metod och verktyg som Yest, starkt kan hjälpa testteam att bemöta övergången till agila metoder och även hantera systemets ökade komplexitet genom att stödja ATDD - Acceptance Test Driven Development.

(23)

4.

Metod

Detta kapitel presenterar arbetsflödet som används för arbetet. För att besvara frågeställningar-na i arbetet har stegen i Figur 4.1 genomförts i följande ordning. Först en litteratursökning för att förstå arbetsområdet. Sedan skapas en modell som ska testas med olika verktyg och meto-der. Därefter väljs några MBT-verktyg som ska testas. Testningen som utförs är uppdelat i två kategorier efter testnings teknik. Den första är JUnit och den andra är MBT. Efter testningen av de två kategorierna, analyseras resultaten. Om tillräckligt med resultat finns är testningen klar. Men om resultaten inte räcker till att besvara frågeställningarna görs ytterligare tester. De följande avsnitt beskriver processen djupare. Se Figur 4.1 för en överblick av arbetsflödet.

(24)

4.1

Val av metod

För detta arbete har den s.k. blandad metoder (mixed methodology) används. Metoden fungerar precis som det låter, en blandning av ett antal metoder används för att uppnå bästa resultat av arbetet. I detta arbete har en litteratursökning gjorts om MBT och även testning av olika MBT-verktyg. Genom att blanda flera metoder kommer resultatet att omfatta problemet med fler perspektiv och ge en större bild att analysera. Informationen som samlas in kommer även att omfatta flera olika typer av data, de kan vara siffror, statistik, fakta och bilder [12].

4.2

Litteratursökning

En litteratursökning är nödvändig för att få en djupare förståelse för arbetsområdet. De områden som är kritiska för arbetet är mjukvarutestning i helhet men framförallt de olika teknikerna som finns och används. Målet med litteratursökningen är att samla information för att kunna välja ut rätt verktyg.

4.3

Modell skapandet

En modell behövs i arbetet så att alla experiment utförs på samma system och att resultaten av de olika experimenten är relevanta att jämföras. Målet är att skapa en enkel modell som är lätt att förstå och samtidigt vara tillräckligt komplex för att kunna utföra tester på. Modellen måste alltså ha flera tillstånd med flervals vägar för att det inte ska blir en enda rak väg genom hela systemet. Modellen som används är en modell av en tvättmaskin.

4.4

Val av MBT verktyg

Val av MBT verktyg gör i arbetet för att begränsa antalet verktyget till en mängd som är rimligt att hinna med tills deadline. Metoden till att välja ut verktyg genomförs med att lista upp ett antal kriterier som verktyget måste uppnå. Dessa kriterier är en del av arbetets avgränsningar som kan läsas i avsnitt 1.4 ”Avgränsningar”.

4.5

Testning i JUnit

För att testa tvättmaskins-modellen i JUnit måste först en implementation av modellen skapas. Därefter skrivs testfall för modellens alla möjliga beteenden. Anledningen till att automatiserad testning utförs i JUnit trots att det ursprungligen inte har något med MBT att göra är för att få ytterligare erfarenhet av automatiserad testning.

(25)

4.6

Testning av MBT-verktyg

I testnings delen för MBT-verktygen test-installeras de olika verktygen först att se om de går att köra. Ifall installationen av verktyget inte går att utföra, måste testningen av verktyget upphöra och nästa verktyg börja testas. Om verktyget däremot fungerar kommer modellen att skapas som ett UML-diagram i verktygets användargränssnitt för att testa verktygets funktioner och för att se vilka resultat som kan fås av verktygen.

(26)

5.

Resultat och Analys

I detta kapitel redovisas resultaten från modellskapandet, litteratursökningen, de testade MBT-verktygen och testerna med JUnit.

5.1

Modellen

Modellen som användas som basmodell i arbetet är en tvättmaskins-modell. Denna modell har valts för detta arbete för att den är en enkel modell som många känner till och förstår eftersom tvättmaskinen är något som nästan alla hushåll använder. Modellen har fem olika tillstånd. Dessa tillstånd är Off, Idle, Wash, Dry och Exit som på en enkel nivå omfattar de steg en tvättmaskin har. De olika tillstånden ändras av olika knappar som Power, Next, Stop, Exit, Reset och Timer som också är en knapp för att underlätta testningen av modellen. I Figur 5.1 visas modellen.

(27)

5.2

Resultat litteratursökning

För litteratursökningen har det gjorts sökningar på relaterade arbeten inom arbetsområdet där information om hur MBT fungerar men framförallt på vilka verktyg som finns att arbeta med inom det aktuella området. I listan nedan finns de verktyg som har hittas under litteratursök-ningen. I Tabell 5.1 ”Lista på MBT-verktyg” finns det många verktyg för MBT, men för detta arbete testas endast de verktygen som markerats gröna eftersom de andra befinner sig utanför arbetets avgränsningar (se avsnitt 1.4 ”Avgränsningar”). Tabell 5.1 ”Lista på MBT-verktyg” ut-går från ett arbete av Zoltan Micskei [17] och har kompletterats med fler verktyg som kommer från böckerna och artiklarna som finns i de relaterade arbeten (se kapitel 3 ”Relaterat arbete”).

Tabell 5.1: Lista på MBT-verktyg

Tool Modified Input format Type

4Test 2018 Custom (Gherkin ba-sed) Commercial + Freeversion

BPM-X 2018 BPMN, UML... Commercial

Conformiq Creator 2018 ActivityDSL Diagrams, Commercial Conformiq Designer 2016 UML State Machines,QML Commercial

fMBT 2017 Custom (AAL) Open source

GraphWalker 2018 FSM Open source

GSL 2017 Petri net Commercial

JSXM 2016 EFSMmachines)(Stream X- Academic

MaTeLo 2018 Markov chains Commercial

MBTsuite 2018 UML or BPMN Commercial + Freeversion

Modbat 2016 EFSMDSL) (Scala-based Open source

ModelJUnit 2016 EFSM Open source

MoMuT::UML 2018 UML state machines,OOAS Academic Cameo Enterprise

Ar-chitecture 2018 UML Commerical + freetrailer

OSMO 2018 model program in Java Open source

RT-Tester 2017 UML/SysML, Matlab Commercial

Smartesting CertifyIt 2017 UML / BPMN + OCL Commercial Smartesting Yest 2018 Workflow models withdecision tables Commercial

Tcases 2018 Custom Open source

TestCast 2018 UML State Machines Commercial

TestOptimal 2017 (E)FSM Commercial

(28)

fortsättning av tabellen 5.1

AETG 2007 customtextual notation)(AETGSpec Information saknas Cow_Suite 2003 UML Use Case and Se-quence Diagrams Information saknas

DTM 2016 custom activity model Commercial

GATeL 2004 Lustre Information saknas

JTorX 2014 LTS Open source

JUMBL 2010 Markov chains Academic

MISTA 2015 PrT net Academic

NModel 2010 model program writtenin C# Open source

PyModel 2013 Python source Open source

SAL-ATG 2011 custom (transition sy-stem) Open source SCOOTER 2005 UML Collaboration di-agrams Information saknas Spec Explorer 2013 model programs in C# Commercial

STG 2007 NTIF (IOLTS) Information saknas

TEMPPO 2014 Task flow model Commercial

TGV 2004 LOTOS / IOLTS Information saknas

TorX 2008 LTS / LOTOS Information saknas

TTmodeler 2009 UML (UML 2 TestingProfile) Information saknas

T-VEC 2013 Simulink Commercial

UPPAAL Cover 2010 timed automata Academic

UPPAAL TRON 2009 timed automata Academic

5.3

JUnit

5.3.1

Bakgrund

Verktyget JUnit används i detta arbetet för att skiva manuella testfall och automatiskt exekvera dem. JUnit är en plugin för Eclipse.

5.3.2

Resultat

I Eclipse har ett enkel implementation i form av en tillståndsmaskin gjorts. Detta program ska motsvara tvättmaskins-modellen som arbetet utgår ifrån och som är testmodellen för MBT de-larna. Övergångarna kommer att fungera som knapparna på en riktig tvättmaskin, t.ex anropar Next() motsvarar det som att tryckt på knappen start i den riktiga tvättmaskinen. Anledningen till att programmet har skrivits på detta sätt är för att underlätta testningen eftersom timers och olika sensorer inte har används i detta arbete.

(29)

Testerna verifierar vad som händer när det trycks på en viss knapp i ett bestämt tillstånd. De undersöker också att alla tillstånd kan nås på rätt sätt, vilket visar att tvättmaskinen fun-gerar som det är tänkt, exempelvis att hamna i tillståndet WASH när metoden Start anropas i tillståndet IDLE (se Figur 5.2). I Figur 5.3 visas resultatet av testfallen (testStart) för Start metoden och som visar om den har nått sitt förväntade resultat.

Figur 5.2: JUnit-test för övergången mellan

tillstånden IDLE och WASH. Figur 5.3: Resultatet av JUnit-test för över-gången som sker i Start metoden.

5.4

Test av olika verktyg

5.4.1

Cameo Enterprise Architecture

Cameo Enterprise Architecture är ett objektorienterat modelleringsverktyg som ger möjlighe-ten att skapa olika typer av modeller och diagram. Verktyget kan simulera och upptäcka fel i modeller som skapas i programmet.

Cameo Enterprise Architecture är verktyg med många alternativ när det gäller skapandet av modeller och diagram. Verktyget kan användas i alla projekt där funktionen att skapa modeller eller diagram behövs. Användningen av programmet är välstrukturerad när det gäller arbetet att skapa modellen men blir mer avancerat när modellen ska testas. Att skapa tvättmaskins-modellen i verktyget var det enda steget av arbetsmetoden i arbetet som kunde utföras (se Figur 5.4). Ett av problemen med att arbeta med MBT i Cameo Enterprise Architecture va-ra att verktyget saknar en förinstalleva-rad testfunktion för modellens egenskaper. Det som finns är en verifierings-funktion som ska upptäcka fel ifall modellen inte är fullständig vilket inte är relevant i detta fall. Förutom att en testfunktion saknades finns det ett annat problem vilket är att demo versionen, som är gratis att använda innehåller en begränsning av verktyget. En begränsning som fanns var att det fanns ett begränsad antal element som går att använda per projekt, vilket också skapade hinder av användningen av verktyget. Verktyget fungerar mycket bra till att arbeta med modeller och diagram. Men demo versionen som användes tyder på att verktyget inte är utvecklat för MBT eller att just demo versionen inte erbjuder alla funktioner som finns, på grund av detta lades verktyget åt sidan av arbetet.

(30)

Figur 5.4: Tvättmaskins-modellen i Cameo Enterprise Architecture

5.4.2

MBTSuite och Enterprise Architect

MBTSuite är ett MBT-verktyg som använder sig av UML-modeller för att generera testfall för SUT. Det är ett enkelt verktyg som endast fokuserar på att generera olika testfall. Testfallen genereras genom olika strategier som analyserar alla de möjliga vägarna som kan väljas i model-len. De strategier som MBTSuite använder är path, edge, node och random vilket är olika sätt för verktyget att gå genom modellen beroende på vilken del av modellen som ska testa. MBTSuite är ett öppet verktyg och kan integreras med många andra verktyg och program, ett exempel är Matlab. Det finns en funktion som gör det möjligt att exportera testfall till olika format beroende på vad som föredras för projektet, några exempel på vilka format som finns och som används mycket är Word-fil, Excel-fil eller Java-kod.

MBTSuite saknar funktionen att skapa modeller utan kan endast användas för att testa model-ler. Därför kräver MBTSuite att testaren använder sig av ett externt modellskapande verktyg. De finns väldigt många av dessa verktyg, det som rekommenderas är Enterprise Architect som är ett verktyg där alla sorters UML-diagram kan skapas.

(31)

5.4.2.1 Resultat av MBTSuite och Enterprise Architect

Både MBTSuite och Enterprise Architect är verktyg som inte kräver förkunskaper i operativ-systemet Windows för att installera och verktygen har ett begripligt användargränssnitt. För modellskapande med Enterprise Architect finns det en del guider som kommer med när man installerar verktyget, vilket ger en bra start vid användningen av programmet. Förutom dessa guider finns det också en del material på nätet som hjälper mycket.

Figur 5.5: Tvättmaskins-modellen i Entreprise Architect

Resultatet för verktyget MBTSuite blev inte riktigt vad som förväntats eftersom inte alla stegen i en MBT process inte kunde utföras (se avsnitt 2.1.2 ”Modell-Baserad Testning”). MBTSuite har de flesta funktioner som behövs för ett MBT verktyg bland annat funktionen att importera en modell, att testa modellen med olika inställningar och dessutom kunna generera testfall. Modellen som skapas i Enterprise Architect kan enkelt importeras till MBTSuite (Se Figur 5.6).

(32)

Figur 5.6: Tvättmaskins-modellen i MBTsuite

Verktyget kan exekvera de olika strategier path, edge, node och random på modellen men alla visar inte resultat. En av strategierna som kan köras och visar resultat är node-strategin. Det som händer när node-strategin körs är att verktyget går genom modellen och markerar alla tillstånd som den har gått genom och sedan går den vidare till nästa och här fortsätter den tills den har kommit åt alla de möjliga tillstånd som kan kommas åt. I Figur 5.7 nedan kan man se hur verktyget har gått tillväga för att nå alla de noder som modellen har. Verktyget visar även i modellen att alla noder har testats genom att fylla i de vägarna som tagits röda (se Figur 5.8). Det finns några övergångar som inte används av verktyget och detta beror på att verktyget kör slumpmässigt när den har flera vägar att välja mellan eftersom modellen inte har några villkor. Vid andra tester av med samma strategi har verktyget använt sig av de andra övergångarna.

(33)

Figur 5.7: Lista på de exekverade till-stånd i ordning

Figur 5.8: De exekverade tillstånden och övergångar visas i modellen, röd med prickad linje innebär exekverade och blå med vanlig linje är icke exe-kverade

Det steg av en MBT process som inte lyckades i verktyget MBTSuit var att generera testfall vilket är det viktigaste steg i MBT processen. Detta betyder att verktyget misslyckats med att utgöra syftet för MBT. Verktyget kunde endast generera tomma testfall i både Word dokument och i Java-fil. Problemet till att detta inte fungerade ligger i att inga exempel i manualen på hur detta steg skall göras finns. Eftersom MBTSuites manual inte visar några exempel på hur testfall generas och inte heller på vilka krav på modell för att kunna genera testfall blev det svårt att undersöka vart felet finns.

5.4.3

GraphWalker

År 2005 startades ett projekt för ett MBT verktyg som var baserat på öppen källkod. Verktyget fick namnet MBT.tigris.org, som idag har bytt namn till GraphWalker. GraphWalker skapades på grund av att de MBT-verktygen som då fanns på marknaden, endast var tillgängliga för fö-retag och dessutom väldigt kostsamma att få tillgång till. Av dessa anledningar blev det därmed svårt för grundaren att kunna få tillgång till ett MBT-verktyg. Detta ledde till att grundaren ska-pade ett MBT-verktyg som var gratis för personer som var intresserade av MBT, vilket blev det öppna källkodsverktyget GraphWalker. Grundarna till GraphWalker jobbar som test-manager för ett globalt IT-företag sedan år 2010, och även håller ett aktivt forum för GraphWalker, där användarna av GraphWalker kan ställa frågor och få svar direkt av grundaren.

(34)

GraphWalker-verktyget som används i detta arbetet är en plugin i Eclipse som heter GW4E. För att kunna utnyttja GraphWalkers funktioner genom ett GUI, behövde GW4E installeras i Eclipse. Genom GW4E går det att skapa en UML-modell av SUT. Grundaren av GraphWalker menar att användningen av en UML-modell gör det enklare att förstå SUT, i jämförelse med att titta igenom alla koder i SUT och försöka förstå hur systemet fungerar. Genom att använda en modell till att generera testfall för SUT, anser grundarna till GraphWalker att det blir ett snabbare och effektivare sätt att kunna testa ett SUT.

5.4.3.1 Resultat

Processen att installera GW4E fungerade inte som instruktionen beskrev, vilket gjorde att in-stallationen misslyckades till en början. Instruktionen till GW4E var tydligt beskrivet, däremot saknades några steg som skulle gjort att installationen skulle lyckas vid första tillfället. De stegen som saknades var installation av Maven som är ett verktyg som användas för att automatiskt paketera programfiler i en enhet. På grund av olika stegen som saknades i instruktionen fick ominstallationen av GW4E gjordes vid flera tillfällen under arbetet. För att komplettera mo-menten som saknades i instruktionen gjordes ytterligare informationssökningar om dem saknade stegen. Vissa av stegen gick att hitta lösningar till, däremot fanns även sökningar som inte hade någon lösningar. Stegen som inte gick att hitta lösning till vid informationssökningen, löstes genom att använda tidigare kunskaper och förståelse av operativsystemet Windows, samt testa sig fram tills stegen löste sig. Erfarenhet av installationen på MBT-verktyget GW4E i en Win-dowsdator tyder på att det krävs en del tidigare kunskaper och förståelse av operativsystemet Windows, för att kunna lyckas med installationen.

(35)

Figur 5.9: Tvättmaskin modellen i GW4E

Genom att konvertera modellen som är skapat i GW4E, skapas ett JUnit-testfall som innehåller tre tester. Dessa tre tester anser grundaren till GraphWalker är de tre mest förekommande tester inom ett MBT-projekt. Dessa tre tester som ingår är Smoke Test, Functional Test och Stability Test (Figur 5.10). För att kunna testa SUT behövs delar av SUT implementers till testfallet som genereras ut av tvättmaskin-modellen.

(36)

Figur 5.10: JUnit-tester för Smoke Test, Functional Test och Stability Test.

Konceptet med Smoke Test är att avgöra om man kan ta sig från tillstånd A till tillstånd B. Främst användes Smoke Test för att testa att nya tillstånden som lagts till i tvättmaskin-modellen under arbetets gång inte påverkade andra funktioner i SUT. Det görs genom att välja om den nya tillstånden som lagts in är punkt A eller B, därefter lägger till noden som är föregående eller efterföljande av den nya tillstånden som har lagts till i tvättmaskin-modellen. Det vill säga användning av Smoke Test är för att säkerhetsställa att alla tillstånden i SUT går att komma åt. Ett exempel på hur Smoke Test har använts i detta arbetet är att testa övergången mellan två tillstånd, till exempel noden IDLE och noden OFF som kan ses på Figur 5.11.

Figur 5.11: Smoke Test för övergången mellan noderna OFF och IDLE.

För att kontrollera om rätt övergång och switch-case har exekverats, kontrolleras det genom att gå in i SUT klass och se hur metoden för Power har betet sig (se Figur 5.12). I Figur 5.12

(37)

exekverats, grönmakering betyder det har exekverat kod raden och rödmakering betyder att exekvering av kod raden inte har gjorts.

Figur 5.12: Power-metoden med switch-case mellan noderna OFF och IDLE.

Koncepten med Functional Test är att exekvera alla övergångar som finns i ett SUT. När Func-tional Test har exekverat alla övergångarna betyder det att testet har nått 100% täckning. Det vill säga att alla övergångar som finns i ett SUT har testats. Koncepten för att utföra Functional Test är att GW4E generera alla möjliga slumpmässiga övergångar från varje tillstånd som finns i modellen. På detta sättet kan Functional Test testa att alla övergångar fungerar som det är tänkt, samt testa att det finns övergångar som fungerar i varje nod (se Figur 5.13).

Figur 5.13: Täcknings resultat av alla övergångar.

Idén med Stability Test är att köra SUT med Functional Test under en bestämd tid, för att kontrollera att programmet kan exekveras under den angivna tiden. Testet är också tänkt till att säkerhetsställa att programmet fungerar under en längre period innan systemet installeras i ett inbyggt system.

(38)

5.4.3.2 Bro mellan SUT och testfall

För att kunna testa SUT med testfallet som generas av GW4E behövs en ”bro” som kopplar samman SUT och testfallet. I testfallet som generas av GW4E inkluderas en bro-mall. Därefter ska testaren manuellt implementera de tillhörande tillstånd och övergång från SUT till bro-mallen (se Figur 5.14), för att kunna skapa tråden mellan SUT och testfallet. Anledningen till att implementationen måste ske är för att testfallet ska kunna få förståelse hur SUT fungerar och beter sig i de olika tillstånd samt övergång.

Figur 5.14: Bro-mall med implementationen av tvättmaskins-programmet

Bron mellan SUT och Testfall i GW4E fungerar som metoden Adaptation från boken ”Practical model-based testing: a tools approach” [10], vilket gör att ”test scripts” inte syns. Test scripts betyder i detta fallet hur exekveringen av testfallet går till.

5.4.3.3 Ytterligare tester

För att få ytterligare förståelse om GW4E kan hitta fel i SUT implementerades två medvetna fel i SUT. Det första felet som lades till i SUT var att ändra ett rätt tillstånd i en switch-case till ett fel tillstånd (se Figur 5.15). Andra felet var att implementera ytterligare en övergång som inte finns med i tvättmaskins-modellen (se Figur 5.16). Efter att båda medvetna felen var implementerade, exekverades testfallet för att se om GW4E kan hitta fel i SUT samt hur verktyget beter sig i en sådan situation. I båda situationerna valde GW4E att hoppa över att testa de medvetna felen i SUT. Anledningen till att GW4E hoppade över de medvetvetna felet är okänt på grund av att koden för hur GW4E fungerar är dolt för användaren.

(39)

Figur 5.15: Första medvetna felet

Det första medvetna felet som implementerades i SUT bör GW4E hitta, eftersom felet var ett övergångsfel. Då Functional Test testar alla möjliga övergångar bör verktyget upptäcka att övergången är fel.

Figur 5.16: Andra medvetna felet

En tanke kring varför GW4E hoppar över de andra medvetna felet är på grund av att den implementerade övergången inte finns inkluderad i tvättmaskins-modellen. Detta gör att GW4E inte vet vad den medvetna felet ska jämföras med för resultat i modellen. Detta leder till att GW4E väljer att hoppa över de medvetna felen i SUT och inte exekvera den. För att kunna lösa den medvetna felet krävs ”Fully Specified” testing, vilket GW4E verka sakna.

5.4.3.4 Intervju

Under arbetets gång togs det kontakt med grundaren av GraphWalker, vilket gjordes för att kunna få en djupare förståelse över hur GraphWalker fungerar. Grundaren nämner att kon-ceptet med GraphWalker är att lägga test-designen i en modell, medan i ett manuellt test ska test-designerna ligga i koden vilket är hans tolkning av hur MBT fungerar. Genom att lägga fokuset på test-designer i en modell ger det möjligheten att kunna återanvända test-designen även om projektet skulle flytta över till ett annat verktyg. Det ger då andra projekt möjlighet att kunna återanvända test-designen, vilket gör det möjligt att kunna hoppa mellan olika verk-tyg. I andra testmetoder som manuell och automatiserad testning är det mycket mer krävande, ifall den skrivna testdesignen skulle behöva flyttas till ett annat verktyg eller skrivas om till ett annat programmeringsspråk, eftersom mycket mer resurser hade behövts i jämförelse med hur en övergång av verktyg fungerar för MBT.

(40)

Under mötets gång ledde diskussionen till varför GraphWalker inte hade en funktion som visar en rapport på vilka tester som har körts likt det JUnit använder. Svaret till denna frågan är att GraphWalker lägger mer fokus på om SUT fungerar och mindre fokus på vad som har ex-ekverats. Detta är också anledningen till att grundaren inte har utvecklat en funktion som ger utvecklaren en rapport av vad som har exekverats. Skulle utvecklaren vilja ha en funktion som sammanfattar resultaten av exekveringen får utvecklaren personligen lägga till en loggfunktion för att kunna få ut en exekverings-rapport.

Ett typiskt test inom GraphWalker är att verktyget försöker göra en hundraprocentig täckning av modellen och sedan visar om den lyckades eller inte. Jämfört med JUnit så kan GraphWalker tolkas som ett enda test som ger pass eller fail, medans i JUnit finns det lika många test med pass eller fail som antalet enhetstester som körts. Sammanfattningsvis är JUnit en testdrivare och GraphWalker ett test. Grundaren nämner också att GraphWalker används främst för system som består av olika tillstånd med olika krav som har en bestämd väg.

Anledningen till detta är för att företaget använder till stort del av continuous integration vilket kräver snabb återkoppling bland de arbetande vilket GraphWalker inte kan bidra med. När det gäller andra MBT verktyg i industrin är det många som hamnar i liknande situation vilket leder till att MBT verktyg används mindre. Tekniken MBT är mer populär inom testning som håller på med tester som körs under en längre tid och väldigt ofta, exempelvis telefonväx-lar och mobilstationer. Ett annat område som också använder MBT mycket är industrin där maskiner kan skapa fara för människan eftersom dessa system måste verkligen allt testas för att bevisa att systemet är säkert att använda för människan. Ett sådant systemet skulle kunna vara ett system i ett flygplan. För tester där produkten inte behöver så avancerad testning eller där produkten endast kräver tester som redan är kända räcker det oftast med automatiserad testning. Eftersom testfall i automatiserad testning kan skrivas specifika behöver man inte gå omvägen med MBT och skapa modeller för att göra testerna.

(41)

6.

Diskussion

6.1

Relaterat arbete

Böckerna och artiklarna som beskrivs i kapitlen 3 ”Relaterat arbete” beskriver hur MBT funge-rar i teorin och vilka verktyg som använts. Men dessa MBT-verktygen som nämns i böckerna och artiklarna är tyvärr inte längre tillgängliga att använda. Om verktygen fanns kvar hade vi kunnat jobba med verktyg som redan är testade vilket hade varit en fördel. Men istället fick vi använda verktyg som har brist på information och verktyg som inte har används i andra relaterade arbeten. Detta gjorde att arbetet blev svårare att genomföra.

Boken ”Practical model-based testing: a tools approach” [10] som nämns i kapitel 3 Relaterade arbetenbeskriver en mognadsskala för MBT-tekniken som visar vilken nivå ett MBT arbete ut-förs på. I skalan som består av nivå noll till fem ska ett arbete ligga på nivå tre eller fyra för att tekniken ska kunna fungera som teorin är tänkt. MBT-verktygerna som används i detta arbete begränsar oss till att ligga på mognadsgrad nivå ett och två, där problemet ligger i att gratis verktygen inte riktigt fungerar som MBT är tänkt vilket begränsar användarens möjlighet att kunna utföra MBT-tekniken fullt ut.

6.2

Metod

Genom att följa stegen i arbetsflödet (se Figur 4.1) i kapitel 4 ”Metod” har vi kunnat besvara frågeställningar för arbetet vilket visar att metoden fungerar bra. De problemen som uppstod under arbetet är inte kopplade till metoden som vi använt utan bristerna ligger istället i MBT verktygen och informationen om dem.

Stegen att välja verktyg och testkörning av verktygen är de två delarna som skilde sig mest ifrån vad som förväntades av arbetet eftersom mycket hinder uppstod vilket vi inte alls hade förväntat oss. Dels fanns det inte så många verktyg att välja bland som vi trott och bristerna i verktygen var fler än väntat. Även funktionerna av de olika verktygen var svåra att arbeta med då så mycket information saknas för att lyckas. Tanken var från början att använda en enkel modell för att sedan göra den mer komplex men det visade sig att de verktygen som använts inte alls kan göra det som MBT är tänkt att göra, nämligen att generera en mängd testfall.

(42)

6.3

Resultat

Målet med detta arbetet har varit att undersöka och testa tekniken MBT för att kunna besvara frågeställningarna som är formulerade i avsnitt 1.3 ”Frågeställningar”. Även om vi inte lycka-des med att generera testfall med de utvalda verktygen, så har vi fått en bättre förståelse av tekniken. Under arbetets gång har brister i MBT-verktygen upptäckts som skulle kunna vara anledningar till varför tekniken inte lyckats i industrin. En brist som påverkade just detta arbetet var att endast tre verktyg från Tabellen 5.1 ”Lista på MBT-verktyg” kunde användas, dessutom fungerade inget av verktygen enligt teorin för MBT. En annan brist som påverkade arbetet med alla de verktygen som användes var att mycket information saknades. Med saknad information menas t.ex att manual för verktygen saknar delar som hur installeringen av ett verktyg går till. Men den informationen som behövs mest men som inte fanns för exempelvis MBTsuite, är hur en modell ska vara uppbyggd och vad som är minimum i detaljnivå för modellen för att verktyget ska kunna generera testfall så som det ska.

Förutom resultaten från de olika verktygen blev intervjun som gjordes med GraphWalkers skapa-re en mycket viktig del av arbetet. Anledningen till att vi gjorde denna intervjun var på grund att GraphWalker gav oss resultat som inte riktigt stämmer överens med hur teorin av MBT fungerar. Vi tog då denna chansen till att ställa frågor om verktyget och dess roll i företaget han arbetar för. Här lyckades vi samla in viktig information för att dels kunna bekräfta att verktyget använts på rätt sätt och dessutom hjälper denna informationen oss att besvara våra frågeställningar.

(43)

7.

Slutsatser

7.1

Frågeställningar

7.1.1

Vad skulle kunna vara anledningen till att MBT inte lyckats i

industrin?

Vi har genom vår undersökning lyckats dra slutsatser till tre olika anledningar varför MBT inte lyckats i industrin.

Den första anledningen är att företag inte kommer upp på UML-modulerings nivå som MBT kräver [10]. Dels för att UML och modellerings kunskaperna inte är tillräckligt och att verktygen kan vara väldigt otydlig med hur detaljerad en modell måste vara. Exempelvis finns det verk-tyg som GraphWalker som används i detta arbete där verkverk-tyget kan förstå enkla modeller som endast har olika tillstånd och övergångar. Andra verktyg kräver modeller som har en djupare detaljnivå där man måste programmera och lägga in logiken i modellen.

Den andra anledningen är att MBT kräver mer tid än automatiserad testing för projekt med mindre system och enkla modeller som i vår arbete. Våra experiment visar att tar längre tid att skapa en modell och hela processen för MBT istället för att direkt skriva enkla testfall. I mindre system vet man oftast redan vilka tester som behöver göras och då går det snabbare att direkt skriva testfallen för dessa. För modellen som används i detta arbete hamnade vi också i denna situationen där testfallen var mycket lättare att skriva manuellt än att försöka få fram dem via olika MBT verktyg.

Den sista anledningen är att MBT tekniken fortfarande är omoget och möjligheten till att lära sig använda den är väldigt liten eftersom fungerade gratis verktyg är svåra att hitta. Gratis verktyg som fungerar behövs för att få fler att lära sig tekniken vilket ger en större möjlighet för vidare utveckling av tekniken. Det finns få arbeten som vi har stött på som visar resultat på hur arbetet gått tillväga när de använt sig av ett MBT-verktyg. Istället är det enbart dokumentation av teorin vilket inte är lika intressant som ett resultat skulle vara. Det enda stället som vi funnit resultat av MBT-verktyg är i några av böckerna som används i arbetet och som vi nämner i kapitel 3 ”Relaterade arbeten”. Problemet med verktygen som nämns i artiklarna och böckerna i Relaterade arbeten"är att de antingen kostar pengar eller är verktyg som inte längre existerar. Tekniken är fortfarande väldigt lite känt utanför industrin och det som finns inom industrin är inte dokumenterad för allmänheten. Eftersom så lite material för MBT existerar bidrar det till att spridningen och utvecklingen av tekniken går väldigt långsamt.

(44)

7.1.2

Vilka MBT verktyg som använder UML finns tillgängliga för

akademiskt syfte, dvs gratis att använda?

I avsnitt 5.2 ”Resultat litteratursökning” presenteras en lista med olika verktyg som ska finnas tillgängliga för MBT. Där listas alla verktygen upp för att sedan sorteras bort efter de avgräns-ningar arbetet har. Två av avgränsavgräns-ningarna som finns är att verktyget ska använda sig av UML och dessutom vara gratis. Slutligen var det bara tre verktyg kvar. Dessa tre verktygen är Cameo Enterprise Architecture, MBTsuite och GraphWalker GW4E.

7.1.3

Vad skiljer teorin från praktiken vid användning av MBT-verktyg?

Boken ”Practical Model-based testing: a tools approach” visar vid flera tillfällen att författarna lyckas få fram flertal testfall genom verktyget som de använder. Dessa testfall är tänkta att kunna ersätta testfallen som skrivs manuellt i till exempel JUnit. Men i praktiken har steget att generera dessa testfall inte fungerat i vår arbete. Teorin visar endast den positiva sidan av MBT och missar att beskriva de misslyckade fallen med tekniken.

En viktigt del som inte beskrivs noggrant i teorin är processen för att koppla sammans testfallet och SUT. Det vill säga bron som nämns i avsnitt 5.4.3.2 ”Bro mellan SUT och testfall”, vilket vi inser var ett viktig del i MBT-verktygen för att kunna exekvera testfall mot en SUT. I teoretiska arbeten nämns vid flera tillfällen att MBT-verktygen ger en rapport om vilka tester som har körts samt hur exekveringen har gått till, vilket vi saknade i MBT-verktygen som vi använde i detta arbetet.

7.2

Framtida arbete

(45)

8.

Referenser

[1] The Rvolution of Software Testing,”Qualitest”[Online] Available:

https://www.qualitestgroup.com/blog/future-of-software-testing/evolution- software-testing/ [vi-ewed 12 March 2019]

[2] What is Software Testing? Introduction, Definition, Basics & Types, ”GURU99” [Online] Available: https://www.guru99.com/software-testing- introduction-importance.html [viewed 12 March 2019]

[3] Grady Booch, James Rumbaugh, Ivar Jacobson, Unified Modeling Language User Guide, The, 2nd Edition, Addison-Wesley Professional (2005)

[4] The History of Software Testing, ”Testingreferences”[Online] Available: http://www.testingreferences.com/testinghistory.php [viewed 12 March 2019]

[5] Mark Blackburn, Robert Busser och Aaron Nauman, Why Model-Based Test Automation is Different and What You Should Know to Get Started, Software Productivity Consortium NFP (2004)

[6] Lars Matsson, Ralf Niska, MJUKVARUTESTNING Gör man som man ska eller göra man som man vill?, Luleå Tekniska Universitet (2003)

[7] Buggar kostar USA 550 miljarder om året, ComputerSweden,[Online] Available:

https://computersweden.idg.se/2.2683/1.40590/buggar-kostar-usa-550- miljarder-om-aret?query Text=mjukvarutestning [viewed 12 March 2019]

[8] The cost of change, hitta fel tidigt och rätta till dem till lägre kostnad!, ”Consid”[Online] Avai-lable: https://www.consid.se/newsroom/blogg/the-cost-of- change–hitta-fel-tidigt-och-ratta-till-dem-till-lagre-kostnad/ [viewed 12 March 2019]

[9] Proportion of budget allocated to quality assurance and spend from 2012 to 2018, ”statis-ta”[Online] Available: https://www.statista.com/statistics/500641/worldwide-qa-budget-allocation-as- percent-it-spend/ [viewed 12 March 2019]

[10] Mark Utting och Bruno Legeard, Practical model-based testing: a tools approach, Else-vier Inc (2007)

(46)

[11] Anne Kramer och Bruno Legeard, Model-based testing essentials: guide to ISTQB cer-tified model-based tester foundation level, John Wiley &; sons inc (2016)

[12] Easterbrook, S., Singer, J., Storey, M.-A., Damian, D.: Selecting Empirical Methods for Software Engineering Research. In: Guide to Advanced Empirical Software Engineering. pp. 285–311. Springer (2008)

[13] J.F. Nunamaker, M. Chen. ”Systems development in information systems research.” in Pro-ceedings of the Twenty-Third Annual Hawaii International Conference on System Sciences, [14] CE Controlled Experiment Definition, ”Biology Disctionary”, [Online] Available: https://biologydictionary.net/controlled-experiment/ [viewed 19 March 2019]

[15] Lightweight Model-Based Testing for Enterprise IT: https://ieeexplore.ieee.org/document/8411756 [16] JUnit 5 User Guide,”JUnit”,[Online] Available: https://junit.org/junit5/docs/current/user-guide/ [viewed 2 May 2019]

[17] Model-based testing(MBT), ”Zoltán Micskei”,[Online] Available:

Figure

Figur 2.1: Manuell testningsprocess [10]
Figur 2.2: MBT process [11]
Figur 2.3: De 14 olika diagramtyperna av UML [13]
Figur 3.1: Modellerings mognadsgrad[10]
+7

References

Related documents

De pekar på Östergötland och menar att de lyckades korta köerna när man införde vårdval 2013, men att hörselvården blivit betydligt sämre!. Bland annat pekar man på att

Med ordet ”hörselskadade” menar vi alla med hörsel- nedsättning, ljud över känslig het, tinnitus och Menières sjukdom samt för föräldrar och andra anhöriga – omkring en

Val av metod gjordes då studien syftade till att öka vår förståelse för hur olika diskurser genom socialt samspel konstrueras på Flashback Forum.. Fortsättningsvis gjordes

Skolan har ett viktigt uppdrag, där ämnet idrott och hälsa ska bidra till att eleverna utvecklar kunskaper, vanor och färdigheter som ett verktyg och grund för att påverka sin

Differensen av två kvoter divideras med summan av två produkter.. Detta problem har två

ståelse för psykoanalysen, är han också särskilt sysselsatt med striden mellan ande och natur i människans väsen, dessa krafter, som med hans egna ord alltid

Växtslag Sortförslag (favoritsorter står först i uppräkningen)

RSMH, Riksförbundet för social och mental hälsa, som företräder personer med bland annat bipolär sjukdom och psykossjukdom, har tvingats stänga sina omkring 100 lokala