Methoden zur Ableitung von Testfällen

Empfehlungen aus ISO 26262

In Teil 6, Abschnitt 9, listet die ISO 26262:2011 in Tabelle 11 die Methoden zur Ableitung von Testfällen für den Software-Unit-Test auf [7; vgl auch Bild 8]. Der Grad der Empfehlung einer Methode hängt vom Automotive Safety Integrity Level (ASIL) ab. Der ASIL geht von A bis D, wobei D die höchsten Ansprüche bzgl. der Risikoreduktion stellt. Methoden, die besonders empfohlen sind, sind mit einem doppelten Pluszeichen („++”) versehen; Methoden, die empfohlen sind, haben ein einfaches Pluszeichen („+”).

Bildergalerie

Bildergalerie mit 8 Bildern

Methode 1a aus Tabelle 11 erfordert, dass die Testfälle aus den Anforderungen abgeleitet werden. Dies ist besonders empfohlen für alle ASIL. Zunächst die Anforderungen zu betrachten, um die Testfälle abzuleiten, ist der naive Ansatz.

Methode 1b aus Tabelle 11 erfordert, dass Äquivalenzklassen verwendet werden, um Testfälle abzuleiten. Das ist empfohlen für ASIL A und besonders empfohlen für ASIL B bis D.

Methode 1c aus Tabelle 11 erfordert, dass Grenzwerte betrachtet werden, um Testfälle abzuleiten. Das ist empfohlen für ASIL A und besonders empfohlen für ASIL B bis D.

Methode 1d aus Tabelle 11 erfordert, dass „Fehler raten“ eingesetzt wird, um Testfälle abzuleiten. Das ist empfohlen für ASIL A bis D.

Die Methoden 1a, 1b und 1c wurden bereits in den vorhergehenden Abschnitten diskutiert. Die Methode 1d wird im Folgenden erläutert.

Fehler raten (error guessing)

Fehler raten (error guessing) erfordert üblicherweise einen erfahrenen Tester, der aufgrund seiner Erfahrung in der Lage ist, fehler-sensitive („spannende”) Testfälle zu finden. Fehler raten wird deshalb auch als erfahrungsbasiertes Testen bezeichnet. Fehler raten ist eine unsystematische Methode, um Testfälle zu spezifizieren (was die ersten drei Methoden nicht sind). Zugegeben, wenn man Checklisten oder Fehlerreports verwendet, kann auch Fehler raten eine gewisse Systematik erhalten. Fehler raten hat einen Bezug zu Grenz-, Extrem- und illegalen Werten, denn Testfälle, die durch Fehler raten entstanden sind, enthalten oftmals solche Werte.

Alternativen

Dieser Abschnitt diskutiert weitere Methoden um an Testfälle zu kommen, die bisher nicht betrachtet wurden.

Testfälle aus dem Quell-Code ableiten

Es ist verlockend, ein Werkzeug zu benutzen, um aus dem Quell-Code automatisiert Testfälle zu erzeugen, beispielsweise mit dem Ziel, 100% Codeüberdeckung zu erreichen. Es gibt hierzu unterschiedliche technische Ansätze, beispielsweise Backtracking oder genetische Algorithmen. Sowohl frei verfügbare Werkzeuge als auch kommerzielle Werkzeuge bieten diese Möglichkeit zur Testfallerzeugung. Wieso sollte man dies nicht im großen Stil verwenden? Nun, es gibt mindestens zwei Aspekte, derer man sich bewusste sein sollte:

• 1. Auslassungen: Es werden keine Auslassungen im Code gefunden. Lautet eine Anforderung beispielsweise „wenn der erste Parameter gleich dem zweiten Parameter ist, soll eine bestimmte Fehlernummer zurückgegeben werden“ und die Implementierung dieser Anforderung fehlt, dann wird dieser fehlende Code niemals durch Testfälle erkannt werden, die aus dem Code abgeleitet sind. Man benötigt Testfälle, die aus den Anforderungen abgeleitet sind, um nicht-implementierte Funktionalität zu finden.

