Analysverktyg för kod och test - Lunds Tekniska Högskola

Analysverktyg för
kod och test
EDA270 Coaching
Emil Einarsson
dt07ee3
2012-02-27

Abstract
Undertiden som man utvecklar programvara vill man på ett eller annat sätt kunna säga på
ett så enkelt sätt som möjligt att det man gjort funkar. Detta brukar man många gånger göra
med hjälp utav tester i olika former. För att underlätta testskrivandet och granskningen utav
den kod som blivit implementerad så brukar man använda sig utav någon form av
analysverktyg som kan presentera olika sorters data beroende på vad det är för sorts verktyg
och vad det är användaren önskar sig få fram. Denna studie fokuserar på analysverktyg för
testfall och därför används ett specifikt program, EclEmma [3], som en del av en empirisk
studie.
1. Inledning
I dagens samhälle finns det programvara inuti i princip allt elektroniskt som existerar.
Samtidigt som andelen elektronik med programvara ökar så ökar även komplexiteten utav
programvaran för dessa elektroniska apparater (tänk bara på hur mycket mobiltelefonerna
har utvecklats under de senare åren). Detta innebär att det blir svårare och svårare att på ett
enkelt sätt kunna säga att systemet fungerar som tänkt och det blir svårt att se om man
förstört gammal funktionalitet under vidareutveckling av en produkt. För att hjälpa till med
detta skriver man olika former utav tester, men att kunna skriva bra testfall som täcker in
alla krav som ställs på systemet så att man samtidigt håller koll på gammal funktionalitet
under utvecklingen av ny är svårt och kräver en hel del kunskap. Oberoende på om man
anser sig ha den rätta kunskapen eller inte för att skriva bra testfall så måste man ställa sig
frågan: ”Vet jag att de tester som görs på systemet verkligen testar all kod och innesluter alla
möjliga scenarion som kan inträffa?”. Detta för oss in på ämnet för denna djupstudie,
nämligen analysverktyg.
Den här artikeln är framtagen som en del i kursen ”Coaching av programvaruteam” vid Lunds
tekniska högskola och är tänkt att ge en djupare förståelse för analysverktyg, hur man väljer
rätt och hur man använder det på bästa sätt. I bakgrunden till alla åtaganden och slutsatser
inom kodning så kommer programmeringsspråket java att vara det enda språket i åtanke.
Detta för att det är det språket som använts i kursen och det känns därför mest logiskt att
utgå från det.
2. Bakgrund
När man testar system så brukar man tala om två olika sätt att testa, nämligen ”black-box
testning” och ”white-box testning” [2]. Black-box innebär att man inte vet något om hur
systemet är implementerat och utformar tester för att se att systemet utför det man vill att
det ska göra (typiskt exempel är användarscenarion). White-box däremot innebär att man
har tillgång till hur systemet är implementerat och testerna utformas för att se att alla
metodanrop och liknande ger de resultat som man förväntar sig (typiskt vad som utförs
2

under utvecklingen för att styrka att systemet fungerar). I denna artikel kommer vi endast
diskutera white-box testning.
För att undersöka hur testningen på ett system påverkas med hjälp av analysverktyg har en
undersökning gjorts under ett projekt som jag har varit coach för. Kursen som jag läste heter
”Coaching av programvaruteam” och ges som en valfri kurs det fjärde eller femte året på
civilingenjörsprogrammet för datateknik på Lunds Tekniska Högskola (LTH) och går ut på att
man ska lära sig hur man coachar ett utvecklingsteam både i teorin och i praktiken.
I samband med att det var en praktisk del i kursen så gick även en annan kurs parallellt med
denna som heter ”Programvaruutveckling i grupp”, eller kort pvg, som istället går ut på att
lära sig jobba i små team på 8 – 10pers och utveckla en produkt enligt modellen för Extreme
Programming (XP-modellen) [5]. Pvg-kursen ges andra året på datateknik på LTH så man kan
redan förutsätta att ev. kodvana bland deltagarna är relativt låg. Systemet som skulle
implementeras var ett system för att hantera tidtagning och resultatberäkningar för lopp
inom sporten enduro. Projektet var uppdelat i sex iterationer där varje iteration var en
långlabb (klockan 08.15 – 17.00) varje måndag plus ett planeringsmöte på två timmar varje
vecka.
Projektet gick som sagt ut på att använda XP-modell och därigenom TDD (Test Driven
Development) vilket betyder förenklat att man skriver testen för något man ska
implementera först och sedan skriver man den faktiska koden och ser att testerna går
igenom. Det är främst av denna anledning som det kändes naturligt att införa en studie över
hur arbetet påverkades i projektet med och utan ett analysverktyg. Därför fick gruppen som
jag coachade först arbeta utan hjälp utav något analysverktyg och för att under iteration 3
(tredje långlabben) införa ett analysverktyg och kolla på skillnaderna i hur mycket kod man
testade och hur bra den testades.
2.1 Analysverktyget
Det verktyg som användes vid undersökningen till denna artikel var en instickningsmodul till
utvecklingsmiljön Eclipse som heter EclEmma [3]. Instickningsmodulen har två olika
funktioner, dels kan man köra det på alla tester och då få fram hur stor andel av koden som
exekveras av de testfall som är skrivna. Det andra sättet är att starta instickningsmodulen i
samband med att man vill köra systemet och testa det manuellt, EclEmma lagrar då vilka
rader kod som man exekverar under tiden som systemet körs. När man sedan stänger ner
programmet presenterar instickningsmodulen data över hur stor andel utav koden som
exekverades vid användningen. Det är främst det första användningssättet som är intressant
i denna artikel, främst för dess enkelhet och för att det är den delen av instickningsmodulen
funktionalitet som används när man arbetar med TDD.
EclEmma valdes främst av den anledningen att jag använt mig av den instickningsmodulen
tidigare och kände därigenom till den och visste hur den fungerade. Rent teoretiskt sätt så
skulle man kunna tänka sig att det skulle vara relativt enkelt att lära sig ett annat
analysverktyg, men på grund av tidsbrist och annat som kommit i vägen blev det endast
3

