Kategori: Testteknikker

Parvis test

Parvis test er måde til at reducere antallet af kombinationer på.

Eksempel:

Vis skal teste 3 webpages på 3 forskellige styresystemer og på 4 forskellige browsere:

• Webpages: Page1, Page2 og Page3
• Styresystem: Windows, Mac OS og Linux
• Browser: Internet Explore, Firefox, Safari og Chrome

Test af alle kombinationer giver: 3 x 3 x 4 = 36 testcases.

Kigger vi på hvor mange kolonner vi skal have, så har vi 3 kolonner (3 betingelser):

Ved parvis test skal vi nedbringe alle parvis kombinationer til kun én for hver række. Altså hvor vi har kombinationer, der parvis allerede er testet.

Værdier pr. kolonne: 3, 3, 4

Ortogonale tabeller

Ved parvis test kan vi med fordel gøre brug af ortogonale tabeller. For at vi kan finde den rigtige tabel, skal vi bruge:

• Mindst én kolonne til hver parameter
• Et tal for hver værdi for hver parameter
• Mindst antal rækker som du får ved at gange de to største antal værdier med hinanden.

Standardnotation for ortogonale tabeller

Standardnotationen for angivelse af ortogonale tabeller er:

Eksemplet viser en ortogonal tabel med:

• 20 rækker
• 3 kolonner
• Max antal værdier er 5

På vores ovenstående eksempel med wepages, styresystemer og browsere har vi følgende:

• 3 kolonner
• 3 x 4 = 12 rækker
• Max antal værdier er 4 (browsere)

Notationen bliver nu L12(4^3)

Tilstandsovergangstest

Tilstandsovergangstest anvender vi på applikationer, der har et endeligt antal forskellige tilstande og hvor overgangen fra en tilstand til en anden følgerne fastlagte regler. Tilstandsovergangsmodellen består af fire dele:

1. de tilstand, som applikationen kan have
2. de overgange, som leder fra en tilstand til en anden
3. de hændelser, der udløser overgangen (input)
4. de aktioner, der er resultatet af overgangen (output)

Tilstandsovergangsmodellen viser vi ofte som et tilstandsdiagram (se nedenstående figur) Eksemplet viser

Ud fra ovenstående tilstandsdiagram kan vi, ved at liste alle tilstande og overgange, danne følgende tilstandstabel:

Vi skal nu skrive en testcase til hver overgang i diagrammet (hver udfyldt felt i tilstandstabellen). Det giver i alt 6 testcases:

0-switch dækning

Ved 0-switch dækning laver vi testcases til alle individuelle overgange – altså én overgang.

1-switch dækning

Ved 1-switch dækning dækker vi alle par af overgange. Ved at tilfører et ekstra trin på hver test, kan vi checke om sluttilstanden i 0-switch-dækningen faktisk er nået korrekt.

N-switch dækning

Dækker alle mulige sekvenser af n af overgange.

Beslutningstabeller

Beslutningstabeller benytter vi, når vi skal designe testcases til test af forretningsregler.

Beslutningstabeller hjælper os med at finde kombinationer af forskellige inputvariabler og handlinger som applikationen udfører afhængigt af inputtet.

Test af kombinationer kan være lidt af en udfordring, specielt hvis der er tale om mange mulige kombinationer. At test alle mulige kombinationer kan næsten være umuligt. Løsningen er at vi kun tester et lille udpluk af kombinationsmulighederne. Her er det så vigtigt, at vi vælger de “rigtige” kombinationer. Beslutningstabeller giver os en teknik til at afgrænse antallet af testcases på en intelligent måde.

En intelligent måde at begrænse antallet af testcases er at fjerne betingelserne og sæt af betingelser der:

1. ikke er mulige
2. redundante
3. ikke relevante for resultatet

Eksempel:

Hos bilforskringsfirmaet BilFo kan kunder opnå to forskellige niveauer: 10% og 30%.

Regel for at opnå rabat : Hvis kunden ingen tidligere skader har haft, er over 25 år og har andre forsikringer hos BilFo, giver BilFo kunden 30% rabat. Til kunder over 25 år, der ikke har andre forsikringer hos BilFo, giver BilFo 10% rabat. Hvis kunden er 25 år eller yngre, giver BilFo 10% rabat, forudsat at kunden ingen tidligere skader har haft og har andre forsikringer hos BilFo. Hvis kunden tidligere har haft skader giver BilFo ingen rabat. Kunden kan maksimalt opnå 30% rabat hos BilFo.

Beslutningstabel – Step 1 (List alle kombinationsmuligheder):

I regel 1 – 4 får vi samme resultat (handlingerne er ens): Kunden får ingen rabat. Når betingelserne ikke påvirker handlingerne, kan kolonnerne slås sammen (kombineres).

Når vi kombinerer kolonnerne får vi følgende tabel (~ betyder at værdien er ligegyldig):

Som det ses, får vi færre testcases, når vi kombinerer kolonner/regler.

Beslutningstabeller kan meget let blive rigtig store.

Hvilke defektyper finder vi

Med testcases dannet ud fra beslutningstabeller finder vi:

• Betingelseskombinationer, applikation ikke håndterer eller ikke bliver håndterer godt nok
• Forkert behandling af specifikke kombinationer af betingelser
• Defekter eller mangler i kravspecifikationen mens vi danner beslutningstabellerne