Methoden und Werkzeuge zur Softwareproduktion Qualitätssicherung. Testorakel. Stefan Lehmann, Benjamin Chapus

Transkript

1 Testorakel Stefan Lehmann, Benjamin Chapus Einleitung Ein entscheidendes Problem beim Testen von Software ist das Orakelproblem. Wie beurteilt man anhand der aus den Testdaten resultierenden Ergebnisse, ob die zu testende Implementierung korrekt arbeitet oder ob sie ein Fehlverhalten aufweist? Um diese für das Testen essentielle Entscheidung treffen zu können, benötigt man die Fähigkeit, das erwartete Ergebnis voraussagen zu können und mit dem tatsächlichen Ergebnis der zu testenden Implementierung zu vergleichen. Diese Fähigkeit erhält man durch ein Testorakel, das seinen Namen in Anlehnung an das Orakel von Delphi erhalten hat. Menschliche Orakel waren feste Bestandteile der antiken Welt und wurden wegen der unterschiedlichsten Dinge konsultiert, um eine zumeist in Rätseln gesprochene Prophezeiung zu erhalten. Die rätselhaften Antworten machten die antiken Orakel aber zugleich irreführend. So erhielt Krösus auf die Frage, ob er gegen die Perser in den Krieg ziehen solle, die Antwort, dass er damit ein großes Imperium zerstören würde. Dass das Orakel damit sein eigenes Imperium meinen könnte, bedachte Krösus nicht und rüstete zu einem Krieg, den er verlieren sollte. Der Begriff des Testorakels ist also passend gewählt. Zum Einen, weil bei der Evaluation von Testdaten Erwartungswerte vorausgesagt werden müssen, zum Anderen aber auch, weil ein Testorakel teilweise korrekt sein kann, gleichzeitig aber irreführend über die allgemeine Zuverlässigkeit eines Systems sein kann. Besonders in der Testautomatisierung spielen Orakel eine gewichtige Rolle. Es gibt eine Vielzahl verschiedener Modelle von Orakeln, die unterschiedliche Ansprüchen genügen und von verschiedenen Bedingungen abhänigig sind. In der Praxis wird man je nach den gegebenen Möglichkeiten und Voraussetzungen verschiedene Modelle von Orakeln kombinieren und einsetzen. In der Objektorientierung spielen die comparators eine entscheidende Rolle beim schwierigen Vergleich von Objekten. Testautomatisierung Definition Testautomatisierung ist Software, die jeden Aspekt des Testens von Software einer Anwendung automatisiert. Dazu gehören die Generierung von Testfällen und der erwarteten Ergebnisse (expected results), die automatische Ausführung von test suites und die Beurteilung des Ergebnisses. Testautomatisierung ist notwendig, um den Aufwand des Testens größerer und komplexer Systeme zu bewältigen. Die manuelle Erzeugung und Auswertung von Testdaten erreicht schnell ihre praktikablen Grenzen und wird mit steigendem Umfang immer ermüdender und damit fehleranfälliger. Die Durchführung langer, komplexer Tests wird durch Automatisierung überhaupt erst durchführbar. Testautomatisierung erlaubt darüber hinaus die schnelle und effiziente Verifikation von bugfixes und erhöht die Produktivität, da mehr Zeit in das Design von Testfällen, statt deren Ausführung, investiert werden kann. 1

