Testen van embedded systemen

Presentatie over: "Testen van embedded systemen"— Transcript van de presentatie:

1 Testen van embedded systemen
software

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 Meer realistisch antwoord:
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: Wanneer moet er getest worden? Wie gaan de testen doen? Waar komen de test cases vandaan? Hoe moet het testresultaat geëvalueerd worden? 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. Het doel is om de gemaakte software te kraken. Dit kan leiden tot gespannen verhoudingen tussen ontwikkelaars en testers.

8 Verschillende type testen
Blackbox testen Whitebox testen

9 Het testspectrum Dekking Tester Toepassing Unit Integratie Functioneel
Type test Dekking Tester Toepassing Unit White Box programmeur Kleine eenheden zoals b.v. klasse Integratie White & Black Box Meerdere klassen Functioneel Black Box Onafhankelijk Gehele product Systeem Gehele product in een representatieve omgeving Acceptatie 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)
Sterke punten: - Requirements problemen - Interface - Meest kritische en meest gebruikte kenmerken Zwakke 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 Whitebox test 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

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 Programma verklaringen 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-cases die 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
Er zijn 3 manieren om de Conditionele complexiteit uit te rekenen. 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 graaf N is aan nodes van de graaf. Cyclomatic Complexity Basis path testing 3: Conditionele complexiteit, V(G) =P+1 P is het aantal beslissingsnode van de graaf.

23 Conditionele complexiteit
Aantal nodes: 7 Aantal edges: 9 Aantal regio's: 4 Aantal cond- itionele nodes 3 V(G)=3+1=4 V(G)=9-7+2=4

24 Een afgeleide test case
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: pad 2: pad 3: pad 4: Stap 4: Maak testcases zodat elk pad doorlopen wordt. Stap 5: Voer de test cases uit en controleer de resultaten

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 test node 3 wordt nooit bereikt

29 Whitebox testen (structueel)
Sterke kanten: Veel dekking Effectief Logische en structuele problemen Reken en data fouten Zwakke kanten: Interface en requirements Gericht focus zoeken Interactie met het systeem Timing problemen