Automatisk generering av enhetstester

Transkript

1 Automatisk generering av enhetstester Av Christoffer Stengren 05/

2 Innehållsförteckning Abstrakt Introduktion PVG projekt: Vad finns det för verktyg? Hur fungerar verktygen? Slumptestning Mer avancerade metoder Hur bra är verktygen och fungerar de att använda i industrin? Tidsbesparande och code coverage Buggar i testad och använd programvara I industrin Experiment på student team Egen teori och utförande Vilka buggar teamet kan behöva hjälp att hitta Resultat av användning i PVG projekt Slutsats Hur verktygen fungerar Randoop DART JCUTE SAGE Code Pro Analytix Referenser Appendix Listning av verktyg Enkät...16

3 Abstrakt I denna rapport kommer jag att ta reda på mer om Automatisk generering av enhetstester. Jag kommer gå igenom vad det finns för verktyg och hur dessa fungerar. Hur effektiva och hur bra de funkar kommer också att tittas på. En studie på studenter kommer genomföras för att bland annat se på implikationerna av att använda en sådan programvara som generar automatiska enhetstester. Lite speciellt är att det att projektet använder sig av XP. Följaktligen kommer en studie göra på om det fungerar att kombinera ett sådant verktyg med XP. Dessutom kommer frågor att att svaras på gällande om vi faktiskt behöver automatiskt enhetstestning. Hjälper det ett teamet att hitta buggar? Sparar det tid? Men kanske viktigast, påverkar detta användandet av TDD negativt eller används det fortfarande på ett bra sätt? Kommer det att påverka arkitekturen och förståelse för själva programmet? Hur blir det med TDD tänket, försvinner det helt? 1. Introduktion Något som är mycket vanligt för utvecklare och studenter är att testning kan vara krånglig och bråka med en. Det har många gånger hänt att en person har skrivit många rader kod och sedan när man testar fungerar det inte. Var ska man då börja när man ska reda ut det? Något som dock ofta gör situationen bättre är TDD. Det gör det hela mycket enklare. Tyvärr händer det dock att även när TDD används missar man att testa saker på grund av att man kanske inte insåg att ett testfall just fanns. Dessutom händer det att just skrivandet av testerna försvinner på grund av brist av tid. Detta kan leda till problem även om tänket som man får från TDD kanske fortfarande finns kvar. Men skulle det inte bli mycket enklare om man kunde använda ett verktyg som testade åt en och sa ifrån att här är det fel? Men i så fall krockar det inte med TDD och dess egenskaper? Gör det så att exempelvis test first inte används då man anser att man kan använda verktyg till testning istället? Missar man på sätt design av arkitektur som man får av test first? Sätter man för mycket tillit till verktyget och på så sätt skippar test? Går det att ens kombinera det på ett bra sätt? Finns det sådana här verktyg och i så fall hur fungerar de? Hur effektiva, både i tid och bugg fynd, är de? Jag blev mycket nyfiken på detta då just testning spelar en så stor roll inom utveckling av programvara. Jag valde därför att ha min djupstudie inom just det området, nämligen inom automatiserade enhets tester. Metoden som kommer används är att med hjälp av litteraturen som finns ta reda på mer och svara på frågor som existerar inom området. Exempelvis vad det finns för verktyg och hur de funkar. Eftersom det finns en tillgång till team av andra års och tredje års elever på 8 personer i ett projekt kallad PVG projektet kommer det team dessutom att användas i studien. Teamet kommer få använda sig av ett sådant här verktyg så att en utvärdera kan sammanställas på kombinationen av XP och detta verktyg. Genom att jämför teamets resultat med andra team som också gör PVG projektet kan man kanske se om det har hjälpt dem. Genom att dessutom ge dom en enkät där de själva får skriva hur de tyckte användning av verktyget hjälpte dem eller hindrade dem, kommer det förhoppningsvis att leda till att man kan få svar på vissa frågor om det fungerar att kombinera med ett XP projekt.

