Das Wort Orakel stammt vom lateinischen „oraculum“ und bedeutet die Beantwortung von Entscheidungs- und Zukunftsfragen. Wenn wir also wie in diesem Heft von der Zukunft des Testens reden, dann hat das etwas mit einem Orakel zu tun. Andererseits braucht das Testen selbst sein Orakel, das voraussagt, was man vom Verhalten eines Testobjekts erwarten kann. Wenn wir schon bei der Zukunftsfrage sind, erlauben wir uns in dieser Kolumne, nach der Zukunft des Testorakels selbst zu fragen.
Das Testorakel und das Orakelproblem
Beim dynamischen Testen führen wir unserem Testobjekt in einem gewissen Anfangszustand bestimmte Eingaben zu, und beobachten das Ergebnis aus Folgezustand und Ausgaben. Um zu prüfen, ob das tatsächliche Ergebnis korrekt ist, brauchen wir ein erwartetes Ergebnis, mit dem wir dieses vergleichen. Stimmen beide überein, so ist der Test bestanden, ansonsten ist er fehlgeschlagen. Die Informationsquelle zur Ermittlung des erwarteten Ergebnisses, um es mit dem tatsächlichen Ergebnis eines Systems unter Test zu vergleichen, nennen wir Testorakel [ISTQBGlossar]. Abbildung 1 veranschaulicht die Rolle des Testorakels.
Abb. 1: Das Testorakel
Manchmal ist das Testorakel eine Spezifikation, und wir Tester können das erwartete Ergebnis mit mehr oder weniger Aufwand und mehr oder weniger genau ermitteln. Einige Testverfahren, wie zum Beispiel das zustandsbasierte Testen oder der Entscheidungstabellentest, nutzen direkt das spezifizierte erwartete Ergebnis. Noch glücklicher können wir uns in den selteneren Fällen schätzen, wenn das Testorakel das erwartete Ergebnis für jede Eingabe automatisch liefert. Zum Beispiel ist die Altanwendung bei einem Softwaremigrationsprojekt ein solches Testorakel.
Aber sehr oft haben wir zumindest teilweise ein Problem mit dem Testorakel, zum Beispiel wenn das erwartete Ergebnis einer komplexen Suche in einem umfangreichen Datenbestand mit vertretbarem Aufwand nicht genau ermittelbar ist. Einige verbreitete Testverfahren wie die Äquivalenzklassenbildung der Eingaben umschiffen das Problem, indem sie gar kein Testorakel enthalten. Damit ist das Problem aber nicht gelöst, sondern uns, den Testern, überlassen. Ein solches Orakelproblem ist ein Testbarkeitsproblem: Wir können nicht entscheiden, ob ein Test bestanden oder fehlgeschlagen ist. Deshalb ist es für den Testerfolg entscheidend, ein effektives und effizientes Testorakel zu haben.
Traditioneller Umgang mit dem Orakelproblem
In einem klassischen Artikel [We82] hat Elaine Weyuker die drei damals bekannten Lösungsansätze des Orakelproblems beschrieben, also den Umgang mit der Situation, dass kein Testorakel verfügbar ist.
Ein erster Lösungsansatz ist, eine vom Testobjekt unabhängige Implementierung der gleichen Spezifikation zu entwickeln. Das Verfahren wird auch duale Entwicklung oder Pseudo-Orakel genannt. Dieser Ansatz wird wegen des hohen Aufwands eher bei Systemen mit hoher Kritikalität angewendet.
Ein zweiter Lösungsansatz ist, nur einfache Eingaben zu testen, für die das Orakel mit vertretbarem Aufwand ein erwartetes Ergebnis liefert. Dieser Lösungsansatz ist bis heute populär. Er hat aber einen erheblichen Nachteil: Er schränkt die verwendbaren Eingaben ein. Und oft steckt gerade bei den komplexen Eingaben ein hohes Fehlerrisiko.
Ein dritter Lösungsansatz ist, das Ergebnis auf Plausibilität zu prüfen, ohne die vollständige Korrektheit zu beweisen. Testen wir zum Beispiel eine numerische Implementierung der Winkelfunktionen, so können wir für die Eingabe α prüfen, ob sin2α + cos2α = 1, ob -1 ≤ sinα ≤ +1, oder ob für α in der Nähe von 0 sinα nahe bei 0 und cosα nahe bei 1 ist. Je mehr solche Eigenschaften wir finden, desto weniger Fehler entgehen uns. Weyuker nannte diesen Ansatz ein partielles Orakel. Heute wird dieser Ansatz eher eigenschaftsbasiertes Testen (engl. property-based testing) genannt. Er hat sich in den letzten Jahren besonders bei Entwicklern verbreitet [Hu17].
Weyuker folgerte in ihrem Artikel, dass das Orakelproblem ein fundamentales Hindernis bei der Praxis des Testens ist, das die Tester-Community angehen muss.
Neuere Testverfahren bei Orakelproblemen
Ein neuerer Ansatz ist das metamorphe Testen, das in 1998 von Chen, Cheung und Yiu veröffentlicht wurde [Ch98]. Die Testbedingungen dieses Verfahrens sind metamorphe Relationen, die beschreiben, wie eine Änderung der Eingaben vom Ausgangstestfall zum Folgetestfall eine Änderung der erwarteten Ergebnisse vom Ausgangstestfall zum Folgetestfall beeinflusst.
Bei einem Steuerungssystem des autonomen Fahrens könnte zum Beispiel der Ausgangstestfall die Fahrzeugsteuerung in einer gewissen Verkehrssituation bei guten Sichtverhältnissen und trockener Fahrbahn sein, die das System bereits erlernt hat. Wir nehmen an, dass das Ergebnis dieses Ausgangstestfalls richtig ist. Die metamorphen Relationen sind, dass die Steuerung bei schlechteren Sicht- und Fahrbahnverhältnissen (z. B. bei Regen, Nebel, Gegenlicht) oder dichterem Verkehr gleich oder ähnlich (z. B. langsamer) sein muss und keinen Unfall verursacht. Die metamorphen Relationen haben fehlgeschlagen, wenn die Folgetestfälle andere Ergebnisse haben als aufgrund der Relation erwartet, zum Beispiel dass das Fahrzeug in den Gegenverkehr gelenkt wird oder in der Kurve ausrutscht. Metamorphes Testen hat sich allmählich in der Praxis bewährt [Se20] und wird allmählich zu einem anerkannten Testverfahren [ISO29119-4].
Einige Tester nutzen beim Fehlen des Testorakels auch Fuzz-Testen zum funktionalen Testen, nämlich zur Entdeckung von Abbrüchen [Bö21]. Fuzz-Testen (engl. „fuzzing“) ist ursprünglich ein Testverfahren zur Entdeckung von Sicherheitsschwachstellen durch die massenhafte Eingabe von zufälligen Daten (Fuzz genannt) in die Komponente oder das System [ISTQBGlossar]. Aus Sicht der IT-Sicherheit ist ein Abbruch ohne Zweifel eine schwerwiegende Sicherheitsschwachstelle. Aber auch aus Sicht der Funktionalität kann ein Abbruch durchaus als schwerwiegende Fehlerwirkung klassifiziert werden.
Der Nachteil dieses Verfahrens beim funktionalen Testen ist, dass das Suchen nach Abbrüchen als einzige Fehlerart kaum ausreicht. Man spricht auch von der „Nullhypothese“: Jeder Testfall ist bestanden, wenn das Testobjekt nicht abbricht. So gesehen kann Fuzz-Testen der Funktionalität nur als Ergänzung anderer Testverfahren sinnvoll sein.
Eigenschaften der neueren Testverfahren
Dem metamorphen, eigenschaftsbasierten und Fuzz-Testen gemeinsam ist, dass sie auf das Finden von Fehlern ausgerichtet sind. Ein Fehlschlag belegt das Vorhandensein eines Fehlerzustands im Testobjekt. Ein bestandener Test liefert hingegen keine Sicherheit über das korrekte Ergebnis. Bei deterministischen Systemen mit festen Geschäftsregeln als Testorakel mag das ein Nachteil sein. Jedoch liegt die Unsicherheit zu bestimmen, ob ein Ergebnis vollständig korrekt ist, bei einem Orakelproblem in der Natur der Sache.
Diese Verfahren liefern auch kein überdeckungsbasiertes Endekriterium: Es reicht nicht aus, eine Testbedingung wie zum Beispiel eine metamorphe Relation oder eine Eigenschaft mit einer Stichprobe zu testen, um bestimmte Fehlerarten zu finden. Dies wird teilweise dadurch kompensiert, dass zu einer Testbedingung viele konkrete Testfälle durchgeführt werden. Wir können zum Beispiel Zufallsgeneratoren nutzen, um Pakete von je hundert Eingabedaten zu generieren und so lange zu testen, bis die neuen Pakete keine neuen Fehlerzustände mehr aufdecken. Zusätzlich zu einem (mehr oder weniger intelligenten) Eingabedatengenerator brauchen wir bei einem solchen stochastischen Vorgehen auch einen Automatismus beim Vergleich der tatsächlichen und erwarteten Ergebnisse.
Diese technischen Eigenschaften machen die erwähnten Verfahren mit dem modellbasierten Testen (MBT) sehr gut kompatibel. Nachdem in der Testanalyse metamorphe Relationen zwischen Testfällen, Eigenschaften der Testfälle oder Strukturen der möglichen Eingabedaten für Fuzz-Testen ermittelt und formal spezifiziert wurden, können alle weiteren Testaktivitäten automatisiert sein: Eingaben und erwartete Ergebnisse werden aus Modellen generiert, die Tests automatisch ausgeführt und die Ergebnisse bewertet. Durch die Automatisierung sind diese Verfahren für agile Entwicklungslebenszyklen und DevOps besonders gut geeignet.
Typische Orakelprobleme
Eine Klasse von Anwendungen, die typischerweise Orakelprobleme aufweist, sind Softwaresysteme mit sehr großen Datenmengen (Big Data), wie Internet-Suchmaschinen und Auskunftssysteme über große Bestände [Se20]. Bei Systemen mit künstlicher Intelligenz (KI) liegt das Orakelproblem ebenfalls auf der Hand, weil das erwartete Verhalten nicht exakt vorhersagbar ist und über die Zeit nicht konstant bleibt.
Aber auch bei klassisch-deterministischen IT-Systemen müssen wir uns darüber bewusst sein, dass ein im Testfall spezifiziertes erwartetes Ergebnis meist unvollständig ist. Das Modell der Aktivierung, Infektion und Übertragung von Fehlerzuständen nach Li und Offutt [Li17] in Abbildung 2 verdeutlicht, warum das so ist.
Abb. 2: Aktivierung, Infektion und Übertragung von Fehlerzuständen
Da beim Testen in der Regel nicht alle Ergebnisse, bestehend aus Ausgaben und Endzuständen des Testobjekts, beobachtet werden können, müssen wir mit einer Testorakelstrategie darauf achten, dass das beobachtete Ergebnis den fehlerhaften Anteil des tatsächlichen Ergebnisses nicht verfehlt.
Deswegen erwartet man vom manuellen Tester „Aufmerksamkeit fürs Detail“ [CTFL] – damit soll er das beobachtete Ergebnis zumindest auf alle Ausgaben ausweiten. Schwierig wird es, wenn das fehlerhafte Ergebnis in einem nicht explizit sichtbaren Programmzustand steckt und erst später eine in den Ausgaben sichtbare Fehlerwirkung verursacht, wie zum Beispiel bei einem Speicherleck. Spezielle Testorakelstrategien zielen darauf ab, solche Fehlerarten aufzudecken.
Wollen wir die Tests automatisiert durchführen, so können wir uns nicht auf die „Aufmerksamkeit des Testers fürs Detail“ verlassen. Wir brauchen eine geeignet gewählte Testorakelstrategie, um falsch-positive Testergebnisse zu vermeiden.
Bedeutung des Testorakels in der Zukunft
Betrachten wir all diese Aspekte, dann können wir dem Testorakel für die Zukunft eine wachsende Bedeutung voraussagen. Da wir immer mehr Tests automatisieren, die Testdatenmengen immer größer und unüberschaubarer werden, und da die Systeme immer intelligenter und immer weniger deterministisch werden, werden wir uns zukünftig um die Testorakel viel mehr kümmern müssen als heute. Die von Elaine Weyuker vor vierzig Jahren vorausgesagte Herausforderung des Orakelproblems wird relevanter denn je. Die traditionellen Lösungsansätze der dualen Entwicklung und des Testens mit einfachen Eingaben werden immer weniger ausreichen, um damit umzugehen.
Die Lösung des Orakelproblems wird deshalb zum kritischen Erfolgsfaktor des Softwaretestens. Tester sollten sich in der Praxis mehr als bisher mit dem Testorakel auseinandersetzen und die neuen Lösungsansätze eines Orakelproblems situationsbedingt anwenden können. Ich hoffe, dass die Forschung noch weitere Lösungsansätze entwickelt und in der Praxis validiert. Auf jeden Fall wird bei allen bekannten und künftigen Lösungsansätzen eine Vielzahl von konkreten Testdaten stochastisch generiert werden, um Fehlerzustände effektiv zu finden. Entscheidende Erfolgsfaktoren werden deshalb die Automatisierung und das modellbasierte Testen sein.
Referenzen
[Bö21]
M. Böhme, C. Cadar, A. Roychoudhury, Fuzzing, Challenges and Reflections, in: IEEE Software Magazine, 2021/3
[Ch98]
T. Y. Chen, S. C. Cheung, S. M. Yiu, Metamorphic testing: A new approach for generating next test cases, Hong Kong Univ. Technical Report, 1998
[CTFL]
ISTQB® Certified Tester Foundation Level Lehrplan v3.1, 2019
[Li17]
N. Li, J. Offutt, Test Oracle Strategies for Model-based Testing, in: IEEE Transactions on Software Engineering, 2017
[Hu17]
J. Hughes, Don’t Write Tests!, Konferenzvortrag auf Curry On Barcelona! 2017, siehe:
https://www.youtube.com/watch?v=hXnS_Xjwk2Y
[ISO29119-4]
ISO/IEC/IEEE Standard 29119-4: Software and systems engineering – Software testing – Part 4: Test techniques, 2021
[ISTQBGlossar]
ISTQB®/GTB Standardglossar der Testbegriffe, siehe:
https://glossary.istqb.org/de/
[Se20]
S. Segura, D. Towey, Z. Q. Zhou, T. Y. Chen, Metamorphic Testing: Testing the Untestable, in: IEEE Software Magazine, 2020/3
[We82]
E. Weyuker, On Testing Non-testable Programs, in: The Computer Journal, 1982
