Softwaretest

Fra HTX Arduino
Version fra 8. nov. 2015, 21:16 af htx_>Bar htx_>Bar (Dokumentation)
(forskel) ← Ældre version | Nuværende version (forskel) | Nyere version → (forskel)
Spring til navigation Spring til søgning

Efter man har skrevet sin software kan man få brug for en test af denne. En test af software kan deles op i mindre struktureret forløb.

- Brænd din software over.

- Start op og test om du får den ønskede virkning. Her kan det være en stor fordel at man kigger på sin Kravspecifikation, for at se hvad den ønskede virkning egentlig skal være.

- Hvis ikke - find fejlen og ret den, hvorefter hele forløbet starter forfra.

- Hvis du får den ønskede virkning og alt lader til at være som det skal være så kan du sandsynligvis fortsætte.

Dokumentation

Dokumentation skal gerne indeholde Flowcharts eller anden overordnet beskrivelse som Pseudokode eller State-diagram samt billeder og en forklarende tekst. Indsæt udvalgte udklip af din kode i din rapport. I Arduinos IDE kan man markere og bruge kopier som HTML, der gør at man får det ind som tekst med syntaksfarvning, hvis man sætter det ind i Word. Et alternativ er at tage billeder man kan for eksempel bruge MVSnap eller et andet klippeværktøj. Man kan med fordel inddele softwaren i mindre strukturerede blokke og teste dem enkeltvis for at mere præcist tjekke for fejl.

Til en grundig dokumentation af din software hører også en beskrivelse af hvordan du har testet softwaren. Det kan være en simpel tekstlig beskrivelse af det, men evt. også nogle tabeller, hvor du viser hvordan du har påvirket opstillingen, og hvilke resultater du har aflæst på dit kredsløb - det kan f.x. være en tabel hvor alle kombinationer af input er sat op, og en konstatering af om det fungerer som forventet for det aktuelle input.

Fejl

For en softwaretest er det vigtigste ved opdagelsen af en fejl at kunne isolere grunden til fejlen og dermed finde ud af hvad der skaber problemet. Derefter kan man tænke over et løsningsforslag eller rettelser som kan udrede problemet. Det næstvigtigste er at dokumentere fejlen. I så fald at man ikke kan løse fejlen så er dét det bedste man kan gøre.