2 Während die automatische Generierung von Testfällen und deren Ausführung relativ leicht zu implementieren ist, stellen die automatische Generierung der erwarteten Ergebnisse und der automatische Vergleich von Objekten ein großes Problem dar. Daher sind Testorakel in der Testautomatisierung unabdinglich. Testorakel Definition Als Testorakel bezeichnet man einen Mechanismus, der die Ergebnisse eines Testfalls als pass oder no pass (fail) einstuft. Dazu sind ein Ergebnisgenerator, der die erwarteten Ergebnisse erzeugt, und ein comparator zum Vergleich der erwarteten und der tatsächlichen Ergebnisse nötig. Es gibt drei grundlegende Arten von Orakeln: pretest oracle erwartete Ergebnisse werden vorher berechnet und gespeichert Anwendung vor allem, wenn das Orakel langsamer als die zu testende Implementierung ist on-demand oracle tatsächliche Ergebnisse (actual results) und erwartete Ergebnisse werden parallel berechnet oder die erwarteten Ergebnisse werden berechnet, sobald die tatsächlichen Ergebnisse verfügbar sind post-test oracle tatsächliche Ergebnisse (actual results) werden gespeichert und später evaluiert ermöglicht größte Flexibilität, erschwert allerdings das Verschachteln von Testen und Debuggen Ein perfektes Orakel wäre vom Verhalten her eine fehlerfreie Version der zu testenden Implementierung. Die Entwicklung eines perfekten Orakels wäre demnach mindestens genauso aufwändig und schwierig, wie die ursprüngliche Entwicklung der zu testenden Implementierung. Dazu müsste die Korrektheit zu einhundert Prozent sichergestellt sein. Ein perfektes Orakel würde zudem die zu testende Implementierung überflüssig machen. Daraus sollte klar werden, das keine wirkliche Garantie gegeben werden kann, dass ein Orakel die Gültigkeit eines Testergebnisses in jedem Fall richtig einstuft. Die Gültigkeit eines Tests kann folgendermaßen unterschieden werden: valid pass zu testende Implementierung und Orakel sind korrekt; benötigtes, tatsächliches und erwartetes Ergebnis sind gleich valid no pass Orakel ist korrekt; benötigtes, tatsächliches und erwartetes Ergebnis sind ungleich spurious pass (false positive) zu testende Implementierung und Orakel sind fehlerhaft; tatsächliches und erwartetes Ergebnis sind gleich spurious no pass (false negative) zu testende Implementierung ist korrekt, Orakel ist fehlerhaft; tatsächliches und erwartetes Ergebnis sind ungleich 2

3 coincidental pass zu testende Software ist zufällig korrekt coincidental no pass zu testende Software und Orakel sind fehlerhaft; tatsächliches und erwartetes Ergebnis sind ungleich Um das Risiko von zufälligen (coincidental) und verfälschten (spurious) Ergebnissen zu minimieren, sollte das Orakel so gut es geht verifiziert werden. Zusätzlich sollte man folgende Strategien verfolgen: immer die einfachste Lösung anstreben die Spezifikation verifizieren Orakel mit trivialen Testfällen testen nach Möglichkeit auf existierende Ressourcen zurückgreifen auf Testfälle konzentrieren, die manuell schwer überprüfbar wären verschiedene Orakel einsetzen Testorakelmodelle Es gibt vier grundlegende Arten von Testorakelmodellen, die im folgenden vertieft werden. Judging Eine Person entscheidet manuell über pass oder no pass eines Testdatums. Die Entscheidung beruht dabei auf analytischer oder subjektiver Evaluation. Judging wird vor allem bei Alpha-, Beta- und improvisierten Testen verwendet. Prespecification Oracels Bei Prespecification Oracles werden die erwarteten Ergebnisse vor dem eigentlichen Test bestimmt und dem comparator zur Verfügung gestellt. Solved Example Oracle Für jeden Testfall wird das erwartete Ergebnis manuell vorberechnet und bereitgestellt. Anwendung erfolgt vor allem, wenn die erwarteten Ergebnisse nicht automatisch erzeugt werden können. Besonders als Erweiterung für durch andere Orakel nicht abgedeckte Spezialfälle sinnvoll. Simulation Oracle Die erwarteten Ergebnisse werden anhand einer vereinfachten oder reduzierten Implementierung oder eines Prototyps ermittelt. Das Verifizieren des Orakels ist dann einfacher, als die Verifikation der zu testenden Software. Das Orakel sollte die grundlegenden Kernfunktionen der zu testenden Software simulieren. Approximation Oracle Die erwarteten Ergebnisse werden nur näherungsweise bestimmt. Anwendung erfolgt vor allem, wenn die zu testende Implementierung ein bisher ungelöstes Problem implementiert oder es keine analytische Lösung zur Erzeugung von Testfällen gibt. 3