EclEmma som kördes, så någon djupare analys mellan verktygen kommer inte tas upp i
denna artikel. Några exempel på andra verktyg som också testar code coverage är Clover,
JTest, Agitar och Cobertura [2].
3. Analysverktyg
Analysverktyg är olika former utav verktyg som man använder för att analysera det system
som man utvecklar. På vilket sätt verktyget analyserar och vad den presenterar för
användaren är helt beroende på vad det är för typ utav verktyg. Det finns relativt många olika
sorters verktyg och alldeles för lite tid att gå in på alla, därför kommer vi främst kolla på
analysverktyg för test och jämföra det med några andra verktyg som kollar på te.x. ”bad
smells in code” (ett uttryck som Fowler har myntat i sin artikel Refactoring: Improving the
Design of Existing Code [6]).
3.1 Analysverktyg för test
Med analysverktyg för test brukar man mäta hur stor andel av koden som man testar i
procent och kalla det för ”code coverage”. Det finns många olika sätt att mäta andelen
testad kod och därför är det en viktig detalj att ta reda på för det analysverktyg som man
tänker använda sig av. Det absolut vanligaste och enklaste är att verktyget kollar vilka rader
kod som blir exekverad av tester och vilka som inte blir det, som tillsammans bildar andelen
testad kod (code coverage). Ett mer avancerat sätt att mäta andelen testad kod är att
använda sig av ”multiple condition coverage”, vilket innebär att alla logiska uttryck granskas
så att de har blivit testade för både sant och falskt [4]. Lägg dock märke till att condition
coverage bara anser delar med logiska uttryck och inte annan kod, det vill säga den kommer
inte köra igenom och kolla så att all kod är testad, utan bara de logiska bitarna. Det är därför
vanligt att de båda kombineras i ett analysverktyg.
Oberoende av hur verktyget tar fram andelen testad kod så kommer det produceras ett
resultat som presenteras för användaren. Med hjälp utav detta resultat kan man som
utvecklare sedan skriva bättre testfall alternativt fler testfall där det behövs. Detta
underlättar utvecklingsprocessen i den mening att man i ett tidigt skede kan upptäcka
buggar (genom i detta fall inse vilken del av koden som man aldrig testar). Man bör dock se
upp med informationen som verktyget ger och inte bara blint skriva testfall så att varenda
rad blir uppfyllt eller så att alla logiska uttryck testas i alla möjliga kombinationer. Anser man
som utvecklare att det inte finns något behov av att testa en specifik del av koden så bör
man inte göra det. Hur stor del testad kod är inget som kunden i slutändan kommer bry sig
om i vilket fall som helst, utan bara hur bra systemet fungerar och att det är utan några
buggar.
Man bör också tänka på att om ett analysverktyg kan hitta delar av kod som är dåligt testad
så är det också sannolikt att det finns delar som är svagt testade på ett sätt som verktyget
inte kan hitta [4]. Dessutom är analysverktyg för bland annat code coverage något som
ensamt inte kan styrka att ett system alltid kommer att fungera, till exempel så innebär inte
100 % code coverage att systemet kommer fungera till 100 % av gångerna.
4

