Struktureret Systemudvikling

1. Struktureret Systemudvikling • Software Test • Introduktion • Black-Box test • Ekstra om blackbox og whitebox

2. Generelt om test ? • Er det ikke testet virker det ikke ! • Alle laver fejl (men der forskel på antallet) • 1%-3% fejl (afh. af kompleksitet, m.m.) • Fejl skal findes så tidligt som muligt

3. Generelt om test ? • Test ≠ debugging • test: påviser fejl • debugging: lokaliserer fejl • Test: kan i visse tilfælde udføres af personer uden kendskab til programmet • Debugging: kræver detaljeret kendskab til programmet

4. Generelt om test ? • Blot det at planlægge test reducerer antallet af fejl ! • Formål med testing: forhindre + finde fejl

5. Forskelligt syn på testing • Ingen forskel mellem testing og debugging • test skal vise af softwaren virker • test skal vise af softwaren IKKE virker • test skal ikke vise noget, men reducere risikoen (statistisk kvalitetskontrol) • testplanlægning fører til software der ikke behøves megen testing.

6. design kodning skrivebordscheck test debug design test design kodning test kode program inspektion test inspektion test debugging testudførelse program debugging test Test bør have en fremtrædende rolle

7. Paradokser • Pesticide paradokset: • Enhver metode til at forhindre eller finde fejl efterlader fejl, som metoden er ineffektiv overfor • Kompleksitets paradokset: • Software kompleksibiliteten øges konstant til grænsen af vores formåen (tilsvarende mere komplekse fejl)

8. Forskellige testbehov • 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.’

9. Forskellige testbehov • Vil en eventuel fejl være svær (dyr!!) at rette? • 'Ja, vores system er installeret på Nordpolen.' • ‘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.’

10. SPU-tests • Modultest • Modulintegration • Procesintegration • Accepttest

11. Testplanlægning

12. Testteknikker • Princip: veldefineret input ⇒ forventet output • Reproducérbare test = veldokumenterede • Interaktiv/manuel test: • billig og enkel udvikling • tidskrævende • Automatiske test: • udviklingskrævende • ved mange ændringer kan det være en effektiv metode

13. Testintrumentering Indsættelse af udskrivningsrutiner i koden: #ifdef TESTENV printf( "%d ", i ); #endif

14. Modultest • Formål: • at sikre at det virker som beskrevet i modulspecifikationen • Indhold: • test af grænsefladen og interne, logiske struktur af programmet

15. Modultest

16. Integrationstests • Trinvis: • enheder tilføjes én efter én med en integrationstest ved hver tilføjelse • Samlet integration (Big Bang) • individuelle enheder testes • alt samles derefter i én ombæring

17. Modulintegration • Modulhiraki:

18. Bottom-up integration

19. Top-down integration

20. I praksis • 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 • kan der testes hvis nogle enheder mangler • er der noget der skal demonstreres tidligt (kritisk)

21. Accepttest

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

23. Stress-test Volumentest Brugertest Sikkerhedstest Test af ydeevne Lagertest Konfig.test Kompatibilitetstest Pålidelighedstest Fejlbehandlingstest Accepttest ideer

24. Testmetoder

25. Black-Box ingen kendskab til interne struktur ikke nødvendigt med kendskab til softwaren primært ved de sidste test trin i V-modellen White-Box tester interne strukturer kendskab til softwaren nødvendig primært de første test trin i V-modellen Black-Box vs. White-Box

26. Black-Box testing • Black-box = functional = behavioral test • Test uden kendskab til programmets struktur • Stort antal black-box teknikker: • IO analyse • domæne-analyse • stokastisk • etc.

27. 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!

28. Klassisk eksempel: trekant • Bestem om en trekant med siderne a,b og c er: • equilateral (alle sider lige lange a=b=c), • isoceles (to sider har samme længe), • scalene (ingen sider har samme længde), • eller ikke en trekant b a c

29. Tests

30. Kombinatorisk eksplosion X1 X2 X3 . . . Xn Program P Hvis n = 10 og der vælges 10 test værdier for hver variabel vil der ialt være 1010 kombinationer !!!!

31. Kombinatorisk problem • Ved kombinatorisk black-box testing opstår der let flere test-cases end der er ressourcer til at udføre • Hvordan reduceres antallet at test-cases uden at mindske sandsynligheden for at finde fejl ?

32. Simpelt eksempel på anvendt IO analyse Input data valgt ud fra ækvivalens opdeling: A={1, 3} B={N,S,E,W} C={TDC, BDM} Program P W Z Det totale antal tests: 2 * 4 * 2 = 16

33. Anvendt IO Analyse A={1, 3} B={N,S,E,W} C={TDC, BDM} W Z

34. Anvendt IO analyse A={1, 3} B={N,S,E,W} C={TDC, BDM} T(W)  T(Z) (1, N, TDC) (1, N, BDM) (3, N, TDC) (3, N, BDM) (1, S, TDC) (1, E, TDC) (1, W, TDC) W Z T(W) (1, N, TDC) (1, N, BDM) (3, N, TDC) (3, N, BDM) T(Z) (1, N, TDC) (1, S, TDC) (1, E, TDC) (1, W, TDC)

35. Optimerings Problem • Bestem det mindst mulige test sæt som dækker alle kombinationer i de individuelle output test sæt: • Test sæt optimeret med “Don’t Care” (DC) T(W) (1, DC, TDC) (1, DC, BDM) (3, DC, TDC) (3, DC, BDM) T(Z) (DC, N, DC) (DC, S, DC) (DC, E, DC) (DC, W, DC) Toptimeret (1, N, TDC) (1, S, BDM) (3, E, TDC) (3, W, BDM)

36. Bestemmelse af Input-Output relationer • Informationer kan fremskaffes på forskellige måder (f.eks. fra specifikationer, kode, mm.) • Manuel bestemmelse er svært og tidskrævende • Automatisk bestemmelse vha. • statisk analyse (vha. kildetekster) • dynamisk analyse (vha. kildetekster) • software kørsler (uden kildetekster)

37. Domæne-testSPU Black-Box test • Identificér muligt in- og output • Identificér gyldigt og ugyldigt in- og output • 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)

38. SPU Black-Box test • Design testcases med gyldigt input som dækker flest mulige klasser • Design en testcase for hver klasse med ugyldigt input • Supplér med grænseværdier: • første element • sidste element • max/min værdi • én over/under grænsen • tomt input • etc.

39. SPU Black-Box test • For hver grænseværdi genereres en ny test-case som dækker én og kun én grænseværdi • Fejlgætning • Til både gyldige og ugyldige test-cases specificeres det forventede output

40. Testdokumentation • Vigtigt af hensyn til: • bedre overblik • grundlag for forbedringer • gentagelse af test • grundlag for godkendelse • etc.

41. Testspecifikation

42. Testrapport

43. Test-dokumentation udvikling gennem faserne

44. Opsummering • Test er en væsentlig del af et udviklingsforløb (≈40-50%) • To grundlæggende test-principper • Black-Box • White-Box (glass-box) • Fuldstændig dækkende test umuligt • Reducér antallet af test-cases • IO-analysis, partitioning, etc.