4 Strategien sind das Bestimmen einer akzeptablen Genauigkeit, die Verkleinerung des Eingabe/Zustandsraum oder das Durchführen einfacher Tests, die leicht manuell zu evaluieren sind. Parametric Oracle Mit einem gesicherten Algorithmus werden ausgehend von den tatsächlichen Ergebnissen die Eingabeparameter berechnet und mit den tatsächlichen Eingaben verglichen. Gold Standard Oracles Bei Gold Standard Oracles werden die erwarteten Ergebnisse von einer oder mehrerer Versionen einer bereits existierenden Implementierung erzeugt. Dies können Konkurrenzprodukte, ältere Versionen der Implementierung oder die gleiche Implementierung auf einer anderen Plattform sein. Die folgenden Modelle unterscheiden sich vor allem in ihrer Nutzung und Konfiguration der existierenden Implementierung. Trusted System Oracle Ein gesichertes System, das sich in der Praxis bewährt und als zuverlässig herausgestellt hat, wird für die Erzeugung der erwarteten Ergebnisse genutzt, indem es die Testdaten für die zu testende Implementierung als Eingabe erhält. Die Ausgaben sind dann die Erwartungswerte für die zu testende Implementierung. Parallel Test Oracle Ist die zu testende Implementierung ein Nachfolger des gesicherten Systems oder weist zumindest erhebliche Ähnlichkeiten auf, so kann es den gleichen Eingabedatenstrom, wie das gesicherte System, erhalten. Bei korrekter Funktionsfähigkeit sollten beide Systeme die gleichen Ergebnisse generieren. Da sich das gesicherte System im normalen Betrieb befindet, sind die Eingaben keine Testdaten, sondern reale Daten, die sich aus dem praktischen Betrieb ergeben. Regression Test Oracle Man benutzt zusätzlich zu den von einem Orakel generierten Erwartungswerten existierende Ergebnisse von einer älteren Version, um sicher zu sein, dass die Funktionalitäten der neuen und der alten Version gleich sind bzw. keine neuen Fehler produziert werden. Voting Oracle Es werden zwei oder mehr gesicherte Systeme genutzt. Sind alle Ergebnisse gleich, so erhält man einen pass. Sind nicht alle gleich, müssen alle Ergebnisse verglichen werden und entschieden werden, welches korrekt ist. Organic Oracles Organic oracles nutzen redundante Informationen in Systemen aus. Das Erzeugen von erwarteten Ergebnissen ist dann nicht mehr notwendig. Smoke Test Ein no pass tritt nur dann auf, wenn das Programm mit einer abnormalen Termination beendet wird. Da nur offensichtliche Fehler wie Speicherüberläufe, Speicherallozierungsfehler oder deadlocks entdeckt werden, ist der Wert von smoke tests eher gering. 4

5 Reversing Bei umkehrbaren Berechnungen kann man eine Gegenprobe machen, indem man auf die Ergebnisse eines Testdatums die umgekehrte Berechnung anwendet. Das Ergebnis sollte dann wieder das Testdatum selbst sein. Executable Specification Oracle Eingabe und Ausgabe werden durch korrespondierende Parameter einer ausführbaren Spezifikation ersetzt. Es ist besonders geeignet für das Testen von Methoden. Der Test ist gültig, wenn das actual results innerhalb spezifizierter Schranken liegt. Das Orakel kann aber nur deterministische, funktionale Eigenschaften modellieren. Different But Equivalent Oracle Hier werden unterschiedliche Sequenzen von Eingaben erzeugt, die allerdings das gleiche Ergebnis haben sollten. Der Aufwand, erwartete Ergebnisse zu erzeugen, entfällt, allerdings müssen stattdessen äquivalente Sequenzen von Eingaben gefunden werden. Comparators Sind die erwarteten Ergebnisse durch das Testorakel erzeugt worden, müssen diese noch mit den tatsächlichen Ergebnissen, die uns die zu testende Implementierung liefert, verglichen werden. Für primitive Datentypen ist dieser Vergleich trivial, für Objekte kann eine Prüfung auf Gleichheit allerdings beliebig kompliziert werden. Bereits in der zu testenden Implementierung enthaltene Vergleichsmethoden sind oft nicht ausreichend für Testzwecke. Deshalb schreibt man comparators, die zwei beliebige Objekte vergleichen. Comparators sollten unbedingt auf Korrektheit überprüft werden. Ein comparator sollte in der Lage sein folgende Aussagen über zwei Objekte zu liefern: Zwei Objekte sind gleich identisch gleich und identisch partiell gleich nil (noch nicht erzeugt) Beim Vergleich von Objekten muss weiterhin auf verschiedene Besonderheiten, die sich durch die Objektorientierung ergeben, Rücksicht genommen werden: Deep/Shallow Scope Shallow Equality (Referenzengleichheit) Zwei Objekte erfüllen shallow equality, wenn beide Objekte auf die gleichen Felder und Referenzen zeigen. 5