3.2 Andra analysverktyg
Utöver verktyg för test finns det även andra sorters analysverktyg som kollar på andra saker i
koden. Ett bra exempel är verktyg som kollar efter så kallade ”bad smells in code”, kod som
luktar illa, det vill säga kod som är fult implementerat och svår att förstå sig på. Ett exempel
på ett sådant program är jCOSMO, som används för utvecklandet av artikeln ”Java Quality
Assurance by Detecting Code Smells” [1]. Sådana verktyg har dock en skild problematik inom
sig i förhållande till verktyg som testar code coverage. Främst har vi problematiken att
illaluktande kod främst är något subjektivt som kommer från erfarenheter och åsikter och
därför kommer i regel inte en person tycka att ett kodstycke ”luktar illa” som en annan
person kanske tycker det gör. Vad som är tanken med den här sortens analysverktyg är att
istället för att tala om för användaren att de här delarna har du inte testat, så ska
användaren istället få upp ett resultat på delar som eventuellt kan vara dåligt skrivna
och/eller som behöver refaktoriseras.
Ett konkret exempel på hur man kan hitta olika typer av illaluktande kod med verktyget
jCOSMO (som letar efter illaluktande kod) är med hjälp av instanceof[1]. Med instanceof
menas att man kollar koncentrationen av instanceof operatorer i ett och samma kodblock
och om det är en väldigt hög koncentration så dras slutsatsen att det kan vara bra att införa
en arvs-hierarki eller att man bryter upp metoden i mindre metoder som får en uppgift
istället för många.
3.3 Behovet av analysverktyg
Eftersom testning används för att bestämma och förbättra kvaliteten på mjukvara är det en
väldigt viktigt del i utvecklingen [1]. Det har även visat sig vara väldigt resurskrävande att
utforma tester för systemen och kostnaderna har visat sig ligga upp över 50 % av de totala
kostnaderna för ett systems utveckling [2]. Eftersom kostnaderna för testning ligger så högt
har man insett att verktyg är betydelsefulla för att göra denna process smidigare, mindre
resurskrävande och i slutändan kan det vara verktyget som är avgörande om systemet blir
färdigt till deadline. Kostnaderna kommer från att det tar ganska så lång tid att komma på
bra test och när man väl ska uppfylla dem så kan det hända att man måste skriva någon form
utav hjälpmetoder för att kunna testa specifika saker.
När kostnaderna för testningen är så höga har det även börjat utvecklas analysverktyg som
genererar testfall utan att utvecklaren behöver skriva några från början. Detta är mer
avancerade verktyg och om man inte har koll på vad det är för testfall som genereras så kan
det göra att koden inte testas på det sätt man tror. Utnyttjar man ett sådant verktyg får man
lägga ner tid på att granska testfallen som genereras istället, men huruvida det tar längre tid
att granska testfall eller att skriva dem själv från början är inget som kommer tas upp i denna
artikel. Alternativet är att man låter systemet generera testfall och sedan kör dem och sparar
undan resultatet för att få till regressionstestning. Efter att man gjort en ändring i koden kan
man kontrollera att systemet ger samma resultat för dessa testfall och samtidigt generera
nya.
5