• 2. Korrektheit: Man kann nicht aufgrund des Codes entscheiden, ob er korrekt ist oder nicht. Beispielsweise weiß man nicht, ob die Entscheidung (i<5) oder (i<=5) die beabsichtigte Funktionalität implementiert. Dazu benötigt man wiederum Testfälle, die aus den Anforderungen abgeleitet wurden oder ein Testorakel. Ein Testorakel ist eine Instanz, die zu einem Satz von Eingangswerten entscheiden kann, ob das Ergebnis korrekt ist oder nicht.

Deshalb ist es nicht ausreichend, nur Testfälle zu verwenden, die aus dem Quell-Code abgeleitet wurden. Man benötigt auch auf jeden Fall Testfälle, die aus den Anforderungen abgeleitet werden. Aber wäre es nicht eine gute Idee, die Hauptarbeit der Testfallerstellung durch ein Werkzeug erledigen zu lassen? Anschließend kann man ja manuell prüfen, ob auch die Anforderungen getestet wurden und wenn nicht, entsprechend nachbessern.

In einer Studie [5] wurde versucht, genau diese Frage zu beantworten. Die Studie kam zu den folgenden vier Hauptaussagen:

• 1. Automatisch generierte Testfälle erzeugen eine höhere Codeüberdeckung als manuell erzeugte Testfälle.

• 2. Automatisch generierte Testfälle führen nicht zu einer Entdeckung von mehr Fehlern.

• 3. Automatisch generierte Testfälle haben einen negativen Effekt auf die Fähigkeit, das beabsichtigte Verhalten des Codes (von Klassen) zu verstehen.

• 4. Automatisch generierte Testfälle führen nicht unbedingt zu besseren Werten beim Mutationstest.

Die Studie verwendete das Werkzeug EvoSuite, das automatisch Tests für Java-Klassen erzeugt. Es war eine empirische Studie, in der einhundert Studenten Fehler in Java-Code finden sollten. Die Hälfte der Studenten begann die Suche mit Testfällen, die von EvoSuite generiert waren; die andere Hälfte startete mit eigenen, selbst aus den Anforderungen abgeleiteten Testfällen.

Die Schlussfolgerung aus der Studie ist für mich, dass automatisierte Testfallerstellung keinen Vorteil bringt (beispielsweise weniger Aufwand oder mehr gefundene Fehler); andererseits ist die automatisierte Testfallerstellung auch kein Nachteil. Diese Grundaussage „kein Vorteil / kein Nachteil“ ist in meinen Augen überraschend.

Natürlich kann man die Randbedingungen der Studie diskutieren (z.B. die verwendete Programmiersprache, die Kenntnisse der Studenten, etc.) und überlegen, ob sie auch auf die eingebettete Software-Entwicklung zutreffen.

Zufällige Testdaten / Fuzzing

Wie die Ableitung von Testfällen aus dem Quellcode ist es ebenfalls verlockend, zufällige erzeugte Testeingangsdaten zu verwenden. Mit automatisierter Testausführung kann man in kurzer Zeit viele Testfälle durchführen. Aber: Ein (funktionaler) Testfall benötigt ein erwartetes Ergebnis! Und ohne Testorakel (siehe oben) kann es sehr aufwendig werden, für jeden Testfall zu prüfen, ob das erhaltene Ergebnis korrekt ist oder nicht.

