2.4 Teste et helt dataprogram

1. Definer testen. 2. Gjennomfør testen.

I dataprogrammering er en test en kontroll av om det vi har utviklet, oppfører seg som forventet. Det vi tester, kan være en funksjon, en komponent eller et helt program.

Vi gjennomfører en test i to steg. Først definerer vi testen ved å gi en tydelig beskrivelse av hvordan testen skal utføres, og hvilket resultat vi forventer. Deretter gjennomfører vi testen ved å følge beskrivelsene og sjekke om resultatet blir som forventet.

Hvis resultatet blir som forventet, sier vi at testen passerte. Hvis resultatet ikke blir som forventet, sier vi at testen feilet. Når en test feiler, er det én eller flere feil i programmet. Da må vi finne ut hva som er årsaken til feilene, og fikse dem hvis det er mulig.

I dette delkapittelet skal vi se nærmere på hvordan vi lager tester for et helt dataprogram. Disse testene utfører vi selv. Vi beskriver hvordan vi skal utføre dem, med vanlig skriftspråk, og av og til supplerer vi med bilder eller illustrasjoner.

I delkapittel 2.6 skal vi se nærmere på hvordan vi skriver enhetstester, som tester at utdataene er som forventet når vi sender visse inndata til funksjoner. Da skriver vi testene som kode, og det er datamaskinen som utfører dem for oss.

TESTTILFELLER, TESTSAMLINGER OG DEKKENDE TESTER

Et testtilfelle er en beskrivelse av hvordan vi skal utføre en test, og testens forventede resultater. Når vi skal teste et helt dataprogram, har vi som regel flere testtilfeller. Alle disse testtilfellene kaller vi for en testsamling. Målet er å ende opp med en testsamling som gjør at vi kan være rimelig trygge på at programmet oppfører seg som det skal. Testsamlingen bør være satt sammen slik at testtilfellene dekker alt som kan skje når brukerne tar programmet i bruk. Da sier vi at testsamlingen er dekkende.

Det er vanskelig å teste alt som kan skje med et dataprogram, uansett hvor lite det er. Målet er å være borti all kode som er utviklet, minst én gang i løpet av testen. Vi vil med andre ord at datamaskinen skal innom alle kodelinjer minst én gang, for eksempel alle deler av en if-else-setning, gjerne med litt forskjellige inndata. Når vi tester et dataprogram med brukergrensesnitt, bør den tenkte brukeren for eksempel ha trykket på alle knapper i brukergrensesnittet, gjerne i litt ulike rekkefølger.

KOMME PÅ TESTTILFELLER TIL ET DATAPROGRAM MED BRUKERGRENSESNITT

Når du skal lage tester, er det lurt å gå ut fra at du er en av dem som skal bruke programmet:

• • Hva vil du oppnå med å bruke programmet? For hver ting du vil oppnå: Hvilke handlinger må du utføre? Hva forventer du at handlingene skal føre til? • Hvordan forventer du at ting skal se ut underveis og helt til slutt?

Vi kan bruke bestigning av topper i et fjellandskap som et bilde på alt som er mulig å gjøre i et program. Vi tenker oss at vi står ved foten av den første fjelltoppen når vi åpner programmet. Hver topp representerer et mål som brukerne ønsker å oppnå.

Hvis vi overfører dette til handlelistenettsiden vår slik den ser ut nå, er det egentlig bare mulig å oppnå ett mål, nemlig å lage en handleliste til en handletur. For illustrasjonens skyld har vi tegnet inn tre mål som brukeren kunne ha oppnådd hvis programmet hadde flere funksjoner, i figuren nedenfor.

Når du skal lage testtilfeller, kan du starte med å lage en test der brukerne følger den glade sti (the happy path på engelsk) til målet: De trykker på alle knapper i riktig rekkefølge, skriver alt riktig og gjør ingen feil. De oppnår målet uten problemer, som i fjellbildet vil si at de går den raskeste veien til fjelltoppen uten å ta en eneste omvei og uten å bli hindret av dårlig vær.

