Ett ramverk för fördelning av arbetsinsats vid injektion och upptäckt av mjukvarufel

DEGREE PROJECT IN TECHNOLOGY, FIRST CYCLE, 15 CREDITS

STOCKHOLM, SWEDEN 2019

Ett ramverk för fördelning av

arbetsinsats vid injektion och

upptäckt av mjukvarufel

KTH Bachelor Thesis Report

Adam Ekström and Felix Magnell

Abstract

Software developers spend much time on finding and fixing software faults, both during the development and the maintanence of the system. Despite this, there hasn’t been much research done on the effort that these activities require.

It is important, both for developers and clients of software systems, to know how they can use their resources as efficiently as possible. Since software er- rors can cause high costs and can result in serious consequences, it is there- fore of interest to have a basis for how much time is spent on finding and fixing software errors.

Software Fault Injection (SFI) is a method of injecting artificial bugs into software, which is used to assess a program’s reliability. This study looks at the possibility of using SFI to develop a framework in order to measure the effort in finding and fixing errors. An existing software system, EXIT, was injected with a set of predefined errors. They were then detected and corrected with activities obtained from previous research conducted by other researchers.

The result was the Software Fault Injection/Detection Framework (SFIDF).

A framework that can be used to measure the time distribution for injection, detection and the fixing of software errors.

Keywords

Effort, Effort distribubtion, Software Fault Injection, Software Fault Detec-

tion, Framework

Abstract

Mjukvaruutvecklare spenderar mycket tid på att hitta och åtgärda defekter i mjukvara, både under utvecklandet och underhållandet av system. Trots detta har det inte forskats särskilt mycket på insatsen som dessa aktiviteter kräver.

Det är viktigt både för utvecklare och beställare av mjukvarusystem att veta hur de kan disponera sina resurser så effektivt som möjligt. Eftersom mjuk- varufel kan orsaka stora kostnader och resultera i allvarliga konsekvenser, är det av intresse att ha underlag för hur mycket tid som går åt till att hitta och åtgärda mjukvarufel.

Software Fault Injection (SFI) är en metod för att injicera artificiella fel i mjukvara, som används för att bedöma ett programs pålitlighet. I denna studie har vi med hjälp av SFI fokuserat på att ta fram ett ramverk för att mäta insatsen som krävs för att hitta och åtgärda fel. Vi använde oss av ett befintligt mjukvarusystem, EXIT, som injicerades med en uppsättning fördefinierade fel. Dessa upptäcktes och åtgärdades med aktiviteter hämtat från tidigare forskning.

Resultatet blev Software Fault Injection Detection Framework (SFIDF). Ett ramverk som kan användas för att mäta insatsdistributionen för både in- jicering, upptäckt och åtgärdande av fel i mjukvara.

Nyckelord

Insats, Insatsdistribution, Software Fault Injection, Software Fault Detec-

tion, Ramverk

Acknowledgements

Vi vill tacka Mira Kajka-Mattson för att hon tagit sig tid att komma med råd

och värdefull feedback.

Authors

Adam Ekström <adaeks@kth.se> and Felix Magnell <fmagnell@kth.se>

Information and Communication Technology KTH Royal Institute of Technology

Place for Project

Stockholm, Sweden

Examiner

Anders Sjögren

KTH Royal Institute of Technology

Supervisor

Mira Kajko-Mattson

KTH Royal Institute of Technology

Contents

1 Introduktion 1

1.1 Bakgrund . . . . 2

1.2 Problem . . . . 2

1.3 Syfte . . . . 3

1.4 Mål . . . . 3

1.5 Samhällsnytta, Etik och Hållbarhet . . . . 3

1.6 Metodologi / Metoder . . . . 3

1.7 Avgränsningar . . . . 4

1.8 Disposition . . . . 4

2 Teoretisk bakgrund 6 2.1 Arbetsinsats . . . . 6

2.2 Mjukvarufel . . . . 7

2.3 Problemrapport . . . 10

2.4 Mjukvarutestning . . . 13

2.5 Fault Injection . . . 18

2.6 EXIT . . . 21

2.7 Metod . . . 22

3 Forskningsmetoder och förfaranden 26 3.1 Forskningsstrategi . . . 26

3.2 Forskningsmetod . . . 27

3.3 Arbetsmetod . . . 27

3.4 Identifiera och beskriv problemet . . . 28

3.5 Datainhämtning . . . 28

3.6 Förklara och lös problemet . . . 30

3.7 Tillämpad forskningsstrategi . . . 35

3.8 Kvalitetssäkring . . . 35

4 Utförande 38

4.1 EXIT . . . 38

4.2 Experimentell uppställning . . . 38

4.3 Roller . . . 40

4.4 Iterationscykel . . . 40

4.5 Iterationsexempel . . . 41

4.6 Utvärdering och förslag på uppdatering av ramverk . . . 44

5 Resultat 46 5.1 Arbetsinsats för upptäckt av fel . . . 46

5.2 Arbetsinsats för injektion av fel . . . 47

5.3 Ramverket efter litteraturstudien . . . 48

5.4 Uppdaterat ramverk . . . 48

6 Diskussion 51 6.1 Reflektion kring projektet . . . 51

6.2 Ramverk . . . 52

6.3 Injiceringsmetoden . . . 52

6.4 Upptäcktsmetoden . . . 53

6.5 Roller . . . 53

6.6 Erfarenhet . . . 53

6.7 Validitet . . . 54

6.8 Framtida arbete . . . 55

Referenser 56

1 Introduktion

I takt med att fler och fler områden datoriseras och blir mer komplexa, får konsekvenserna av mjukvarufel allt större betydelse [1]. När mjukvara in- tegreras med allt mer säkerhetskritisk utrustning är det viktigt att hitta fel innan mjukvaran används. Vi blir ständigt påminda i media om katastrofer orsakade av fel i mjukvaran. Ett aktuellt exempel är Boeings 737-max-plan som orsakade två dödliga krascher inom loppet av fem månader [2]. Mycket tyder på att båda krascherna orsakades av fel i mjukvaran i flygplanens anti- stalling-system, vilket ska förhindra planet från att peka med nosen uppåt i för stor vinkel. Vid båda olyckorna tvingade systemet ner nosen upprepade gånger trots att planen inte stegrade. En sannolik anledning är att de sen- sorer som skulle mäta planets vinkel gav fel värden [3].

I sammanhanget ska man skilja på fel i hårdvara och fel i mjukvara. Hård- varufel uppstår som ett resultat av tillverkningsfel, förslitning och/eller påverkan av yttre faktorer som strålning eller korrosion. Mjukvarufel uppstår vid fel i kodlogiken eller genom att felaktig data matas in i programmet, eller en kombination av dessa faktorer. Det kan finnas flera anledningar till att kod är logiskt felaktig. Den främsta anledningen är att programmet är felkodat, eller att specifikationen är bristfällig. Att felaktig data matas in i systemet beror främst på antingen mänskliga fel när systemet är i drift, eller på fel i ex- tern hård-eller mjukvara som ansvarar för inmatning till systemet [1].

Ett problem när man testar mjukvara är att fel som kan leda till allvarliga

konsekvenser och dessutom är sällsynta, ofta är svåra att upptäcka genom

testning och andra typer av analysmetoder. Man förlitar sig oftast på att fel

som ger allvarliga konsekvenser hittas innan mjukvaran släpps, men troligtvis

känner man inte till att de existerar [1].

1.1 Bakgrund

Att mäta arbetsinsatsen för injicering och upptäckt av mjukvarufel (defekter, buggar) innebär att man mäter tidsåtgången för de aktiviteter som utförs un- der de båda processerna. Arbetsinsatsen är de mantimmar som läggs ner för de olika aktiviteterna som utförs för att injicera samt upptäcka mjukvarufel [4].

Ett tillvägagångssätt för att injicera fel i mjukvara är Software Fault Injec- tion (SFI). SFI är en teknik för att emulera mjukvarufel som används för att bedöma pålitligheten i ett program eller system. Detta kan bland annat ske genom att källkoden injiceras med artificiella fel - det kan vara allt från att ändra värdet av en variabel till att modifiera hur en algoritm fungerar [1][5].