Eine sinnvolle Anwendung von zufällig erzeugten Testdaten gibt es allerdings: Wenn man „alten“, betriebsbewährten Code (sog. „legacy code“), zu dem es vielleicht nie eine Spezifikation gab, portieren oder optimieren muss, dann ist es nützlich, zuvor Tests mit zufällig erzeugten Testdaten auszuführen, die Ergebnisse aufzuzeichnen, und dieselben Test danach zu wiederholen. Erhält man identische Ergebnisse, kann man mit einer gewissen Sicherheit annehmen, dass die Arbeit am alten Code erfolgreich war. Ansonsten betrachte ich Test mit zufälligen Eingangsdaten ohne Ergebnisprüfung als eine Art von Robustheitstest. Durch Robustheitstests wird lediglich grobes Fehlverhalten (z.B. Absturz) festgestellt.

Allerdings kann diese Art von Tests zur Aufdeckung von Safety- und Security-Schwachstellen führen. Die Methode, ein Testobjekt mit syntaktisch richtigen, aber inhaltlich zufälligen Testdaten zu testen, wird auch „Fuzzing“ genannt.

Mutationstest

Wie wir in den vorhergehenden Abschnitten gesehen haben, garantiert 100% Codeüberdeckung nicht die Qualität der Testfälle.

Aber wie kann man die Qualität der Testfälle bewerten? Eine Möglichkeit sind Mutationstests (in IEC 61508 [8] werden diese Tests „error seeding“ oder „Fehlereinpflanzung“ genannt). Wenn man einen Satz von bestandenen Testfällen hat, mutiert man den Code und führt die Testfälle erneut aus. Mutieren bedeutet, den Code semantisch zu verändern, aber so, dass er syntaktisch korrekt bleibt. Beispielsweise kann man eine Entscheidung von (i<5) zu (i<=5) ändern oder man könnte in einer Entscheidung ein logisches ODER durch ein logisches UND ersetzen. Die Frage ist nun, ob der Satz der vorhandenen Testfälle diese Veränderung im Code aufdeckt, d.h. ob mindestens einer dieser Testfälle fehlschlägt. Aus der Zahl der entdeckten bzw. übersehenen Mutationen kann man auf die Qualität der Testfälle schließen.

Fazit

Wie wir gesehen haben, bedeuten 100% Codeüberdeckung nicht automatisch gute Testfälle. Man braucht aber gute Testfälle, um Fehler im Code zu finden. Die Aufgabe, gute Testfälle zu erstellen, ist eine schwierige (hauptsächlich menschliche) Aufgabe; der Einsatz von Werkzeugen ist mit Vorsicht zu genießen.

Absicherung von Testsystemen nach ISO 26262

Fuzzing von Embedded Software – Grundlagen und Erfahrungen

Der Autor

* Frank Büchner hat ein Diplom in Informatik von der Technischen Hochschule Karlsruhe, heute KIT. Seit mehreren Jahren widmet er sich dem Thema Testen und Software-Qualität. Seine Kenntnisse vermittelt er regelmäßig durch Vorträge und Fachartikel. Momentan arbeitet er als „Principal Engineer Software Quality“ bei der Fa. Hitex GmbH in Karlsruhe.

Literaturverzeichnis

[1] Grünfelder, Stephan: Software-Test für Embedded Systems, 2. Auflage, dpunkt.verlag GmbH, Heidelberg, 2017.

{2] Spillner, Andreas, et al: Basiswissten Softwaretest, 5. Auflage, dpunkt.verlag GmbH, Heidelberg, 2012.

[3] Liggesmeyer, Peter: Software-Qualität, 2. Auflage, Spectrum Akademischer Verlag, Heidelberg, 2009.

[4] Tuinhout, René: The Software Testing Fallacy, Testing Experience 02/2008.

[5] Fraser, Gordon, et al: Dos automated Unit Test Generation Really Help Software Testers? A controlled Empirical Study, ACM Transactions on Software Engineering and Methodology, Vol. 24, No. 4, Article 23, published August 2015.

[6] http://www.hitex.de/tessy: Mehr über das Unit-Test-Werkzeug TESSY

[7] ISO 26262, International Standard, Road vehicles – Functional Safety, First edition, 2011

[8] IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems, part 7, IEC, 2000

(ID:45686267)