3.4 Vad man vill uppnå
Med användandet av analysverktyg vill man uppnå så hög code coverage som man bara kan,
det vill säga så stor andel testad kod som det bara är möjligt. Tillsammans med det följer
även att man vill ha ett system som är så fritt från buggar som möjligt så tidigt i utvecklingen
som möjligt. Detta för att hålla kostnaderna nere eftersom det i regel är billigare att rätta till
ett fel innan systemet vuxit sig för stort eller efter att ett system har lanserats.
Fastän man anser sig vara noga vid testning och att allt ska vara testat så brukar man
rimligtvis ha en code coverage på mellan 60% - 70%, vilket brukar vara acceptabelt eftersom
det vanligtvis anses alldeles för resurskrävande att höja det över 60% [2]. Utöver detta vill
man sänka kostnaderna för testningsdelen av utvecklingen så att man kan leverera ett buggfritt
system snabbare och därigenom till ett lägre pris.
Snabbt och enkelt skulle man kunna säga att allt handlar om pengar (och då menar jag allt
här i världen), utvecklingen ska kosta så lite som möjligt så att cheferna blir glada och kan
sälja en produkt med så mycket vinst som möjligt samtidigt som kunden vill ha en produkt
till ett så billigt pris som möjligt. Aldrig är det någon som blir nöjd heller, utan man strävar
hela tiden efter att få eller skapa så mycket som möjligt för en så liten summa som möjligt.
En fråga som du som läsare bör ställa dig är: Hur skulle utvecklingen inom analysverktyg,
eller rent av all utveckling, se ut om det inte var effektivisering för att tjäna in pengar som
drev den framåt? Vad skulle annars driva den framåt?
3.5 Hur det kan gå fel
Code coverage är inget allvetande svar som presenteras på hur man bör förbättra sina test
för att säkra att systemet är helt testat och funktionellt. Code Coverage talar bara om vilka
rader kod som blivit exekverade av de test som finns och därigenom kan man inte göra
antagandet att hög code coverage säger att systemet är testat för alla tänkbara scenarion.
Samma sak inträffar om man implementerat funktionalitet på ett inkorrekt sätt och som
man sedan dessutom testar på fel sätt, då kommer hög code coverage inte alls säga något
om hur funktionellt och stabilt systemet är. Om man är duktig på att skriva bra testfall och är
noggrann med vad man sysslar med så borde det dock inte kunna inträffa, i den bästa av
världar. Vill man i det sistnämnda fallet garantera sig att systemet i sin helhet utför den
tänkta uppgiften så kan det vara lämpligt att fundera på eventuella ”Black-box tester”.
6

4. Empirisk studie
För att undersöka hur code coverage påverkas inom programvaruutveckling om man
använder sig av ett analysverktyg eller inte så infördes det i ett programvaruutvecklings
team i kursen ”Programvaruutveckling i grupp” som ges på LTH.
4.1 Undersökningen
Från start fick utvecklarna i teamet skriva testfall för systemet efter bästa förmåga utan hjälp
av några analysverktyg. Detta med anledning av att deltagarna i teamet gick andra året på
datatekniksutbildningen och därför inte läst så många programmeringskurser tidigare, så de
kunde behöva lite tid att komma igång med projektet när allt var nytt istället för att införa
allt på en gång. Förutom det hade deltagarna inte jobbat i större projekt tidigare och heller
aldrig använt sig av XP-modellen med tillhörande testdriven utveckling.
När deltagarna hade kommit igång bra och fått in en bra rutin på hur arbetet skulle flyta på
så ansåg jag det vara dags att införa analysverktyget till dem för att de skulle kunna börja se
hur mycket de egentligen testade. Vi hade nu kommit in på iteration tre, dvs. den tredje
långlabben i projektet.
4.2 Resultat
Redan efter den första iterationen så hade teamet åstadkommit en code coverage på 74 %,
som den för övrigt höll sig på mer eller mindre även under nästa iteration. Efter att ha
introducerat analysverktyget för deltagarna på iteration tre höjdes deras code coverage till
83%. Tillgången till ett analysverktyg som kunde tala om för användaren vad som hade
missats att testas var något som uppskattades inom teamet som jag coachade och som
synes på siffrorna så blev de motiverade till att skriva fler testfall för att försöka få så mycket
av koden testad som möjligt.
5. Diskussion
5.1 Allmänt
Först och främst är studien som utfördes inte särskilt generell eftersom den utfördes i
endast ett team mitt under utvecklingen och bara under utvecklingen av en produkt. För att
få en tyngre och mer styrkt studie så hade det varit vettigare att utföra samma sak parallellt
på alla team inom kursen och eventuellt även under flera år. Detta hade dock varit omöjligt
främst för min oförmåga att klona mig själv eftersom det hade krävt att jag varit delaktig i
alla andra team samtidigt som jag skulle sköta mitt eget. Förutom det hade det även krävts
att coacherna för de andra teamen inte hade något att säga till om huruvida deltagarna i
deras team fick använda analysverktyg eller när de fick använda det. Man kan enkelt dra
slutsatsen att i det här sammanhanget hade studien inte kunnat utformas på något bättre
sätt.
7

