Basic personligt

Daniel Brahneborgs blogg

Testning utan droger

För ungefär 15 år sedan hamnade jag för första gången på ett företag som hade en speciell grupp människor som primärt arbetade med att testa den kod som vi programmerare producerade. Efter att ha fixat koden så att de inte längre hittade några fel, rapporterades exakt noll buggar i fält. Det var uppenbart att det inte bara handlade om slump vilket data man testade med, men längre än så kom jag inte. Jag hade länge en misstanke om att det involverade droger.

Till min framtida Master-examen behöver jag ytterligare två kurser (eller 15 hp, mer exakt) i datavetenskap på avancerad nivå, så nu under våren går jag en kurs i just testing hos MDH i Västerås. Några månader med föreläsningar, vetenskapliga artiklar och egna uppgifter har bilden klarnat rejält. Istället för att hela området är en vit yta har jag åtminstone en översiktlig karta nu.

Första pusselbiten är att se utvecklingsprojekt ur tre perspektiv. Först har man omvärldens önskemål på systemet. De formaliseras i en specifikation, som i sin tur implementeras i kod. De tre har en exakt överlappning varje gång som en enhörning och en flygande gris tillsammans får en fertil avkomma.

Nästa pusselbit är synen på program som funktioner som omvandlar indata till utdata. Att skapa testfall handlar då om att hitta bra och minimala subset av det där indatat. T.ex. brukar det vara mer intressant att skicka in -1, 0 och 1 än 2, 3 och 4. Testar man med 2 och 3, behöver man förmodligen inte testa med 4 och 5 också.

Även processen att skapa testfall kan ses som en sådan här funktion. När indatat är kod, består funktionen av verktyg som Valgrind och kompileringsvarningar. De är enkla att använda, och är en bra början. För mig är de också den lägsta nivån som är acceptabel. Program kan ha buggar, men om Valgrind gnäller så är programmet opålitligt. Då får man saker som Heartbleed.

När indatat är omvärldens önskemål blir funktionen att se hur slutanvändarna faktiskt använder systemet, hur blicken rör sig över skärmen, om det finns funktionalitet som fattas, osv. Här börjar det gränsa till psykologi och beteendevetenskap, så det är lite för långt utanför min kompetens.

Min senaste besatthet är istället området däremellan. Om specifikationerna är tillräckligt formaliserade (XML, tillståndsdiagram i UML och liknande), finns det några olika typer av verktyg man kan köra för att få ut serier med testdata. Antingen har man sedan ett annat program som tar det testdatat och matar den riktiga applikationen med, eller så har man det som protokoll för mer manuella tester. Poängen är att man får minimalt med testfall som täcker maximalt med kombinationer av indata.

Antag att man har 10 parametrar som kan vara 0 eller 1. Att testa alla kombinationer av dessa ger 1024 testfall. Med fler parametrar som kan ha fler värden, växer det där antalet snabbt. Istället börjar man med 0 överallt, så blir testfall 2-11 när man ändrar en parameter i taget till 1. På 11 testfall har man då täckt in samtliga värden av samtliga parametrar. Skapar man testfallen manuellt är det ungefär här man hamnar. Dags att levla upp.

Det finns flera verktyg som kan ge en lista med testfall där alla värden på alla parametrar minst en gång kombineras parvis med alla värden på alla andra parametrar. För 3 parametrar får man t.ex. serierna 0-0-0, 0-1-1, 1-0-0, 1-1-1, 0-0-1, och 0-1-0. För 10 parametrar blir det totalt 20 testfall. Det är fler än 11, men enormt mycket färre än 1024. Många buggar behöver bara att 2-3 variabler har en viss kombination av värden för att triggas, så effektiviteten är förvånansvärt hög. Om själva testandet kan automatiseras blir det en utmärkt testsvit att köra efter varje incheckning, varje natt eller vad som nu är lämpligt.

När kursen började sa jag till lärarna att jag ville ha nya mentala verktyg, för att kunna testa program på ett mer strukturerat sätt. Det kan man ju lugnt säga att jag har fått. Kursen pågår två månader till, men av det jag sett av det återstående innehållet är det inget som riktigt slår steget från “det kräver hallucinogena droger” till “testdata kan genereras automatiskt från kravspecifikationer”.

March 16th, 2016 Posted by Daniel Brahneborg | blogg | no comments

|