Struktureret system udvikling Minimodul 5: Testdesign og planlægning af test

Transkript

1 Struktureret system udvikling Minimodul 5: Testdesign og planlægning af test Rasmus L. Olsen, 9 April, 2008

2 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)

3 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

4 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 kr. pr. time. Ja, tænk på firmaets gode rygte og markedsandel. Nej, den retter vi bare.

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

6 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

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)

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, især velegnede til generering af data med hensyn til senere statistisk undersøgelse Tidsbesparende ved mange parameter ændringer/stort parameter rum

9 SPU-tests Modultest Modulintegration Procesintegration Accepttest Test planlægning Test udførelse

10 Modultest Formål: At sikre at modulet virker som beskrevet i modulspecifikationen Indhold: Test af grænsefladen og interne, logiske struktur af programmet

11 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 System The Big Bang Trinvis integration

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

13 Bottom-up integration Integrationsretning Sikrer at de overordnede funktioner virker som forventet Kræver dog at underliggende funktioner er færdige Sekventielt udvikling/integrationsforløb

14 Top-down integration Integrationsretning Tillader parralelle udviklingsforløb Kræver at interface og funktionalitet er korrekt emuleret af stubbe

15 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)

16 Procesintegration Planlægning af aktiviteter HvornårermodulX 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- og afhængighedslinjer

17 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?.

18 Accepttest

19 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

20 Testmetoder

21 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

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

23 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! X 1 X 2 X 3... X n Program P Hvis n = 10 og der vælges 10 test værdier for hver variabel vil der ialt være kombinationer!!!!

24 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

25 Domæne-test - SPU 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

26 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ætning 9. Til både gyldige og ugyldige test-cases specificeres det forventede output

27 SPU Black-Box test - eksempel

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

29 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

30 Test dokumentation/test rapport 1. Indledning Referencer Identifikation 2. Test resultater 3. Afvigelser og kommentarer Afvigelser fra normal afvikling Problemer/ændringsforslag 4. Konklusion

31 Testaktiviteter og testdokumentation

32 Et par ord på vejen. Test er en væsentlig del af et udviklingsforløb ( 40-50%) Fuldstændig dækkende test umuligt

33 White-Box Testing Også kendt som Structural test Glass-Box test Test af implementering Instruktioner Forgreninger Tilstande etc

34 White-Box tests Team baserede ( human testing ): Code Inspection Walk Through Ikke nødvendigvis team baserede: Path Testing Loop Testing Domain Testing Dagens emne

35 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

36 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 3 20 forskellige sekvenser

37 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

38 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

39 Eksempel 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

40 Eksempel I flowgraph version Node Link 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

41 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)

42 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

43 Eksempler på Branch og Statement testing 1 a b c d e i h g f 10 l T k F m j T F

44 Branch and Statement dækning Spørgsmål: Harhverforgreninget 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.

45 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 ifthen-else statements. Eksempel Input {X1,,X6} if (X5 > 0 X6 < 0) /* predicates A,B */... if(x1 + 3 * X >= 0) /* predicate C */... if(x3 == 17) /* predicate D */... if(x4 - X1 >= 14 * X2) /* predicate E */... Path Predicate udtryk: ACDE + BCDE = (A+B)CDE

46 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 af processeringen i rutinen (Un)Correlated Predicates: hvis resultatet afhænger af hinanden

47 Eksempel: ukorreleret & uafhængig a T b c F d e f l A 4 C g B F F T l h 9 i T m F D j T k 4 binære beslutninger medfører: 4 2 = 16 mulige paths.

48 Eksempel: korrellerede & uafhængige b e F a l A 4 d A 6 2 F g T T c f Paths abdeg og acdfg synes at give dækning, men er ikke muligt!! Kun 2 paths er mulige: abdfg og acdeg.

49 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!

50 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

51 To eksempler på path testing Funktionen int Abs(int x) Funktionen Count(file *textfile)

52 Using Path Testing to Test Function ABS 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 }

53 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 } % path dækning umulig!!!

54 Statement Testdækning Paths Process links Test cases a b c d Input Output abc A negative integer, x -x adc A positive integer, x x d F a b c T

55 Branch Testing Paths Decisions Test cases Input Output abc T A negative integer, x -x adc F A positive integer, x x F T

56 Funktionen Count(file *fp) /* COUNT This program counts the number of characters and lines in a text file. INPUT: Text File OUTPUT: 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; 7 8 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 else 25 ++numchars; 26 } 27 printf( \nnumber of characters = %d, numchars); 28 printf( \nnumber of lines = %d, numlines); 29 }

57 The Flowgraph for COUNT g (a) Flowgraph til statement dækning j i a b c d e k h f L F F F 1 8 T T T 22 T F (b) Flowgraph til branch dækning

58 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 aghd efli Input File with one character and no Carriage Return at the end of the line Input file with no characters and one carriage return Number of characters = 1 Number of lines = 0 Number of characters = 0 Number of lines = 1

59 Branch Testdækning PATHS DECISIONS TEST CASES 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

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

61 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

62 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

63