Struktureret system udvikling

Minimodul 15: Testdesign og planlægning af test

Rasmus L. Olsen, 6. April, 2011

Tak til Ulrik Nyman for inspiration til eksempelslides 1

Dagens program

• Generelt omkring test og testudførsel

• Test behov

• Planlægning

• SPU test metode

• Modultest

• Integrationstest

• Test metoder

• Black box test

• White box test

• Test dokumentation

• Opgaver

2

Generelt om test

• Er det ikke testet virker det ikke !

• Alle laver fejl (men der forskel på antallet)

• Fejl skal findes så tidligt som muligt

• Test ≠ debugging

• Test: påviser fejl

- kan i visse tilfælde udføres af personer uden kendskab til

programmet

• Debugging: lokaliserer fejl (og inkluderer ofte også fejlretning)

- kræver detaljeret kendskab til programmet

3

Testbehov er forskellige

• Hvordan gik det ved afleveringen af det sidste system?

• 'Vi havde lovet at aflevere den 15. september. Det gjorde vi, så vi måtte

rejse over og rette alle de fejl, der blev fundet bagefter!'

• 'Det betød ikke noget, om det varede en måned mere eller mindre.‘

• 'Kunden ville ikke betale, før systemet virkede, som han mente, der var

aftalt.' .

• Er en fejl kritisk i det endelige system?

• ‘Ja, du godeste, der er jo menneskeliv på spil!’

• ‘Ja, produktionsstop koster 50.000 kr. pr. time.’

• ‘Ja, tænk på firmaets gode rygte og markedsandel.’

• ‘Nej, den retter vi bare.’

4

Testbehov er forskellige #2

• Vil en eventuel fejl være svær (dyr!!) at rette?

• 'Ja, vores system er i kredsløb om Jorden.'

• ‘Ja, vi sælger 50.000 apparater om året, og vi kan ikke rette, når først

apparatet er på markedet.’

• ‘Nej, udstyret står jo blot i vores laboratorium.’

• Skal der bygges/testes videre på programmet?

• 'Ja, vi forventer at sælge et stort antal af dette program i mange variationer.'

• ‘Ja, og vi ønsker ikke, at Søren skal hænge på vedligeholdelse i al fremtid.’

• ‘Nej, det er kun et demo-program.’

5

Hvorfor planlægge tests?

• Blot det at planlægge test reducerer antallet af fejl!• Formål med testning:

• Forhindre og finde fejl

• Dokumentere funktionalitet og mangler

• Eftervise funktionalitets- og ydelseskrav

• Tests kan ske på forskellige planer

• Design - Kan det designede system håndtere de angivne scenarier?

• Program inspektion - Inspektion af program og diagrammer etc.

• Kodning - Kan det kompileres

• Program test – Kan programmet køre som forventet?

• Funktionalitet - Kommer der sort røg ud når vi tænder for strømmen?

Kravspec.

Programdesign

Procesdesign

Moduldesign

Implementation

Procesintegration

Accept-

test

Modultest

Modulintegration

6

Et eksempel på rigtig dårlig planlægning af tests

Chernobyl, 26. April, 1986 :

- En beslutning var taget om at teste

værkets evne til at producere

elektricitet nok til at drive værkets

sikkerhedssystem i det tilfælde den

eksterne el forsyning forsvandt.

- En lang række af omstændigheder

ikke taget i betragtning under

testen, ledte til nedsmeltningen af

reaktor 4 på kraftværket

- Konsekvenserne ses stadig i dag og

er meget virkelige på mange

mennesker. En del er også døde

som direkte og indirekte

følgevirkning

7

Test parakdokser

• Pesticide paradokset:

• Enhver metode til at forhindre eller finde fejl efterlader fejl, som

metoden er ineffektiv overfor

• Kompleksitets paradokset:

• Software kompleksiteten øges konstant til grænsen af vores formåen

(tilsvarende mere komplekse fejl)

Og husk

- If there is a possibility of several things going wrong the one that will cause the

most damage will be the one to go wrong. http://www.murphys-laws.com/

8

Test principper

• Princip: veldefineret input ⇒ forventet output

• Reproducérbare test = veldokumenteret test miljø

• Interaktiv/manuel test:

• Billig og enkel udvikling

• Tidskrævende

• Automatiske test:

• Udviklingskrævende

• Tidsbesparende ved gentagende testudførsel,

• generering af data med hensyn til senere statistisk undersøgelse

