TDP003 Projekt: Egna datormiljön

Testdokumentation

Syfte

Den typ av testning vi tar upp här brukar kallas acceptanstestning och är i normalfallet bara en liten del av all testning som utförs. För en snabb översikt av andra typer av testning kan du slå upp programvarutestning på wikipedia.

Acceptanstestningen skall bevisa att systemet verkligen fungerar enligt specifikation, eller om så är fallet vad som inte fungerar. Efter ändringar i kodbasen skall alla tester kunna utvärderas igen på exakt samma sätt som förut för att säkerställa att allt fortfarande fungerar enligt specifikation. Alla funna fel loggas. Det är lämpligt att utgå från kravspecifikationen och verifiera att alla funktionella krav fungerar både i normalfallet och i undantagsfall.

För att uppnå repeterbarhet måste varje testfall specificeras noga. Beskriv vilket krav som testas (hänvisa till kravspec), och lista alla indata. Beskriv den utdata som förväntas med den givna indatan. Tänk på att varje krav bör testas med olika uppsättning indata, både för normallfall och undantagsfall. Det blir alltså flera testfall per krav.

Vidare måste det faktiska resultatet av varje test dokumenteras. I bästa fall stämmer den faktiska utdatan helt överens med den förväntade och testet passerar utan anmärkning. I annat fall måste avvikelser noga dokumenteras, med en kommentar om hur allvarligt felet är. Om kodbasen ändras bör samtliga tester köras igen. Det blir då ett nytt testprotokoll, och det är nu viktigt att hålla reda på när en viss testomgång kördes och vilken version av mjukvaran som testades. En bra testlogg visar även på systemets kvalité och tjänar som grund för projektledare och kanske kund att avgöra när projektet är redo att tas i drift.

Krav på testdokumentet

Dokumentet bevisar att systemet fungerar enligt specifikation, och dokumenterar eventuella avvikelser från det.
Varje funktionellt krav ska ha minst ett relevant testfall. Om ni känner till eller kan generera felaktig indata för kravet (exempelvis något ni hittade under testsessionen) ska även minst ett testfall med felaktig indata finnas med, utöver korrekt indata. Dessa testfall skall vara motiverade och dokumenterade för att vara repeterbara.
Det skall finnas minst en daterad testlogg där samtliga testfall körts på en angiven version av systemet.

Riktlinjer för testdokumentet

Bilder/figurer ska ha förklarande figurtexter med nummer, och de ska refereras till i texten.
Det skall finnas information om författare, datum, dokumentversion, projektnamn, kurs och totalt antal sidor (dessa saker är bra att ha med i en dokumentmall, t.ex. i sidhuvud/sidfot på varje sida).
Inlämning sker som pdf med höga krav på språk och tydlig layout. Korrekturläs. Använd flera rubriknivåer. Sätt tydliga relevanta rubriker. Använd bilder och figurer för att förtydliga eller exemplifiera det som beskrivs i text. Numrera figurer och tabeller och hänvisa i texten så bilden ingår i den röda tråden. Formatera konsekvent kod, filnamn, eller andra typer av nyckelord med en annan font. Infoga innehållsförteckning om det är motiverat utifrån sidantalet, färre än fem sidor behöver sällan förteckning, det är lätt hitta ändå.

Exempel

För exempel på hur testspecifikation och testlogg kan se ut, se exempel här:

Testspecifikation och testlogg

Ni får själva fundera på om ni vill presentera tester och logg på annat sätt, men sikta på att skapa ett översiktligt och välstrukturerat dokument.

Sidansvarig: Pontus Haglund
Senast uppdaterad: 2023-08-28