Embedded-Software automatisiert testen
Testfallgüte problemlos prüfen
Fortsetzung des Artikels von Teil 1
Endlosschleifen und Abstürze bei Mutationen
Durch Mutationen können auch Endlosschleifen entstehen. Das bedeutet, dass ein Test nicht zum Ende kommt. Damit eine solche Mutation nicht den gesamten Prozess zum Erliegen bringt, überwacht TESSY die Ausführungszeit. Überschreitet die Ausführungszeit einer Mutation die Ausführungszeit ohne Mutation um das Zehnfache, bricht TESSY die Testdurchführung ab. Endlosschleife beziehungsweise Timeout tötet die Mutation. Ergibt sich durch eine Mutation ein Absturz des Testobjekts, tötet dies ebenfalls die Mutation. Bild 6 zeigt, wie die Funktion count() mit einem Testfall getestet wird, der den Eingabewert 10 für den Parameter x hat und mit dem Return-Wert 1 das korrekte Ergebnis liefert. Dieser Testfall tötet alle vier auf der linken Seite von Bild 6 angegebenen Mutationen. Die dritte Mutation (von <= zu >=) wird allerdings nicht wie üblich durch Fehlschlagen des Testfalls getötet, sondern durch eine Endlosschleife und dem dadurch ausgelösten Timeout. TESSY bewertet diese Mutation als getötet.
Jobangebote+ passend zum Thema
Äquivalente Mutationen sind problematisch
Das Hauptproblem des Mutationstests sind äquivalente Mutationen. Sie verändern das Verhalten des Testobjekts nach außen nicht, weshalb eine solche Mutation nicht durch einen Testfall getötet werden kann. Daher muss man alle überlebenden Mutationen aufwendig manuell daraufhin überprüfen, ob es sich um eine äquivalente Mutation handelt oder nicht. Hilfreich ist es in diesem Fall jedoch, wenn, wie bei TESSY, immer nur eine Mutation vorgenommen wird. Äquivalente Mutationen kann man wie getötete Mutationen betrachten; sie weisen nicht auf mangelhafte Testfälle hin.
Bild 7 zeigt eine äquivalente Mutation. Die Änderung des relationalen Vergleichsoperators von > zu >= erzeugt keine nach außen sichtbare Wirkung und lässt sich deshalb auch durch keinen Testfall töten. Aber für den Eingabewert 0 ergibt sich durchaus ein anderes internes Programmverhalten (im Originalcode wird der else-Zweig der if-Anweisung durchlaufen, in der Mutation der then-Zweig).
Mutationstest in IEC-/ISO-Standards
Die IEC 61508 bezeichnet den Mutationstest als »Durchführung von Testfällen nach Fehlereinpflanzung« und empfiehlt dies für SIL 2 bis 4 (in Tabelle B.2 von Teil 3). Die ISO 26262 erwähnt »Code Mutations« lediglich in einer Fußnote zur Methode »Fault Injection Test« in Tabelle 7 von Teil 6, die Methoden zur Software-Unit-Verifikation aufführt. Allerdings werden hier »Code Mutations« in einen Topf mit Verfahren des Robustheitstests wie das willkürliche Verändern (Korrumpieren) von Datenspeicher oder CPU-Registern geworfen. Durch das Korrumpieren beispielsweise von Werten von Variablen im Datenspeicher liest das Testobjekt nicht die Werte zurück, die dort vorher abgespeichert waren. Das Testziel einer solchen Fehlerinjektion (Fault Injection) ist es, herauszufinden, ob das Testobjekt damit zurechtkommt.
Konkreter formuliert: Erkennt (beispielsweise aufgrund redundanter Speicherung der Werte) das Testobjekt beispielsweise einen Bitflip durch kosmische Strahlung, und reagiert es geeignet darauf? Eine solche Fragestellung unterscheidet sich fundamental vom Ziel des Mutationstests, nämlich die Qualität der Testfälle zu bewerten und durch bessere Testfälle möglicherweise Programmierfehler aufzudecken.
Automatisierte Tests
Mit Mutationstest lassen sich mangelhafte Testfälle aufdecken. Deren Verbesserung erhöht die Chance, Fehler in der getesteten Software zu finden. Deshalb bewerten Mutationstest nicht nur die Güte der Testfälle, sondern tragen auch zu einer besseren Qualität der getesteten Software bei. In TESSY lassen sich solche Tests ohne weiteren Aufwand automatisiert vornehmen.
| Fachbegriffe bei Mutationstests |
|---|
|
➔ Fehlermodell (Fault Model): Die Kategorien der möglichen Mutationen. Diese sind natürlich beieinem C-Programm als Testobjekt anders als zum Beispiel bei einem Zustandsdiagramm. ➔ Fehlereinpflanzung (Error Seeding): In der IEC 61508 heißt der Mutationstest Fehlereinpflanzung beziehungsweise Error Seeding. ➔ Kopplungseffekt (Coupling Effect): Wird ein Mutant mit einer einzelnen Mutation durch eine Testfallmenge entdeckt, so werden auch mehrfache Mutationen entdeckt. ➔ Starker Mutationstest (Strong Mutation Test): Der Mutant wird nur von außen betrachtet (Black Box). Er wird nur durch einen Testfall entdeckt, der nach außen ein anderes Ergebnis liefert als das Original. ➔ Schwacher Mutationstest (Weak Mutation Test): Ein Testfall sorgt im Innern des Mutanten für ein anderes Verhalten als beim Original. Dieses andere Verhalten wird jedoch nicht nach außen sichtbar. ➔ Adäquater Testfall/adäquate Testfallmenge: Ein Testfall heißt adäquat, wenn er einen Mutanten tötet oder wenn die Mutation äquivalent war. Eine Testfallmenge heißt adäquat, wenn sie alle nicht-äquivalenten Mutanten tötet. ➔ Mutation Score: Das Verhältnis der getöteten Mutanten zur Zahl aller Mutanten, üblicherweise in Prozent angegeben. ➔ Fehlerinjektion (Fault Injection): In nicht mutiertem Testobjekt werden Fehler von außen injiziert, um die Robustheit zu prüfen. |
Literatur
[1] A. Jefferson Offut, Clemson University: Investigations of the software testing coupling effect, in ACM Transactions on Software Engineering and Methodology, New York, Volume 1 Issue 1, Jan. 1992.
[2] DIN EN 61508 (VDE 0803): 2011-02, DIN Deutsches Institut für Normung e.V. und VDE Verband der Elektrotechnik, Elektronik, Informationstechnik e.V. (IEC 61508:2010).
[3] ISO 26262, International Standard, Road vehicles – Functional Safety,
Second edition, 2018
[4] Liggesmeyer, Peter: Software-Qualität: Testen, Analysieren und Verifizieren von Software. 2. Auflage, Heidelberg, Berlin, 2009. Spektrum Akademischer Verlag, ISBN 978-3-8274-2203-3.
[5] Dirk W. Hoffmann, Software-Qualität. Springer-Verlag Berlin Heidelberg, 2008, ISBN 978-3-642-35700-8.
Der Autor
Frank Büchner
hat ein Diplom in Informatik und widmet sich seit vielen Jahren dem Thema Testen und Softwarequalität. Momentan arbeitet er als »Principal Engineer Software Quality« bei der Firma Hitex in Karlsruhe.
frank.buechner@hitex.de
- Testfallgüte problemlos prüfen
- Endlosschleifen und Abstürze bei Mutationen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Interview mit Reinhard Keil, Arm Germany
»Cloud und Edge ergänzen sich«
Wibu-Systems erweitert Portfolio
Schutz für Python-Code
Konforme Software erstellen
Mit Tool Suite zu besserem Code
Software-Entwicklung
Einfach Programmieren mit »semf«
Softwarefehler visualisieren
Tracealyzer für Multicore-Systeme mit Azure RTOS ThreadX SMP