Brukerne følger sjelden den glade sti. De trykker på knapper de ikke burde trykke på (fordi de bommer, blir distraherte eller misforstår), og de skriver ikke alltid riktig på første forsøk når de skal skrive inn noe i et felt. Etter at du har skrevet et testtilfelle der brukerne følger den glade sti, kan du skrive ett eller flere testtilfeller der brukerne tar omveier og gjør feil underveis. Slike testtilfeller kaller vi realistiske tilfeller.

Når du har bestemt deg for hvilke testtilfeller du vil ha med i testsamlingen, skriver du ned hva de som tester programmet, skal gjøre, og hvilke resultater de skal forvente. Beskrivelsen må være så detaljert at andre kan utføre testene uten å spørre deg. Når andre kan utføre en test på nytt uten å spørre deg, sier vi at testen er reproduserbar.

Du står selv fritt til å velge hvordan du vil beskrive testene. Avslutt hvert testtilfelle med en beskrivelse av de forventede resultatene, eller sluttresultatet, som godt kan være et bilde. Du kan godt beskrive forventede delresultater underveis når det er nyttig.

Sende en handleliste til en venn Lage en handleliste til en handletur Lage en handleliste som jeg kan lagre og hente senere

«Den glade sti» Faktisk bruk

EKSEMPEL

Testsamling for handlelisten

Nå skal vi teste handlelistekoden fra forrige delkapittel. Vi ser for oss at brukeren ønsker å lage en handleliste med 1 kaffe, 3 epler og 4 brød.

I den-glade-sti-testtilfellet klarer brukeren å legge til de tre varene, redigere navnene og angi antallet uten å trykke feil en eneste gang. I et annet mer kaotisk testtilfelle ønsker vi at testen skal omfatte følgende handlinger: • endre antall før man skriver inn navn • skrive inn feil navn på en av varene • skrive inn et navn som ikke har bokstaver • skrive inn et navn som inneholder rare bokstaver (vi velger «crème fraîche») • avbryte redigeringen av et varenavn • bruke minusknappen for å redusere antallet av en vare fordi man har trykket for mange ganger Vi har skrevet de to testene slik:

#1 Lage handleliste, den glade sti

Dersom du følger de fire stegene nedenfor, skal det ligge ett punkt i handlelisten: «kaffe» med verdien 1. 1. Klikk på «Legg til vare». 2. Klikk på blyantknappen ved siden av den siste varen i listen. 3. Skriv inn «kaffe» og klikk på «Lagre». 4. Klikk på plussknappen én gang. Gjenta deretter steg 1 til 4, men skriv inn «epler» og klikk på plussknappen tre ganger. Da skal • et nytt punkt ha dukket opp til slutt i listen: «epler», med verdien 3 • de tidligere punktene være uendrede Gjenta til slutt steg 1 til 4, men skriv inn «brød» og klikk på plussknappen fire ganger. Da skal • et nytt punkt ha dukket opp til slutt i listen: «brød», med verdien 4 • de tidligere punktene være uendrede Sluttresultatet skal se slik ut:

#2 Lage handleliste med forviklinger

I dette tilfellet skal du gjøre akkurat som i testtilfelle #1, men når du har lagt til epler, gjør du følgende før du fortsetter med brød:

1. Klikk på «Legg til vare». 2. Klikk på plussknappen tre ganger og deretter på minusknappen én gang.

Nå skal varen ha verdien 2. 3. Klikk på blyantknappen ved siden av den siste varen i listen. 4. Slett innholdet i feltet og klikk på «Lagre».

Nå skal varen vises uten navn. 5. Klikk på blyantknappen ved siden av den siste varen i listen. 6. Skriv inn «krem fresj» og klikk på knappen «Avbryt».

Varen skal gå tilbake til forrige verdi, som var uten navn. 7. Skriv eller lim inn teksten «crème fraîche» og klikk på knappen «Lagre».

