Schwerpunkte

Software-Test

Wie robust ist mein Code?

16. Juli 2018, 17:00 Uhr   |  Frank Büchner, Hitex


Fortsetzung des Artikels von Teil 2 .

Fehlerinjektion ohne Änderung am Quellcode

Mit der neuen Version 4.1 bietet TESSY, ein Werkzeug zum automatisierten Unit-Test eingebetteter Software, einen recht komfortablen Mechanismus zur Fehlerinjektion an. Dieser Mechanismus erfordert keine Änderung des Quellcodes und vermeidet damit viele Nachteile der herkömmlichen Methode. Insbesondere ist es ausgeschlossen, dass die Fehlerinjektion im Endprodukt aktiviert ist, denn die Fehlerinjektion fügt TESSY nur in einer Kopie des Originalcodes ein. Das Tool übernimmt auch die Verwaltung des Codes, der die Fehlerinjektion bewirkt. Außerdem sorgt es dafür, dass die Injektion immer an der richtigen Stelle im Quellcode erfolgt, auch wenn dieser erweitert oder geändert wurde.

Die Stelle der Injektion wird im Flussdiagramm des Testobjekts ausgewählt. Diese Flussdiagramm wird auch dazu verwendet, um ausgeführte (grüne) und nicht ausgeführte (rote) Zweige des Testobjekts darzustellen. Dies ist sinnvoll, denn eine Fehlerinjektion dient ja üblicherweise dazu, einen bisher nicht ausgeführten Zweig des Testobjekts zu durchlaufen.

Hitex
© Hitex

Bild 3: Fehlerinjektion in TESSY V4.1.

Auf der linken Seite von Bild 3 ist das Flussdiagramm unseres Testobjekts ReadWrite() dargestellt und zwar vor jeglicher Fehlerinjektion. Es wurde lediglich der then-Zweig der if-Anweisung durchlaufen (linker Zweig, in grün). Der rechte Zweig, der den else-Zweig der if-Anweisung darstellt, wurde noch nicht durchlaufen. Er ist selektiert, um über die hervorgehobene Schaltfläche mit dem blauen Kreis eine Fehler-injektion zu erzeugen. In der Mitte dieses Bildes wird die Fehlerinjektion spezifiziert. Es ist lediglich der einzufügende Code anzugeben (in unserem Fall die Invertierung des Inhalts der Variablen memory). Auf der rechten Seite von Bild 3 sieht man das Flussdiagramm des Testobjekts nach Durchführung von zwei Testfällen. Die Markierung am rechten Zweig, der den else-Zweig der if-Anweisung darstellt, zeigt, dass dieser Zweig aufgrund einer Fehlerinjektion durchlaufen wurde.

Den Mechanismus zur Fehlerinjektion in TESSY V4.1 eignet sich auch gut, um ohne Änderung am Quellcode dafür zu sorgen, dass der default-Zweig einer switch-Anweisung durchlaufen wird, auch wenn die case-Labels alle möglichen Auswahlwerte abdecken.

Zum Autor:

Frank Büchner ist Prinzipal Engineer Software Quality bei Hitex.

Fault Injection ist nicht Error Seeding

Die in diesem Artikel beschriebene Fehlerinjektion (Fault Injection) ist nicht zu verwechseln mit dem ähnlichen Begriff Fehlereinpflanzung (Error Seeding). Fehlereinpflanzung ist in der IEC 61508, Teil 7, Abschnitt C.5.6 beschrieben. Hierbei geht es um das Einpflanzen von Fehlern in das Testobjekt. Im Fall von Software-Tests wird ein Fehler (Defekt) in den Quellcode, der bereits Tests bestanden hat, eingepflanzt. Beispielsweise wird ein logisches UND durch ein logisches ODER ersetzt, oder aus einem relationalen „<“-Operator wird ein „>“-Operator, oder eine arithmetische Berechnung wird verfälscht. Eingepflanzte Fehler können sehr subtil sein (beispielsweise das Entfernen eines Gleichheitszeichens) oder grob (beispielsweise das Auskommentieren eines ganzen else-Zweigs). Der Fantasie sind keine Grenzen gesetzt, solange die Software syntaktisch korrekt bleibt. Die zugrunde liegende Idee ist, die bereits mit dem Original-Quellcode bestanden Tests nochmals für den Quellcode mit dem eingepflanzten Fehler auszuführen. Die Frage ist, ob (mindestens) einer der Tests nun fehlschlägt und somit den eingepflanzten Fehler aufdeckt. Hieraus kann man Aussagen zur Güte der Testfälle ableiten. Eine Fehlereinpflanzung ist also eine Mutation des Quellcodes, deshalb spricht man bei Fehlereinpflanzung auch von Mutationstests.

Fehlereinpflanzung ändert also das Testobjekt. Ziel ist es, Aussagen über die Güte der Testfälle zu erhalten. Fehlerinjektion hingegen benutzt ein unverändertes Testobjekt, die Fehler werden von außerhalb des Testobjekts in dieses eingebracht oder injiziert. Dessen Ziel ist es, herauszufinden, ob das Testobjekt mit diesen Fehlern umgehen kann.

Seite 3 von 3

1. Wie robust ist mein Code?
2. Gezielte Fehlerinjektion
3. Fehlerinjektion ohne Änderung am Quellcode

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Das könnte Sie auch interessieren

DER Branchentreff der Safety & Security-Experten
Safety trifft auf Security
Reinigung für den Code
Statische Code-Analyse mit Security-Berichten
Statische Tests automatisieren

Verwandte Artikel

Hitex GmbH