Flera tekniker har utvecklats för att upptäckta mjukvarufel. En väldoku- menterad metod är mjukvarutestning, som innefattar en uppsättning steg att genomföra för att hitta defekter. Mjukvarutestning görs antingen genom automatiserade verktyg, eller genom att manuellt söka efter brister för att undersöka om systemet uppfyller kravspecifikationerna [6].

1.2 Problem

Mjukvaruutvecklare ägnar en signifikant mängd tid åt att hitta och åtgärda defekter, både under utvecklandet och underhållandet av systemet. Trots detta har arbetsinsatsen för dessa aktiviteter inte adresserats. Därav strävar undersökningen mot att besvara:

Hur fördelas arbetsinsatsen för injicering och upptäckt av mjukvarufel?

1.3 Syfte

Syftet med projektet är att presentera ett ramverk som kan användas för att mäta arbetsinsatsen för injicering och upptäckt av mjukvarufel.

1.4 Mål

Det huvudsakliga målet är att presentera ett ramverk som kan användas för att mäta arbetsinsatsdistribution för injicering och upptäckt av mjuk- varufel.

Ett sekundärt mål är att presentera arbetsinsatsdistributionen för de olika aktiviteter som utfördes då ramverket applicerades på ett givet målsystemet.

1.5 Samhällsnytta, Etik och Hållbarhet

För utvecklare och beställare av mjukvarusystem är det viktigt att veta hur man ska disponera sina resurser så effektivt som möjligt [7]. Eftersom mjuk- varufel orsakar stora kostnader och kan resultera i allvarliga konsekvenser är det därför av intresse att ha underlag för hur mycket tid som går åt till att hitta och injicera mjukvarufel [1][8].

Med ramverket presenteras ett tillvägagångssätt för att mäta arbetsinsatsen för injicering och upptäckt av fel, som förhoppningsvis är så pass effektivt att det kan användas som ett verktyg för fortsatta studier av arbetsinsatsdis- tribution.

1.6 Metodologi / Metoder

I vår studie har vi valt att använda oss av en kvalitativ forskningsmetod. Vårt

första steg har varit att göra en litteraturstudie, för att undersöka befintliga

metoder för att injicera och upptäcka fel i mjukvara. Vi undersökte också

vilka typer av fel som var vanligt förekommande. Efter det utformade vi en metod i två steg: en för injicering av fel och en för upptäckt av fel. Detta var det första steget i upprättandet av vårt ramverk. När grunden till ramverket var lagd påbörjade vi våra försök, de s.k. iterationerna. Utifrån dessa iter- ationer optimerade vi ramverket efter hand för att effektivisera processen, vilket ledde till vårt slutgiltiga ramverk.

1.7 Avgränsningar

När ramverket utvecklades, applicerades och uppdaterades utefter ett mål- system, fanns det ingen garanti för att det skulle fungera lika effektivt på andra typer av mjukvarusystem. Den migrerade versionen av EXIT var inte helt färdigutvecklad, vilket begränsade programmets funktionalitet och hur vårt ramverk användes.

1.8 Disposition

Rapportens struktur är följande:

• I kapitel 2 presenteras djupare information om den teoretiska bak- grunden som uppsatsen vilar sig mot. Här presenteras information om vad ett fel är, olika typer av fel, varför de uppstår samt metoder för hur de kan upptäckas och injiceras.

• I kapitel 3 presenteras de metodologier och metoder som användes i rapporten.

• I kapitel 4 presenteras tillvägagångssättet för hur metoderna för att in- jicera och upptäcka fel utvecklades, samt hur ramverket applicerades på målsystem.

• I kapitel 5 presenteras resultaten av ramverkets applicering på målsys-

temet.

• I kapitel 6 diskuteras resultaten och framtida arbete.

2 Teoretisk bakgrund

Det här kapitlet beskriver den teoretiska bakgrunden till denna studie.

I avsnitt 2.1 presenteras arbetsinsats som är en viktig del av vårt under- sökande arbete. I avsnitt 2.2 presenteras mjukvarufel, definitioner av mjuk- varufel och olika typer av fel. I avsnitt 2.3 förklaras vad en problemrapport är. I avsnitt 2.4 presenteras olika metoder för mjukvarutestning. I avsnitt 2.5 presenteras läsaren för felinjicering. I avsnitt 2.6 presenteras målsys- temet EXIT som ramverket applicerades på. I avsnitt 2.7 presenteras teori om metoder och metodologier.

2.1 Arbetsinsats

Kostnaden för mjukvarufel kan snabbt bli väldigt hög, inte bara för att det är dyrt att hitta och åtgärda fel, utan också för att konsekvenserna ofta blir dyra driftstopp eller att hela system förstörs [9].

Enligt en rapport från Cambridge University [10], lägger mjukvaruutveck- lare i snitt 50% av sin tid på att hitta och åtgärda fel, vilket innebär en kostnad globalt på uppskattningsvis 312 miljarder dollar årligen. En annan studie visar att mellan 60 och 80% av den totala utvecklingskostnaden läggs på underhåll och omarbetning av mjukvara [9]. Enheten för kostnad uttrycks oftast i någon valuta. Arbetsinsats, som är en del av kostnaden, syftar på de mantimmar som läggs ner på aktiviteter eller uppgifter för att kunna lever- era eller underhålla en specifik produkt eller tjänst så att det lever upp till dess specifikationer [4].

Arbetsinsatsen för att leverera eller underhålla en produkt eller tjänst kan mätas på olika sätt, bl.a. [9][11]:

• Antal persontimmar per dag

• Antal timmar i förhållande till antal kodinstruktioner

• Antal kalenderdagar som en problemrapport varit öppen fram tills att problem åtgärdats.

Att mäta arbetsinsats i antalet kalenderdagar är inte att rekommendera då det introducerar partiskhet, vilket kan leda till felaktiga resultat. Detta då utvecklare kanske inte arbetar med att åtgärda problemet utan uppehåll från att problemrapporten öppnades.

För att undvika partiska resultat förespråkar Hamill m.fl. att arbetsinsats ska mätas endast baserat på faktiska timmar som läggs ner på att åtgärda problemet [9].

2.2 Mjukvarufel

I mitten av 1990 byggdes rymdfarkosten Mars Climate Orbiter för att skickas upp i Mars omloppsbana och studera klimatet där. Farkosten var utvecklad med den tidens mest avancerade teknik och produktionskostnaderna uppg- ick till 125 miljoner dollar. I december 1998 sändes sonden upp i rymden och i september 1999 närmade den sig Mars för att lägga sig i omlopps- banan. Plötsligt bröts radiokontakten och sonden förklarades saknad två dagar senare. Det visade sig att den hade kommit för nära Mars, vilket re- sulterade i att den brann upp i atmosfären. Det som orsakade olyckan var ett mjukvarufel. NASA som utvecklade rymdsonden hade beställt komplet- terande mjukvara av ett annat företag som gjorde sina beräkningar i det en- gelska måttsystemet med inches, feet och pounds. När detta sattes ihop med NASA’s mjukvara som förväntade sig SI-enheter blev det fel i beräkningarna [12].

Exemplet med NASA’s rymdfarkost visar hur viktigt det är med en tydlig

specifikation av mjukvaran. Specifikationen bestämmer nämligen vad som

är värt att lägga testtid på. Det är svårt om inte omöjligt att hålla en mjukvara

fri från defekter. Däremot är det enklare att testa om allt fungerar som det

ska om man specificerar förväntad input och output. Många analyserings-

och testningstekniker har som mål att upptäcka fel som sen kan åtgärdas.

Att hitta och ta bort fel under utvecklingen hjälper till att öka kvalitén hos slutprodukten, men det är samtidigt svårt att garantera att systemet är helt fritt från defekter när den släpps. Skulle man fortsätta att leta efter defekter tills alla fel är borttagna skulle man få testa i all evighet [13].

2.2.1 Definitioner av fel

Det finns flera olika typer av fel som kan inträffa i ett mjukvaruprogram. I denna rapport används de definitioner som presenteras i ISO/IEC/IEEE24765 standard: Systems and software engineering — Vocabulary [14].

Ett fel i mjukvaran kan antingen vara: error, failure eller fault med kon- sekvensen att systemet agerar inkorrekt och/eller oväntat, eller att det pro- ducerar felaktiga värden.

