• No results found

Ytterligare tester

In document Modell-Baserad Testning (Page 38-43)

5.4 Test av olika verktyg

5.4.3 GraphWalker

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.

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.

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.

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.

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.

7.

Slutsatser

7.1

Frågeställningar

7.1.1

Vad skulle kunna vara anledningen till att MBT inte lyckats i

In document Modell-Baserad Testning (Page 38-43)

Related documents