1

Testen van embedded systemensoftware

2

Testen kenmerken

• Alle software heeft fouten

• Programma’s kunnen niet uitvoerig worden getest.

• De afwezigheid van fouten kan niet bewezen worden.

• Software systemen zijn vaak broos

3

Wat is een bug

•Een “bug” is een software defect = incorrecte software

•Een software defect is een geval waarin de software in strijd is met de specificaties.

Meer realistisch antwoord:

•Faalt bij het uitvoeren van het gewenste gedrag.

•Verstrekken van een ongedocumenteerd gedrag.

•Niet nakomen van een ontwerp beperkingen (timing, veiligheid,..

•Niet alle requirements zijn in de software uitgevoerd.

• Alle “redelijke” klachten van een klant.

• ………….

Het doel van testen is het vinden van de meeste bug’s in de meest uitgebreide zin.

4

Testen van embedded software

• soorten testen• wanneer testen• hoe moet er getest worden• programma doorlopen

5

Testen van embedded software

De meeste multithreads programma’s lijken perfect te lopen wanneer de locks worden verwijderd

?

6

Testen

• Testen is de fundamentele manier om betrouwbare embedded software te creëren.

• Goede test-technieken zijn niet gemakkelijk of intuïtief.• Er zijn veel basis vragen:

o Wanneer moet er getest worden?o Wie gaan de testen doen?o Waar komen de test cases vandaan?o Hoe moet het testresultaat geëvalueerd worden?o Wanneer is er voldoende getest?

7

Testen

• Het maken van goede testen van je eigen software is moeilijk.

• Bij de meeste bedrijven zijn testers en ontwikkellaars verschillende personen.

• Goede testers zijn vijandig.o Het doel is om de gemaakte software te

kraken.o Dit kan leiden tot gespannen verhoudingen

tussen ontwikkelaars en testers.

8

Verschillende type testen

• Blackbox testen

• Whitebox testen

9

Het testspectrumType test Dekking Tester Toepassing

Unit White Box programmeur Kleine eenheden zoals b.v. klasse

Integratie White & Black Box

programmeur Meerdere klassen

Functioneel Black Box Onafhankelijk Gehele product

Systeem Black Box Onafhankelijk Gehele product in een representatieve

omgeving

Acceptatie Black Box Klant(en) Product bij de klant

Regressie White & Black Programmeurs of onafhankelijke

Na een verandering, test opnieuw op betrouwbaarheid

10

Blackbox testen

11

Blackbox testen (functioneel)

Voer gegevens in en onderzoek hoe het systeem reageert.

Testprocedures worden van te voren beschreven evenals de verwachte uitkomst.

Subsystemen worden getest en geïntegreerd

- Het effect is matig

- kosten: tijd is matig, materiaal variërend.

12

Blackbox testen (functioneel)

Zwakke punten:

- Requirements problemen

- Interface

- Meest kritische en meest gebruikte kenmerken

Sterke punten:

- Slechte dekking.

-Timing en andere problemen blijven verborgen.

- Fout condities

13

Blackbox test procedures.

• Requirements testen.

• Kies een strategie

- 1 test per requirement.

- Test kleine groepen requirements.- Scenario.

• Schrijf test cases.

-Omgeving

-Requirements

-Verwachte uitvoer

• Traceerbaarheid

14

Whitebox testen

15

Whitebox testen (structueel)

• Bekijk hoe de code werkt.

• Test procedures.

• Volg de paden (PATH) met gebruik making van de vele variabele.

• Consistentie tussen ontwerp en implementatie.

- Het effect is hoog.

- kosten: tijd is hoog, materiaal laag tot middelmatig.

16

Wat is white-box testen van software?Basisidee is om een programma te testen dat gebaseerd op de structuur van een ontwerp.

Wat heb je nodig voor de white-box testen?- Een white-box testmodel en testcriteria- Een white-box opzet van de test- en productie-methode- Programma broncode.

White-box testmethoden kunnen worden ingedeeld in:- Traditionele white-box testmethoden- Object-oriented white-box testmethoden- Component-oriented white-box testmethoden

Whitebox test

17

Whitebox test

Het voornaamste doel van white-box testen is om zich te concentreren op de interne structuur van het programma, en alle interne programma fouten te ontdekken.

De hoofdtest richt zich:- Programma structuren

o Programma verklaringeno Doorlopen van verschillende programmapaden

- interne logica en datastructuren van een programma.

- interne gedrag en states van een programma.

18

Whitebox test

Test Model: controleprogramma-graaf

Testcase ontwerp:Diverse white-box testmethoden genereren test-casesdie gebaseerd zijn op de controle-programmagraaf van het programma.

Het doel is om:- Waarborgen dat alle onafhankelijke paden binnen

een module ten minste een keer worden doorlopen.- Voer alle logische beslissingen aan zowel de true

als de false kant uit.- Voer alle lussen op de grenzen en binnen de

operationele grenzen uit.- Controleer de interne data structuren of ze geldig

blijven.- Controleer alle data definities en de gebruikte

paden.

19

Basis pad testen

- Wordt gebruikt als basis set om alle paden te doorlopen. - Zorg ervoor dat elke instructie in het programma tenminste 1

keer wordt uitgevoerd.

20

Programma uitvoerings graaf.

21

Programma uitvoerings graaf.

22

Conditionele complexiteit

1: Het aantal regio's van een uitvoeringsgraaf komt overeen met de conditionele complexiteit

2: Conditionele complexiteit, V(G) van een uitvoeringsgraaf is als volgt te definiëren: V(G)= E-N+2

E is aan aantal edges van de graafN is aan nodes van de graaf.

3: Conditionele complexiteit, V(G) =P+1

P is het aantal beslissingsnode van de graaf.

Er zijn 3 manieren om de Conditionele complexiteit uit te rekenen.

23

Conditionele complexiteit

Aantal regio's:

9Aantal edges:

4

7Aantal nodes:

Aantal cond-itionele nodes 3

V(G)=9-7+2=4

V(G)=3+1=4

24

Stap 1: Teken de uitvoeringsgraaf a.d.v. het ontwerp of de code.

Stap 2: Bepaal de conditionele complexiteit a.h.v. de gemaakte graaf.

Stap 3: Bepaal een minimale basis set van lineair onafhankelijke paden.

Bijvoorbeeld,

pad 1: 1-2-4-5-6-7pad 2: 1-2-4-7pad 3: 1-2-3-2-4-5-6-7pad 4: 1-2-4-5-6-5-6-7

Stap 4: Maak testcases zodat elk pad doorlopen wordt.

Stap 5: Voer de test cases uit en controleer de resultaten

Een afgeleide test case

25

Een voorbeeld

26

Data flow Software test

Test de paden van de graaf aan de hand van de waarde van variabelen.

27

Data flow Software test

28

Data flow Software testnode 3 wordt nooit bereikt

29

Whitebox testen (structueel)

Sterke kanten:

• Effectief

• Logische en structuele problemen

• Veel dekking

• Reken en data fouten

Zwakke kanten:

• Interface en requirements

• Gericht focus zoeken• Interactie met het systeem

• Timing problemen