4 Detta tillsammans med litteraturen kommer troligen leda till att åtminstone en någorlunda slutsats kan dras. 2. PVG projekt: Som tidigast andra års elev på civilingenjörs programmet i datateknik vid lunds universitet kan man läsa en kurs, EDA60, som kallas PVG projektet. Kursen är uppdelad i två olika delar. I den första delen som går på hösten går man igenom teori för projekt delen. Projektet är den andra delen i kursen och går på våren. Meningen är att eleverna ska få testa på att göra ett projekt i del två, med fokus på XP. Nödvändig kunskaps lärs ut och även ett litet test görs för att testa elevernas kunskaper, så att de är reda för projektet. Del två är som nämnt en projekt del där 8 personer bildar ett team och ska utveckla ett system inom Enduro race. Som fjärdeårselev har man valmöjligheten att välja Kursen EDA270, som är coachning av programvaruteam. Precis som den andra kursen har man först en teori del, och sedan en praktik del där två personer blir coacher för just ett sådant team av 8 utvecklare. Om man är intresserad att läsa mer om projektet och hur det går till hänvisas ni till exempel till Teaching Extreme Programming to Large Groups of Students, volym 74 år 2005, av Görel Hedin, Lars Bendix, Boris Magnusson. Om man inte är bekant med XP kan Kent Becks Embracing Change with Extreme Programming, Oct 1999 rekommenderas som en mycket god start punk. 3. Vad finns det för verktyg? Det finns faktiskt en hel del olika verktyg att välja på inom automatiserad testning. Det finns all från slumptestning till mer avancerade metoder för exempelvis java, C och C++. Ett flertal är dessutom open source och kan användas av alla. Genom en snabb sökning på google kan man hitta ett dussintal. Det är alltså mycket lätt att hitta verktyg, men frågan är så klart hur dessa fungerar. Mer om detta kommer snart. Om läsaren är intresserad att se en liten listning av en del verktyg som finns står det en sådan i appendix. 4.Hur fungerar verktygen? Det finns många olika sätt att göra automatiserad testning och vissa verktyg skiljer sig därför följaktligen sig åt. Därför kommer det beskrivas generellt hur dom allra vanligaste metoderna fungerar. För en mer detaljerad beskrivning av hur vissa av verktygen fungerar och vissa metoder finns det ett avsnitt i slutet för den intresserade läsaren. 4.1 Slumptestning Det allra enklaste sättet att automatisera enhetstest är helt enkelt att bara slumpa fram inputs och värden. Eftersom en dator är snabb kan den nämligen generera massor med sådana här slump test snabbt och på så sätt testa så mycket som möjligt. Problemet är att när man slumpar fram värden finns det risk att felaktiga inputs genereras som inte funkar alls. Det är vanligt att man används sig av någon slags analys i förväg för att identifiera vilken typ av inputs som ska göras på metoden. De tillsammans kallas även för black box fuzzing[1]. Ett annat problem med slumpning är att det kan vara en mycket liten chans att just ett värde slumpas

5 fram. Detta blir särskilt tydligt om man exempelvis har flera if-satser i rad som testar just en specifik sak. Detta leder till att en exakt följd av värden måste slumpas fram för att alla vägar ska gå igenom. 4.2 Mer avancerade metoder För att lösa detta kan man använda sig av bland annat dynamisk test generering. Detta innebär helt enkelt att man analyserar exempelvis if-satser och tar reda på vad som står inuti dem[2]. Detta gör att man kan skapa restriktioner utöver vad som står i en sådan if-sats. Genom att bygga upp ett set av sådana här restriktioner har man allt man behöver veta för att kunna köra igenom alla grenar. Man löser helt enkelt dessa restriktioner och ser till att input värdena får de värdena man vill ha för att just testa en gren. Resultatet blir att man får en heltäckande test täckning av koden. Det är mycket vanligt att verktyg kombinerar både slumtestning och lite mer avancerade metoder för att få så bra resultat som möjligt. Det är också vanligt att man använder sig av förutbestämda heuristiker. Exempelvis använder sig verktyget SAGE[3] och Code Pro Analytix[4] sig av det. Kort sagt innebär detta att man använder sig av förutbestämda tekniker för att ta reda på vilka värden som kan komma att användas i exempelvis en switch case sats. Dessa värden används sedan för att testa den. Ett problem som ibland uppstår är att testerna inte ser på relationer mellan exempelvis olika metoder. Detta gör att värden som egentligen inte kan skapas testas ändå, samt att man ser inte på vad det betyder att en metod använder sig av en annan. För att testa detta har det utvecklats en metod som kallas White box fuzzing. White box fuzzing som bygger på black box fuzzing använder sig också det senaste inom dynamisk test generering, och har den utbyggda funktionen att den också kan fungera på hela applikationer och inte bara på enskilda kod stycken[1]. Detta används i exempelvis verktyget SAGE som vi kommer se mer av senare. 5.Hur bra är verktygen och fungerar de att använda i industrin? Vi har nu sett vad det finns för verktyg och hur de fungerar. Vi ska nu istället titta mer på hur effektiva verktygen är och hur bra de dessutom fungerar. Hittar de buggar som tidigare inte fanns och fås en bra code coverage? Det är meningen att svar på dessa frågor ska ges i denna del av studien. 5.1 Tidsbesparande och code coverage. I en studie[5] testades manuell testning mot 3 olika verktyg, JUnit Factory, JCrasher och Randoop på 15 klasser. Vad som var mycket intressant var att den manuella testningen låg på 490 timmar medan ett annat verktyg hade så låg som 15 timmars testning. Man kan alltså potentiellt spara mycket tid på att använda sig av ett sådant verktyg. Även det verktyget som tog längst, Randoop, tog bara 165 timmar vilket fortfarande är en avsevärd mycket mindre tid. Detta gör att den intressant frågan uppstår om något liknande kan hända för PVG teamet. Kan det hjälpa dem att spara tid i projektet som sedan kanske kan lägga den på annat? Vad som också stod i studien var hur mycket code coverage och hur många tester som genererades. Vad som kunde ses var att det var en stor skillnad mellan verktygen. Det bästa verktyget gav en code coverage på nästan all kod medan det sämsta lite bättre än hälften. Vad som också var intressant var att det sämsta generade nästan tio gånger fler testfall. Det är alltså en stor skillnad mellan verktygen. Detta knyter ann till hur verktygen fungerar då det sämsta verktyget använder sig enbart av