• ved mange parameter ændringer/stort parameter rum

9

Dagens program

• Generelt omkring test og testudførsel

• Test behov

• Planlægning

• SPU test metode

• Modultest

• Integrationstest

• Test metoder

• Black box test

• White box test

• Test dokumentation

• Opgaver

10

SPU-tests

• Modultest

• Modulintegration

• Procesintegration

• Accepttest

Test planlægning Test udførelse

11

Modultest

• Formål:

• At sikre at modulet virker som beskrevet i modulspecifikationen

• Indhold:

• Test af grænsefladen og interne, logiske struktur af programmet

• Udarbejdelse af test stubbe

• Automatiseret test

• Generering af test data

• Gyldig data

• Ugyldig data

• Test af interface

12

Integrationstests

• Trinvis:

• Enheder tilføjes én efter én med en integrationstest ved hver tilføjelse

• Samlet integration (The Big Bang):

• Individuelle enheder testes

• Alt samles derefter i én ombæring

Tri

nvis

inte

gra

tio

n

Th

e B

ig B

an

g

System

13

Eksempel på hvad man ikke skal gøre - Ariane 5

4. Juni 1996 - jomfruflyvning af den

nye Ariane 5

- Ariane 4 havde været en

aldeles stabil raket, og derfor

genanvendte man softwaren fra

4‟eren i 5‟eren!

- Ariane 5 accellerede dog

hurtigere end 4‟eren….

- Et sted i koden, skulle en 64

bit float værdi konverteres til

en 16 bit integer…

- Man ‟antog‟ at 16 bit var nok,

men pga. forskellen mellem

Ariane 4 og 5, tog man fejl….

- Det kostede $500.000.000

14

Trinvis integration

For et givet modul hieraki er der to principielle metoder:

• Bottom up integration

• Top down integration

15

Inte

gra

tio

nsre

tnin

g

• Sikrer at de overordnede funktioner virker som forventet

• Kræver dog at underliggende funktioner er færdige

• Sekventielt udvikling/integrationsforløb

Bottom-up integration

16

Top-down integrationIn

teg

ratio

nsre

tnin

g

• Tillader parallelle udviklingsforløb

• Kræver at interface og funktionalitet er korrekt emuleret af stubbe

17

I praksis er det en blandet landhandel

Kompromis mellem bottom-up og top-down afhængigt af:

• Hvilke ydre enheder der er tilknyttet

• Hvilke enheder der er færdige

• Hvilke hardware dele der er færdige eller givet på forhånd

• Kan der testes hvis nogle enheder mangler

• Er der noget der skal demonstreres tidligt (kritisk)

18

Procesintegration

• Planlægning af aktiviteter

• Hvornår er modul X og

Y klar til integrering?

• Hvad afhænger af hvad?

• Hvor kan der med

fordel benyttes stubbe?

• Alle involverede skal være

klar over tids- og

afhængighedslinjer

19

Procesintegrations-test

• Først lidt debugning

• Vær beredt: Uforudsete fejl

dukker normalt altid op!

• Typiske fejl er mistilpassede

interfaces (som kan grunde

i funktionsmisforståelse!)

• Dernæst testning af proces

• Udfører processen sin

dedikerede opgave?

• Resulterer et givet input i

forventet output?

• Opfører modulet som

forventet over tid?

• ….

20

Accepttest

21

Ups... Therac 25

The Therac-25 radiation therapy

machine was a medical device that

used beams of electrons or photons

to kill cancer cells.

Between 1985- 1987, at least six people

got very sick after Therac-25 treatments.

Four of them died. The manufacturer was

confident that their software made it

impossible for the machine to harm

Patients, however… (among other bad things)

The equipment control task did not properly synchronize with the

operator interface task, so that race conditions occurred if the operator

changed the setup too quickly. This was missed during testing, since it

took some practice before operators were able to work quickly enough

to trigger this failure mode.22

Dagens program

• Generelt omkring test og testudførsel

• Test behov

• Planlægning

• SPU test metode

• Modultest

• Integrationstest

• Test metoder

• Black box test

• White box test

• Test dokumentation

• Opgaver

23

Testforberedelse- og udførelse

• Forberedelse

• Specificerer testemner. Hvad skal testes ?

• Design testen. Hvordan skal testen udføres ?

• Udførelse

• Implementer testen; Skriv testdrivere/stubbe.

• Klargør testdata

• Kør test

• Evaluér testforløb

