Struktureret system udvikling

Minimodul 5: Testdesign og planlægning af test

Rasmus L. Olsen, 9 April, 2008

Kursusoversigt og tidsplan

Mm1: Introduktion til kursus, UML og use cases (13/2, 2008)Mm2: Kravspecifikation og accepttest (27/2)Mm3: SPU og UML (12/3)Mm4: Design af system (26/3)Mm5: Design og test planlægning (9/4)

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

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.’

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 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.’

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 - Test design• Kodning - Test kode• Program inspektion - Test inspektion• Test debugging - Testudførelse• Program debugging – Program Test

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)

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, især velegnede til

generering af data med hensyn til senere statistisk undersøgelse• Tidsbesparende ved mange parameter ændringer/stort parameter rum

SPU-tests

• Modultest• Modulintegration• Procesintegration• Accepttest

Test planlægning Test udførelse

Modultest

• Formål: • At sikre at modulet virker som beskrevet i modulspecifikationen

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

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

Trin

vis

inte

grat

ion

The

Big

Ban

g

System

Trinvis integration

For et givet modul hieraki er der to principielle metoder:• Bottom up integration• Top down integration

Bottom-up integrationIn

tegr

atio

nsre

tnin

g

• Sikrer at de overordnede funktioner virker som forventet• Kræver dog at underliggende funktioner er færdige• Sekventielt udvikling/integrationsforløb

Top-down integrationIn

tegr

atio

nsre

tnin

g

• Tillader parralelle udviklingsforløb• Kræver at interface og funktionalitet er korrekt emuleret af stubbe

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)

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?• Eksempel fra SPU bog• Alle involverede skal være

klar over tids- ogafhængighedslinjer

Procesintegrations-test

• Først lidt debugning• Vær beredt: Uforudsete fejl

dukker normalt altid op!• Typiske fejl er mistilpassede

interfaces

• 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?• ….

Accepttest

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

Testmetoder

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

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.

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 ialtvære 1010 kombinationer !!!!

X1 X2 X3 . . . Xn

Program P

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

Domæne-test- SPU Black-Box test

1. Identificér muligt in- og output2. Identificér gyldigt og ugyldigt in- og output3. 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 klasser5. Design en testscenarier for hver klasse med ugyldigt input

SPU 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• Tomt input• ….

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

8. Fejlgætning9. Til både gyldige og ugyldige test-cases specificeres det forventede output

SPU Black-Box test - eksempel

Testdokumentation

Vigtigt af hensyn til:• Bedre overblik• Grundlag for forbedringer• Gentagelse af test• Grundlag for godkendelse• etc.

Testspecifikation

1. Indledning• Formål• Referencer• Tekstens omfang og begrænsninger• Godkendelse

2. Test emner3. Test design4. Test implementation5. Udførelse af test6. Bilag

Test dokumentation/Test rapport

1. Indledning• Referencer• Identifikation

2. Test resultater3. Afvigelser og kommentarer

• Afvigelser fra normal afvikling• Problemer/ændringsforslag

4. Konklusion

Testaktiviteter og test-dokumentation

Et par ord på vejen….

• Test er en væsentlig del af et udviklingsforløb (≈40-50%)

• Fuldstændig dækkende test umuligt

White-Box Testing

• Også kendt som• Structural test• Glass-Box test

• Test af implementering• Instruktioner• Forgreninger• Tilstande• etc

White-Box tests

• Team baserede (“human testing”):• Code Inspection • Walk Through

• Ikke nødvendigvis team baserede:• Path Testing • Loop Testing • Domain Testing

Dagensemne

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

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

Path testing

Procedure:1. Vælg en sti gennem softwaren2. Bestem data der giver den pågældende sti3. Kør softwaren med data fra 2)4. Observér output5. Sammenlign 4) med forventet output

Flowgraph - bestanddele

• En forgrening = et sted hvor der kan ske en ud af flere efterfølgendehandlinger, 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 afforgreninger eller samlinger.• En proces blok har én indgang og én udgang• Programmet hopper hverken ind eller ud af en proces blok

1 INPUT X,YZ:=X+YV:=X-Y

3 IF Z>=0 GOTO SAM4 JOE: Z:=Z+V5 SAM: Z:=Z+V

U:=06 LOOP

B(U),Q(V):=(Z+V)*U7 IF B(U)=0 GOTO JOE

Z:=Z-18 IF Z=0 GOTO ELL

U:=U+19 UNTIL U=Z

B(U-1):=B(U+1)+Q(V-1)10 ELL:B(U+Q(V)):=U+V11 IF U=V GOTO JOE12 IF U>V THEN U := Z13 YY: Z:=U2 END

Eksempel

Eksempel – I flowgraph version

76531 4

91011132 12 8

LinkNode

1 INPUT X,YZ:=X+YV:=X-Y

3 IF Z>=0 GOTO SAM4 JOE: Z:=Z+V5 SAM: Z:=Z+V

U:=06 LOOP

B(U),Q(V):=(Z+V)*U7 IF B(U)=0 GOTO JOE

Z:=Z-18 IF Z=0 GOTO ELL

U:=U+19 UNTIL U=Z

B(U-1):=B(U+1)+Q(V-1)10 ELL:B(U+Q(V)):=U+V11 IF U=V GOTO JOE12 IF U>V THEN U :=

Z13 YY: Z:=U2 END

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)

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

Eksempler på Branch og Statement testing

10

3 4 5 6 2

9 8 7

1

m

a b c d e

i h g f

jklT TF F

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.

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

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• Der findes ingen generel algoritme til at finde ud af hvorvidt en path

predicate er reachabel eller ej

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

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

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

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

Fd

Hvad kan et flowgraph ellers bruges til?

Typiske kode fejl sker i forbindelse med forgreninger og beslutninger. Pathpredikater 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!”

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 overenser 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

To eksempler på path testing

• Funktionen int Abs(int x)• Funktionen Count(file *textfile)

• Betragt følgende funktion:

/* ABSThis program function returns the absolute value of the integerpassed 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

The Flowgraph for ABS

/* ABSThis program function returns the absolute value of the

integerpassed 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 }

100% path dækning umulig !!!

1 3 5 6

Statement Testdækning

1 3 5 6a b c

dF

T

x

-x

Output

√

d

√

√

c

√

b

A positive integer, x

√adc

A negative integer, x

√abc

Inputa

Test casesProcess linksPaths

Branch Testing

x

-x

Output

A positive integer, x

Fadc

A negative integer, x

Tabc

Input

Test casesDecisionsPaths

1 3 5 6F

T

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 }

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 29F

TF

T TT

FF14 23

(b) Flowgraph til branch dækning

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

aghdjkli

√ √ √ √ √ √ √ √ Input File with one character

and no Carriage Return at the

end of the line

Number of characters = 1

Number of lines = 0

aghdefli

√ √ √ √ √ √ √ √ Input file with no characters and

one carriage return

Number of characters = 0

Number of lines = 1

Branch Testdækning

PATHS DECISIONS TEST CASES

8 14

19

22

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

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 50% af alle de fejl der

findes ved modultest• ca. 35% af alle fejl.

• Path testing er mere effektiv for ustruktureret kodning• Erfarne programmører kan “springe over” flow-graphs og vælge

paths direkte fra koden.

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

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