6 slumptestning medan det bästa använder sig av mer avancerade metoder. Om man vill se de exakta siffrorna rekommenderas man att läsa studien. Vad som är intressant är att det verkar vara stor skillnad på vilket verktyg man använder sig av. Det som blir intressant är att om rätt verktyg väljs kan då det hjälpa teamet att få upp deras code coverage? Om man väljer ett verktyg som använder sig mer än slump testning kan man misstänka att så är fallet. Även om det inte ger perfekt test täckning kanske ett verktyg fortfarande ge bättre code covergage då det kanske testar delar av koden som ej var testad förut. En intressant fråga som uppstår. 5.2 Buggar i testad och använd programvara Code coverage är såklart bra, men om testerna bara testar bra saker, dvs om det funkar rätt, kan man få hög code coverage men buggar missas. Finns det några exempel på buggar som verktyg har hittat på redan testad och använd programvara? Svaret på det är ja, och nedan kommer ett par exempel på det med verktygen DART och JCUTE/CUTE. För att utvärdera DART industriella relevans testade man att använda DART på osip[2]. Detta är ett bibliotek för C som implementerar sessions initiation protocol, vilket används vid samtals upprättande av multi-media sessesioner över IP nätverk. Biblioteket består av ca rader C kod och finns att hämta exempelvis på GNU:s hemsida. Resultatet av en körning gav att det gick att krascha hela 65% utav alla funktionerna i biblioteket. DART hittade alltså väldigt många sätt att använda biblioteket fel. Dock var många utav dom null pointer problem och eftersom API inte är tillräckligt specificerad är det svårt att dra någon bindande slutsatser då kanske biblioteket är menat att inga null pointer referenser får finnas. Men det kan tyckas konstigt om så är fallet att en del funktioner kollar efter just att inte null pointer referenser finns medan andra inte göra det. På grund av detta valde man att fokusera på mindre delar. Man fick reda på att det gick att krascha parsen i biblioteket, vilket är en potentiell stor säkerhetslucka. Just detta ger en möjlighet att fjärr döda vilken SIP klient eller server som helst som förlitar sig på osip biblioteket för parsning av SIP meddelanden om inte klienten och server tar hänsyn till buggen. Detta fixades senare i version För att utvärdera hur bra JCUTE[6] och CUTE[7] funkade bestämde man sig för att testa verktyget på SBLIB version och Sun Microsystems Java Collection Framework. SBLIB är ett populärt open source verktyg och har exempelvis använts till att implementera Xrefactory, som är en kommersiell programvara. CUTE hittade snabbt 2 buggar i biblioteket, trots att biblioteket redan använts kommersiellt. Buggarna rapporterades och utvecklarna bekräftade att buggarna verkligen fanns. När JCUTE testades på Java Collection Framework var förväntningarna på att hitta nya buggar mycket låg då biblioteket redan var mycket populärt. Dessutom stod det i JAVA DOC AIP:n att många av data strukturer redan var trådsäkra. Men när verktyget kördes hittades ett flertal odokumenterade buggar i systemet. Flera data races, deadlocks, ofångade exceptions, och en oändlig loop hittades. Det intressanta av det vi har sett är att det visar att det finns en potentiell nytta att använda sig av ett sådant verktyg i exempelvis ett PVG team. Att buggar hittades i redan använd programvara bodar mycket väl för användning av ett sådant här verktyg. Kan något liknande hända för teamet? 5.3 I industrin När vi kollade hur effektiva verktygen var kunde vi se att även på använd och testad programvara som används ute i industrin kunde verktygen ändå hitta nya odokumenterade buggar. Dessutom kunde de hjälpa en att spara tid. Även om många av verktygen är experimentella och inte har direkt använts i industrin så har experimenten med verktygen gett bra resultat. Det kan alltså vara värt att i framtiden titta noggrannare på sådana här verktyg av företagen. Men det finns ett mycket bra