Ett fault (synonymt med bugg) är en oavsiktligt händelse eller ett villkor som när det inträffar kan resultera i att systemet eller komponenten inte agerar enligt specifikationerna [8][14].

Orsaken till ett fault kallas error. Error är ett resultat av mänsklig faktor som:

slarv vid programmering, okunskap om specifikationen, felaktiga speci- fikationer eller andra typer av misstag [14].

Ett failure är ett systems eller en komponents oförmåga att utföra de funk- tioner som är specificerade. Det är ett inkorrekt beteende som är observer- bart. Varje failure är en följd av ett eller flera faults. Även om ett failure or- sakas av faults behöver faults inte nödvändigtvis resultera i ett failure. Detta då villkoren för ett fault som resulterar i ett failure kanske aldrig uppfylls utan ligger latent [8][14].

Defekt är en samlingsterm som används för att referera både till ett fault eller failure [14].

För att illustrera begreppen error, failure och fault kan vi utgå från följande

funktion som har specifikationerna:

• Ett heltal som inparameter

• Ett heltal som är det dubblerade värdet av inparametern som utparam- eter

Funktionen ser ut som följande:

doubleValue ( int i ) { int r e s u l t ; r e s u l t = i * i ; return r e s u l t ; }

Om funktionen doubleValue anropas med inparameter med värdet 3, kom- mer returnvärdet att vara 9. Detta är ett exempel på ett failure. Funktio- nen utför inte det som är specificerat och det är observerbart genom att det förväntade värdet av utparametern skiljer sig mot det faktiska, 2•3 ̸= 9.

Orsaken till detta failure är kodinstruktionen result = i•i;. Istället för att dubblera inparameterns värde, kvadrerar den det, dvs ett fault.

Varför detta fault uppstod kan exempelvis vara att programmeraren av funk- tionen inte vet hur ett värde dubbleras eller förstod sig inte på specifikation- erna för funktionen, varvid det uppstod ett error.

2.2.2 Vanligt förekommande fel

Studier visar att det finns vissa typer av faults som förekommer oftare än

andra, dessa presenteras i tabell 2.1 [15][16].

Typ av fault Beskrivning

MFC Missing function call

MVIV Missing variable initialization using a value MVAV Missing variable assignment using a value MVAE Missing variable assignment with an expression MIA Missing IF construct around statements

MIFS Missing IF construct + statements

MIEB Missing IF construct + statements + ELSE construct MLAC Missing AND in expression used as branch condition MLOC Missing OR in expression used as branch condition MLPA Missing small and localized part of the algorithm WVAV Wrong value assigned to variable

WPFV Wrong variable used in parameter of function call WAEP Wrong arithmetic expression in function call parameter

Table 2.1: Förekommande fel [15]

För att se konkreta exempel på de olika felen se bilaga A.

2.3 Problemrapport

En problemrapport är ett dokument som identifierar och beskriver en defekt som har upptäckts under en mjukvaras testfaser. Syftet med rapporten är att på ett så tydligt sätt som möjligt beskriva defekten för att utvecklare ska kunna återskapa och åtgärda defekten [17].

Inom mjukvaruorganisationer skiljer man på externa och interna problem- rapporter. Externa problemrapporter är de rapporter som skickas in av ex- terna slutanvändare av mjukvaran.

Interna problemrapporter är de rapporter som skickas in av personer inom organisationen. Det kan bl.a. vara från utvecklare, testare eller från de som underhåller systemet.

Det är viktigt att skilja på dessa typer av problemrapporter. Målet är att

upptäcka så många defekter som möjligt innan lansering av mjukvaran. An-

ledningen till detta är att externa problemrapporter är mer kostsamma än

interna, då det i många fall är flera underhålls- och kundorganisationer in- blandade i att hantera dem.

Vissa problem kan dessutom leda till att ändringar behöver göras i flera ut- gåvor och att alla utgåvor behöver analyseras, testas och slutligen levereras till kunden på nytt.

På grund av detta bör mjukvaruorganisationer sträva efter att minimera an- talet externa problemrapporter och maximera antalet interna [18].

Hos de flesta företag används ett verktyg för problemrapportering, där infor- mationen som bifogas kan skilja sig från företag till företag. Generellt sett brukar följande information dokumenteras [17]:

• ID

• Projekt

• Produkt

• Titel

• Problembeskrivning

• Steg för att återskapa problemet

• Förväntat resultat

• Faktiskt resultat

När ett problem väl rapporteras är det viktigt att det dokumenteras effek- tivt. Informationen som bifogas bör vara tydligt specificerad för att undvika otydligheter för den som tar emot rapporten och ska återskapa problemet [17].

Ett exempel på hur en problemrapport ser ut är följande från ABB Robotics

AB [18]:

Figur 2.1: Problemrapport ABB Robotics AB [18]

2.4 Mjukvarutestning

Mjukvarutestning innefattar en uppsättning steg med målet att hitta defek- ter i mjukvara. Mjukvarutestning är en nödvändighet för att kunna utvärdera mjukvarans kvalité. En effektivare teknik för mjukvarutestning ger generellt stora vinster i form av högre kvalité på mjukvaran, nöjdare användare, lägre underhållskostnader och tillförlitligare prestanda. Mjukvarutestning är en av de viktigaste faserna i mjukvarans livscykel. Ofta läggs mellan en tred- jedel och hälften av all utvecklingstid på testning, men ännu mer tid kan gå åt för system som kräver hög tillförlitlighet [6].

Mjukvarutestning är vidare en process för att utvärdera systemets krav som görs antingen genom automatiserade verktyg eller genom att manuellt efter- söka brister i syfte att undersöka om systemet uppfyller kravspecifikatio- nen och för att avgöra skillnader mellan förväntade och faktiska resultat [6].

2.4.1 Problemhanteringsprocess

Mira Kajko Mattson beskriver i sin avhandling en process för problemhanter- ing på ett större företag [19]. Processen beskriver olika faser och roller för problemhantering av mjukvara inom en organisation.

2.4.2 Roller

• Problemrapport-ägaren är ansvarig för en viss produkt eller kompo- nent i ett mjukvarusystem. Problemrapport-ägaren kontrollerar och administrerar hela processen för problemhanteringen för sin produkt eller komponent [19].

• Problemrapports-ingenjören utför ett antal aktiviteter som vanligtvis

är designade av Problemrapport-ägaren för att undersöka ett prob-

lem, identifiera orsaken till problem, designa lösningar till ett problem

och att implementera dessa[19].

• Underhålls-ingenjören står för underhåll och optimering av en viss produkt eller flera produkter och komponenter [19].

Problemhanteringsprocessen för mjukvara är fokuserad på att samla infor- mation om IT-relaterade problem, identifiera defekter, åtgärda defekter samt att förhindra att problem och defekter i mjukvaran uppstår [19]. Problemhanter- ingsprocessen är indelad i ett antal faser som är:

• Problemrapporterings-fas

I denna fas rapporteras problem till underhållsavdelningen eller motsvarande inom organisationen [19].

• Problemanalysfas

I denna fas försöker underhållsingenjörer att återskapa problemen och samtidigt identifiera deras orsak. I vissa fall försöker de även hitta grundproblemet som kan vara brister i utvecklings- eller underhåll- sprocessen eller brister som kan kopplas till den rapporterade mjuk- varan [19]. Denna analysfas delas in i följande subfaser:

– Problemanalysfas I

I denna subfas fastställs en preliminär kvalitetskontroll av prob- lemrapporten för att kunna tilldela rapporten till ett relevant un- derhållsteam [19].

– Problemanalysfas II

I denna subfas har ett lämpligt underhållsteam och dess Problemrapport- ägare blivit tilldelade problemet. Problemrapport-ägaren ad-

ministrerar det rapporterade problemet. Målet i detta stadie är att göra en preliminär analys av problemrapporten för att avgöra om rapporten har hamnat hos rätt underhållsteam och för att starta planeringen av problemanalysen. Här utses även en lämplig un- derhållsingenjör som får ta del av problemrapporten [19].

– Problemanalysfas III

