minimodul 5: testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemdesign08/mm5.pdf ·...
TRANSCRIPT
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