7 exempel på då ett sådant här verktyg har använts och används än i dag. Det är verktyget SAGE som dagligen används av Microsoft för att hitta nya buggar i deras programvara. SAGE har använts sedan 2007 och har körts på allt från image processors till media spelare[1]. Kanske det mest notabla är att SAGE stod för att hitta en tredjedel av buggarna som hittades med file fuzzing i windows 7. Eftersom SAGE körs sist är detta buggar som inte har hittats tidigare. Upptäckten av dessa buggar har sparat Microsoft miljoner dollar och mycket tid och har lätt till att SAGEs körs sedan 2008 dygnet runt. SAGE är alltså ett mycket bra exempel på hur en sådan här automatiskt testning programvara kan både spara tid och pengar, men också göra programvaran bättre då buggar hittas tidigt innan programvaran börjar användas kommersiellt. Ett annat intressant exempel är en action research som gjordes på det kommersiella SCADA, vilket används av flera klienter i Nordamerika. SCADA kallas även för ett Rocket Monitoring and Control Platform [8]. Forskningen gick ut på att skapa ett automatiskt test genererings program för just det raket system. Resultatet var att man estimerade att runt 138 timmar sparades genom att använda sig av detta program istället för att testa manuellt. Dock krävs fortfarande mer forskning på utbytet mellan fel detektering effektivitet och effektiviteten av code coverage. Dvs fler bra test men mindre code coverage mot mindre bra test men mer code coverage. Eftersom så stora företag som Microsoft har haft framgång med att använda sig av automatiserad testning stärker det ytterligare att användandet av ett sådant verktyg bodar väl för ett PVG team. Men Microsoft är ett stort företag och har mycket erfarenhet. Kan verkligen ett helt nytt team, som dessutom måste lära sig ett helt nytt koncept med XP, ha samma framgång? Det är en fråga som uppstår och som kommer tittas närmare på. 6. Experiment på student team När man tittar på effektiviteten och även på de tester som har gjorts på de olika test verktygen ser det mycket lovande ut att använda sig av ett sådant här verktyg i studien. Även de fall då de har använts i industrin har det haft positiva resultat. Därför kan man misstänka att det också skulle funka i ett PVG projekt. Men hur fungerar det med XP och TDD som används i projektet? Kanske kan man kombinera båda och får det bästa av varje? Vi kommer nu att titta närmare på experimentet på student teamet och ta reda på exempelvis designen man får av TDD påverkas. Först kommer min egna teori på om det kan gå och i så fall hur. Sedan kommer jag med hjälp av det lägga upp hur användandet av verktyget kommer att utföras av teamet. 6.1 Egen teori och utförande Enligt min egen teori skulle det funka att kombinera på ett bra sätt genom att använda sig lite av båda. Man börjar som vanligt med test first och sedan implementerar. När detta är klart kör man sedan verktyget för att hitta eventuella buggar och fel efter man känner sig klart med testningen och implementeringen. Detta ger förhoppningsvis två saker. För det första behöver inte utvecklarna lägga allt för mycket tid på att förespå buggar då ett bra verktyg skulle kunna hitta sådana. Mer tid kan då istället läggas på att exempelvis dubbelkolla testerna eller till renfaktorisering av koden. För det andra ger det en mer skärhet för teamet då man vet att bra tester har gjorts vilket kan hjälpa teamet till att våga göra mer, exempelvis större renfaktoriseringar. Eftersom verktyget bara används sist behåller man tänket med TDD före man skriver kod och skapandet av arkitektur med hjälp av test first då detta fortfarande används. Förhoppningsvis hjälper det också till att ge bra tester och bra code coverage. Jag tog därför beslutet att låta teamet jag coacher få testa på ett sådant här verktyg. Jag pressenterade tre olika verktyg för teamet, Tpalus, Code Pro Analytix och Randoop. Dessa fick sedan två studenter fick en spike på att testa vilket verktyg de ville ha. De valde Code Pro Analytix