24

Testmetoder

25

Kravspec.

Programdesign

Procesdesign

Moduldesign

Implementation

Procesintegration

Accept-

test

Modultest

Modulintegration

Black-Box vs. White-Box

• Black-Box

• Ingen kendskab til intern struktur

• Ikke nødvendigt med kendskab til softwaren

• Primært de øverste trin i V-modellen

• White-Box

• Tester interne strukturer

• Kendskab til softwaren nødvendig

• Primært de nederste test trin i V-modellen

26

Black box test

27

Black-Box testing

• Black-box dækker test af funktion/system opførsel

• Baseret på en dedikeret specifikation

• Test uden kendskab til systemets interne struktur

• Eksempler på black-box teknikker:

• IO analyse

• Domæne-analyse, f.eks.

• Frekvensrespons

• Tidsrespons

• Statistisk analyse

• etc.

28

Kombinatorisk problem

• For et program med flere inputs skal der tages stilling til hvilke

kombinationer der skal testes med

• Det sikreste ville være at test med alle mulige kombinationer – men det

kan være umuligt pga. antallet!

• Hvis n = 10 og der vælges 10 test værdier for hver variabel vil der i alt

være 1010 kombinationer !!!!

X1 X2 X3 . . . Xn

Program P

29

Kombinatorisk problem

• Ved kombinatorisk black-box testing opstår der let flere test-cases end

der er ressourcer til at udføre (selv for automatiserede tests!)

• Hvordan reduceres antallet at test-cases uden at mindske sandsynligheden

for at finde fejl?

Fra uoverskueligt…. Til overskueligt

30

Domæne-test

- Black-Box test

1. Identificér muligt in- og output

2. Identificér gyldigt og ugyldigt in- og output

3. Opdel det gyldige og ugyldige område i klasser

Eks. gyldigt input: 0 ≤ X ≤ 999

klasse 1: X<0 (ugyldigt input)

klasse 2: X>999 (ugyldigt input)

klasse 3: 0≤X ≤10 (gyldigt input)

klasse 4: 11≤X ≤999 (gyldigt input)

4. Design testscenarier med gyldigt input som dækker flest mulige klasser

5. Design en testscenarier for hver klasse med ugyldigt input

31

Black-Box test

6. Supplér med grænseværdier, eks.:

• Første element

• Sidste element

• Max/min værdi

• En over/under grænsen

• ….

7. For hver grænseværdi genereres en ny test-case som dækker én og kun én

grænseværdi

8. Fejlgætning; hvis vi kan indse/gætte fejlagtige værdier der kan give

anledning til bekymring, f.eks.

• Tomt input

9. Til både gyldige og ugyldige test-cases specificeres det forventede output

32

Black-Box test - eksempel

33

U.S.S. Yorktown – A SmartShip?!?!

Krigskibet USS Yorktown

af Essex klassen fra 1943

er løbende blevet

moderniseret siden krigen.

På et tidspunkt får skibet

installeret SmartShip system

der skal afhjælpe sømænd

med trivielle opgaver.

Et indtastet ‟0‟ i et datafelt ledte til en ‟division by zero‟ fejl. Den efterfølgende

fejl spredte sig efterhånden til skibets motorstyring og stoppede motoren.

Skibet lå dødt hen i vandte i flere timer… godt det ikke var i fjendeland.

The Smart Ship program is still in development, and officials said glitches are

to be expected, but in this case the problem appeared to be more political than

technical. Using Microsoft's Windows NT operating system in such a critical

environment, some engineers said, was a bad move. 34

Testdokumentation

Vigtigt af hensyn til:

• Bedre overblik

• Grundlag for forbedringer

• Gentagelse af test

• Grundlag for godkendelse

• etc.

35

Testspecifikation

1. Indledning

• Formål

• Referencer

• Tekstens omfang og begrænsninger

• Godkendelse

2. Test emner

3. Test design

4. Test implementation

5. Udførelse af test

6. Bilag

36

Test rapport

1. Indledning

• Referencer

• Identifikation

2. Test resultater

3. Afvigelser og kommentarer

• Afvigelser fra normal afvikling

• Problemer/ændringsforslag

4. Konklusion

37

Testaktiviteter og test-

dokumentation

38

White box test

39

Eksempel fra den kolde krig:

Russerne angriber?!?!

The United States established the Ballistic

Missile Early Warning System (BMEWS)

during the Cold War to detect a Soviet

