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

Obs! Innan man får skicka in inlämningsuppgifter i den här kursen ska man fylla i en särskild fusk-enkät!

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 vara noggrann och metodisk när man programmerar. Men det blir ändå fel, och därför måste man också 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?

Konstruera ett antal testfall som kan användas för att testa programmet på ett bra sätt.

(Hur hittar man på testfall? Kanske kan man tänka så här: Du ska köpa en begagnad bil av en känd bedragare. Bedragaren påstår att bilen fungerar perfekt. Nu ska du undersöka bilen, och för varje fel du hittar kan du förhandla ner priset.)

För att förtydliga: Uppgiften går inte ut på att provköra programmet, utan på att skapa en lista med de testfall som du tycker är lämpliga att mata in för att testa programmet på ett bra sätt. Det är inte förbjudet att provköra programmet, men det som ska skickas in som lösning på uppgiften är själva listan med testfall.

Redovisning

Lämna in listan med testfallen till läraren, antingen på papper eller med e-post. Det är alltså listan med testfall som är lösningen på den här inlämningsuppgiften.

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 på inlämningsuppgifterna: Varje grupp (som normalt består av en eller två studenter) 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 lösning måste ange namnet på alla som bidrog i arbetet. Samarbete är alltså tillåtet, men måste redovisas.

Observera vad det står i rutan ovanför. Det står att samarbete är tillåtet, men varje grupp ska göra en egen lösning. Något som inte är tillåtet att utgå från en existerande lösning, som man till exempel fått av en kamrat, och ändra lite i den så man tror att läraren inte ska känna igen den. Man måste alltså göra en egen lösning.

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), 16 januari 2017