8 eftersom de tyckte att verktyget var mycket enkelt att använda och det gick dessutom att skaffa som plugin in till eclipse. Utvecklarna använder sig nämligen av eclipse och ansåg att det var ett bra val. Dessutom testade verktyget mer än Raandop som också fanns som eclipse plugin. Om man som läsare är intresserad av hur Code Pro Analytix fungerar refererars läsaren till appendix. Eftersom verktyget är ett eclipse plguin och är enkelt att använda sig av kan teamet förhoppningsvis direkt gå på att använda sig av det istället för att spendera tid på fundera ut hur det funkar. Utförandet kommer ske på följande sätt. Utvecklarna kör som vanligt enligt XP med exempelvis test first. Sedan när de känner att de är klara med implementeringen och testningen kommer de sedan att köra själva verktyget som en dubbelkoll. Ett förslag lades fram till utvecklarna under kursen att ha det som krav att köra verktyget innan en story kunde flyttas till steget Done Done. Förslaget godkändes och följande restriktion lades till. För mer om Done Done refereras läsaren till exempel till J. Shore, S. Warden: The Art of Agile Development där det står tydligt vad som menas med Done Done. 6.2 Vilka buggar teamet kan behöva hjälp att hitta Verktygen som finns tittar mest på två olika sorters buggar. Den ena är fel i inputsen och den andra är fel i koden. Detta blir mer klart om man läser den mer detaljerade delen om hur verktygen fungerar att just dessa är i fokus. Fel i inputen, exempelvis ett null objekt som en input till en metod, brukar vara mycket enkla att glömma bort att testa. Därför är förhoppningarna är att verktyget ska hjälpa dem att hitta sådana. Om verktyget testar fall med exempelvis null objekt kommer det att fungerar som en påminnelse att också hantera det fallet då ett test fallerar på grund av det. Fel i koden, som kan exempelvis uppstå av att en del av koden kraschar programmet när den körs, är också något teamet kan behöva hjälp att hitta. Men eftersom det ofta blir uppenbart rätt snabbt med sådana problem behöver teamet antagligen inte lika stor hjälp att hitta dem. Fel i koden är oftare lättare att se eftersom du själv precis har skrivit koden. Dessutom ska man förhoppningsvis fortfarande testa som vanligt med test first. Då borde de flesta sådana här upptäckas. Medan med inputs kan det vara så att man bara får ett fel input i specialfall som bara händer ibland. Och om det glöms bort att testas kan det plötsligt synas när du minst anar det. Men även i koden finns det såklart specialfall som kanske bara körs ibland som förhoppningsvis verktyget hjälper till att hitta. 6.3 Resultat av användning i PVG projekt När man jämförde med andra team är det svårt att se om verktyget hade någon speciell inverkan. När man kollar på code coverage fanns det de team som hade mindre, men också de team som hade mer. Samma sak gäller med antalet test fall och vad de faktiskt testar. Eftersom teamet verkar ligga ungefär i mitten av allt kan man inte direkt se några tydliga resultat. När teamet skapades sattes de ihop slumpvis och följaktligen är också kunskapen mycket utsprid. Det är alltså mycket svårt att jämföra teamen åt då vissa team kan vara bättre än andra. Man får istället se mer på hur det påverkade själva teamet i sig, istället för att jämföra det med andra. Efter att teamet hade svarat på enkäten, som finns i appendix, kan man konstatera att användning av Code Pro Analytix i teamet gav både positiva och negativa resultat. I det hela verkade verktyget inte ha används full ut och två stycken ur de åtta uppgav att de i princip inte använde det alls. Eftersom teamet generellt kämpade med test delen i projektet blev det mycket för dem att också använda verktyget. Men alla var dock överens att det hjälpte dem att få upp test täckningen av koden. Fler tester blev också gjorda än vad som annars hade gjorts. Men problemet var att vissa tester som var genererade av verktyget inte var relevanta då det redan testades eller testade en sak som inte kunde ske. Detta relaterar till att Code Pro bara testar på kod stycken och inte hela applikationen. Intressant var att utav de som använde verktyget var det bara en som sa att inga buggar hittades. De