I denna subfas försöker underhållsingenjören bekräfta mjukvarufelet som beskrivs i problemrapporten. De exakta stegen som tas i denna fas kan variera beroende på vilken typ av fel det handlar om. Hu- vudfokus är att återskapa problemet, huvudsakligen genom att ex- ekvera koden. Problemrapporten status ändras då till ”Problem investigated”, problem undersökt [19].

– Problemanalysfas IV

I denna subfas försöker problemrapports-ingenjören att identi- fiera underliggande orsaker till det rapporterade problemet, s.k.

defekter. Defekter kan uppstå i alla typer av systemdokumenta- tion (krav, design, test case, specifikationer, mjukvarukod, använ- darmanual, och annat) [19].

– Problemanalysfas V

Under den femte och sista subfasen inom analysfasen försöker problemrapports-ingenjören att identifiera grundproblemet till mjuk- varuproblemet. Som tidigast bör analys av grundproblemet ske efter subfas IV. Det kan däremot ske senare, när problemet har åt- gärdats. Målet är att identifiera de brister som har orsakat mjuk- varufelet [19].

• Problemlösningfas

I denna fas föreslår underhållsingenjören en eller flera lösningar till mjukvaruproblemet, en plan för att genomföra dessa lösningar samt en presentation av lösningar tillsammans med planen till ansvariga.

Denna fas delas i likhet med Problemanalysfasen in i subfaser [19].

– Design av ändringar

I denna subfas designar problemrapports-ingenjören en eller flera

lösningar av det rapporterade mjukvaruproblemet och skapar en

plan för att åtgärda dem. För varje lösning skapas en preliminär

evaluering som ska hjälpa ingenjören att rangordna lösningar och

hitta den optimala lösningen. Varje lösning är sen antingen in-

spekterad eller informellt undersökt [19].

– Beslut om ändringar

I denna subfas presenteras lösningsförslag till ansvariga inom or- ganisationen som tar ett beslut om den optimala lösningen [19].

– Implementation av ändringar

I denna subfas implementeras lämpliga ändringar i mjukvarusys- temet. Ändringarna identifieras, dokumenteras och undersöks på nytt [19].

2.4.3 Corrective maintenance testing

Corrective maintenance testing är en process för att testa en mjukvara innan några ändringar görs för att åtgärda felet. Corrective maintenance testing in- nefattar två faser. Dessa är: pre change-testing och post change-testing. Un- der pre change-fasen undersöks och bekräftas ett rapporterat problem. Un- der post change-fasen undersöks om det rapporterade problemet har blivit åtgärdat på ett korrekt sätt under pre change-testing [20].

2.4.4 Pre change-testing

Testning under pre change-fasen avser processen att undersöka och bekräfta

ett rapporterat problem. Aktiviteter som utförs inom pre change-testning är

typiskt för problemhantering. Pre change-testing bygger på tre nivåer i en

support-kedja. Dessa är: 1) kunder som använder mjukvaran, 2) front-end

support som har direktkontakt med användare, 3) back-end support som

utvecklar och underhåller mjukvaran. Processen för pre change-testing kan

delas in i följande steg som väljs från en aktivitetslista [20] Figur 2.2 :

Figur 2.2: Aktivitetslista från Kajko Mattsons Pre change-testing [20]

• Så fort ett problem blir inrapporterat till front-end supporten, under-

söker dess personal problemet för att bekräfta det. Denna undersökn-

ing sker genom att supporten utvecklar ett eller flera tester och därför

inte kan undersöka bakomliggande orsaker. En eller flera av dessa test- fall resulterar i att problemet då uppstår. Innan personalen tar fram testfall ska de söka internt för att undersöka om problemet redan har registrerats av organisationen [20].

• Valet av kvarvarande aktiviteter beror på om problemet redan har fån- gats upp av organisationen. Om det inte finns någon information om problemet, kan det antas att problemet är okänt för organisationen och aktiviteter för att undersöka ett unikt fel tillämpas [20].

• När ett unikt mjukvarufel undersöks, måste supporten välja en lämplig version av mjukvaran som ska testas. Även om problemet rapporter- ades för en specifik version av mjukvaran bör supporten säkerställa att problemet inte existerar i en tidigare eller senare version. Detta gör att supporten måste skapa flera test-miljöer för flera versioner av mjukvaran. Efter att testmiljöerna har förberetts testas mjukvaran tills problemet kan återskapas. Om testerna var lyckade kan problembeskrivnin- gen uppdateras och testresultaten sparas för att skicka vidare till back end-supporten som då ska åtgärda problemet [20].

2.5 Fault Injection

2.5.1 Introduktion

Utvecklingen av högkvalitativ mjukvara har blivit alltmer viktigt för samhäl- let. Mjukvara används till fler kritiska applikationer, där konsekvenserna av fel och driftstopp blir allvarligare än tidigare. Hårdvarufältet har varit framgångsrikt i utvecklingen av tillförlitlighetsmodeller, vilket har lett till att man kan förutsäga hur länge en hårdvarukomponent kommer att fungera.

Detta har väckt ett intresse bland mjukvaruutvecklare att utforma liknande

modeller. Sådana modeller skulle kunna göra att man kan förutspå pålit-

ligheten hos mjukvara innan den släpps, med vetskapen om att den når upp

till sitt syfte och att den är säker att använda [21].

2.5.2 Hardware fault injection

När man ska injicera fel i hårdvara använder man ytterligare hårdvara för att introducera fel i målsystemets hårdvara. Detta kallas Hardware fault in- jection (HFI) som kan delas in i två kategorier:

• Hardware fault injection with contact

Detta innebär att den som ska injicera fel har direkt åtkomst till hård- varan samt spänning eller ström i hårdvarans kretskort.

• Hardware fault injection without contact

Detta betyder att den som injicerar fel inte har en direkt åtkomst till målsystemets hårdvara. Istället utsätts hårdvaran för ett fysiskt fenomen såsom joniserande strålning eller elektromagnetisk störning, vilket or- sakar strömförändringar inuti målhårdvarans kretskort [22].

2.5.3 Software Fault Injection

Software Fault Injection (SFI) är en metod för att bedöma programvarans pålitlighet. Detta sker genom att på ett realistiskt sätt emulera mjukvarufel.

SFI är relevant i sammanhanget eftersom mjukvarufel är en av de främsta or- sakerna till systemfel [23]. Injicering av hårdvarufel är en beprövad metod för att utvärdera hur datorsystem hanterar och motstår felaktiga tillstånd [24]. Däremot är emulering av programvarufel i mjukvara ett relativt out- forskat område [5].

Möjligheten att emulera mjukvarufel med hjälp av mjukvaruinjektion ökar

relevansen och användbarheten av SFI för validering och för att öka feltoler-

ansen i datorsystem. Att på ett pricksäkert sätt kunna emulera mjukvarufel

gör det möjligt att hitta dolda defekter i ett system. Det är svårt att garantera

att en komplex mjukvara är fri från defekter, trots att man har omfattande

testningsmodeller. Detta gör SFI till ett möjligt komplement till andra tester

[5]. Målet med SFI är att snabba upp felfrekvensen i en mjukvara för att se

hur den reagerar. Det finns i huvudsak tre fördelar med SFI:

• En förståelse för effekterna av riktiga fel

• Återkoppling för systemkorrigering eller förbättring

• En prognos av förväntat systembeteende.

SFI är inte helt olik HFI. Den främsta skillnaden mellan SFI och HFI är målet av felinjiceringen och typen av fel/störningar som injiceras [1].

Till skillnad från fault injection i hårdvara där man börjar tidigt i design- fasen, applicerar man SFI senare i produktionen. SFI bör göras innan mjuk- varan släpps, men nära i tid till att den ska släppas. Det är för tidigt att in- jicera fel när det fortfarande sker stora modifikationer av mjukvaran [1].

Exempel på SFI: Ett fel A injiceras i mjukvaran som kör testfall B. Program- met ändrar då beteende från C till D, vilket kan sägas vara en precis förän- dring av systemet. Nästa steg för testaren är då att överväga om förekomsten av tillstånd D kan ske naturligt för ett annat testfall än B utan att fel A in- jicerats. Representerar A ett fel som faktiskt kan uppstå? Det är frågor som dessa som måste besvaras innan man med bakgrund av resultaten modi- fierar mjukvaran för att öka feltoleransen och därmed pålitligheten [1].