Eftersom kursen är relativt liten och därmed har en begränsning så fanns det inte plats för
att under utvecklingen studera huruvida olika sorters analysverktyg kunde ha en inverkan på
hur bra systemet fungerade eller hur bra code coverage som uppkom. Hade iterationerna
varit längre och projektet i sig varit längre hade man kunnat tänka sig att införa att under
varje iteration testa ett nytt analysverktyg för att sedan jämföra hur resultatet blev från en
iteration till en annan. Men även det sättet att gå tillväga har sina brister för vad säger att
svårighetsgraden och de problem man måste slåss med är lika stora i varje iteration?
5.2 Analysverktyg
Analysverktyg är ett väldigt kraftigt hjälpmedel under en utveckling, så länge som man vet
hur det ska användas och man är införstådd i hur det fungerar. Vet man inte det så hade
man nog klarat sig bättre utan det. Analysverktyg är heller inget som hjälper en användare
att garantera att systemet fungerar. Är till exempel testerna dåligt testade och bara
utformade för att skapa så hög code coverage som möjligt så kan det mycket väl vara så att
det uppkommer buggar senare i utvecklingen som man inte har funderat på. Detta hade vi
tydliga exempel på i vårt team där deltagarna lyckats uppnå en relativt hög code coverage,
men när det efter iteration fyra önskades en testrelease av systemet till mig och min
coaching partner, så upptäckte vi att systemet inte alls fungerade som det var tänkt längre.
På något sätt har deltagarna lyckats skriva testfall för att testa så att specifika delar av
systemet fungerar, men inte alls tänkt på att testa så att allt fungerar tillsammans. Vilket är
ett otroligt bra exempel på att man inte ska lita blint på att fungerande tester innebär att ett
system fungerar till 100 %.
I artikeln “A survey of coverage based testing tools” tas det upp att 60 % - 70 % är en rimlig
siffra för cod coverage, vilket dock kan uppfattas som ganska lågt i ett projekt där man
implementerar TDD, det vill säga alla test skrivs först innan något implementeras. Detta kan
man se genom att vårt team hade en code coverage på 74 % utan att använda sig av något
verktyg och med hjälp av ett lyckas höja det med 10 % utan några vidare svårigheter. Sen
huruvida vårt projekt är för litet eller för enkelt för att man ska kunna dra den
generaliseringen eller inte är svårt att avgöra. Man skulle kunna tänka sig att efter hand som
att ett system växer sig större blir det svårare och svårare att testa och även om det är
meningen att man ska skriva testfall för allt, så är det inte alltid lätt eller rimligt att testa allt.
Det blir nog svårare och svårare att få hög code coverage efter hand som systemet blir större
och dess komplexitet ökar.
6. Slutsater
Analysverktyg är viktiga hjälpmedel för att öka produktiviteten under utvecklingen av
programvara. För att de ska vara användbara är det viktigt att folk lär sig hur de fungerar
innan de använder sig av dem och att de som använder dem inte litar blint på allt som
verktyget säger utan istället mer ser det som en rekommendation.
8

Referenslista
[1] van Emden, E., Moonen, L. (2002). Java quality assurance by detecting code smells,
Reverse Engineering, 2002. Proceedings. Ninth Working Conference on, s. 97-106.
[2] Qian Yang, J. Jenny Li, David Weiss. (2006). A survey of coverage based testing tools,
Proceedings of the 2006 international workshop on Automation of software test.
[3] EclEmma. Retrived 6 December 2011, from http://www.eclemma.org
[4] Brian Marick (1997). How to Misuse Code Coverage, Retrived 6 December 2011.
[5] Kent Beck (2002). Embracing change with extreme programming, IEEE Computer, s. 70-77.
[6] M. Fowler (1999). Refactoring: Improving the Design of Existing Code. Addison-Wesley.
9