C: Inlämningsuppgift 1, Felsökning och testfall

Den här uppgiften handlar om "professionalism i programmering", och kräver inga kunskaper i C-programmering. Om man går campuskursen (men inte distanskursen) finns det en deadline, när uppgiften ska vara inlämnad.

Bakgrund

Programmering är svårt. Det är lätt att göra misstag, så att ens program sen ger fel svar när man kör det. Därför måste man dels vara noggrann och metodisk när man programmerar, och dels måste man testa, dvs provköra, sina program.

Under testningen provkör man programmet med olika kombinationer av indata, för att försöka hitta felen i programmet. Att välja ut lämpliga indata att provköra med, så kallade testfall, är inte alltid så enkelt.

Specifikation

På den här webbsidan (som tidigare fanns på http://www.testobsessed.com/exercises/triangle.html) kan man mata in de tre sidorna på en triangel. Med hjälp av ett JavaScript-program ritar webbsidan sen upp triangeln, och berättar om den var:

liksidig (Equilateral)
likbent (Isosceles)
rätvinklig (Right)
alla sidor olika (Scalene)
omöjlig (Invalid)

Men gör programmet rätt?

Gör ett antal testfall, och provkör dem.

(Hur hittar man på testfall? Jo, man ska försöka göra ett testfall för varje variant av inmatning, så man ser om programmet gör rätt för den varianten.)

Redovisning

Lämna in listan med testfallen till läraren, antingen på papper eller med e-post.

De som går distanskursen skickar in sina lösningar via e-post, men de som går campuskursen ska helst lämna in lösningen på papper, och bara i nödfall skicka den med e-post. Se då till att det är i ett enkelt läsbart format, till exempel PDF eller vanlig text i brevet. Word-dokument är inte enkelt läsbara. För inlämningar på papper finns det en brevlåda utanför studentexpeditionen i Teknikhuset.

Om något behöver förklaras, så skriv en förklaring.

Glöm inte en tydlig rubrik som beskriver vad det hela handlar om, datum, och namn.

På campuskursen är tanken i första hand att två studenter ska arbeta tillsammans, och lämna in en gemensam rapport, men det går också bra med grupper, och rapporter, på en eller (i nödfall) tre studenter.

Om samarbete: Varje grupp ska göra en egen lösning, och skicka in den, men det är inte förbjudet att samarbeta eller fråga andra studenter om hjälp. Däremot ska man i så fall tydligt ange vilka som man samarbetat med. Varje rapport måste ange namnet på alla som bidrog i arbetet. Samarbete är alltså tillåtet, men måste redovisas.

Några tips

Testfallen ska inte vara ett protokoll över provkörningen, utan de ska vara ett recept för provkörningen. Testfallen är en lista som man ska köra igenom inte bara en gång, utan varje gång man gjort en ändring i programmet. (Det är tyvärr inte ovanligt att man, när man lägger till eller lagar någon detalj i ett program, råkar ha sönder något annat så att det slutar fungera.)
Listan med testfall ska vara konkret, dvs det ska vara en fullständig lista med alla de värden som ska matas in. Vilka data man använder ska alltså vara uttänkt i förväg, och inget man behöver hitta på sen vid själva testkörningen. Att konstruera testfall kan vara ett både stort och svårt jobb, som kräver grundligt tankearbete, så det ska man göra i lugn och ro, före testkörningen. Och bara en gång, inte vid varje testtillfälle.
Att hitta på bra testfall handlar mycket om två saker:
1. Man vill provköra varje del av programmet minst en gång, och (så långt möjligt) alla möjliga vägar genom programmet. Även när man inte tittar på programkoden (eller inte har den), kan man tänka i såna termer, till exempel så man har minst ett testfall för varje typ av triangel (rätvinklig, liksidig och så vidare).
2. Randvillkor (exempel: om ett program ska kunna hantera namn på 1-30 tecken, så provkör man kanske särskilt med namn på just 1 och 30 tecken, och för att testa felhanteringen också 0 och 31). Just sådana gränsfall kan vara krångliga att få rätt, och programmerare gör ofta fel just där.
Precis som att ett matrecept bör vara tydligt och lättbegripligt, så bör även det här "testreceptet" vara så tydligt och lättbegripligt som det går. En lista med testfall är kommunikation, nämligen med den som ska testa programmet. Det spelar kanske inte så stor roll om du ska provköra programmet direkt, men det kan också vara någon annan som ska köra testerna, och det kan vara du själv om tre år, när någon gjort en ändring i programmet och du måste kontrollera att den ändringen inte haft sönder något.

Thomas Padron-McCarthy (Thomas.Padron-McCarthy@oru.se), 11 november 2009