För att erhålla meningsfulla resultat är det viktigt att de injicerade felen efterliknar riktiga fel som kan uppstå i mjukvaran under utvecklingen [5].

Det finns tre olika tillvägagångssätt som används för att injicera fel i mjuk- vara [1]:

• Lägga till kod målsystemet

• Ändra befintlig kod i målsystemet

• Ta bort befintlig kod i målsystemet

Målet med samtliga tillvägagångssätt är att det ska resultera i att program- mets utdata eller interna tillstånd ändrar sig för minst ett av valda testfall.

Utan detta krav saknar effekten av de injicerade felen värde [1].

Metoderna för felinjektioner kan kategoriseras efter det tillfälle då injektio-

nen äger rum, antingen under kompileringstid eller exekveringstid [22][25].

Felinjektioner under kompileringstid innebär att programinstruktioner än- dras innan programmet exekveras. Detta sker genom att felen injiceras i källkoden. Ett sätt att injicera dessa fel på är genom kodmutation, vilket innebär att man ändrar befintlig kod eller lägger till nya kodinstruktioner i mjukvaran [1][26].

Ett exempel på en kodinstruktion:

a = a + 1; (1)

Kan muteras till följande:

a = a + 10; (2)

Efter kodmutationen kommer variabeln a att tilldelas ett felaktigt värde vilket riskerar att resultera i ett felaktigt tillstånd för systemet eller inkorrekt ut- data [1].

För att injicera fel i programmet under exekveringstiden behöver man an- vända sig av triggermekanismer. Vanligt förekommande triggermekanismer är time-out, exception/trap och code insertion. Injektionen kommer då att äga rum först när mekanismen triggas [25].

För att effektivisera SFI har det utvecklats många olika verktyg för att au- tomatisera processen, både kommersiella och kostnadsfria. Ett av dessa verktyg är Ferrari som utvecklades vid University of Texas vilket använder sig av mjukvaru-traps för att injicera faults i CPU, minne och bussar [25][27].

Ett annat exempel är DOCTOR som tillåter injektioner av faults i CPU, minne och nätverk [25][28].

2.6 EXIT

Mjukvaran som SFI kommer att utföras på i detta arbete är EXIT - Eximi-

natorer inom Informationsteknik, vilket är ett system utvecklat i program-

meringsspråket PHP. EXIT utvecklades som ett kandidatexamensarbete på

KTH av Sara Hägglund och Linda Eriksson. Skaparna beskriver program- met enligt följande [29]:

EXIT är ett system där studierektorer kan lägga till budgetår och examinatorer. Genom att sedan specificera hur mycket ar- betstid varje examinator skall lägga på handledning vid exam- ensarbeten gör studierektorn det möjligt för examinatorerna att hålla reda på hur mycket tid de förväntas lägga på handledning och hur mycket tid de har kvar för det aktuella budgetåret. Även studenter har nytta av systemet eftersom de kan se vilka exami- natorer som finns tillgängliga när de söker examensarbeten.

EXIT som utvecklades 2011 har inte underhållts efter sin introduktion, vilket har lett till att programmet inte längre är användbart. Därför kommer vi att använda oss av en migrerad version som skapades av Cornelis Strohkirch och Marcus Österberg under ett kanditatexamensarbete skrivet år 2019 [30].

Vid migrerandet av systemet övergick koden från att vara skriven i PHP till att istället använda Javascript.

2.6.1 Javascript

JavaScript är ett objektorienterat programmeringsspråk som är mest känt som ”skriptspråket för webben”, men används också för ickewebb-ändamål.

JavaScript körs på webbsidans klientsida, som kan användas för att designa / programmera hur webbsidorna beter sig vid interaktion. JavaScript är ett skriptspråk som används i stor utsträckning för att kontrollera webbsidors beteende [31].

2.7 Metod

Det finns huvudsakligen två kategorier av forskningsmetoder: kvantitativ

forskning och kvalitativ forskning. Dessa två metoder appliceras på pro-

jekt som är antingen numeriska eller icke-numeriska. En av forskningsme-

toderna måste väljas, som då avgör om projektet är av kvantitativ eller kval- itativ karaktär [32].

2.7.1 Kvantitativ forskning

Kvantitativ forskning bygger på objektiva mätningar och statistik, genom vilka det går att verifiera eller falsifiera teorier och hypoteser. Ett krav för en kvalitativ hypotes är att den måste vara mät- och kvantifierbar. Meto- den kräver stora datamängder och använder statistik för att testa hypoteser [32].

2.7.2 Kvalitativ forskning

Kvalitativ forskning är en forskningsmetod som bygger på observationer för att samla in icke-numerisk data för att nå preliminära hypoteser och teorier.

Kvalitativ forskning svarar på varför och hur ett visst fenomen kan förekomma snarare än hur ofta det förekommer [33]. Metoden använder oftast mindre datamängder som är tillräckliga för att nå tillförlitliga resultat, där data sam- las in tills man nått önskade resultat [32].

2.7.3 Forskningsförfaranden

Forskningsförfaranden används för att dra slutsatser och fastställa vad som är sant eller falskt. De vanligaste är induktion och deduktion, men det finns också en blandning av dessa som kallas abduktion [32].

2.7.4 Deduktion

Deduktion är en grundläggande form av resonemang som börjar med en hy-

potes, utifrån vilka möjligheterna att nå en logisk slutsats undersöks. Det

innebär att man antar att en eller flera premisser är sanna och från dessa

drar logiska slutsatser om vad som bör gälla i det allmänna fallet [32].

2.7.5 Induktion

Induktion är ett filosofiskt förfaringssätt för att dra slutsatser och skapa teorier utifrån observationer. Data inhämtas för att få en förståelse och hitta olika synvinklar för ett visst fenomen. Induktion är generellt associerat med kval- itativ forskning, medan deduktion oftast associeras till kvantitativ forskning.

[32].

2.7.6 Abduktion

Abduktion är en kombination av deduktion och induktion för att nå en slut- sats. Abduktion börjar med en eller flera observationer, där den enklaste och mest sannolika förklaringen söks. Abduktion startar med en ofullständig up- psättning data eller observationer och använder förhandsvillkor för att förk- lara resultatet [32].

2.7.7 Fallstudie

När man genomför en fallstudie studerar man ett problem genom att illus- trera det genom ett s.k. fall. Ett fall kan vara en individ, en mindre grupp, en organisation eller ett program [34]. En Fallstudie lämpar sig väl till både en kvalitativ och kvantitativ studie [32] där forskaren undersöker en verklig, samtida och begränsat system (fall) . Man kan också studera flera fall i en fallstudie men det finns då en risk att det inte blir samma djup på forsknin- gen som när man studerar ett enskilt fall [34].

2.7.8 Förfaringssätt för en fallstudie

En fallstudie börjar med att identifiera ett specifikt fall. Det viktiga steget här

är att definiera ett fall som kan begränsas eller förklaras inom vissa ramar,

såsom en specifik plats eller tid. Typiskt studeras verkliga fall som pågår

samtidigt som studien genomförs för att få noggran information [34].

Avsikten med en fallstudie är viktig. En kvalitativ fallstudie kan illustrera ett unikt fall, ett fall som är ovanligt och behöver beskrivas närmare eller för att förstå ett specifikt problem eller fenomen [34].

Något som kännetecknar en bra kvalitativ studie är att den presenterar en djup förståelse av fallet. För att uppnå detta samlar forskaren in många olika former av kvalitativ data, detta kan vara: intervjuer, observationer, doku- ment och audiovisuella material [34].

Det finns olika tillvägagångssätt i valet av dataanalys i en fallstudie. Antin-

gen kan flera enheter inom ett fall analyseras eller så analyseras fallet som

en helhet [34].

3 Forskningsmetoder och förfaranden

I detta kapitel presenteras forskningsmetodiken som användes i denna studie.

I avsnitt 3.1 ges en överblick av vår forskningsstrategi. I avsnitt 3.2 pre- senteras forskningsmetoder. Avsnitt 3.3 presenterar arbetsmetoden. I avs- nitt 3.4 identifieras och beskrivs problemen. Avsnitt 3.5 presenterar datain- hämtningen. I avsnitt 3.6 presenteras en lösning till problemet. Avsnitt 3.7 presenterat den tillämpade forskningsstrategin 3.8 presenterar kriterierna för kvalitetssäkring.