missile attack. On October 5, 1960 the

BMEWS radar at Thule, Greenland detected

something. Its computer control system

decided the signal was made by hundreds of

missiles coming toward the US.

The radar had actually detected the Moon

rising over the horizon. Unfortunately, the

B M EW S c o mp u t e r h a d n o t b e e n

programmed to understand what the moon

looked like as it rose in the eastern sky, so

it interpreted the huge signal as Soviet

missiles. Luckily for all of us, the mistake

was realized in time.

???

40

White-Box Testing

• Også kendt som

• Structural test

• Glass-Box test

• Test af implementering

• Instruktioner

• Forgreninger

• Tilstande

• etc

41

White-Box tests

• Team baserede (“human testing”):

• Code Inspection

• Walk Through

• Ikke nødvendigvis team baserede:

• Path Testing

• Loop Testing

• Domain Testing

42

Path testing

Antagelser ved Path Testing:

• Specifikationerne er korrekte

• Data er til rådighed og tilgås korrekt

• De eneste bugs i programmet er dem der har indflydelse på kontrol

flow‟et

43

Path testing cases

• Instruktionsdækning

• alle instruktioner gennemløbes min. én gang

• Forgreningsdækning

• alle forgreninger gennemløbes min. én gang

• Betingelsesdækninger

• alle sammensatte betingelses afprøves indtil

alle betingelser er dækket

• Umuligt at teste selv et simpelt program fuldstændigt !!!

• Eksempel

• Tre mulige stier gennem programmet

• Hvis løkken gennemløbes 20 gange er

der i alt 320 forskellige sekvenser

44

Path testing

Procedure:

1. Vælg en sti gennem softwaren

2. Bestem data der giver den pågældende sti

3. Kør softwaren med data fra 2)

4. Observér output

5. Sammenlign 4) med forventet output

45

Flowgraph - bestanddele

• En forgrening = et sted hvor der kan ske en ud af flere efterfølgende

handlinger, f.eks.,

• If/then/else

• case statements

• En samling = et sted hvor handlinger (risikere at) samles, f.eks.

• end if

• end loop

• goto label

• En procesblok = en sekvens af handlinger som ikke afbrydes af

forgreninger eller samlinger.

• En proces blok har én indgang og én udgang

• Programmet hopper hverken ind eller ud af en proces blok

46

1 INPUT X,Y

Z:=X+Y

V:=X-Y

3 IF Z>=0 GOTO SAM

4 JOE: Z:=Z+V

5 SAM: Z:=Z+V

U:=0

6 LOOP

B(U),Q(V):=(Z+V)*U

7 IF B(U)=0 GOTO JOE

Z:=Z-1

8 IF Z=0 GOTO ELL

U:=U+1

9 UNTIL U=Z

B(U-1):=B(U+1)+Q(V-1)

10 ELL:B(U+Q(V)):=U+V

11 IF U=V GOTO JOE

12 IF U>V THEN U := Z

13 YY: Z:=U

14 END

Eksempel

47

Eksempel – I flowgraph version

76531 4

91011132 12 8

LinkNode

1 INPUT X,Y

Z:=X+Y

V:=X-Y

3 IF Z>=0 GOTO SAM

4 JOE: Z:=Z+V

5 SAM: Z:=Z+V

U:=0

6 LOOP

B(U),Q(V):=(Z+V)*U

7 IF B(U)=0 GOTO JOE

Z:=Z-1

8 IF Z=0 GOTO ELL

U:=U+1

9 UNTIL U=Z

B(U-1):=B(U+1)+Q(V-1)

10 ELL:B(U+Q(V)):=U+V

11 IF U=V GOTO JOE

12 IF U>V THEN U :=

Z

13 YY: Z:=U

2 END

48

Begreber

• Path: en sekvens af statements (instruktioner)

• Node: entry, junction, decision eller exit

• Link: forbindelsen mellem to nodes

• Path længde: antallet af links

• Entry/exit path eller complete path: en path der begynder og slutter

ved hhv. rutinens start og slutpunkt (dvs. ingen spring ind/ud midt i

rutinen)

49

Path Testing Kriterier

Tre path testing kriterier (blandt uendeligt mange)

1) Statement Testing (P 1 ):

• 100% statement dækning

• Udfør alle statements i programmet mindst én gang

2) Branch Testing (P 2 ):

• 100% branch dækning

• Udfør test som sikrer at alle branches har været gennemløbet