9 andra hittade buggar lite varierande, en del hittade mycket och en del få. De buggar som främst hittades var fel i if-satser som hade glömt att testa vissa utfall som kunde hända. Exempelvis testa så att ett object inte var lika med null. Verktyget verkar faktiskt ha hjälpt dem att hitta fel i koden och rätta till dem. Det påpekades också att verktyget hittade alla buggar som teamet själva hade testat för där det användes. På frågan om det sparade tid för teamet är svaret både ja och nej. Ungefär hälften av teamet som använda verktygen märkte att de sparade tid, medan den andra delen inte gjort det. Det är ett mycket intressant resultat att det kan vara så olika. Eftersom tid fick läggas på att gå igenom testerna och ta bort eller rätta till dem förlorades tid på detta. Vad som också påpekades var att eftersom Code Pro har en funktion som visar vilken del av koden som är testad, lades för mycket tid på att få allt testat enligt verktyget. Exempel var en tostring metod som testades och som fungerade bra, men som verktyget av någon anledning klagade på att den aldrig testades allt. Trots att metoden anropades och testades av verktygets egna tester, testades det fortfarande aldrig enligt verktyget. Onödig tid lades ner på att försöka fixa detta när det egentligen funkade bra. Som nämnt tidigare fanns det också irrelevanta test. Å andra sidan hade man att tid faktiskt sparades. Eftersom buggar hittades tidigare med verktyget slapp man att senare försöka leta igenom koden efter just dessa buggar. Man behövde inte heller skriva alla tester då verktyget fixade att testa mycket åt en. Dock påpekades det att det fanns en risk att man litade för mycket på verktyget m man lät verkytget göra allt. Men hur blev det med exempelvis test first och vad det ger? Gav det fortfarande design och tänket med TDD? Detta är är kanske det viktigaste frågan av alla, och tyvärr är det ett blandat svar. Utav de sex som använde sig av verktyget tyckte tre att det inte påverkades. Ytterligare en tyckte att det var tveksamt att det skulle ha påverkats. Enligt dem användes verktyget mer som en dubbelkoll och användes alltså sist. De skrev helt enkelt tester först och fick därav fortfarande TDD tänket med design och arkitektur före. Tyvärr var det två som tyckte test first användes mindre och att tänket påverkades. Eftersom de hade ett verktyg lade de istället en del av testningen på verktyget istället för att göra det själv. Detta gav i sin tur att de designade mindre innan och gick direkt på att koda. Intressant nog tyckte inget i teamet att användandet av verktyget hade påverkad teamet negativt. Eftersom det faktiskt hjälpte att få upp code coverage och att buggar hittades upplevdes det som antingen neutralt eller positivt. Dock är frågan om det verkligen inte var negativt för åtminstone två team medlemmar då TDD tänket påverkades för deras del. 7. Slutsats I det hela verkar det finns bra verktyg för att generera enhets test, men också de som inte fungerar lika bra. Det gäller alltså att kolla upp verktygen om man har för avsikt att använda sig av dem för att hitta ett som är tillräckligt bra för projektet du ska använda det på. Men de verktygen som fungerar bra verkar vara mycket välgjorda och mycket bra att använda sig av. Effektiva verktyg hjälper till att hitta buggar som inte tidigare har hittats. Dessutom kan de hjälpa en att potentiell spara en avsevärd mycket tid och pengar. Ett praktexempel på det är SAGE som används av Microsoft. I dagsläget verkar det dock inte vara så utspritt att använda sig av ett sådant här verktyg, men det det är något som jag tror kommer att ändras och kommer bli mycket mer utbrett i framtiden. I det hela verkar det vara mycket lämpligt att använda sig av ett sådant här verktyg och jag ser ingen anledning till att det inte kommer att sprida sig mer. Dock kan vara värt att ta med sig att inget verktyg hittar alla buggar än och dessutom kanske inte testar allt. Manuell koll är därför fortfarande nödvändigt. Att kombinera både manuell och verktyg verkar vara det bästa, vilket kan leda till som sagt tidsparning beroende på hur mycket man är beredd på att lägga på den manuella biten När man ser på resultatet av användningen av verktyget i PVG teamet är det svårt att dra en slutsats

10 när man jämför med andra teams prestation. Men om man istället ser på teamet i sig självt verkar det finns en viss glimt av att det kan fungera. En del av teamet verkade få en positivt erfarenhet och där TDD faktiskt inte påverkades. Tyvärr fanns det en del som påverkades negativ. Problemet var dock att de inte använda verktyget som det var tänkt, som en dubbelkoll. De förlitade sig istället för mycket på verktyget. Det kan tänkas att om de istället hade använt det så som det var tänkt hade det fått med TDD tänket. Eftersom hela XP metoden i sig är helt ny för studenterna var det mycket att ta in, vilket gjorde att mycket annat hade mer fokus. Om teamet hade varit mer erfaret kan det tänkas att mer tid kunde ha lagt på att faktiskt se till att använda verktyget rätt och att dessutom använda det mer. Tyvärr satte också verktyget i sig käppar i hjulet då det inte alltid fungerade som bäst. Slutsatsen blir följaktligen att det lutar åt att det faktiskt skulle fungera att kombinera XP och automatiserade enhetstester, men kanske för ett lite mer erfaret team och med ett bättre verktyg. Det lämpas sig kanske inte att använda sig ett sådant verktyg i ett projekt där XP är helt nytt. Utan det är bättre att koncentrera sig på att verkligen få in XP i projektet. När man har det på plats blir det mycket enklare att se till att ett verktyg faktiskt används på rätt sätt och det är först då man kan börja fundera på att introducera ett. Alltså är det kanske inte ett så bra val att använda sig av ett sådant verktyg i ett PVG projekt på grund av att så mycket nytt måste läras in. En studie skulle behöva göras på ett mer erfaret team behövas för att veta säkert, men glimtar om att det kan fungera har observerats.