3.1 Forskningsstrategi

Vår övergripande forskningsstrategi presenteras i figur 3.1.

Figur 3.1: Forskningsstrategi

3.2 Forskningsmetod

I vårt arbete fanns flera faktorer som gjorde att vi valde att använda en kvali- tativ forskningsmetod. Vi har fokuserat främst på att ta fram ett ramverk, en metod, snarare än ett kvantifierbart resultat. I vårt forskningsarbete hittade vi väldigt få studier med fokus på faktorn arbetsinsats, därav lämpade sig en kvalitativ forskningsmetod för att undersöka fenomenet.

3.3 Arbetsmetod

I en rapport skriven av Niclas Andersson och Anders Ekholm [35], som ut- gör en vetenskaplig granskning av tre forskningsprojekt, presenteras en ar- betsmetod som är baserad på Mario Bunges forskningsstrategier. Denna ar- betsmetod består av ett antal steg för att på ett vetenskapligt sätt besvara forskningsfrågan 3.3 som vi har använt oss av:

1. Identifiera ett problem inom ett ämnesområde 2. Beskriv problemet tydlig

3. Kartlägg befintlig kunskap inom området, dvs. identifiera information, metoder eller instrument som är relevanta för problemställningen 4. Förklara och lös problemet med utgångspunkt från bakgrundskunskapen

i steg 3. Om befintlig kunskap inom området inte är tillräckligt för att lösa problemet, gå vidare till steg 5, annars hoppa till det därpå följande steget.

5. Föreslå nya idéer, tekniker, teorier eller hypoteser och ta fram ny em- pirisk data för lösning av problemet.

6. Lägg fram lösningsförslag, antingen en exakt eller en approximativ lös- ning

7. Härled konsekvenserna av den presenterade lösningen.

8. Testa lösningsförslaget.

9. Korrigera lösningsförslaget efter testresultatet.

10. Undersök lösningen i perspektiv av befintlig kunskap inom ämnesom- rådet (steg 3) och identifiera nya problemställningar.

[35]

3.4 Identifiera och beskriv problemet

För att beskriva problemet enligt Bunges 3.3 (punkt 2) analyserades forskn- ingsfrågan Hur fördelas arbetsinsatsen för injicering och upptäckt av mjuk- varufel?. Denna frågeställning innefattar tre huvudsakliga delar:

• Injicering av fel

Frågor som vi sökte svar på var:

Hur injicerar man fel i mjukvara? Finns det olika sätt att injicera fel?

Upptäckt av fel

För att kunna upptäcka fel var vi tvungna att identifiera:

Vad är ett fel? Finns det olika typer av fel? Hur upptäcker man fel i mjukvara? Vilka aktiviteter kan vara användbara för att hitta fel i mjukvara?

• Arbetsinsats

Vad innebär arbetsinsats? Finns det olika sätt att mäta arbetsinsat- sen?

3.5 Datainhämtning

För att kartlägga befintlig kunskap inom området och identifiera metoder

som är relevanta för problemställningen enligt Bunges 3.3 (punkt 3) utförde

vi en litteraturstudie 3.5.1.

3.5.1 Litteraturstudie

Eftersom vår studie tangerar flera områden - injicering, upptäckt och ar- betsinsats - delade vi upp litteraturstudien dessa olika faser för att besvara frågorna som formuleras i problembeskrivningen ( 3.4).

Injicering av fel

Vi studerade först litteratur som berör mjukvarufel generellt. Vi fann då att en specifikation är nödvändig för att kunna definiera en fungerande eller felaktig mjukvara. Vi studerade sen felinjektion med sökorden - software fault injection, fault injection, error injection. Eftersom definitionerna av olika typer av mjukvarufel (fault, failure, error) var tvetydiga beroende på författare, valde vi i ett sidospår att studera definitioner för dessa.

Upptäckt av fel

För upptäckt av mjukvarufel undersöktes metoder för felsökning och prob- lemhanteringsprocesser. Vi undersökte mjukvarutestning som en generell term för att hitta brister och fel i mjukvara. För att vi själva skulle kunna hitta fel i mjukvara försökte vi se på befintliga metoder för att hantera prob- lem och fokuserade på främst två metoder som var: Problemhanteringspro- cess avsnitt 2.4.1 och Corrective maintenance testing avsnitt 2.4.3 som är två arbetsmetoder som rör upptäckt och åtgärder av mjukvarufel.

Arbetsinsats

Efter Upptäckt av fel undersökte vi litteratur som behandlade arbetsinsats.

Det var svårt att hitta litteratur om arbetsinsats kopplat till felinjicering, däremot finns det artiklar som tar upp arbetsinsats inom mjukvaruutveck- ling. Det fastslogs att det finns olika sätt att mäta arbetsinsats på som tas upp i 2.1.

Allteftersom vi lärde oss mer, fick vi anledning att återgå till litteraturstudier

under arbetets gång för att fördjupa våra kunskaper.

3.6 Förklara och lös problemet

För att lösa problemet med utgångspunkt från vår inhämtade bakgrund- skunskap enligt Bunges punkt 4 togs ett ramverk fram för de olika delprob- lemen som nämns i 3.4. Målet var att ramverket skulle innehålla de olika delar som identifierades som delproblem 3.6.1.

3.6.1 Ramverkets beståndsdelar

De delar som ansågs nödvändiga för ramverket, baserat på datainhämntnin- gen 3.5, var: En metod för att injicera fel, en metod för att upptäcka fel, ar- betsinsats, roller, typer av fel samt problemrapport. Hur de olika bestånds- delarna togs fram beskrivs mer ingående nedan.

3.6.2 Metod för Injicering

I de artiklar som undersöktes presenterades flera olika verktyg för att au- tomatisera felinjektioner i mjukvara, men ingen metod för hur man manuellt kan injicera fel. Därför skapade vi en injiceringsmetod baserat på informa- tion från litteraturstudiefasen vilket motsvarar punkt 5 i Bunges 3.3 med följande faser:

• Kravstudie

Injektionscykeln börjar med att studera målsystemets specifikationer.

Detta kan göras antingen genom att intervjua utvecklarna eller genom att läsa tillgänglig dokumentation.

Då specifikationerna avgör vad som är ett fel, är det av intresse att veta detta i egenskap av injicerare.

Denna fas utförs en gång.

• Undersöka källkoden

För att erhålla förståelse för hur målsystemet är implementerat under-

söks källkoden. Detta sker genom att gå igenom de olika skripten. För att se hur de olika skripten samverkar kan man titta efter vilka andra skript de importerar. Utvecklarens kommentarer kan också ge vägled- ning om vad en viss funktion gör. Koden granskas för att se att den lever upp till de sagda eller dokumenterade specifikationer.

Denna fas utförs en gång.

• Identifiera svaga punkter

När förståelse för hur målsystemet är uppbyggt erhållits, identifieras ett godtyckligt antal svaga punkter. Svaga punkter är de kodinstruk- tioner som med kodmutation kan resultera i att något eller några av de faults som presenteras i tabell 2.1 kan injiceras.

• Felinjektion

I denna fas injiceras utvalda faults genom kodmutation i de svaga punk- ter som identifierades i föregående fas. Med målsystemets specifika- tioner i åtanke väljs faults som resulterar i att målsystemet inte agerar korrekt vid exekvering.

• Exekvering

Målsystem exekveras för att bekräfta att injicerade faults har önskad effekt.

Tillvägagångssätt för injicering av fel, steg för steg beskrivs enligt följande flödesdiagram:

Figur 3.2: Injiceringsmetodens faser

3.6.3 Metod för upptäckt av fel

Vår metod för upptäckt av fel bygger på Mira Kajko Mattsons artiklar om problemhanteringsprocesser (se 2.4.1) och corrective maintenance testing (se 2.4.3). Vi delade upp metoden för upptäckt av fel i följande faser: Prob- lemanalysfas, förberedelsefas, exekveringsfas samt utvärderingsfas. Utöver faserna som är tagna från Kajko Mattssons artiklar kompletterades även up- ptäcktsmetoden med aktivitetslistan från corrective maintenance testing (se 2.4.3) som översattes och kan ses i 3.1.

