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

More documents

Recommendations

Info

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
Page 1 and 2: Analysverktyg för kod och test EDA
Page 3: under utvecklingen för att styrka
Page 7 and 8: 4. Empirisk studie För att unders
Page 9: Referenslista [1] van Emden, E., Mo

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

Create successful ePaper yourself

Delete template?

Save as template?