Struktureret system udvikling

Transkript

1 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

2 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

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 3

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

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

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 - 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 Modultest Modulintegration Accepttest Procesintegration 6

7 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

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

9 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

10 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

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

12 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

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

14 Eksempel på hvad man ikke skal gøre - Ariane 5 4. Juni 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 $

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

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

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

18 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

19 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

20 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

21 Accepttest 21

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

23 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

24 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

25 Testmetoder 25

26 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 Kravspec. Accepttest Programdesign Procesintegration Procesdesign Modulintegration Moduldesign Modultest Implementation 26

27 Black box test 27

28 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

29 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 i alt være kombinationer!!!! 29

30 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

31 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 klasse 2: X>999 klasse 3: 0 X 10 klasse 4: 11 X 999 (ugyldigt input) (ugyldigt input) (gyldigt input) (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

32 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

33 Black-Box test - eksempel 33

34 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

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

36 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

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

38 Testaktiviteter og testdokumentation 38

39 White box test 39

40 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 E W S c o m p 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

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

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

43 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

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

45 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

46 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

47 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 14 END 47

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

49 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

50 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

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

52 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

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

54 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

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

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

57 Rekursive algoritmer/uendelige løkker... Pga. Loop har vi stadig mange muligheder Hvis løkken gennemløbes 20 gange er der i alt 3 20 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

58 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

59 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

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

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

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

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

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

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

66 The Flowgraph for COUNT (a) Flowgraph til statement dækning g 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 66

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

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

69 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

70 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

71 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 72

73 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