Testen van embedded systemen software

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

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.

Testen van embedded software soorten testen wanneer testen hoe moet er getest worden programma doorlopen

? Testen van embedded software De meeste multithreads programma’s lijken perfect te lopen wanneer de locks worden verwijderd ?

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?

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.

Verschillende type testen Blackbox testen Whitebox testen

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

Blackbox testen

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.

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

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

Whitebox testen

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.

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

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.

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.

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.

Programma uitvoerings graaf.

Programma uitvoerings graaf.

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.

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

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: 1-2-4-5-6-7 pad 2: 1-2-4-7 pad 3: 1-2-3-2-4-5-6-7 pad 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 voorbeeld

Data flow Software test Test de paden van de graaf aan de hand van de waarde van variabelen.

Data flow Software test

Data flow Software test node 3 wordt nooit bereikt

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