min. én gang.

3) Path Testing (P ∞):

• 100% path dækning

• Gennemløb samtlige stier gennem programmet

• Sikrer også at kriterie 1) og 2) er dækket

50

Eksempler på Branch og Statement testning

10

3 4 5 6 2

9 8 7

1

m

a b c d e

i h g f

jklT TF F

T T

F F

51

Branch and Statement dækning

• Spørgsmål: Har hver forgrening et T (true) og et F (false) i den pågældende søjle?

Svar: Hvis ja, så har vi branch dækning.

• Spørgsmål: Er alle links dækket min. én gang?

Svar: Hvis ja, så har vi statement dækning.

52

Path Predicates

• Hver path svarer til en sekvens af True og False værdier • Path Predicate Expression: et boolsk udtryk som tvinger

programmet gennem en veldefinert path.• Multiway branches (f.eks. case/switch statements) behandles som if-

then-else statements.

EksempelInput {X1,…,X6}

if (X5 > 0 || X6 < 0) /* predicates A,B */...

if(X1 + 3 * X2 + 17 >= 0) /* predicate C */...

if(X3 == 17) /* predicate D */...

if(X4 - X1 >= 14 * X2) /* predicate E */...

Path Predicate udtryk: ACDE + BCDE = (A+B)CDE

53

Nogle vigtige begreber

• Path sensitization: Det at finde en løsning til et path predicate udtryk. Et path predicate kan være reachable eller unreachable

• Reachable hvis der findes et input vektor der fører programmet af den givne path predicate

• Unreachable hvis der ikke findes noget input der kan føre programmet gennem den givne path predicate

• Desværre findes der ingen generel algoritme til at finde ud af hvorvidt en path predicate er reachabel eller ej

• Process Independent: hvis et predicate ikke afhænger af processeringen i rutinen

• (Un)Correlated Predicates: hvis resultatet afhænger af hinanden

54

Eksempel: ukorreleret & uafhængig

l A 4 C 6 7 2

B

D9l m

j kh

g

T

F

T

i

ba c d e f

FT

F

T

F

4 binære beslutninger medfører:

= 16 mulige paths.42

55

Eksempel: korrellerede & uafhængige

• Paths abdeg og acdfg synes at give dækning, men er ikke muligt !!

• Kun 2 paths er mulige: abdfg og acdeg.

l A 4 A 6 2a

b

c f

e

g

F

T

T

F

d

56

Rekursive algoritmer/uendelige løkker....

• Pga. Loop har vi stadig mange muligheder

• Hvis løkken gennemløbes 20 gange er

der i alt 320 forskellige sekvenser

• Derfor, alternativt

• Bryd loopet og test som normalt med

path/branch test med fokus på

1. Ugyldigt input

2. Produktion af ugyldigt output/input

57

Hvad kan et flowgraph ellers bruges til?

Typiske kode fejl sker i forbindelse med forgreninger og beslutninger. Path

predikater kan være et godt redskab til at opdage inkonsistens mellem

designet kode og implementeret kode.

Hvad vil i helst?

1) Få en (evt. automatisk) til at oversætte jeres assembly kode til et

flowgraph, og sammenlign med det udtænkte

2) Sidst på natten inden aflevering, spørge jeres medstuderende i

desperation: ”Vil du ikke lige se mit assembly kode igennem, jeg kan

simpelthen ikke finde den #”!”#= bug!”

58

Test resultater

• Test resultater skal være som forventet

• Generelt

• Kør test

• Observér aktuel resultat

• Sammenlign det aktuelle resultat med det forventede.

• Spørgsmål: Hvis det aktuelle og det forventede output stemmer overens

er testen så bestået?

Svar: Nej! Resultatet kan være opnået ved en tilfældighed!!

- Måske endda via fejlagtige paths !!

- Derfor: Log den fulgte vej gennem programmet

59

To eksempler på path testing

• Funktionen int Abs(int x)

• Funktionen Count(file *textfile)

60

• Betragt følgende funktion:

/* ABS

This program function returns the absolute value of the integer

passed to the function as a parameter.

INPUT: An integer.

OUTPUT: The absolute value if the input integer.

*/

1 int ABS(int x)

2 {

3 if (x < 0)

4 x = -x;

5 return x;

6 }

Using Path Testing to Test Function ABS

61

The Flowgraph for ABS

/* ABS

This program function returns the absolute value of the integer

passed to the function as a parameter.

INPUT: An integer.

OUTPUT: The absolute value if the input integer.

*/