Nå skal navnet være «crème fraîche».

Da skal

• et nytt punkt ha dukket opp til slutt i listen: «crème fraîche», med verdien 2 • de tidligere punktene være uendrede Fortsett som i testtilfelle #1 fra steget der du legger til brød.

Sluttresultatet skal se slik ut:

Her har vi prøvd så godt vi kan å få med alt brukerne kan finne på. Vi har klikket på alle knappene, og takket være testtilfelle #2 har vi også klikket på dem i litt ulik rekkefølge. Derfor vil vi si at disse testene er dekkende. Hvis vi utfører testene med et vellykket resultat, kan vi lansere nettsiden med handlelisten med visshet om at de fleste brukerne vil få en god opplevelse.

Som sagt står vi fritt til å velge hvordan vi skriver ned testene. Her er noe av det vi liker med formatet vi valgte i testsamlingen for handlelisten:

•Testene har en ID. Dette gjør det lett å snakke om testene med andre, for eksempel kan vi si at «Testtilfelle #1 feilet». • Hver test har et navn som beskriver hva målet med akkurat denne testen er.

Da blir det lett for folk å forstå hva vi ønsker å teste. Jo større testsamlingen er, desto nyttigere er det å ha gode navn på testene. • Det er tydelig hva som er instrukser, og hva som er forventede resultater.

Det er tydelig hva som skal gjøres, og hva som er de forventede mellom- og sluttresultatene. • Vi har lagt ved et bilde av sluttresultatet. Dette burde bidra til å avklare eventuelle utydelige instruksjoner.

EKSTRASTOFF

Tenke som en motstander

Når du skal skrive tester for realistiske tilfeller, kan det være nyttig å tenke som en motstander som prøver så godt han kan å ødelegge programmet ditt. En slik motstander kunne for eksempel ha funnet på å gjøre følgende: • skrive inn en veldig lang streng i input-feltet, for eksempel lime inn en hel avisartikkel • la strengen inneholde forskjellige tegn, som norske bokstaver, bokstaver med aksenter (for eksempel é, à eller ö) eller emojier • la være å skrive inn noe • klikke på helt andre knapper enn «Lagre»- og «Avbryt»-knappen etter at han har redigert innholdet • lime inn tekst på andre skriftspråk, for eksempel arabisk, kinesisk eller gresk • prøve å lime inn et bilde i input-feltet Når du har skrevet ned alt en motstander kunne ha gjort for å ødelegge programmet, tar du stilling til om du synes det er verdt å lage tester som prøver ut disse punktene. Mye av det som står på listen ovenfor, er rimelig å teste: • Noen matvarer har rare tegn i navnet, som crème fraîche. • Brukere gjør feil, som å lagre tomme verdier. • Folk liker å bruke emojier. • Hvis brukerne blir distrahert, kan de fort glemme at de holdt på å redigere navnet på én vare og klikke på pluss- og minusknappen for en annen vare. Når det gjelder handlelisten, har vi allerede tatt hensyn til de to første punktene ovenfor i testtilfelle #2. De to siste punktene har vi ikke tatt hensyn til. Selv forslag som kan virke urimelige ved første øyekast, kan være verdifulle. Det virker for eksempel urimelig at programmet skal tåle at brukerne limer inn en hel avisartikkel. Men brukere kan jo lime inn lange strenger uten at de har til hensikt å ødelegge noe. En bruker kan for eksempel ha prøvd å kopiere én ingrediens fra en lengre matoppskrift og ved en feil ha kopiert hele matoppskriften. Dermed kan det være lurt å teste om programmet tåler det, slik at brukeren kan rette opp i feilen etterpå. Noen forslag kan vi overse med god samvittighet. De fleste nettlesere nekter å lime inn bilder i tekstfelter, så det er unødvendig å teste dette. Hvis vi lager en handleliste med norsk brukergrensesnitt, klarer brukerne seg sannsynligvis uten arabiske og kinesiske tegn.