Branch-Coverage-Tests
Minimalinvasiv testen
Fortsetzung des Artikels von Teil 1
Path Coverage
Demgegenüber müssen beim Path Coverage alle möglichen Pfade durch ein Modul durchlaufen werden (Bild 2). Dies führt bei mehreren nacheinander folgenden Entscheidungen, insbesondere aber bei Schleifen, die Entscheidungslogik enthalten, zu extrem vielen Pfaden. Vollständiges Condition Coverage wiederum verlangt, dass jede atomar zu testende Bedingung einer Entscheidung in allen Kombinationen einmal mit wahr (true) und einmal mit falsch (false) durchlaufen werden muss. Selbst bei einem einfachen Entscheidungsausdruck wie if (a || b) ergibt das bereits vier zu testende Möglichkeiten.
Jobangebote+ passend zum Thema
Branch Coverage meistens gute Wahl
Eine höhere Stufe der Codeabdeckung lässt sich also bei konventioneller Vorgehensweise in jedem Fall nur mit einem höheren Testaufwand erzielen. In der Praxis ist deshalb immer eine Kosten-Nutzen-Abwägung zu treffen. ISO 26262 gibt beispielsweise zum Erreichen bestimmter Automotive Safety Integrity Levels (ASIL) die in der Tabelle aufgeführten Empfehlungen. Diesen Empfehlungen zufolge ist Branch Coverage über alle ASIL-Levels als solides Verfahren zur Codeabdeckungsanalyse eingestuft.
| ASIL A | ASIL B | ASIL C | ASIL D | |
|---|---|---|---|---|
| Statement Coverage (C0) | ++ | ++ | + | + |
| Branch Coverage (C1) | + | ++ | ++ | ++ |
| MC/DC (Modified Condition/Decision Coverage) (C3) | + | + | + | ++ |
Empfehlungen zu Coverage-Verfahren nach ISO 26262. + + steht für »sehr zu empfehlen (highly recommended)«, + steht für »zu empfehlen (recommended)«
Aufgabe einer Testanordnung für Branch Coverage ist neben der Stimulierung des Systems mit speziellen oder funktionalen Tests die Erkennung der durchlaufenen Kanten des Kontrollflussgraphen. Dies erfolgt häufig immer noch durch eine Instrumentierung des Programmcodes, der Speicherung der Ergebnisse im Datenspeicher des Systems und/oder der Aussendung der Daten. Für die hier betrachtete Klasse von Steuergeräten im Automotive- und insbesondere Powertrain-Bereich ist ein solches Vorgehen aber nur sehr bedingt anwendbar. Zum einen hat die Instrumentierung einen signifikanten Einfluss auf das Laufzeitverhalten des Systems, zum anderen wird durch den zusätzlichen Programmcode die Gesamtgröße und damit gegebenenfalls auch das Speicherlayout der Applikation verändert. Außerdem lässt sich das Verfahren nur an nicht optimiertem Code sinnvoll durchführen, weil die Code-Optimierung die Struktur des Maschinencodes derart verändern kann, dass die eineindeutige Abbildung von Basisblöcken der Quellcode-Ebene auf Basisblöcke der Maschinencode-Ebene nicht mehr möglich ist. Unter anderem werden Basisblöcke bei der Optimierung vervielfältigt, zusammengefasst oder eliminiert. Solche Programmtransformationen treten z.B. bei Optimierungen wie Schleifentransformationen (Schleifenspaltung, -vereinigung, oder -expansion), if-then-else-Transformationen (z.B. Eliminierung eines Anweisungszweiges) und Umwandlung von Basisblöcken in Tabellenzugriffe auf. Die zuletzt genannte Optimierung soll am Beispiel einer switch-Anweisung demonstriert werden.
- Minimalinvasiv testen
- Path Coverage
- Code-Optimierung: von leicht geändert bis total umgewandelt
- Erkennung der Programmstruktur
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Kooperation von PLS und LieberLieber Software
Modellorientiert entwickeln, testen und debuggen
Lizenzen, Exportbestimmungen, Schwachstellen:
Open Source Code effektiv verwalten
Entwicklungswerkzeuge
Automatisch testen im Zielsystem
Forum Funktionale Sicherheit 2014
Fehler sind menschlich
Betriebssysteme
Linux mit Sicherheit
Kooperation im Tool-Bereich
Hitex vertreibt UDE von PLS
Software-Sicherheit
Protection Suite von Wibu schützt und lizenziert
