minimodul 5: testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemdesign08/mm5.pdf ·...
TRANSCRIPT
![Page 1: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/1.jpg)
Struktureret system udvikling
Minimodul 5: Testdesign og planlægning af test
Rasmus L. Olsen, 9 April, 2008
![Page 2: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/2.jpg)
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)
![Page 3: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/3.jpg)
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
![Page 4: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/4.jpg)
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.’
![Page 5: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/5.jpg)
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.’
![Page 6: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/6.jpg)
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
![Page 7: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/7.jpg)
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)
![Page 8: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/8.jpg)
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
![Page 9: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/9.jpg)
SPU-tests
• Modultest• Modulintegration• Procesintegration• Accepttest
Test planlægning Test udførelse
![Page 10: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/10.jpg)
Modultest
• Formål: • At sikre at modulet virker som beskrevet i modulspecifikationen
• Indhold: • Test af grænsefladen og interne, logiske struktur af programmet
![Page 11: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/11.jpg)
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
![Page 12: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/12.jpg)
Trinvis integration
For et givet modul hieraki er der to principielle metoder:• Bottom up integration• Top down integration
![Page 13: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/13.jpg)
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
![Page 14: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/14.jpg)
Top-down integrationIn
tegr
atio
nsre
tnin
g
• Tillader parralelle udviklingsforløb• Kræver at interface og funktionalitet er korrekt emuleret af stubbe
![Page 15: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/15.jpg)
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)
![Page 16: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/16.jpg)
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
![Page 17: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/17.jpg)
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?• ….
![Page 18: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/18.jpg)
Accepttest
![Page 19: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/19.jpg)
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
![Page 20: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/20.jpg)
Testmetoder
![Page 21: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/21.jpg)
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
![Page 22: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/22.jpg)
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.
![Page 23: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/23.jpg)
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
![Page 24: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/24.jpg)
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
![Page 25: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/25.jpg)
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
![Page 26: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/26.jpg)
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
![Page 27: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/27.jpg)
SPU Black-Box test - eksempel
![Page 28: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/28.jpg)
Testdokumentation
Vigtigt af hensyn til:• Bedre overblik• Grundlag for forbedringer• Gentagelse af test• Grundlag for godkendelse• etc.
![Page 29: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/29.jpg)
Testspecifikation
1. Indledning• Formål• Referencer• Tekstens omfang og begrænsninger• Godkendelse
2. Test emner3. Test design4. Test implementation5. Udførelse af test6. Bilag
![Page 30: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/30.jpg)
Test dokumentation/Test rapport
1. Indledning• Referencer• Identifikation
2. Test resultater3. Afvigelser og kommentarer
• Afvigelser fra normal afvikling• Problemer/ændringsforslag
4. Konklusion
![Page 31: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/31.jpg)
Testaktiviteter og test-dokumentation
![Page 32: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/32.jpg)
Et par ord på vejen….
• Test er en væsentlig del af et udviklingsforløb (≈40-50%)
• Fuldstændig dækkende test umuligt
![Page 33: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/33.jpg)
White-Box Testing
• Også kendt som• Structural test• Glass-Box test
• Test af implementering• Instruktioner• Forgreninger• Tilstande• etc
![Page 34: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/34.jpg)
White-Box tests
• Team baserede (“human testing”):• Code Inspection • Walk Through
• Ikke nødvendigvis team baserede:• Path Testing • Loop Testing • Domain Testing
Dagensemne
![Page 35: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/35.jpg)
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
![Page 36: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/36.jpg)
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
![Page 37: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/37.jpg)
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
![Page 38: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/38.jpg)
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
![Page 39: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/39.jpg)
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
![Page 40: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/40.jpg)
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
![Page 41: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/41.jpg)
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)
![Page 42: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/42.jpg)
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
![Page 43: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/43.jpg)
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
![Page 44: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/44.jpg)
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.
![Page 45: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/45.jpg)
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
![Page 46: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/46.jpg)
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
![Page 47: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/47.jpg)
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
![Page 48: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/48.jpg)
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
![Page 49: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/49.jpg)
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!”
![Page 50: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/50.jpg)
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
![Page 51: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/51.jpg)
To eksempler på path testing
• Funktionen int Abs(int x)• Funktionen Count(file *textfile)
![Page 52: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/52.jpg)
• 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
![Page 53: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/53.jpg)
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
![Page 54: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/54.jpg)
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
![Page 55: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/55.jpg)
Branch Testing
x
-x
Output
A positive integer, x
Fadc
A negative integer, x
Tabc
Input
Test casesDecisionsPaths
1 3 5 6F
T
![Page 56: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/56.jpg)
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 }
![Page 57: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/57.jpg)
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
![Page 58: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/58.jpg)
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
![Page 59: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/59.jpg)
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
![Page 60: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/60.jpg)
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.
![Page 61: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/61.jpg)
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
![Page 62: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/62.jpg)
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
![Page 63: Minimodul 5: Testdesign og planlægning af testkom.aau.dk/~rlo/lectures/systemDesign08/mm5.pdf · 2008-04-09 · Testbehov er forskellige • Hvordan gik det ved afleveringen af det](https://reader033.vdocuments.net/reader033/viewer/2022041717/5e4c617c1f5ec902ee4f70e3/html5/thumbnails/63.jpg)