• Problemanalysfasen

Testningscykeln börjar med att studera problemrapporten och speci- fikationen för den del som problemet rör. Utifrån problemrapporten

utförs tester för att bekräfta problemet. Detta görs likt Problemrapporterings- fasen i 2.4.1.

• Förberedelsefasen

Förberedelsefasen går ut på att skapa ett eller flera testfall för att testa en funktionalitet och jämföra det förväntade resultatet med det fak- tiska resultatet. Detta görs likt första punkten i corrective maintenance testing (se 2.4.3). Testfallen är utformade enligt:

– Input:

– Output:

• Exekveringsfasen

I denna fas körs mjukvaran baserat på varje testfall. Ett förslag på åt- gärder skapas. Detta som en kombination av problemanalysfas III och problemlösningsfasen i problemhanteringsprocesser (se 2.4.1)

• Utvärderingsfasen

Detta är den sista fasen där testningscykeln analyseras för att identi-

fiera nya strategier att implementera i nästa iteration. Idén med tes-

tutvärderingen är att ta bort onödiga steg i testningen för framtida iter-

ationer. Detta sker genom att utvärdera förslag som Upptäckaren har

gett på förbättringar.

Tillvägagångssätt för upptäckt av fel beskrivs steg för steg enligt följande flödesdiagram:

Figur 3.3: Upptäcktmetodens faser

A-1 Bekräfta det inrapporterade problemet A-1.1 Undersök om problemet är unikt A-1.1.1 Identifiera och klassificera problemet

A-1.1.2 Undersök om problemet har fångats upp av organisationen med hjälp av information om problemets symptom

A-1.2 Om problemet är unikt:

A-1.2.1 Välj en lämplig version av produkten A-1.2.2 Skapa en lämplig testmiljö

A-1.2.3 Skapa lämpliga testfall A-1.2.4 Testa mjukvarusystemet

A-1.2.4.1 Testa systemet med hjälp av testfallen A-1.2.4.2 Dokumentera resultaten av testerna A-1.2.4.3 Modifiera testfallen om det behövs

A-1.2.4.4 Komplementera beskrivningen av problemet om det behövs A-1.2.4.4 Uppdatera organisationens problemhanteringssytem med

information om testfallen och hur problemet återskapas

A-1.3 Om problemet redan har fångats upp av organisationen:

A-1.3.1 Undersök om det redan finns tesfall för att återskapa problemet

A-1.3.2 Om det finns testfall anpassa dessa till den valda versionen av produkten A-1.3.3 Testa mjukvarusystemet

A-1.3.3.1 Testa mjukvarusystemet med testfallen A-1.3.3.2 Dokumentera resultaten av testerna A-1.3.3.3 Modifiera testfallen om det behövs

A-1.3.3.4 Komplementera beskrivningen av problemet om det behövs A-1.3.3.5 Uppdatera organisationens problemhanteringssytem

med information om testfallen och hur problemet återskapas

A-1.3.4 Om inga testfall existerar som kan användas, utför aktiviteter från A-1.2 A-2 Efter att testningen har lyckats:

A-2.1 Vidta lämpliga åtgärder

A-2.2 Sök efter befintliga lösningar om det finns A-2.3 Uppgradera problemrapporten och testfallen

till nästa avdelning i supportkedjan

Table 3.1: Aktivitetslista för upptäcktsmetoden

3.6.4 Arbetsinsats

Tiden för de olika stegen i ramverket mäts i minuter avrundat uppåt till

närmsta femtal [9].

3.6.5 Roller

Det är möjligt att dela in upptäckt i flera roller likt Kajko Mattsons prob- lemhanteringsprocesser (se 2.4.1). Eftersom denna studien utfördes av två personer skapades två roller, en Injicerare för injicering av fel som också agerade problemrapportör och en Upptäckare.

3.6.6 Typer av fel

En lista med vanligt förekommande fel ingår i ramverket baserat på [15][16].

3.6.7 Problemrapport

Efter att ett fel har injicerats uppförs en problemrapport likt problemrappor- teringsfasen i Kajko Mattsons problemhanteringsprocesser (se 2.4.1). Denna problemrapport används sen i upptäcksmetoden.

3.7 Tillämpad forskningsstrategi

För detta arbete valdes fallstudie som forskningsstrategi för att ta fram ett ramverk för att mäta arbetsinsatsen för injicering och upptäckt av fel. Vi studerade tre fall. Dessa var: injicering av fel, upptäckt av fel och arbetsin- satsen som krävdes för dessa.

3.8 Kvalitetssäkring

Kvalitetssäkring innebär att man validerar och verifierar forskningsarbetet.

Kriterier för kvalitetssäkring skiljer sig beroende på vilken forskningsmetod som har valts. För kvantitativ forskning måste följande kriterier diskuteras:

validity, reliability, replicability and ethics. I en studie som tillämpar kvalita-

tiv forskning diskuteras följande: Credibility, Transferability, Dependability och Confirmability [36].

3.8.1 Kvalitetssäkring för kvalitativ forskning

Kvalitativ forskning är en typ av forskning där resultaten inte har uppkom- mit genom statistiska eller kvantitativa metoder. En del av den data som samlas in i en kvalitativ studie kan vara kvantifierad men huvuddelen av analysen är tolkande. Av den anledningen kan det vara svårt att komma fram till en allmän slutsats. Utifrån detta är det en stor utmaning inom kvalitativ forskning att säkerställa kvalitén och trovärdigheten i forskningen. För att genomföra forskningen på ett trovärdigt sätt tar forskaren fram kriterier för evaluering. Det finns olika perspektiv i forskarsamhället för hur man ska ta fram eller välja kriterier för evaluering. I denna rapport har vi valt att följa Lincoln Gubas termer och perspektiv där de klassifierar kriterierna i: Cred- ibility, Transferability, Dependability och Confirmability[34].

• Credibility

Credibility (Trovärdighet) innebär att man på något sätt konstaterar att resultaten av forskningen är trovärdig. Det finns många sätt att ut- föra detta på och dessa skiljer sig åt beroende på vilken typ av forskning det gäller. Vi har valt två kriterier: Clarifying researcher bias och Tri- angulering [34].

1) Clarifying researcher bias innebär att forskaren redogör för per- sonliga fördomar eller antaganden som kan ha påverkat resultaten. I detta klargörande kommenterar forskaren tidigare erfarenheter, anta- ganden och förutfattade meningar som kan ha format tolkningen och utförandet av studien [34].

2) Triangulering innebär att forskaren tar in information från flera

källor. När en kvalitativ forskare exempelvis lokaliserar bevis för att

dokumentera en kod i olika datakällor triangulerar de informationen,

vilket ger mer tillförlitliga resultat [34].

• Dependability refererar till idén om tillförlitlighet som tillämpas i kvantitativ forskning. En mätning är tillförlitlig när oberoende men jämförbara mätningar ger resultat som stämmer överens. Tillförlit- ligheten beror på hur stor del av variationen i datan som beror på slump.

Tillförlitlighet kan inte kontrolleras på samma sätt i kvalitativ forskn- ing. Kvalitativa forskare säkerställer istället tillförlitlighet genom att dokumentera data och metoder [36].

• Confirmability bekräftar att forskningen har utförts i god tro utan att personliga bedömningar har påverkat resultatet. För att bekräfta forskningen tittar forskaren på sin egen bakgrund och position för att se hur dessa kan ha influerat forskningsprocessen [37].

• Transferability är ett sätt att skapa beskrivningar av forskningen

som kan stå till grund för att andra forskare ska kunna återskapa ar-

betet [32].

4 Utförande

I detta kapitel beskrivs hur ramverket som togs fram i kapitel 3 testades och utvärderades vilket motsvarar Bunges steg 5-9. För att testa ramverket ap- plicerades det på mjukvaran EXIT som beskrivs i 4.1.

I avsnitt 4.2 avhandlas den experimentella uppställningen för testerna. I 4.3 presenteras de roller som ingick i utförandet av testerna. Tillvägagångssättet för hur ramverket applicerades beskrivs i avsnitt 4.4. I 4.5 visas ett exempel på när ramverket appliceras på EXIT. Slutligen i avsnitt 4.6 presenteras en utvärdering av ramverket.

