Automatgenererade testsviter som hanterar
kombinatorisk explosion
Auto-generated Test Suites that handle Combinatorial Explosion
JOEL ANDERSSON JOELAND@KTH.SE
Examensrapport vid CSC Handledare: Karl Meinke Examinator: Stefan Arnborg
Exjobbsämne: Datalogi Uppdragsgivare: Scania Datum: June 12, 2013
Referat
I alla mjukvaruprojekt spelar mjukvarutestning en viktig roll. Om en programdefekt inte upptäcks och rättas innan systemet sätts i produk-tion, kan detta leda till betydande förluster för organisationen.
Scanias kunder har möjligheten att skräddarsy sina fordon, efter kundens egna behov, istället för att välja bland en uppsättning färdiga modeller. Denna praktiskt taget oändliga uppsättning teoretiska model-ler medför dock svårigheter inom testning.
En elektronisk styrenhet (ECU) är ett inbyggt system som kon-trollerar ett eller flera av de elektroniska systemen i ett fordon, t.ex. motorn, kraftöverföringen och luftkonditioneringen. När fordonen läm-nar produktionen parametersätts deras ECU-parametrar efter ett regel-verk som anges i konfigureringsprogrammet Parameter Setting Module (PSM). Syftet med denna rapport är att finna/föreslå en systematisk testmetod för att testa PSM. Målet är att hitta en metod som på ett effektivt sätt skapar en lämplig testsvit och som med stor sannolikhet lyckas hitta potentiella fel innan PSM används i produktion.
Ju fler parametrar som kombineras, desto högre blir antalet möjliga kombinationer. Detta vanligt förekommande fenomen inom mjukvaru-testning kallas för kombinatorisk explosion. Kombinationsstrategier är en familj testfallsmetoder, som hanterar kombinatorisk explosion.
Genom att medvetet införa fel i PSM:s källkod, med mutationstest-ning, och genom att jämföra den nuvarande testsvitens mutationspoäng med andra kombinationsstrategier, var det möjligt att få en uppfattning om hur lämpliga testsviterna är för detta specifika ändamål.
Resultatet visade att varken 1-wise-testning (test av varje parame-tervärde minst en gång), eller den nuvarande testsviten, är bra nog för att upptäcka potentiella fel i PSM, samtidigt som 3-wise-testning in-volverar alltför många testfall för att kunna användas i praktiken. 2-wise-testning, å andra sidan, tycks ha en god avvägning mellan antalet testfall och kodtäckning/mutationspoäng.
Nyckelord: Mjukvarutestning, elektronisk styrenhet, kombinatorisk explosion, kombinations-strategier, mutationstestning, 2-wise-testning, kodtäckning, mutationspoäng
Abstract
Auto-generated Test Suites that handle Combinatorial
Explosion
In all software projects, software testing plays an important role. If a software defect is not detected and corrected before the system is put into production, this can lead to significant losses for the organization. Scania customers have the ability to customize their vehicles, ac-cording to their needs, instead of choosing among a set of ready-made models. This practically infinite set of theoretical models poses difficul-ties in testing.
An Electronic Control Unit (ECU) is an embedded system that con-trols one or more of the electronic systems in a vehicle, such as the en-gine, transmission and air conditioner. When vehicles leave production, their ECU parameters are set using rules defined in the configuration program Parameter Setting Module (PSM). The purpose of this report is to find/propose a systematic test method for testing PSM. The goal is to find a method that effectively creates a suitable test suite which is likely to succeed in finding defects before PSM is used in production.
The more parameters you combine, the higher the number of possi-ble combinations will be. This common phenomenon, in software test-ing, is called combinatorial explosion. Combination strategies are a family of test case methods, which handle combinatorial explosion.
By deliberately introducing defects in PSM’s source code, using mu-tation testing, and by comparing the current test suite’s mumu-tation score with other combination strategies, one can get an idea of the test suites’ adequacy.
The results showed that neither 1-wise testing (testing every pa-rameter value at least once), nor the current test suite, is good enough to detect defects in PSM, while 3-wise testing involves too many test cases to be used in practice. 2-wise testing, on the other hand, seems to have a good balance between the numbers of test cases and code coverage/mutation score.
Keywords: Software testing, electronic control unit, combinatorial explosion, combination stra-tegies, mutation testing, 2-wise testing, code coverage, mutation score
Författarens tack
Detta examensarbete genomfördes på Scania i Södertälje. Jag vill börja med att tacka alla på min avdelning på Scania som har hjälpt mig, och då speciellt min handledare Oscar Blomqvist. Jag vill tacka min handledare på KTH, Karl Meinke, som har hjälpt mig från projektets början till slut, speciellt med skrivandet av denna rapport. Jag vill också tacka min examinator, Stefan Arnborg, som har granskat rapporten och bidragit med sina värdefulla kommentarer. Slutligen vill jag tacka min opponent, Sara Hägglund, för den tid du har lagt ner på att bidra till ett bättre slutresultat av rapporten.
Innehåll
1 Introduktion 1
2 Bakgrund 3
2.1 Förklaring av begrepp och termer . . . 3
2.2 Kombinatorisk explosion . . . 4
2.3 Kombinationsstrategier . . . 4
2.3.1 Input Parameter Model . . . 5
2.3.2 Testnivåer . . . 5
2.4 Automatic Efficient Test Generation . . . 7
2.5 Konflikter och avoid-metoden . . . 9
2.6 Black-box-testning . . . 10 2.7 White-box-testning . . . 10 2.8 Regressionstestning . . . 11 2.9 Kodtäckning . . . 11 2.10 PICT . . . 12 2.11 Mutationstestning . . . 12 2.11.1 Ekvivalenta mutationer . . . 13 2.11.2 Mutationspoäng . . . 14
2.11.3 Flera ordningens mutationer . . . 14
2.11.4 Mothras mutationssystem . . . 14 2.11.5 Coupling effect . . . 15 2.12 Testning av PSM idag . . . 15 2.13 Syfte och mål . . . 16 2.14 Begränsningar . . . 16 2.15 Relaterat arbete . . . 16 3 Utförande 17 3.1 Välja ECU . . . 17 3.2 Skapa en IPM . . . 18 3.3 Mutationsoperatorer . . . 18 3.4 Mutationsgeneratorn . . . 19
3.5 Testgenerering och exekvering . . . 19
4 Resultat 21 4.1 Kodtäckning . . . 21 4.2 Mutationstestning . . . 22 5 Slutsats 25 5.1 Kodtäckning . . . 25 5.2 Mutationstestning . . . 26 5.3 Framtida arbete . . . 28 Bilagor 28 Litteraturförteckning 29 A Mothras mutationsoperatorer 33
Figurer
2.1 Exempelkod från PSM . . . . 42.2 Linjediagram över hur antalet testfall ökar (fullständig testning och med 2-wise-testning) då antalet parametrar ökar, båda med 3 parametervär-den var . . . 6
2.3 Kodtäckning i felaktig kod . . . . 11
2.4 Kodtäckning i korrekt kod . . . . 12
2.5 Originalkod . . . . 13
2.6 Mutantprogram . . . . 13
2.7 Definition av mutationspoäng (MS) . . . . 14
3.1 Schematiskt diagram över testarkitekturen . . . . 17
3.2 Mutationsgeneratorns pseudo kod . . . . 19
4.1 Stapeldiagram över kodtäckningen för den nuvarande, 1-wise och 2-wise testsviten . . . 21
4.2 Beräkning av mutationspoäng för den nuvarande testsviten . . . . 22
4.3 Stapeldiagram över mutationspoängen för den nuvarande, 1-wise, 2-wise och den slumpmässiga testsviten . . . 23
4.4 Stapeldiagram över antalet testfall för den nuvarande, 1-wise, 2-wise och den slumpmässiga testsviten . . . . 23
Tabeller
2.1 En IPM som beskriver ett enkelt ritprogram . . . . 5
2.2 Alla möjliga testfall för IPM:en i Tabell 2.1 . . . 6
2.3 En IPM med tre parametrar . . . . 7
2.4 Alla kombinationer av par från Tabell 2.3 . . . . 8
2.5 Tabell 2.4 med borttagna par . . . . 8
2.6 Antal gånger varje värde förekommer i Tabell 2.5 . . . 8
2.7 Antal gånger par förekommer i testsviten . . . 8
2.8 Antal gånger par förekommer i testsviten, efter upprepning av steg 2 . . 9
2.9 Ny lista av par efter att nytt testfall tagits fram . . . . 9
2.10 IPM med konflikterna (a1,b2), (a1,b3) och (a2,b3) . . . . 10
3.1 Mutationsoperatorerna MO1-MO4 . . . 18
A.1 Mothras mutationsoperatorer [1] . . . . 33
Ordlista
ECU Elektronisk styrenhet PSM Parameter Setting Module
PICT Pairwise Independent Combinatorial Testing tool AETG Automatic Efficient Test Generation
CAN-buss Controller Area Network-buss FPC Functional Product Characteristic IPM Input Parameter Model
Kapitel 1
Introduktion
En mjukvarubugg, eller programdefekt, är ett programbeteende som avviker från programspecifikationen [2].
Programdefekter kan leda till mycket höga kostnader, inte minst för USA:s eko-nomi, som uppskattningsvis spenderar 59,5 miljarder dollar årligen på programde-fekter, vilket motsvarar 0,6% av USA:s BNP [3]. Inte nog med att programdefekter är mycket kostsamma, de kan också leda till mycket allvarliga konsekvenser.
Therac-25 incidenten, inträffade mellan juni 1985 och januari 1987, som utan tvekan orsakades av det mest betydande mjukvarufelet i en medicin- och biologipro-gramvara [4]. Therac-25 var en bimodal linjäraccelerator som till följd av defekten gav, vid sex separata tillfällen, dödliga doser av radioaktivetet till patienterna.
Raketen Ariane 5:s första flygning, den 4 juni 1996, slutade i ett misslyckande på grund av specifikation- och designfel i programvaran [5]. Ca 40 sekunder efter takeoff och på 3700 meters höjd svängde bärraketen från sin flygbana, gick sönder och exploderade.
På grund av ett mjukvarufel i GE:s XA/21 alarmhanteringssystem, augusti 2003, orsakades ett strömavbrott i nordöstra USA. Ett minnesfel som utlöstes av ett race
condition fick systemet att hamna i en evig loop, som lämnade operatorn utan
uppdaterad information om systemets tillstånd. Den uppskattade kostnaden som kunde associeras till strömavbrottet var 7-10 miljarder dollar [6].
Mjukvarutestning i sig är också tidsödande och materiellt kostsamt. Av den totala utvecklingsbudgeten i ett mjukvaruprojekt står testning för ca 20 till 30% [7] (ibland upp till 50% [8]) och förlänger utvecklingscykeln avsevärt. Mjukvarutestning är dock nödvändigt för att hitta och radera ut potentiella fel. Dessutom är testning nödvändigt för att i någon form kunna försäkra sig om att programmet fungerar som avsett. Förbättringar i testprocessen kan också leda till avsevärda besparingar [7].
Det är också speciellt viktigt att hitta defekter så tidigt som möjligt i utveck-lingsprocessen. Ju längre tid det tar innan en defekt hittas, desto dyrare blir det att åtgärda felet [9] [10]. Kostnaden för att reparera defekter ökar ju senare i utveck-lingsprocessen som de hittas. En defekt kan kosta ca 30 gånger så mycket om den
KAPITEL 1. INTRODUKTION
hittas efter produktlansering jämfört med om samma defekt skulle ha hittats redan i krav/designfasen [11]. Detta beror bland annat på att programmet behöver skrivas om för att rätta felet och att tidigare steg i testprocessen måste anpassas till den nya ändringen i koden. Dessutom är det också generellt svårare för en utvecklare att rätta till fel i kod som denne inte har arbetat med på ett tag. Detta beror ofta på att utvecklaren på nytt måste sätta sig in i koden, vilket är både tidskrävande och kostsamt.
I en ideal värld skulle det vara önskvärt att testa alla möjliga permutationer av indata till ett program, så kallad fullständig testning. Men även för små program är detta inte genomförbart [8]. Ett förhållandevis litet program kan ha hundra-eller tusentals möjliga kombinationer av indata. Detta gör det opraktiskt att skapa testfall för alla dessa. Fullständig testning för ett komplext program skulle ta alldeles för lång tid att genomföra och kosta enorma summor. En testare är alltså tvungen att välja ut en delmängd av testfall ur alla möjliga kombinationer av programmets indata.
Kapitel 2
Bakgrund
2.1
Förklaring av begrepp och termer
Testning definieras som processen att exekvera ett program med avsikten att hitta fel [8].
Ett testfall består av en uppsättning villkor som ofta bestäms utifrån en pro-gramspecifikation i syfte att avgöra om programmet fungerar som avsett.
En testsvit är en samling testfall som används för att testa om ett program uppfyller en uppsättning av villkor eller beteenden.
Testning kan antingen utföras manuellt eller automatiskt. Manuell testning krä-ver att testaren spelar rollen som slutanvändare och testar programmets egenskaper manuellt för att försäkra sig om att programmet fungerar som avsett. Automatisk testning innebär automatisering av en manuell testprocess som testar en eller flera av programmets funktioner.
Ett testorakel är en mekanism som avgör om ett program fungerar korrekt el-ler inte [12]. Exempelvis kan ett testorakel vara programmets specifikation som beskriver hur programmet är avsett att fungera.
En elektronisk styrenhet (ECU) är ett samlingsnamn för inbyggda system som kontrollerar en eller flera av de elektriska systemen eller delsystemen i till exempel ett motorfordon. Moderna bilar innehåller mycket elektronik och kan vara utrustade med fler än 80 ECU:er [13]. I motorfordon finns det ECU:er som är styrenheter för t.ex. motorn, automatiska växellådan och klimatanläggningen.
En Controller Area Network-buss (CAN-buss) är en busstandard för fordon som är utformad för att möjliggöra mikrokontrollers och enheter att kommunicera med varandra direkt, utan en värddator. Varje enhet i CAN-bussen kan skicka och ta emot meddelanden, men inte samtidigt. Robert Bosch utvecklade och konstruerade den första CAN-bussen år 1983 [14]. CAN är ett meddelandebaserat protokoll som är specifikt utformat för att användas av bilapplikationer, men används även inom andra områden så som industriell automation och medicinsk utrustning.
En Functional Product Characteristic (FPC) parameter beskriver fordonets ka-raktäristik och dess fysiska konfiguration. Några exempel på FPC-parametrar är
KAPITEL 2. BAKGRUND
fordonstyp, rullningsradie och bränsletankens kapacitet. Tillsammans använder ECU:erna sig av ca 400 FPC-parametrar för att beskriva fordonets fysiska konfigu-ration. Exempelvis motsvarar FPC1 vilken fordonstyp fordonet har, och FPC1=A om fordonstypen är lastbil och FPC1=B om fordonstypen är buss.
Parameter Setting Module (PSM) är ett program som används för att para-metersätta fordon. PSM parametersätter ett fordon genom att justera ECU:ernas FPC-parametrar i fordonet till de värden som lämpar sig bäst för dess konfiguration eller efter kundens behov. Parametersättningen görs i produktion, efter att fordonet har blivit färdigmonterat i fabriken och innan det provkörs. PSM använder sig alltså av FPC:er för att avgöra vilka värden som ska skrivas till ECU-parametrarna.
PSM-koden består till största delen av nästlade if-satser där varje if-sats in-nehåller ett eller flera villkor av FPC-uttryck. Denna uppsättning if-satser skapar ett regelverk för hur en parametersättning av en ECU ska gå till, utifrån vilka FPC-värden som är satta. För varje ECU finns PSM-kod som hanterar just dennes parametersättning.
if (FPC2537.value in {"A","B","C","D","ZZ"}) if (FPC42.value == "G")
if ((FPC116.value == "B") && (FPC584.value == "D")) LidCabVolume = 45
else ...
Figur 2.1. Exempelkod från PSM
Till exempel parametersätts klimatanläggningens ECU till att ha ett luftflöde som är anpassat till en kabinhyttsvolym på 45 enheter med FPC-kombinationen FPC2537=A, FPC42=G, FPC116=B och FPC584=D (se Figur 2.1).
2.2
Kombinatorisk explosion
Kombinatorisk explosion är ett vanligt förekommande problem inom mjukvarutest-ning. Kombinatorisk explosion uppstår när programmet som testas har flera olika parametrar och där varje parameter har så många värden att det är ogenomförbart att testa alla möjliga kombinationer av parametervärden [15].
2.3
Kombinationsstrategier
Kombinationsstrategier används för att hantera kombinatorisk explosion [15] och använder sig av kombinatoriska strategier för att välja ut en uppsättning testfall av rimlig storlek [16].
Tillämpningen av en kombinationsstrategi består i huvudsak av två delar. Den första delen går ut på att skapa en IPM (modell) som beskriver programmets
in-2.3. KOMBINATIONSSTRATEGIER
data. Här analyserar testaren programmets parametrar och värden och väljer ut de som anses vara lämpliga, och som bör ingå i programmets IPM. I den andra delen används en kombinationsstrategi för att välja ut en delmängd av alla kombinationer av parametervärden.
Kombinationsstrategier kan delas upp i två olika grupper, deterministiska och ickedeterministiska kombinationsstrategier. De deterministiska kombinationsstrate-gierna producerar alltid samma resultat för samma indata. De ickedeterministiska kombinationsstrategierna beror alla till viss del på slumpen, vilket gör att testsviten kommer att se olika ut för samma indata (IPM) från gång till gång. Ett exempel på en ickedeterministisk kombinationsstrategi är t.ex. när en testsvit slumpas fram utan någon specificerad täckningsgrad. Ett annat exempel är AETG, som ingår bland de ickedeterministiska kombinationsstrategierna [17].
2.3.1 Input Parameter Model
För att kunna tillämpa en kombinationsstrategi krävs det att programmets indata formuleras i form av en uppsättning parametrar och parametervärden. Modellen kallas för Input Parameter Model (IPM) och är en abstrakt representation av pro-grammets indata [18] som ofta är en ett-till-ett-mappning mot IPM-parametrarna [19].
Parameter Värde 1 Värde 2 Värde 3 Verktyg P enna P ensel Sprayburk
Tjocklek 1 mm 2 mm 3 mm
Färg Röd Blå
Tabell 2.1. En IPM som beskriver ett enkelt ritprogram
Anta att det finns ett enkelt ritprogram som det ska skapa en IPM för. Ritpro-grammet består av tre parametrar; verktyg, tjocklek och färg. Parametern verktyg kan ha tre olika värden; penna, pensel och sprayburk. Parametern tjocklek kan ha värdena 1, 2 och 3 millimeter. Parametern färg kan ha värdena röd och blå. Nu kan en IPM skapas över ritprogrammet genom att all data stoppas in i en tabell, se Tabell 2.1. Se även Tabell 2.2 för en lista över alla möjliga testfall (fullständig testning) för IPM:en.
2.3.2 Testnivåer
Teststrategin 2-wise-testning definieras på följande sätt: Givet en uppsättning av N oberoende parametrar f1, f2, . . . , fN där varje parameter fi har Li möjliga värden,
fi = {li, 1, ..., li, Li}, produceras en uppsättning testfall R. Varje testfall i R
inne-håller N testnivåer, en för varje parameter fi, och tillsammans täcker alla testfall i
KAPITEL 2. BAKGRUND
(P enna, 1 mm, Röd) (P ensel, 1 mm, Röd) (Sprayburk, 1 mm, Röd) (P enna, 1 mm, Blå) (P ensel, 1 mm, Blå) (Sprayburk, 1 mm, Blå) (P enna, 2 mm, Röd) (P ensel, 2 mm, Röd) (Sprayburk, 2 mm, Röd) (P enna, 2 mm, Blå) (P ensel, 2 mm, Blå) (Sprayburk, 2 mm, Blå) (P enna, 3 mm, Röd) (P ensel, 3 mm, Röd) (Sprayburk, 3 mm, Röd) (P enna, 3 mm, Blå) (P ensel, 3 mm, Blå) (Sprayburk, 3 mm, Blå)
Tabell 2.2. Alla möjliga testfall för IPM:en i Tabell 2.1
av värden li, p och lj, q (1 ≤ p ≤ Li, 1 ≤ q ≤ Lj och i 6= j) förekommer åtminstone
ett testfall i R som innehåller både li, p och lj, q [20].
Detta koncept kan enkelt utvidgas från att täcka alla par till att täcka någon
t-wise kombination där 1 ≤ t ≤ N . När t = 1 är teststrategin ekvivalent med 1-wise,
som innebär att uppsättning testfall väljs ut så att varje parametervärde förekommer minst en gång i något testfall. När t = 2 är teststrategin ekvivalent med 2-wise, som innebär att en uppsättning testfall väljs ut så att varje par av parametervärden förekommer minst en gång i något testfall. När t = N är teststrategin ekvivalent med fullständig täckning, som innebär att uppsättningen testfall väljs ut som täcker alla möjliga kombinationer av parametervärden.
Se Figur 2.2 för ett diagram över hur antalet testfall ökar då antalet parametrar ökar (fullständig testning jämfört med 2-wise-testning).
Figur 2.2. Linjediagram över hur antalet testfall ökar (fullständig testning och med
2.4. AUTOMATIC EFFICIENT TEST GENERATION
2.4
Automatic Efficient Test Generation
Automatic Efficient Test Generation (AETG) strategin väljer ut en uppsättning testfall så att varje par av parametervärden förekommer minst en gång i något testfall.
AETG:s algoritm hittar ett testfall per iteration, och i varje iteration försöker algoritmen att hitta ett testfall som maximerar ökningen i 2-wise-täckning [16]. AETG terminerar när uppsättningen av testfall som har hittats satisfierar 100% i 2-wise-täckning. Antalet testfall som AETG kommer att generera är omöjligt att bestämma i förväg eftersom AETG bygger på en heuristisk algoritm [16].
Termen testvektorer används i motsats till testfall eftersom AETG i de flesta fall inte skapar faktiska testfall, utan en tabell av indatavärden som behövs för att exekvera de önskade testfallen [21].
Exempel
Här följer AETG:s algoritm: 1. Skapa en IPM
2. Hitta alla kombinationer av par
3. Välj det värde som förekommer flest gånger i resterande par 4. Slumpa fram ordningsföljden av resterande parametrar 5. Upprepa från steg 2
Skapa en IPM
Först skapas en IPM över ett programs parametrar a, b och c (se Tabell 2.4). Parameter Värde 1 Värde 2 Värde 3
a a1 a2 a3
b b1 b2 b3
c c1 c2
Tabell 2.3. En IPM med tre parametrar
Hitta alla kombinationer av par
Sedan hittas alla kombinationer av par, se se Tabell 2.3. Antag också att det finns en testsvit som redan innehåller två testfall (a1, b2, c1) och (a2, b3, c2).
Sedan tas de par som redan ingår i de testfall som finns med i testsviten bort, dvs. testfall (a1, b2, c1) och (a2, b3, c2). Tabell 2.5 representerar Tabell 2.4, men
KAPITEL 2. BAKGRUND (a1,b1) (a1,b2) (a1,b3) (a2,b1) (a2,b2) (a2,b3) (a3,b1) (a3,b2) (a3,b3) (a1,c1) (a1,c2) (a2,c1) (a2,c2) (a3,c1) (a3,c2) (b1,c1) (b1,c2) (b2,c1) (b2,c2) (b3,c1) (b3,c2)
Tabell 2.4. Alla kombinationer av par från Tabell 2.3
(a1,b1) (a1,b3) (a2,b1) (a2,b2)
(a3,b1) (a3,b2) (a3,b3)
(a1,c2) (a2,c1) (a3,c1) (a3,c2)
(b1,c1) (b1,c2) (b2,c2) (b3,c1)
Tabell 2.5. Tabell 2.4 med borttagna par
Välj det värde som förekommer flest gånger i Tabell 2.4 Värde a1 a2 a3 b1 b2 b3 c1 c2
Antal förekomster 3 3 5 5 3 3 4 4
Tabell 2.6. Antal gånger varje värde förekommer i Tabell 2.5
Värde a3 och b1 förekommer båda fem och flest antal gånger var, se Tabell 2.6. Ett av dessa värden väljs godtyckligt, till exempel värdet a3.
Slumpa fram ordningsföljden av resterande parametrar
Nu finns testfallet (a3, x, y) där parametrarna x och y är okända. Sedan slumpas
en ordningsföljd fram av resterande parametrar, till exempel först c och sedan b. Upprepa från steg 2
Nu finns testfallen (a3, x, c1) och (a3, x, c2), med paren (a3, c1) och (a3, c2), som båda förekommer en gång var i Tabell 2.5, se Tabell 2.7. Ett godtyckligt testfall väljs, till exempel (a3, x, c1).
Värde (a3,x,c1) (a3,x,c2)
Antal förekomster 1 1
2.5. KONFLIKTER OCH AVOID-METODEN
Upprepa från steg 2, igen
Paren som ingår i kombinationen (a3, b2, c1) förekommer tillsammans två gånger. Paren i kombinationerna (a3, b1, c1) och (a3, b3, c1) förekommer båda tre gånger
var (se Tabell 2.8). En av dessa kombinationer väljs, t.ex. (a3, b1, c1), som blir ett nytt testfall som kan läggas till i testsviten.
Värde (a3, b2, c1) (a3, b1, c1) (a3, b3, c1)
Antal förekomster 2 3 3
Tabell 2.8. Antal gånger par förekommer i testsviten, efter upprepning av steg 2
Testsviten innehåller nu testfallen (a1, b2, c1), (a2, b3, c2) och (a3, b1, c1). Den nya listan av par finns beskriven i Tabell 2.9.
(a1,b1) (a1,b3) (a2,b1) (a2,b2) (a3,b2) (a3,b3)
(a1,c2) (a2,c1) (a3,c2) (b1,c2) (b2,c2) (b3,c1)
Tabell 2.9. Ny lista av par efter att nytt testfall tagits fram
Ovanstående process upprepas tills listan av par är tom. När listan är tom, har en testsvit med 2-wise-täckning skapats, dvs. alla kombinationer av par förekommer i något testfall.
2.5
Konflikter och avoid-metoden
Ibland uppstår en så kallad konflikt mellan parametervärden, dvs. när det inte är tillåtet att kombinera två eller fler parametervärden, av något skäl. Detta uppstår i samband med testexekveringen och när ett testfall innehåller två parametervärden som är i konflikt med varandra.
När en sådan typ av konflikt uppstår bör testfallet inte nödvändigtvis uteslutas från testsviten eftersom testfallet kan täcka andra valida kombinationer som inte täcks i något annat testfall [20]. Om ett sådant testfall tas bort, utan att ersät-tas av ett annat giltigt testfall, är det inte säkert att testsviten uppfyller samma täckningsgrad (t.ex. 2-wise-täckning) som innan testfallet togs bort.
I PSM finns det kombinationer av FPC-värden i ECU:n som inte är tillåtna. T.ex. är det fysiskt omöjligt att kombinera en lastbilsmotor med ett busschassi, vilket också gör det omöjligt att kombinera deras respektive FPC-parametrar. För-utom denna uppenbara ogiltiga kombination, finns en enorm uppsättning andra icke-giltiga FPC-kombinationer.
KAPITEL 2. BAKGRUND
Avoid-metoden förhindrar kombinationsstrategin från att välja testfall som in-kluderar parametervärden som är i konflikt med varandra. Istället tvingas kombi-nationsstrategin att hitta en uppsättning konfliktfria testfall tills att den önskade täckningsgraden är uppfylld [19].
Parameter Värde 1 Värde 2 Värde 3
a a1 a2 a3
b b1 b2 b3
c c1 c2 c3
Tabell 2.10. IPM med konflikterna (a1,b2), (a1,b3) och (a2,b3)
Anta att en testsvit med 1-wise-täckning skapas för IPM:en i Tabell 2.10, med konflikterna (a1, b2), (a1, b3) och (a2, b3). Anta också att det redan finns två testfall, (a1, b1, c1), (a3, b2, c2), som ingår i testsviten. För att åstakomma 1-wise-täckning
krävs det att ännu ett testfall (a2, b3, c3) läggs till. Dock innehåller testfallet (a2,
b3, c3) konflikten (a2, b3).
Med avoid-metoden, och efter att a2 har valts, är kombinationsstrategin tvungen
att välja antingen b1 eller b2 för att undvika konflikten, eftersom b3 inte är tillåten att användas i kombination med a2. På det här sättet väljer avoid-metoden nästa oanvända värde som inte skapar en konflikt. Om det inte finns några konfliktfria oanvända värden, måste ett redan använt konfliktfritt värde användas [19].
Kombinationsstrategin AETG använder sig av avoid-metoden för att undvika ogiltiga kombinationer [22].
2.6
Black-box-testning
Black-box-testning går ut på att programmet som testas betraktas som en svart låda. Målet med black-box-testning är att testaren testar programmet helt omedve-ten om programmets interna beteende och struktur och koncentrerar sig istället på att hitta omständigheter där programmet inte uppför sig enligt programspecifika-tionen [8]. Testaren anger indata och jämför faktiskt utdata med förväntat utdata. För att kunna hitta alla fel i ett program med hjälp av black-box-testning, är en testare tvungen att testa alla möjliga kombinationer av indata (fullständig indata testning), vilket är ogenomförbart för de allra flesta program.
PSM testas idag med hjälp av black-box-testning — en uppsättning FPC-värden ges som indata (som baseras på ECU-specifikationen) och sedan jämförs faktisk med förväntad utdata, utan att ha kännedom om PSM:s interna struktur.
2.7
White-box-testning
I white-box-testning tillåts testaren att undersöka programmets kod och interna struktur, för att sedan kunna basera sina testfall utifrån denna. För att hitta alla
2.8. REGRESSIONSTESTNING
fel i ett program med hjälp av white-box-testning är en testare tvungen att testa alla möjliga flödesvägar [8].
2.8
Regressionstestning
Regressionstestning utförs på ett program efter ändringar har gjorts i program-met, för att försäkra sig om att programmet fungerar lika bra innan som efter att ändringarna gjordes. En ändring i programmet kan t.ex. vara ny funktionalitet el-ler en buggrättning. Regressionstestning är viktigt eftersom att kodändringar och buggrättningar ofta tenderar att vara mycket mer felbenägna jämfört med origi-nalkoden [8]. Regressionstestning går ofta ut på att en testsvit bestående av en delmängd av programmets alla testfall körs, på den nya koden och sedan jämförs testresultatet med den gamla kodens (orginalkodens) testresultat.
2.9
Kodtäckning
Kodtäckning är ett sätt att mäta hur mycket som har testats jämfört med vad som är möjligt att testa. Statement coverage används för att se vilka exekverbara kodra-der som har körts och kan användas för att försäkra sig om att alla eller nästan alla exekverbara kodrader i ett program har exekverats minst en gång under testexekve-ringen [23]. Om det finns kod som inte har körts av något testfall innan produkten släpps kommer inte funktionaliteten ha testats förrän kunden eventuellt gör det, vilket kan leda till allvarliga konsekvenser om funktionaliteten skulle innehålla en defekt. Desto tidigare en defekt kan hittas, desto snabbare, enklare och billigare kan rättas till.
100% kodtäckning är dock inte ekvivalent med att programmet testas fullstän-digt, och därmed inte innehåller några oupptäckta defekter. Kodtäckning kan t.ex. inte enkelt hitta tidsproblem (timing problems) eller saknad kod. Därför bör testfall inte skapas endast för att få hög kodtäckning [21].
If(FPC1 = A) Exit(1) Else
Allt OK, fortsätt
Figur 2.3. Kodtäckning i felaktig kod
Anta att koden i Figur 2.3 ska täckas med två testfall FPC1=A och FPC1=C (ett värde skiljt från A). Anta också att koden i Figur 2.3 är felaktigt programmerad, och skulle egentligen ha sett ut som i Figur 2.4. Detta innebär att det är 100% kodtäckning i Figur 2.3 (som är felaktig), men bara 66% i Figur 2.4 (som är korrekt).
KAPITEL 2. BAKGRUND If(FPC1 = A) Exit(1) Else if(FPC1 = B) Återställ från fel Else
Allt OK, fortsätt
Figur 2.4. Kodtäckning i korrekt kod
White-box-testning är bra för att kunna täcka stora delar av koden och få en hög kodtäckning. Dock hjälper inte white-box-testning mot saknade if-satser (para-metersättningar) i PSM. ECU-specifikationen tillsammans med black-box-testning måste utnyttjas för att kunna ha möjligheten att hitta den typen av fel.
Förutom statment coverage finns många andra typer av kodtäckning, bland annat branch coverage som kollar på andra kodtäckningsaspekter i programmet.
2.10
PICT
Pairwise Independent Combinatorial Testing tool (PICT) är ett existerande och allmänt tillgängligt verktyg som är byggt ovanpå en kombinatorisk testfallsgenere-ringsmotor.
Även om förmågan av att skapa den minsta möjliga täckningsmatrisen fick mind-re vikt när PICT utvecklades, är effektiviteten på programmets kärnalgoritm jäm-förbar med andra kända testgenerationsstrategier [20].
Indata till PICT är en vanlig textfil (modell/IPM) där testaren specificerar sina testparametrar och testvärden. Som standard producerar PICT en parvis testma-tris (t=2), men det är också möjligt att specificera en annan kombinationsordning så länge som 1 ≤ t ≤ N [20]. PICT stödjer också att kombinationer av parame-tervärden som inte ska ingå i testsviten definieras [20]. PICT använder sig av en deterministisk version av kombinationsstrategin AETG, och undviker ogiltiga test-fall med hjälp av avoid-metoden [20]. Med andra ord kräver PICT att det finns en IPM över programmets indataparametrar samt specificerar vilka eventuella konflik-ter som finns.
2.11
Mutationstestning
Mutationstestning är en felbaserad testteknik (felinjiceringsmetod) som hjälper tes-taren att skapa en testsvit som hittar en viss typ av fel. Testtekniken går ut på att testaren medvetet introducerar en stor mängd enkla fel, så kallade mutationer, i ett program för att skapa en uppsättning mutantprogram. Varje mutantprogram blir då en kopia av originalprogrammet, men innehållande ett eller flera introducerade fel i programmets kod. Mutantprogrammen, eller mutanterna, skapas genom att
appli-2.11. MUTATIONSTESTNING
cera mutationsoperatorer som beskriver syntaktiska förändringar på originalkodens programkod. Testsviter kan sedan mätas genom att avgöra antalet mutantprogram som producerar inkorrekt utdata när det exekveras. Om ett testfall körs och mu-tanten producerar inkorrekt utdata, har testfallet hittat det introducerade felet och mutanten anses då vara död. Mutationstestning kan användas för att mäta en test-svits kvalité och målet är förstås att få en testsvit som dödar så många mutanter som möjligt [24]. Mutationstestning är den vanligaste formen av felinjicering [25] och är orsaken till varför den har använts i denna studie. Mutationstestning har inga speciella krav på hur källkoden måste se ut och kan tillämpas inom en rad möjliga områden. Ett annat exempel på felinjiceringsmetod är bebugging.
2.11.1 Ekvivalenta mutationer
Två program som alltid producerar samma utdata för varje indata är funktionellt ekvivalenta [24]. Vissa mutanter är funktionellt ekvivalenta till originalprogrammet och kan därför inte dödas av någon testsvit.
int index = 0; while (...) { ...; index++; if (index == 10) { break; } } Figur 2.5. Originalkod int index = 0; while (...) { ...; index++; if (index >= 10) { break; } } Figur 2.6. Mutantprogram
Mutationsoperatorn byter ut == mot >= i if-satsens villkor, se Figurerna 2.5 och 2.6. Även om koden ändras, påverkas inte programmets logik och därför kan inte mutanten dödas av något testfall, dvs. det är en ekvivalent mutant. Anledningen är att oavsett om värdet på index är exakt 10 eller högre än 10, kommer if-satsens
KAPITEL 2. BAKGRUND
villkor att vara sant och exekveringen kommer att hoppa ut ur programmets while-loop.
2.11.2 Mutationspoäng
För att kunna jämföra olika testsviters förmåga att hitta fel används testsvitens mutationspoäng. En testsvits mutationspoäng är andelen av icke-ekvivalenta mu-tanter som testsviten dödar. Mer formellt, om ett program P har M mumu-tanter, E stycken ekvivalenta mutanter och en testsvit T som dödar K mutanter definieras mutationspoäng på följande sätt:
M S(P, T ) = 100 ∗ K
M − E (2.1)
Figur 2.7. Definition av mutationspoäng (MS)
Om en testsvit dödar alla icke-ekvivalenta mutanter, dvs. en mutationspoäng på 100%, är testsviten mutationsadekvat. I praktiken är det dock svårt att skapa en testsvit som överstiger en mutationspoäng på 95% [24].
2.11.3 Flera ordningens mutationer
Första ordningens mutanter (FOMs) genereras genom att applicera mutationsopera-torer endast en gång. Detta medför en uppsättning mutantprogram med enbart ett introducerat fel per mutant. Högre ordningens mutanter (HOMs) genereras genom att applicera mutationsoperatorer mer än en gång [26]. T.ex. skapas 2:a ordningens mutationer genom att kombinera två mutationer, 3:e ordningens mutationer skapas genom att kombinera 3 mutationer, och generellt n:te ordningens mutationer skapas genom att kombinera n mutationer.
2.11.4 Mothras mutationssystem
Mothra är en fullständig och flexibel mjukvarutestmiljö som stödjer mutationsbase-rad testning av mjukvarusystem. Mothras testprojekt startades av medlemmar på Georgia Institute of Technology’s Software Engineering Research Center år 1986. Mothra innehåller en tabell (se Tabell A.1) med över 22 olika mutationsoperatorer [1]. Dessa mutationsoperatorer, eller Mothras operatorer, representerar mer än tio års förfiningar med olika mutationssystem. Mutationsoperatorerna är härledda från studier gjorda på programmeringsfel som motsvaras av enkla fel som programmerare ofta gör [1].
2.12. TESTNING AV PSM IDAG
2.11.5 Coupling effect
Ett komplext fel är ofta kopplat till ett enkelt fel på så sätt att en uppsättning testfall som hittar enkla fel i ett program kommer att hitta en hög andel komplexa fel. Detta fenomen kallas för the coupling effect.
Mutation coupling effect innebär, på samma sätt som för the coupling effect, att
komplexa mutanter är kopplade till enkla mutanter och om det finns en testsvit som hittar de enkla mutanterna, hittas med stor sannolikhet även de komplexa [24]. I denna studie används därför bara första ordningens mutanter.
2.12
Testning av PSM idag
Scanias kunder har möjligheten att skräddarsy sina fordon precis efter kundens egna behov, istället för att välja bland en färdig uppsättning fordonsmodeller. För att kunna göra detta möjligt, är ECU:erna beroende av fordonskonfigurationen. T.ex. är klimatanläggningens luftflöde beroende av fordonets hyttstorlek, för att kunna fungera som avsett. Därför parametersätts fordonets ECU:er istället för att ha en nästintill oändlig uppsättning mjukvara för varje fordonskonfiguration.
Idag skrivs testfall manuellt för att testa PSM, vilket ofta är svårt och kompli-cerat. Detta gör den nuvarande testprocessen kostsam i både tid och pengar. Det finns flera anledningar till att det är svårt att skriva testfall för PSM.
Det är svårt att formulera testfall som inte strider mot de FPC-konflikter (ogil-tiga kombinationer) som finns i systemet. Antalet ogil(ogil-tiga kombinationer av FPC-parametrar varierar beroende på vilken ECU som testas. Desto fler FPC-FPC-parametrar och restriktioner, desto mer komplicerat blir det för testaren att skriva bra och gil-tiga testfall.
Förutom detta, är det i dagsläget svårt för testaren att få en bra uppfattning om testfallens kvalité. Det är också svårt att få en bra överblick över hur bra en testsvit egentligen är och om det finns ett behov av att lägga till fler testfall till testsviten eller inte.
Testning av PSM går idag till så att testaren läser igenom ECU-specifikationen och bestämmer parametersättningar som anses lämpliga att implementera i form av testfall. Varje testfall är en kombination av FPC-parametrar och motsvarar en parametersättning av ECU:n. När ny ECU-mjukvara släpps måste PSM-uppdateras för att kunna stödja de nya möjliga parametersättningarna. Detta innebär också en uppdatering i testsviten för PSM genom att nya testfall som testar den nya parametern läggs till.
Men det räcker inte med att bara testa den nya parametern — även gammal funktionalitet måste verifieras. Detta görs genom att den gamla testsviten exekveras på den nya mjukvaran. Sedan jämförs det nya testresultatet med det gamla testre-sultatet från den senaste PSM-releasen, för att bekräfta att gammal funktionalitet fortfarande fungerar efter att den nya parametern har introducerats.
Det är inte rimligt att testa alla kombinationer av FPC-värden. Växellådans ECU har 19 FPC-parametrar och ett genomsnittligt antal FPC-värden på 28 per
KAPITEL 2. BAKGRUND
FPC-parameter. Anta att en testsvit som testar alla kombinationer av FPC-värden skapas, samt att ett testfall tar mellan 10-20 (i snitt 15) sekunder att exekvera. När ett testfall exekveras genomförs en parametersättning som tar en stor del av den totala tiden, därav den relativt höga exekveringstiden per testfall. Exekve-ringstiden beror för övrigt på flera faktorer som t.ex. antalet FPC-parametrar och FPC-värden. Testsviten skulle då bestå av mer än 2819 testfall och ha en uppskat-tad exekveringstid på mer än tusen miljarders miljarder år. Detta är ett exempel på kombinatorisk explosion vid testning av PSM och bekräftar att endast en delmängd av FPC-kombinationer kan testas.
2.13
Syfte och mål
Syftet med denna studie är att hitta en systematisk testmetod för testning av PSM. Målet är att hitta en metod som på ett effektivt sätt väljer ut en lämplig testsvit med testfall som har stor sannolikhet att fånga potentiella fel innan PSM används i produktion.
2.14
Begränsningar
Detta examensarbete är begränsat till att endast testa FPC-parametrar och inga övriga parametrar som PSM består av. Alla tester som beskrivs i denna rapport utförs på en och samma ECU (klimatanläggningens), av praktiska skäl. I denna rapport antas det också att alla parameterkonflikter är givna, eftersom informatio-nen om ogiltiga parametersättningar finns tillgänglig idag och troligen kommer att kunna utnyttjas mer effektivt av PSM-testerna i framtiden.
2.15
Relaterat arbete
Studier gjorda på en delmängd av Nortels interna e-mail system visade att en test-svit, genererad med AETG, lyckades täcka 97% av alla kodgrenar (brancher) med färre än 100 giltiga och ogiltiga testfall [21].
Telcordia Technologies (tidigare Bell Communications Research) erfarenhet är att 2-wise-testning är tillräckligt för att få bra kodtäckning och kontrollerandet av interaktioner mellan systemfunktioner [27].
Mätningar gjorda på 10 Unix-kommandon visade att 2-wise-testning gav en block (statement) coverage på högre än 90% [28].
Jämfört med ett traditionellt företag som skulle använda kvasi-fullständig test-ning, skulle ett innovativt företag som använder en kombinationsstrategi kunna re-ducera den schemalagda systemtesttiden med 67% och spara 67% i arbetskostnader för testning [27].
I NASA:s databasapplikation var 67% av felen triggade av bara ett parameter-värde, 93% av två parametervärden och 98% av tre parametervärden [29].
Kapitel 3
Utförande
3.1
Välja ECU
En ECU är ett inbyggt system som kontrollerar de elektriska systemen i ett motor-fordon. Det finns många olika typer av ECU:er, allt ifrån de som säkerhetsställer en optimal drift i motorn till de som styr ventilationsfläktens hastighet i klimatan-läggningen.
Figur 3.1. Schematiskt diagram över testarkitekturen
KAPITEL 3. UTFÖRANDE
uppsättning parametersättningar utförs med hjälp av PSM.
Det finns allt från mycket komplexa till enklare typer av ECU:er. De komplexa har många parametrar och parametervärden (ofta med många ogiltiga kombinatio-ner), samtidigt som de enklare typerna bara har ett fåtal parametrar, vilket gör dem enklare att hantera och testa.
Den ECU som används för testexekvering i denna rapport är den som kontrolle-rar klimatanläggningen i ett fordon. Denna ECU hade ett lämpligt antal parametkontrolle-rar, vilket gjorde det möjligt att utföra tester i rimlig tid. Dessutom hade ECU:n ett relativt lågt antal FPC-kombinationer som var ogiltiga, vilket underlättade testge-nereringsprocessen. Se Figur 3.1 för ett schematiskt diagram över testarkitekturen.
3.2
Skapa en IPM
För att kunna tillämpa en kombinatorisk strategi är kravet att det finns en IPM som beskriver programmets indataparametrar.
IPM:en hade en ett-till-ett-mappning direkt mot FPC-parametrarna vilket re-sulterade i en tabell med en FPC-parameter per rad och ett FPC-värde per kolumn.
3.3
Mutationsoperatorer
En mutationsoperator beskriver syntaktiska förändringar på originalkodens pro-gramkod. Mutationsoperatorerna som har valts att användas i denna studie är baserade på dels Mothras operatorer och dels på fel som har gjorts tidigare och sannolikt kommer att göras av PSM-programmerare i framtiden.
Fyra mutationsoperatorer, som alla modifierar koden bara en aning, har valts ut och använts för att introducera fel i PSM-koden.
Mutationsoperator Beskrivning
MO1 Lägger till || true i en if-sats villkor. Resulterar i att uttrycket alltid blir sant
MO2 Lägger till && false i en if-sats villkor. Resulterar i att uttrycket alltid blir falskt
MO3 Ersätter != med ==
MO4 Ersätter == med !=
Tabell 3.1. Mutationsoperatorerna MO1-MO4
Mutationsoperatorerna i Tabell 3.1 skapar dock ibland två eller fler funktionellt likadana program, så kallade ekvivalenta mutationer. De ekvivalenta mutationerna måste hanteras separat och tas bort från listan av alla mutationer, för att beräkna mutationspoängen på ett korrekt sätt. I det här fallet var samtliga ekvivalenta muta-tioner funktionellt ekvivalenta med originalprogrammet, vilket gjorde dem omöjliga att döda med någon testsvit.
3.4. MUTATIONSGENERATORN
3.4
Mutationsgeneratorn
Det finns en mängd olika program/ramverk för mutationstestning som t.ex. Ja-valanche för Javaprogram [30] och Nester för C#-program [31]. Eftersom PSM är skrivet i programmeringsspråket Matrix har en mutationsgenerator speciellt ta-gits fram och utvecklats i detta examensarbete för att kunna skapa en uppsättning mutanter av PSM-koden. Mutationsgeneratorn skapar en uppsättning första ord-ningens mutanter av PSM-koden genom att först skapa en kopia av originalkoden och sedan applicera mutationsoperatorerna MO1-MO4.
En tidig version av mutationsgeneratorn (se Figur 3.2) producerade fler än 300 första ordningens mutanter för klimatanläggningens PSM-kod. Denna stora mängd mutanter skulle ha tagit orimligt lång tid att testa och därför togs det ett beslut om reducera antalet mutanter, trots att detta sannolikt kunde påverka testresultatets noggrannhet. Genom att introducera en slumpfaktor som slumpmässigt valde ut ca en tiondel av de 300 mutanterna reducerades antalet mutanter till 35.
FOR EACH Mutationsoperator DO
WHILE Så länge det finns nya mutanter att skapa Skapa en kopia av originalkoden till PSM Modifiera kopian med mutationsoperatorerna
Välj slumpmässigt ut ett heltal X mellan 1 till 10 IF X är lika med 1
Spara kopian (mutanten) som en separat fil ENDIF
ENDWHILE ENDFOR
Figur 3.2. Mutationsgeneratorns pseudo kod
3.5
Testgenerering och exekvering
Det finns en mängd olika verktyg tillgängliga idag för att generera testfall. I detta examensarbete användes verktyget PICT för att generera testfall, eftersom det var enkelt att använda och kunde exportera den generade testsviten till ett format som PSM:s testverktyg kunde läsa.
Varje gång en ny mutant av PSM-koden skulle testas, var det nödvändigt att ersätta denna manuellt. Med tanke på att varje testfall tog ca 15 sekunder att exekvera, tog det ca 24 timmar, dvs. ett dygn, att exekvera 2-wise testsvitens al-la testfall på samtliga 35 mutantprogram. För att undvika detta monotona och tidskrävande arbete, användes ett inspelningsprogram för mus- och tangentbords-rörelser. Programmet spelade in allt under tiden exekveringen av hela testsviten
KAPITEL 3. UTFÖRANDE
utfördes på den första mutanten. Detta arbete kunde sedan upprepas med hjälp av inspelningsprogrammet för de övriga mutanterna.
När exekveringen hade genomförts på samtliga mutanter, jämfördes resultatet för mutanterna manuellt med resultatet för originalkoden. Om resultaten var olika var det möjligt att konstatera att testsviten hade lyckats hitta det introducerade felet. Om resultaten var identiska hade testsviten inte lyckats hitta felet.
3.6
Kodtäckning
PSM-koden som användes för att parametersätta klimatanläggningens ECU bestod av 38 if-satser. Varje if-sats tilldelades ett nummer från 0 till 37. Precis i början av varje if-sats lades en utskrift till som skrev ut det tilldelade numret. Efter att en testsvit hade exekverats var det möjligt att manuellt gå igenom testloggen och notera vilka tilldelade nummer som hade skrivits ut. För varje tilldelat nummer som skrevs ut, fanns det också en if-sats som hade täckts. På det här sättet var det möjligt att mäta antalet if-satser som hade täckts i förhållande till det totala antalet if-satser i koden. Med hjälp av detta kunde testsviternas statement coverage erhållas.
Kapitel 4
Resultat
4.1
Kodtäckning
Den nuvarande testsviten som användes för regressionstest av PSM-koden bestod av 23 testfall. Dessa 23 testfall täckte 29 av de 38 if-satser som fanns med i koden, vilket är en statement coverage på 76%.
Testsviten med 1-wise-täckning bestod av 21 testfall. Dessa 21 testfall täckte 23 av de 38 if-satserna, vilket är 61% av koden. Detta innebär att den nuvarande testsviten täckte sex stycken if-satser fler jämfört med testsviten som hade 1-wise-täckning, vilket är positivt.
Testsviten för 2-wise-täckning bestod av 165 testfall, varav 36 av 38 if-satser täcktes. Testsviten gav då en statement coverage på hela 95% av if-satserna, dvs. sju if-satser fler jämfört med den nuvarande testsviten och 13 if-satser fler jämfört med testsviten med 1-wise-täckning.
Se Figur 4.1 för ett diagram över testsviternas kodtäckning i procent.
Figur 4.1. Stapeldiagram över kodtäckningen för den nuvarande, 1-wise och 2-wise
KAPITEL 4. RESULTAT
4.2
Mutationstestning
Med hjälp av mutationsgeneratorn skapades 35 stycken första ordningens mutanter av PSM-koden. Av dessa 35 mutanter, var 8 funktionellt ekvivalenta, dvs. produ-cerade samma utdata för varje indata och därmed omöjliga att döda med någon testsvit. De funktionellt ekvivalenta mutanterna upptäcktes i samband med att mu-tantprogrammets utdata med originalprogrammets utdata jämfördes. Om mutant-programmets och originalmutant-programmets utdata var likadant, var det möjligt att dra slutsatsen att mutationen i mutantprogrammet inte hade förändrat originalkodens funktionella beteende så att det var märkbart på programmets utdata. De ekviva-lenta mutanterna togs bort och resterande 27 mutanter användes för att exekvera testsviter på.
Den nuvarande testsviten, som bestod av 23 testfall, lyckades döda 25 av 27 mutanter, dvs. en mutationspoäng på 93% (se Figur 4.2), vilket är imponerande.
M S(P, T ) = 100 ∗ 25
35 − 8 = 93% (4.1)
Figur 4.2. Beräkning av mutationspoäng för den nuvarande testsviten
Testsviten med 1-wise-täckning bestod av 21 testfall och lyckades döda 24 av 27 mutanterna, dvs. 89% i MS. Vilket är en mutant färre jämfört med den nuvarande testsviten.
Testsviten med 2-wise-täckning, med 165 testfall, dödade samtliga av de 27 mutanterna och är då mutationsadekvat.
Testsviten med 165 slumpmässigt utvalda testfall lyckades också döda alla mu-tanter, även denna mutationsadekvat. För att få ett tillförlitligt resultat på en slumpmässig testsvit, bör testfallsgenereringen upprepas några gånger och ett sta-tistiskt medelvärde på de slumpmässiga testsviternas mutationspoäng och kodtäck-ning beräknas. I detta examensarbete genererades endast en slumpmässig testsvit på grund av begränsande tidsresurser.
Se Figur 4.3 för ett diagram över testsviternas mutationspoäng och Figur 4.4 för ett diagram över testsviternas storlek.
4.2. MUTATIONSTESTNING
Figur 4.3. Stapeldiagram över mutationspoängen för den nuvarande, 1-wise, 2-wise
och den slumpmässiga testsviten
Figur 4.4. Stapeldiagram över antalet testfall för den nuvarande, 1-wise, 2-wise och
Kapitel 5
Slutsats
5.1
Kodtäckning
Statement coverage har använts i denna studie för att få en uppskattning av hur mycket av PSM-koden som har exeverats för olika testsviter. Eftersom att det to-tala antalet if-satser i PSM-koden var känt samt att det var möjligt att utläsa antalet exeverade if-satser i testresultatet och kodtäcknigen kunde på så sätt mätas manuellt.
Den nuvarande testsviten presterade något bättre (15%) än testsviten med 1-wise-täckning (76% jämfört med 61%). Detta resultat var dock förväntat, eftersom varje parametervärde åtminstone testas minst en gång i något testfall för den nu-varande testsviten. I det här fallet testas varje parametervärde minst en gång, men det är dock fortfarande 24% (nästan 14) av PSM-koden som inte testats alls.
Testsviten med 2-wise-täckning täckte 19% mer av PSM-koden, jämfört med den nuvarande testsviten, och 34% bättre jämfört med testsviten med 1-wise-täckning. Med endast 165 testfall ger 2-wise testsviten en kodtäckning på imponerande 95%. 95% kodtäckning är också bara 5% sämre jämfört med om alla kombinationer av parametervärden skulle testas. Testsviten med 2-wise-täckning skulle dock ta 28-55 minuter att exekvera, jämfört med 4-8 minuter för den nuvarande testsviten.
Även om det tar ungefär 7 gånger längre tid att exekvera testsviten med 2-wise-täckning, sparas mycket tid på själva testgenereringen, eftersom den kan utföras automatiskt. Tiden som sparas på testgenereringen är svår att noggrant uppskatta — men att manuellt skapa en testsvit med 2-wise skulle vara nästintill omöjligt att genomföra i praktiken. Även skapandet av en testsvit med 1-wise-täckning skulle ta flera arbetsdagar eller veckor (beroende på bland annat ECU:ns komplexitet), jämfört med några minuter eller någon timme om PICT används.
Däremot finns det ECU:er som har fler parametrar och parametervärden än den för klimatanläggningen, vilket gör att testsvitens storlek ökar tillsammans med den totala exekveringstiden. Dock bör en testsvit aldrig ta länge än en natt att exekvera, även för ECU:er med många parametrar, vilket fortfarande är realistiskt.
dub-KAPITEL 5. SLUTSATS
belfel som kan uppstå mellan FPC-parametrar testas, vilket skulle vara mycket svårt och tidskrävande att uppnå med manuellt skrivna testfall. Det finns exempel där testaren har glömt att testa ett parametervärde helt, vilket naturligtvis kan leda till drastiska försämringar i både kodtäckningen och mutationspoängen. Ofta beror den här typen av fel på den mänskliga faktorn och kan undvikas genom att testgenereringen utförs automatiskt istället för manuellt.
5.2
Mutationstestning
Mutationtestning, som en felinjiceringsmetod, har använts i denna studie för att möjliggöra uppskattningen av olika testsviters förmåga att hitta fel i PSM-koden. För att introducera fel i PSM-koden användes en mutationsgenerator som speciellt har tagits fram i detta examensarbete för att kunna skapa en uppsättning muta-tionsprogram av PSM.
Den nuvarande testsviten med 23 testfall lyckades döda en mutant fler jämfört med testsviten med 1-wise-täckning, vilket är bra med tanke på antalet testfall. Testsviten med 2-wise-täckning, bestående av 165 testfall, lyckades döda samtliga 27 mutanter.
För att jämföra testsviten med 2-wise-täckning skapades en till testsvit med 165 slumpmässigt utvalda testfall. Den slumpmässigt utvalda testsviten lyckades, precis som testsviten med 2-wise-täckning, döda alla 27 mutanter. Att testsviten med slumpmässigt utvalda testfall och testsviten med 2-wise-täckning presterade lika bra, beror sannolikt på att 165 testfall är många testfall i relation till antalet mutanter. I en studie [32] hittades dock inte heller några signifikanta skillnader mellan feldetekteringseffektiviteten för testsviter med 2-wise-täckning och slump-mässiga testsviter med samma storlek.
Antagligen skulle ett noggrannare och mer korrekt resultat erhållits om tester hade utförts på en komplexare ECU, med ännu fler parametrar. Tiden att generera 2-wise och slumpmässiga testsviter med PICT skulle dock fortfarande ha varit liten jämfört med tiden det skulle ha tagit att skriva testfallen manuellt.
För att kunna särskilja de båda testsviterna skulle det antingen vara nödvändigt att skapa fler mutanter av PSM-koden eller använda sig av en ECU med fler para-metrar. Även om testsviterna dödar lika många mutanter i denna undersökning, så är det med stor osäkerhet som testsviten med slumpmässigt utvalda testfall används. Ibland kan den slumpmässiga testsviten prestera bra och ibland mycket dåligt. Till exempel finns det alltid en liten sannolikhet för att den slumpmässiga testsviten inte ens uppfyller kraven för 1-wise-täckning, vilket troligen leder till att testsviten dödar betydligt färre mutanter jämfört med om 1-wise eller 2-wise-täckning skulle uppfyllas.
Samtidigt som den slumpmässiga testsviten presterar olika bra från gång till gång, går det att veta säkert att testsviten med 2-wise-täckning alltid kommer testa alla kombinationer av par av FPC-värden.
5.2. MUTATIONSTESTNING
testsviten med 2-wise-täckning betydligt lämpligare att använda för att testa PSM-koden jämfört med den slumpmässiga testsviten.
Black-box-testning tillsammans med en testsvit som har 2-wise-täckning visar ett bra resultat, både med hög statement coverage och mutationspoäng, samtidigt som antalet testfall inte blir för högt för att vara opraktiskt. Testsviten med 1-wise-testning är inte tillräcklig för att hitta fel i PSM, med en förhållandevis låg kodtäckning och mutationspoäng, jämfört med testsviten med 2-wise-täckning. En testsvit med 3-wise-täckning däremot, bör prestera ännu bättre jämfört med test-sviten med 2-wise-täckning, men samtidigt innehålla alldeles för många testfall för att kunna vara användbart i praktiken. I andra fall, men inte för PSM, kan möjli-gen 3-wise- eller 4-wise-testning användas, men en högre testnivå har en signifikant påverkan på testsvitens storlek [33].
Eftersom regressionstestning är en viktig del i testprocessen idag, kan testarna med fördel definiera de gamla testfallen som finns i den nuvarande testsviten och ge det som indata till PICT. PICT kommer då kunna ta med de gamla testfallen och utöka denna testsvit till att ha 2-wise-täckning. På samma sätt är det möjligt att använda de nuvarande testfallen, de utökade testfallen som har 2-wise-täckning, samt de nya testfallen som behövs för att matcha eventuellt nya introducerade parametrar i en ny PSM release. Genom att göra detta går det att på samma sätt utföra regressionstestning på samma sätt som de har gjort tidigare.
White-box-testning kan utnyttjas effektivt genom att t.ex. använda sig av an-tingen den nuvarande testsviten eller testsviten med 1-wise-täckning, och sedan lägga till testfall för att täcka icke-täckta if-satser. För att göra detta är det nöd-vändigt att undersöka koden för att kunna försäkra sig om vilka if-satser som inte täcks, och sedan manuellt utöka testsviten med fler testfall. På detta sätt är det enkelt att komma upp i 100% kodtäckning med ett lågt antal testfall.
Men utnyttjas white-box-testning för konstruktion av testfall, får programspe-cifikationen aldrig ignoreras helt och hållet. T.ex. kan testaren ha glömt att imple-mentera en parameter helt i PSM-koden, som egentligen ska finnas med. Den typen av fel hittas inte om enbart programkoden utnyttjas vid skapandet av testfall, men hittas däremot om programspecifikationen används.
Det är generellt svårt att jämföra testsviters prestanda, men mutationstestning är ett sätt. Ett problem med mutationstestning är dock att mutationsoperatorerna inte alltid representerar riktiga fel. Andra problem med mutationstestning är också att fel som introduceras kan ibland förstöra programkoden helt eller påverka koden så lite så att felet blir omöjligt att hitta, så kallade ekvivalenta mutanter.
Även om mutationstestning har sina nackdelar är det ändå möjligt att erhålla en uppfattning om hur bra en testsvit egentligen är på att hitta fel. Även om muta-tionsoperatorerna är tänkta att representera riktiga fel som görs av programmerare i PSM, var det ändå svårt att komma fram till en liten mängd mutationsoperatorer som skulle representera de vanligaste felen.
I alla mjukvaruprojekt spelar testning en viktig roll och inte minst i testning av PSM. PSM används för att parametersätta ECU:erna i fordonen, vilket är ett mycket kritiskt skede i slutet av produktionen. Om en parametersättning inte visar
KAPITEL 5. SLUTSATS
sig gå att genomföra på grund av ett fel i PSM kan detta resultera i omfattande kostnader för Scania. Därför är det mycket viktigt med bra testsviter som lyckas hitta så många av felen som möjligt, inom rimlig tid, innan det är för sent.
5.3
Framtida arbete
Mutanterna kan förbättras genom att förbättra mutationsoperatorerna för att kun-na mäta testsvitens mutationspoäng i framtiden. Genom att alltid dokumentera fel som upptäckts vid testning kan testarna då och då se över vilka fel som ofta görs, och implementera dessa i form av mutationsoperatorer. På detta sätt är det möjligt att få en ännu bättre bild över vilken testsvit som är bäst att använda för att hitta just den typen av fel som görs i PSM-koden.
I denna rapport har olika testsviter med olika egenskaper används för att testa PSM. Testsviten med 2-wise-testning har visat sig vara bra, eftersom att den med ett rimligt antal testfall lyckats hitta många fel i PSM-koden. Den nuvarande test-sviten bör expanderas genom att lägga till fler testfall för att öka kodtäckningen och sannolikheten för att hitta fel. Med hjälp av PICT kan detta enkelt göras genom att definiera de nuvarande testfallen och sedan utöka med testfall för att uppnå 2-wise-täckning. När ny PSM-kod introduceras kan testaren lägga till nya parametrar i IPM-modellen och sedan generera en ny testsvit. Denna testsvit kommer då att innehålla de gamla testfallen samt en uppsättning nya testfall som testar de nya parametrarna.
Exekveringstiden för att köra en testsvit med 2-wise-täckning kommer att ta längre tid jämfört med den nuvarande testsviten. Detta bör dock inte vara något problem då större testsviter förslagsvis kan köras på natten och kortare testsviter under dagen.
Analys av testloggar och testresultat kan göras nästkommande dag och PSM-utvecklarna kan bli informerade om eventuella fel för att så snabbt som möjligt komma med en buggrättning. Rättningar i PSM-koden innebär självklart att regres-sionstestsviten måste köras om igen, eventuellt nästkommande natt, tills testarna är nöjda med testresultatet.
Tidigare tog det mycket lång tid att skapa nya testfall manuellt, men nu är det möjligt att automatiskt generera en testsvit som är betydligt bättre på att hitta fel i PSM, förutsatt att alla ogiltiga kombinationer är kända.
Litteraturförteckning
[1] K.N. King and A.J. Offutt. A Fortran language system for mutation-based software testing. Software: Practice and Experience, 21(7):685–718, 1991. [2] E. Allen. Bug patterns in Java. APress, 2002.
[3] M. Newman. Software errors cost US economy $59.5 billion annually. NIST
Assesses Technical Needs of Industry to Improve Software-Testing, 2002.
[4] J.P. Bowen and M.G. Hinchey. Ten commandments of formal methods... ten years later. Computer, 39(1):40–48, 2006.
[5] J.L. Lions et al. Ariane 5 flight 501 failure, 1996.
[6] M. Zhivich and R.K. Cunningham. The real cost of software errors. Security
& Privacy, IEEE, 7(2):87–90, 2009.
[7] D.M. Cohen, S.R. Dalal, A. Kajla, and G.C. Patton. The automatic effici-ent test generator (AETG) system. In Software Reliability Engineering, 1994.
Proceedings., 5th International Symposium on, pages 303–309. IEEE, 1994.
[8] G.J. Myers, C. Sandler, and T. Badgett. The art of software testing. Wiley, 2011.
[9] S. Ambler. Agile modeling: Effective practices. John Wiley&Sons, 2002. [10] S. Lauesen and O. Vinter. Preventing requirement defects: An experiment in
process improvement. Requirements Engineering, 6(1):37–50, 2001.
[11] G. Tassey. The economic impacts of inadequate infrastructure for software tes-ting. National Institute of Standards and Technology, RTI Project, (7007.011), 2002.
[12] A. Memon, I. Banerjee, and A. Nagarajan. What test oracle should I use for effective GUI testing? In Automated Software Engineering, 2003. Proceedings.
18th IEEE International Conference on, pages 164–173. IEEE, 2003.
[13] A. Nechypurenko, E. Wuchner, J. White, and D. Schmidt. Applying model intelligence frameworks for deployment problem in real-time and embedded systems. Models in Software Engineering, pages 143–151, 2007.
LITTERATURFÖRTECKNING
[14] S. Boxcar, M. Richardson, and U. Sandell. Motorsimuleringav CAN-buss. 2003. [15] M. Grindal. Handling combinatorial explosion in software testing. Department
of Computer and Information Science, Linköpings universitet, 2007.
[16] M. Grindal, B. Lindström, J. Offutt, and S.F. Andler. An evaluation of com-bination strategies for test case selection. Empirical Software Engineering,
11(4):583–611, 2006.
[17] M. Grindal, J. Offutt, and S.F. Andler. Combination testing strategies: a survey. Software Testing, Verification and Reliability, 15(3):167–199, 2005. [18] M. Grindal and J. Offutt. Input parameter modeling for combination
strate-gies. In Proceedings of the 25th conference on IASTED International
Multi-Conference: Software Engineering, pages 255–260. ACTA Press, 2007.
[19] M. Grindal, J. Offutt, and J. Mellin. Managing conflicts when using combi-nation strategies to test software. In Software Engineering Conference, 2007.
ASWEC 2007. 18th Australian, pages 255–264. IEEE, 2007.
[20] J. Czerwonka. Pairwise testing in the real world: Practical extensions to test-case scenarios. Microsoft Corporation, Software Testing Technical Articles,
2008.
[21] K. Burr and W. Young. Combinatorial test techniques: Table-based automa-tion, test generation and code coverage. In Proc. of the Intl. Conf. on Software
Testing Analysis & Review. Citeseer, 1998.
[22] D.M. Cohen, S.R. Dalal, M.L. Fredman, and G.C. Patton. The aetg system: An approach to testing based on combinatorial design. Software Engineering,
IEEE Transactions on, 23(7):437–444, 1997.
[23] M.M. Tikir and J.K. Hollingsworth. Efficient instrumentation for code coverage testing. In ACM SIGSOFT Software Engineering Notes, volume 27, pages 86– 96. ACM, 2002.
[24] A.J. Offutt. Investigations of the software testing coupling effect. ACM
Trans-actions on Software Engineering and Methodology (TOSEM), 1(1):5–20, 1992.
[25] J Bieman, Daniel Dreilinger, and Lijun Lin. Using fault injection to test soft-ware recovery code. Final report of a CASI FY95 Technology Transfer Grant.
Fort Collins, Colorado, USA: Colorado Advanced Software Institute, 1996.
[26] Y. Jia and M. Harman. Constructing subtle faults using higher order muta-tion testing. In Source Code Analysis and Manipulamuta-tion, 2008 Eighth IEEE
[27] J. Huller. Reducing time to market with combinatorial design method testing. In Proceedings of 10th Annual International Council on Systems Engineering
(INCOSE’00) 2000, Minneapolis, MN, USA, 16-20 July 2000, 2000.
[28] D.M. Cohen, S.R. Dalal, J. Parelius, and G.C. Patton. The combinatorial design approach to automatic test generation. Software, IEEE, 13(5):83–88, 1996.
[29] R. Kuhn, Y. Lei, and R. Kacker. Practical combinatorial testing: Beyond pairwise. IT Professional, 10(3):19–23, 2008.
[30] David Schuler and Andreas Zeller. Javalanche: efficient mutation testing for java. In Proceedings of the the 7th joint meeting of the European software
engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, pages 297–298. ACM, 2009.
[31] Anna Derezinska and Karol Kowalski. Object-oriented mutation applied in common intermediate language programs originated from c#. In Software
Testing, Verification and Validation Workshops (ICSTW), 2011 IEEE Fourth International Conference on, pages 342–350. IEEE, 2011.
[32] Patrick J Schroeder, Pankaj Bolaki, and Vijayram Gopu. Comparing the fault detection effectiveness of n-way and random test suites. In Empirical Software
Engineering, 2004. ISESE’04. Proceedings. 2004 International Symposium on,
pages 49–59. IEEE, 2004.
[33] James Bach and Patrick Schroeder. Pairwise testing: A best practice that isn’t. In Proceedings of 22nd Pacific Northwest Software Quality Conference, pages 180–196. Citeseer, 2004.