11 8. Hur verktygen fungerar Randoop Randoop använder sig lite som namnet låter, slumptestning men med tillägg att den använder sig av feedback från exekveringen till att inte skapa nödiga och felaktiga inputs [9]. Verktyget fungerar så att den skapar sekvenser genom att slumpvis välja metod anrop att kalla och sedan väljs argument från föregående körda sekvenser så att feedback om eventuella felaktigheter används. Så fort en sådan har skapats exekveras den och testas så att den inte bryter mot ett set av contracts eller dåligt beteende som exempelvis illigalargumentexception. Denna kollen gör så att inte onödig a test som inte fungerar används. Men fortfarande är grunden i att bara slumpa fram test vilket kan leda till problem DART DART står för Directed Automated Random Testing och precis som det låter använder sig DART av slump testning, men tillsammans med dynamisk testning med symbolic reasoning [2]. Detta innebär att helt enkelt att värden, till exempel en integer, slumpas fram för testning, men också att symbolerna i exempelvis en if-sats analyseras så att alla grenar körs. När jag läste om detta hittade jag ett mycket bra exempel[2] som beskriver detta på ett bra sätt. Jag kommer därför att använda mig av just det exemplet. Tänk dig en if-sats där två integer värden, x och y, först testas så att de inte är lika. Sedan kommer en till if-sats i den första som kollar om f(x) = x + 10 där f(x) = 2x. Om så är fallet körs en abort kod för att simulera ett fel. Först används slumpning och två värden på x och y slumpas fram. I exemplet blev x = och y = Vi testar den första if satsen och ser att det inte är något problem alls. Det är en mycket liten chans att x = y. Problemet med slumpning är dock just det, att det är en mycket liten chans att ett värde är lika med ett annat. I vårt fall är det en liten chans att just f(x) = x +10 och den andra if satsen körs. Vi måste slumpa fram ett tal som precis stämmer med just detta. Ett annat exempel är om vi till exempel en integer på 32 bitar och vill testa om x = 10, så är chansen att vi faktiskt testar detta en på 2^32. För att lösa sådant här problem där if satserna måste testa ett värde som det är en liten chans att det faktiskt testas, kollar DART också på symboliken i if satser för att hitta restriktioner. I det första exemplet kommer vi först få för den första if satsen restriktionen x!=y, och sedan x*2!= x +10 för den andra if-satsen. Därefter räknas en lösning för restriktionerna ut genom att negera det sista predikatet för restriktion. I vårt exempel är x = 10 y = exempelvis en lösning då 2 * 10 = och 10!= Genom att kombinera både slumpvalda värden, men också sökning av förutsättnings vägar kan verktyget göra flera olika tester som ser till att gå igenom så många vägar som möjligt, och som bara begränsas av själva effektiviteten av verktyget själv JCUTE JCUTE använder sig av något som kallas concolic testing[6]. För att utföra denna concolic testning använder sig verktyget av en algoritm som exekverar ett program både konkret men också symboliskt. Det symboliska sättet skiljer sig från vanligt sätt då den följer de konkreta vägarna genom exekveringen. Efter en exekvering har verktyget samlat ihop en sekvens av symboliska restriktioner. En sådant sekvens kallas för väg restriktion. Detta innebär att om exempelvis en ifsats säger att a ska vara lika med b kan en väg restriktion vara a!=b. Detta ger oss att för varje värde där a = b kommer gå en väg, och för a!= b en annan. Eftersom verktyget också funkar på trådar tittar även verktyget på eventuella race conditions. Själva algoritmen fungerar så att först genereras slumpvalda inputs och eventuell schemaläggning

12 av trådar görs. Sedan exekveras koden med inputsen och det eventuella schemat. Under exekveringen räknas symboliska restriktioner och race conditons ut. Genom att sedan backtracka och generera nya inputs och scheman kan verktyget söka igenom alla möjliga vägar med hjälp av bredden först sökning. Eftersom algoritmen gör en konkret sökning kommer de buggar som hittas att faktiskt vara buggar, och inte exempelvis felaktiga inputs som inte fungerar. Så kallade överflöds test. Ett problem med JCUTE är dock att lösningen av vissa restriktioner inte är tillräckligt bra då själva programmet som löser dem inte är starkt nog. Detta leder till att en approximering används vilket självklart kan leda till att felaktigheter uppstår SAGE SAGE är en utbyggnad av DART och använder sig av precis som DART black box fuzzing och dynamisk testning med symbolic reasoning, men är utökad till att även använda white box fuzzing. Den dynamiska test genereringen är också utökad till att nu hantera stora applikationer. Dessutom är den optimerad för långa symbolisk exekvering på x86 binary nivå[10]. Whitebox fuzzing kan beskrivas som DART möter fuzzing, där Whitebox fuzzing använder sig av de senaste inom dynamisk test generering och kan köra på hela applikationer och inte bara mindre kod avsnitt [1]. Istället för att titta på en if-sats separat tittar SAGE på exempel en hel metod och dess användning i programvaran. Dessutom använder den sig av för definierade värden istället för att slumpa fram värden. Ett exempel[3] på hur det funkar är om du har fem if-satser där den sista beror på de andra. Varje if sats kollar om en array av char som skickas in till metoden har en specifik bokstav på en specifik plats i array:n, och då räknas en integer variabel upp. Om den variabeln är större än eller lika med tre körs den sista if satsen. I exemplet kollade if satserna tillsammans om char array = bad! där de fyra första if satserna kollade varsin bokstav i array:n. Den första if satsen kollade om det första tecknet var lika med b och så vidare. Vad som händer är att SAGE genererar ett träd med varje kombination av de 4 restriktionerna i if-satserna. Sedan sker en sökning där lösningen hittas i sökutrymmet. Exempel med inputen good testar den först good, sedan byta ut d mot! Och testar goo!, sedan d mot det sista o och testar godd. Den testar alltså varje kombination av ordet good med byte av karaktärer från bad!. Det är viktigt att notera att den bara testar kombinationer från bad! på ordet good, dvs bokstaven b kommer aldrig att finnas på o:ets plats i good utan bara som en möjlighet på g:ets plats. Detta ger oss 2^4 = 16 möjligheter. Tillslut genereras bad!. Om bredden först sökning används i vårt fall krävs det bara att 9 iterationer för att den sista if-satsen slår igenom. Se bild nedan. För att optimera sökningen dock används en ny generations algoritm som bland annat ser på heuristiker för att maximera code coverage så snabbt som möjligt.