1 int ABS(int x)

2 {

3 if (x < 0)

4 x = -x;

5 return x;

6 }

1 3 5 6

62

Statement Testdækning

1 3 5 6a b c

d

F

T

Paths Process links Test cases

a b c d Input Output

abc A negative

integer, x

-x

adc A positive

integer, x

x

63

Branch Testing

Paths Decisions Test cases

Input Output

abc T A negative

integer, x

-x

adc F A positive

integer, x

x

1 3 5 6

F

T

64

Funktionen Count(file *fp)

/* COUNT This program counts the number of characters and lines in a text file.INPUT: Text FileOUTPUT: Number of characters and number of lines.

*/1 main(int argc, char *argv[])2 {3 int numChars = 0;4 int numLines = 0;5 char chr;6 FILE *fp = NULL;78 if (argc < 2)9 {10 printf(“\nUsage: %s <filename>”, argv[0]);11 return (-1);12 }13 fp = fopen(argv[1], “r”);14 if (fp == NULL)15 {16 perror(argv[1]); /* display error message */17 return (-2);18 }

19 while (!feof(fp))20 {21 chr = getc(fp); /* read character */22 if (chr == „\n‟) /* if carriage return */23 ++numLines;24 else25 ++numChars;26 }27 printf(“\nNumber of characters = %d”, numChars);28 printf(“\nNumber of lines = %d”, numLines);29 }

65

The Flowgraph for COUNT

(a) Flowgraph til statement dækning

1 8 11 17 24 26 29a

g

b c

h

d e

f

j

i

k23

L

14 19 22

1 8 11 17 19 22 24 26 29

F

T

F

T TT

FF

14 23

(b) Flowgraph til branch dækning

66

Statement Testdækning

PATHS PROCESS LINKS TEST CASES

a b c d e f g h i j k l INPUT OUTPUT

ab None “Usage: COUNT

<filename>”

agc Invalid Input

Filename

Error Message

aghd

jkli

Input File with

one character

and no Carriage

Return at the

end of the line

Number of

characters = 1

Number of lines

= 0

aghd

efli

Input file with no

characters and

one carriage

return

Number of

characters = 0

Number of lines

= 1

67

Branch Testdækning

PATHS DECISIONS TEST CASES

8 1

4

1

9

2

2

INPUT OUTPUT

ab T None “Usage: COUNT

<filename>”

agc F T Invalid Input

Filename

Error Message

aghdjkli F F T,

F

F Input File with one

character and no

Carriage Return at

the end of the line

Number of

characters = 1

Number of lines = 0

aghdefli F F T,

F

T Input file with no

characters and one

carriage return

Number of

characters = 0

Number of lines = 1

68

Effektivitet af path testing

• Ca. 65% af alle fejl kan fanges i forbindelse med modultest.

• Path testing metoder er væsentlige værktøjer til modultest.

• Statement og branch testing er de dominerende path testing metoder.

• Undersøgelser har vist, at path testing fanger ca. 50% af alle de fejl der findes ved modultest

• Path testing er mere effektiv for ustruktureret kodning

• Erfarne programmører kan “springe over” flow-graphs og vælge paths direkte fra koden.

69

Begrænsninger ved Path Testing

• Path testing kan ikke stå alene som test metode eftersom:

• Fejl i interfaces ikke fanges

• Ikke alle initialiseringsfejl fanges

• Specifikationsfejl fanges ikke

• Manglende funktionalitet

70

Opfølgning af dagens program

• Husk at:

• Hvis IKKE det er testet, så VIRKER DET IKKE!!!

• Test løbene og i forhold til V modellen• Black box test

• Mest anvendt i forhold til accepttest

• Dokumenterer om input/output forhold er I overensstemmelse med det specificerede

• Bestemmelse af test input/input område yderst vigtigt• White box test

• Path test:

• Formålet med path testing er at udføre et tilstrækkeligt antal tests til at sikre statement og branch dækning

• Find input data der tvinger programmet igennem den ønskede path (path sensitization)

• Check at programmet følger forventet path (path instrumentation)

• Sammenlign aktuelt og forventet output

71

72

Dagens program

• Generelt omkring test og testudførsel

• Test behov

• Planlægning

• SPU test metode

• Modultest

• Integrationstest

• Test metoder

• Black box test

• White box test

• Test dokumentation

• Opgaver

73