4.1 EXIT

EXIT är en applikation skriven i HTML, CSS och Javascript med en till- hörande postgreSQL-databas. Den migrerade versionen av EXIT var frånkop- plad från inloggnings-funktionen som var en del av den ursprungliga ver- sionen av EXIT. För att EXIT skulle fungera utan inloggningsfunktionen var vissa variabler tvungna att läggas in manuellt innan testerna genom- fördes. Detta beskrivs under Installation 4.2.2 i Experimentell uppställning 4.2.

4.2 Experimentell uppställning

För att testa ramverket som skapades i kapitel 3 applicerades det på EXIT.

Här beskrivs den experimentella uppställningen. Testerna kördes lokalt på två datorer.

4.2.1 Systemspecifikation

Testerna utfördes på två datorer, en dator för injicering och en för upptäckt

av fel.

System för injicering av fel var följande:

• Processor: 2 GHz Intel Core i5

• Minne: 8 GB 1867 MHz LPDDR3

• Grafikkort: Intel Iris Graphics 540 1536 MB

• OS: macOS 10.14.3

System för upptäckt av fel var följande:

• Processor: 2,3 GHz Intel Core i7

• Minne: 16 GB 1600 MHz DDR3

• Grafikkort: NVIDIA GeForce GT 650M 1024 MB

• OS: macOS 10.13.6

4.2.2 Installation

Installationen skedde på samma sätt för både Upptäckaren och Injiceraren.

Mjukvara som installerades för systemet var:

• Node.js användes som webserver för EXIT.

• PostgreSQL användes som databas och en ingående beskrivning hur vi satte upp databasen kan ses i bilaga D

• PgAdmin4 användes för att få en grafiskrepresentation av databasen när testerna utfördes.

• Visual Code användes för att öppna källkoden.

• Google Chrome användes för att köra EXIT.

4.3 Roller

Studien omfattar två metoder. En metod för injicering av fel och en för up- ptäckt av fel. Arbetet delades upp i två roller, där en deltagare stod för in- jicering av fel: Injiceraren, och en för upptäckt: Upptäckaren. Eftersom vi själva ingick som deltagare i studien var det viktigt att vi inte delgav den andre information om vilka typer av fel som skulle injiceras, antalet fel och annan information som skulle kunna undanröja en trovärdig upptäckt av fel.

I utformningen av möjliga fel att injicera, användes befintliga studier där de oftast förekommande typerna av fel presenterades, se tabell 2.1. Eftersom det var eftersträvansvärt att felen som injicerades skulle vara så realistiska som möjligt, begränsades de till att vara tagna från tabellen. Typerna av fel matchades sedan med arbetsinsatsen för upptäckten av felen.

Eftersom vi var deltagare i vår egen studie, valde vi att definiera regler att förhålla oss till under arbetets gång. Dessa handlade om vad vi skulle mäta tid på, och att vi inte skulle delge varandra information om felen förrän vi utvärderade dem tillsammans.

Vårt tillvägagångssätt var följande:

• Injiceraren sätter sig in i koden för att få en förståelse för mjukvaran.

• Injiceraren injicerar fel under tidtagning. Antalet och typ av fel är okänt för upptäckaren

• Upptäckaren försöker identifiera fel under tidtagning

• Utvärdering av tidsåtgång och typer av fel

4.4 Iterationscykel

Iterationscykeln för injicering av fel, upptäckt av fel och slutligen utvärder-

ing beskrivs enligt följande flödesdiagram:

Figur 4.1: Iterationscykel

Varje iteration påbörjas med att injiceringsmetoden appliceras på målsys- temet. Efter det skriver injiceraren en problemrapport. Problemrapporten skickas sen till Upptäckaren så att användning av upptäcktsmetoden kan påbörjas. I utvärderingsfasen dokumenteras typen av fel som injicerats, ar- betsinsatsen för samtliga steg samt om felen upptäckts eller inte. Injiceraren och Upptäckaren för loggbok se bilaga (B och C) under hela processen, dels för att kunna redovisa vilka steg som tas, men också för att kunna utvärdera ramverket och uppdatera det vid behov.

4.5 Iterationsexempel

Nedan följer ett exempel på en iterationen, den första som utfördes. För en mer detaljerad beskrivning över stegen som utfördes se bilaga B och C. Figur 4.2 och 4.3 visar EXIT innan felinjektionen ägt rum respektive efter.

4.5.1 Injiceringsmetod

Felet som injicerades var av typen WPFV, vilket innebär att de ursprungliga inparametrarna i ett funktionsanrop modifierats genom kodmutation.

Kodinstruktionen som muterades ansvarade för att hämta information från

databasen genom att skicka en förfrågan. Felinjektionen resulterade i att programmet inte längre kunde tilldela examinatorer handledningstid, då till- gängliga examinatorer inte kunde hämtas från databasen.

4.5.2 Problemrapport

Problemrapporten var följande:

• Problembeskrivning: Kan inte tilldela examinatorer ”tutoring hours”

då inga alternativ på examinatorer syns

• Steg för att återskapa problemet: Lägg till en examinator genom att välja ”add examiner” i menyn, fyll i de nödvändiga stegen. Gå sedan till ”Specify tutoring hours” via menyn.

• Förväntat resultat: Att den nyligen tillagda examinatorn och övriga tillgängliga examinatorer är synliga alternativ att tilldela handläggn- ingstimmar till.

• Faktiskt resultat: En avsaknad av examinatorer.

4.5.3 Upptäcktsmetod

För att verifiera felet följdes instruktionerna i problemrapporten. Testerna som utfördes var att lägga till examinator för att sedan kontrollera om det gick att tilldela handläggningstid.

Efter att felet verifierats påbörjades en initial gransknings av koden. Fokus hamnade på två funktioner, en som hämtade handläggningstid från databasen

"get_tutoring_hours()" och en som lagrade handläggningstid i databasen

"specify_tutoring_hours()".

Efter att aktiviteter från aktivitetslistan 3.1 utfördes på följande två funk-

tioner kunde det injicerade felet upptäckas och därav åtgärdas.

Figur 4.2: Före felinjektion

Figur 4.3: Efter felinjektion

4.6 Utvärdering och förslag på uppdatering av ramverk

När alla iterationer var genomförda utvärderades injicerarens och upptäckarens loggböcker för att eventuellt uppdatera ramverket. Detta motsvarar Bunges punkt 9.

4.6.1 Injiceringsmetoden

Tidigt i iterationscykeln ansåg Injiceraren att det vore bättre att faserna ”in- jicering av fel” och ”exekvering” slogs samman till en gemensam fas. I de it- erationer som genomfördes gav de injicerade felen inte alltid den effekt som avsågs från första början. Detta upptäcktes först vid exekveringsfasen. Att de injicerade felen inte resulterade i önskat beteende gjorde att Injiceraren behövde återgå till injiceringsfasen.

4.6.2 Upptäcktsmetoden

Efter ett antal iterationer ansåg Upptäckaren att det fanns ett behov av någon typ av kodanalys för att gå igenom koden och jämföra funktioner och genom det hitta brister i systemet.

Detta var ett centralt tillvägagångssätt för att upptäcka fel. Upptäckaren föreslog två alternativ: antingen att ha kodanalys som en egen fas, eller att lägga till kodanalys i aktivitetslistan. Vi valde att ha kodanalys som en egen fas då det användes i varje iteration, eftersom vi ville ha möjlighet att an- vända aktivitetslistan som ett komplement. Aktivitetslistan uppdaterades också med aktiviteter för kodanalys. Dessa aktiviteter var:

• Undersök namnen på funktionerna och se om de innehåller namn eller delar av namnet som berör problemet.

• Jämför funktioner med liknande egenskaper - Detta innebär att hitta

mönster med funktionen som undersöks och andra funktioner i sys-

temet och se om de ha liknande funktionalitet.

Ett annat förslag på åtgärd var att ta bort exekveringsfasen för att istället lägga till det i aktivitetslistan, eftersom upptäckaren ofta exekverade koden under andra faser än själva exekveringsfasen.

Upptäckaren påpekade också att terminalen kunde avslöja enklare fel och

då även peka ut på vilken rad felet låg. Att söka efter fel genom terminalen

lades därför till i aktivitetslistan.