6 Deep Equality Zwei Objekte erfüllen deep equality, wenn sie die gleiche Felder- und Zeigerstruktur haben, die die gleichen Werte beinhaltet. Sie teilen sich keine gemeinsamen Speicheradressen. Abstract/Concrete Content Der abstrakte Inhalt (abstract content) eines Objektes ist der Inhalt, der nur durch öffentliche Methoden zugänglich ist. Der konkrete Inhalt (concrete content) ist der gesamte Inhalt eines Objektes. Die konkrete Gleichheit zweier Objekte liegt vor, wenn sich die Objekte in ihrer Gesamtheit gleichen. Zwei Objekte sind hingegen dann abstrakt gleich, wenn ihr abstrakter Inhalt gleich ist. Abstrakte Gleichheit lässt sich demnach mithilfe der öffentlichen Methoden einer Klasse überprüfen. Collections Für collections, wie Listen, Bäumen oder Arrays, gilt Gleichheit, wenn die einzelnen Elemente der collection gleich sind. Dabei kann man es durch das Erstellen und Berücksichtigen von Entscheidungstabellen unter Umständen vermeiden, durch alle Elemente zu iterieren. 6

7 Supertype/Subtype Equality Beim Vergleich superclass == subclass wird die equality-methode der Superklasse aufgerufen. Demnach wird nur der durch die Superklasse spezifizierte Inhalt verglichen, zusätzlicher Inhalt in der Subklasse wird nicht berücksichtigt. Beim Vergleich subclass == superclass wird die equality-methode der Subklasse aufgerufen. Dabei kann die Abwesenheit der Subklassenvariablen im Objekt der Superklasse zu Ungleichheit führen, was in vielen Fällen nicht wünschenswert ist. Daher sollten für jede Vergleichsmöglichkeit von Sub-/Superklassen-Relationen gesonderte Vergleichsmethoden geschaffen werden: superclass == superclass superclass == subclass subclass == superclass subclass == subclass Partielle Gleichheit Mitunter ist es nicht gefragt, zwei Objekte auf vollständige Gleichheit zu überprüfen. In manchen Fällen ist es nur interessant, ob zwei Objekte bezüglich einer oder mehrerer Eigenschaften gleich sind. In diesen Fällen sollte man für die Vergleichsmethode entsprechende eindeutige Bezeichner benutzen und keinesfalls allgemeine Methoden wie isequal oder == überladen. Zusammenfassung Beim Einsatz von Testorakeln sollten die Orakelmodelle den Anforderungen der jeweiligen Tests entsprechend ausgewählt werden. Hier sind vor allem die Kosten, die Anwendbarkeit und die Genauigkeit der verschiedenen Modelle zu berücksichtigen. Es gilt, eine praktisch sinnvolle Balance zwischen Kosten- und Nutzenoptimierung zu finden. In der Praxis ist eine Mischung aus judging und einfacher, automatischer Testevaluation typisch. Bei automatischer Evaluation ist beim Bau des comparators zu beachten, wie sich Gleichheit von Objekten im jeweiligen Einsatzgebiet definiert. Bei jeglichen zu Testzwecken selbst erstellten Tools (sowohl Orakel, als auch die dazugehörigen comparators) ist die Verifikation dieser essentiell, um verfälschte Ergebnisse für die Gültigkeit zu vermeiden. Gerade im Bereich der Testautomatisierung ist der Einsatz von Testorakeln, die automatisch Testergebnisse evaluieren, unumgänglich. Literatur Robert V. Binder; Testing Object-oriented Systems: Models, Patterns and Tools; Copyright