13 Bild 1. Visar genereringen av sök trädet. Siffran ovanför visar värdet på integer:en som testas i den sista if-satsen[3] Code Pro Analytix För att generera enhets test använder sig först code pro av ett antal av heuristiker för att få fram en lista av värden för ett givet argument[4]. Detta görs genom att först analyseras metoden för att försöka se hur parametern används och på så sätt veta hur den ska testas. Om detta inte funkar kollar den istället om parametertypen är av en känd typ då den använder standard värden redan definierade. Exempel på en känd typ är en string. Om argumentet är en klass eller en fixture istället letar den efter noll argument static accessor metoder, konstruktorer och multi-argument static accessor metoder, och ser sedan till att genererar dessa på ett korrekt sätt för testet. Eftersom det oftast finns många kombinationer av värden använder sig verktyget av speciella fördefinierade regler för att hantera detta. Sedan räknar verktyget ut ett resultat för varje värde som den förutspår från funktionen. Om exempelvis resultatet av en metod är en integer där värdet int x som argument till metoden adderas med 1 testar den att resultatet är x + 1. Verktyget måste sedan validera detta. Detta görs olika beroende på vad som förväntas hända. Om exempelvis en metod returnerar ett värde bestäms det hur detta värde kan testas på bästa sätt. Till sist genereras själva testet i JUnit.

14 9. Referenser [1] SAGE: Whitebox Fuzzing for Security Testing, 2012, av Patrice Godefroid, Michael Y. Levin, David Molnar [2] DART: Directed Automated Random Testing, 2005, av Patrice Godefroid, Nils Klarlund, Koushik Sen [3] Automated Whitebox Fuzz Testing, 2008, av Patrice Godefroid, Michael Y. Levin, David Molnar [4] 04/03/13 [5] On the effectiveness of manual and automatic unit test generation, 2008, av Alberto Bacchelli, Paolo Ciancarini, Davide Rossi [6] CUTE and jcute : Concolic Unit Testing and Explicit Path Model-Checking Tools, 2006, av Koushik Sen, Gul Agha [7] CUTE: A Concolic Unit Testing Engine for C, 2005, av Koushik Sen, Darko Marinov, Gul Agha [8] Automated Unit Testing of a SCADA Control Software: An Industrial Case Study based on Action Research, 2012, av Shahnewaz Amin Jolly, Vahid Garousi, Matt M. Eskandar [9] Randoop: Feedback Directed Random Testing for Java, 2007, av Carlos Pacheco, Michael D. Ernst [10] 04/03/13, Patrice Godefroid

15 10. Appendix 10.1 Listning av verktyg Eftersom denna djupstudie har fokuserar på ett PVG projekt, där java används som utvecklingspåk, kommer också flera av verktyg som listas att vara just för java. För att nämna några som är open source för de som är intresserade att titta på dem kan JCUTE, Randoop, Tpalus, Jcrash, Junit factory nämnas. Andra verktyg som SAGE och DART existerar också, men de har aldrig gjorts publika. I djupstudien användes också Code Pro Analytix, efter eget val av deltagarna, att användas som test i ett PVG team för att kunna göra en utvärdering av påverkan av detta verktyg i projektet.

16 10.2 Enkät Code Pro Analytix och Enhetstestning. Hur mycket använde du Code Pro Analytix för testning? Hjälpte det dig att hitta buggar? Vilka buggar hittades när verktyget användes? Hjälpte verktyget dig att spara tid? Påverkades test first av att ni hade tillgång till verktyget? Dvs används fortfarande test first eller används det mindre för att ni hade tillgång till verktyget? Skippade ni tester när ni hade verktyget och så fall vilken sorts tester? Hjälpte det er med code coverage? Påverkades ni något negativt av att använda sig av verktyget?