De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

1 Testen van embedded systemen software. 2 Testen kenmerken • Alle software heeft fouten •Programma’s kunnen niet uitvoerig worden getest. •De afwezigheid.

Verwante presentaties


Presentatie over: "1 Testen van embedded systemen software. 2 Testen kenmerken • Alle software heeft fouten •Programma’s kunnen niet uitvoerig worden getest. •De afwezigheid."— Transcript van de presentatie:

1 1 Testen van embedded systemen software

2 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 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 4 Testen van embedded software • soorten testen • wanneer testen • hoe moet er getest worden • programma doorlopen

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

6 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 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. oHet doel is om de gemaakte software te kraken. oDit kan leiden tot gespannen verhoudingen tussen ontwikkelaars en testers.

8 8 Verschillende type testen • Blackbox testen • Whitebox testen

9 9 Het testspectrum Type test DekkingTesterToepassing Unit White BoxprogrammeurKleine eenheden zoals b.v. klasse Integratie White & Black Box programmeurMeerdere klassen Functioneel Black BoxOnafhankelijkGehele product Systeem Black BoxOnafhankelijkGehele product in een representatieve omgeving Acceptatie Black BoxKlant(en)Product bij de klant Regressie White & BlackProgrammeurs of onafhankelijke Na een verandering, test opnieuw op betrouwbaarheid

10 10 Blackbox testen

11 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 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 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 14 Whitebox testen

15 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 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 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 verklaringen o Doorlopen van verschillende programmapaden - interne logica en datastructuren van een programma. - interne gedrag en states van een programma.

18 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 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 20 Programma uitvoerings graaf.

21 21 Programma uitvoerings graaf.

22 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 graaf N 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 23 Conditionele complexiteit Aantal regio's: 9 Aantal edges: 4 7Aantal nodes: Aantal cond- itionele nodes 3 V(G)=9-7+2=4 V(G)=3+1=4

24 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: 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 Een afgeleide test case

25 25 Een voorbeeld

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

27 27 Data flow Software test

28 28 Data flow Software test node 3 wordt nooit bereikt

29 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


Download ppt "1 Testen van embedded systemen software. 2 Testen kenmerken • Alle software heeft fouten •Programma’s kunnen niet uitvoerig worden getest. •De afwezigheid."

Verwante presentaties


Ads door Google