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

More documents

Recommendations

Info

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
Page 1 and 2: Analysverktyg för kod och test EDA
Page 3 and 4: under utvecklingen för att styrka
Page 5: 3.2 Andra analysverktyg Utöver ver
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?