Der Tester kann durch die Automatisierung einzelner Aktivitäten bei der Testfallermittlung geleitet werden. Des Weiteren bietet die Klassifikationsbaum-Methode eine Möglichkeit zur grafischen Notation, die eine Visualisierung der Testfallermittlung unter Verwendung moderner grafischer Oberflächen ermöglicht. Nachfolgend möchte ich die Methode zunächst allgemein beschreiben und danach zum besseren Verständnis an einem Beispiel verdeutlichen.

Die Ermittlung der Test relevanten Aspekte erfolgt meist manuell durch den Tester mittels der funktionalen Spezifikation des Testobjektes. Diese dienen der einfachen Unterscheidung der möglichen Eingabedaten. Im Anschluss wird die Menge aller möglichen Eingaben unter dem jeweiligen Aspekt disjunkt in Klassen zerlegt. Alle Werte einer Klasse sind demzufolge äquivalent (bei Interesse kann man sich zusätzlich meinen Beitrag zu Äquivalenzklassen durchlesen). Im konkreten Testfall reicht ein Repräsentant aus. Die Zerlegung unter den Aspekten sind Klassifikationen.

In komplexen Systemen werden Klassen mit Hilfe vo Klassifikationen wiederum in weitere Klassen unterteilt. Das rekursive Vorgehen resultiert in einem Klassifikationsbaum, der die anschaueliche Darstellung der mehrstufigen Zerlegung repräsentiert. Klassifikationen werden in der grafischen Darstellung des Baumes als benannte Rechtecke dargestellt. Darunter werden jeweilige Klassen angeordnet. Entsprechend werden die tiefer liegenden Klassifikationen mit ihren Klassen jeweils unter der zugehörigen Klasse notiert.

Im letzten Schritt der Methode werden die Testfälle gebildet. Aus der Kombination verschiedener Klassifikationen entsteht jeweils ein Testfall. Dieser wird in Form einer Zeile in einer Kombinationstabelle notiert. Die Namen der Spalten dieser Tabelle resultieren aus den Blättern (Klassen) des Baumes. Bei logisch unvereinbaren Kombinationen (z.B. Klassen ein und derselben Klassifikation) bleibt der Tabelleneintrag leer.

Die Ermittlung der Test relevanten Aspekte ist oft vom Tester abhängig. Genauer kommt es hierbei auf Kreativität und Verständnis des Problembereichs an. Dadurch ergibt sich die Möglichkeit, dass Fehler im Testobjekt aufgrund unvollständiger Klassifikationsbäume unerkannt bleiben.

Die Methode soll am folgenden Beispiel veranschaulicht werden: Ausgangspunkt ist eine Spezifikation einer Computer-Vision-Systems, welches mit einer Kamera verschiedene Objekte erkennen soll. Mögliche Test relevante Aspekte können hierbei Farbe und Form sein. Damit ergeben sich die KLassifikationen für Farbe und Form. Die Klassifikation Farbe lässt sich beispielhaft in drei Klassen unterteilen: Rot, Gelb und Blau. Bei der Form könnte das Objekt exemplarisch in Kreis, Dreieck oder Rechteck unterteilt sein. Zur Repräsentation einer tiefer liegenden Klassifikation wird die Art eines Dreiecks betrachtet. Hierbei wird zwischen gleichseitigen, gleichschenkligen und ungleichseitigen Dreiecken unterschieden. Mit Hilfe des Klassifikationsbaums können nun Testfälle bestimmt werden.

Es genügt den unteren Grenzwert sowie den nächstkleineren Wert, den oberen Grenzwert sowie den nächstgrößeren Wert und einen Mittelwert zu generieren, um einen geschlossenen Wertebereich zu testen. Diese Werte sind stellvertretend für alle weiteren innerhalb und außerhalb des jeweiligen Wertebereichs. Ein kleines Beispiel dazu findet ihr im vorangegangenem Beitrag über Äquivalenzklassen.

Eine Äquivalenzklasse besteht aus einer Menge an Daten, welche als äquivalent angesehen werden, d.h. sie liefern erwartungsgemäß bei einem Test dieselben Ergebnisse. Jeder Datenwert innerhalb einer Äquivalenzklasse ist also so gut wie jeder andere. Die Datenwerte können dabei entweder aus tatsächlichen Wertebereichen, wie z.B. 0 bis 100, oder aus Mengen an Datensätzen bestehen. Für den Test bietet dies folgende Erkenntnisse (nachzulesen in A Practitioner’s Guide to Software Test Design – Copeland, L., 2003):

1. Falls ein Testfall einer Äquivalenzklasse einen Fehler aufdeckt, so decken auch alle anderen Testfälle der Äquivalenzklasse den Fehler auf.
2. Falls ein Testfall einer Äquivalenzklasse keinen Fehler aufdeckt, so decken auch alle anderen Testfälle der Äquivalenzklasse keine Fehler auf.

Interessant ist also die tatsächliche Wahl der äquivalenten Daten einer Äquivalenzklasse. Allgemein betrachtet ergeben sich zwei Möglichkeiten:

1. Verwendung von gültigen Wertebereichen (Testing-by-contract)
2. Verwendung von ungültigen Wertebereichen (Defensive testing)

Bei dem Testing-by-contract Ansatz geht man davon aus, dass der zu testende Softwareteil (auch Modul genannt) nur Eingabeparameter erhält, welche es verarbeiten kann. Zudem werden dem Modul unabhängig von der Eingabe Daten zur Verfügung gestellt, welche es zur fehlerfreien Verarbeitung der Eingabeparameter braucht. Entsprechend werden hierbei nur Äquivalenzklassen mit gültigem Wertebereich erstellt und durch ihre Repräsentanten getestet.

Äquivalenzklassen mit Daten außerhalb des zulässigen Bereichs werden hierbei nicht berücksichtigt, weil man evtl. davon ausgeht, dass die unzulässigen Bereiche nicht erreicht werden. Problematisch ist bei diesem Ansatz die Tatsache, dass Probleme auftreten könne, sobald ein unzulässiger Bereich in einem ausgelieferten Produkt tatsächlich erreicht wird (z.B. das Jahr 2000 bei einer 1985 geschriebenen Software). Um diesem Problem entgegenzuwirken, werden beim defensive-testing Ansatz auch unzulässige Bereiche zugelassen. Dies bedeutet, dass neben einer Äquivalenzklasse im gültigen Bereich auch mindestens eine Äquivalenzklasse für den ungültigen Bereich erstellt werden und durch einen Repräsentanten getestet werden muss. Die Anzahl nötiger Testfälle erhöht sich zwangsläufig.

Ein kleines Beispiel dazu:

Man hat ein Softwaremodul, das die Wurzelfunktion implementiert und nur ganze Zahlen im Bereich 0 bis 64 akzeptiert. Beim Testing-by-contract Ansatz benötigt man (grob betrachtet) zwei Äquivalenzklassen mit entsprechenden Repräsentanten. Eine davon nennen wir mal die Ganzzahl-Äquivalenzklasse und die andere Dezimal-Äquivalenzklasse. Wir gehen davon aus, dass die Ganzzahl-Äquivalenzklasse alle Eingabeparameter enthält, bei denen das Modul als Ergebnis eine Ganzzahl liefert, z.B. 4 oder 16. Hieraus wählen wir einen Repräsentanten, die 16, was dem ersten Testfall entspricht. Für die zweite Äquivalenzklasse nehmen wir entsprechend die 17, da hier bekannt ist, dass keine Ganzzahl als Ergebnis zu erwarten ist.

Beim defensive-testing werden nun weitere Äquivalenzklassen hinzugefügt. Wir erwarten z.B., dass das Modul bei der Eingabe einer negativen Zahl, einer Dezimalzahl oder einer Zahl größer 64 eine Fehlermeldung liefern muss. Mit der Bildung der entsprechenden Äquivalenzklassen (Negativ-Äquivalenzklasse, Dezimaleingabe-Äquivalenzklasse und Zugroßeeingabe-Äquivalenzklasse) erhält man drei weitere Testfälle: z.B. (-1|0,3|65) oder (-5|20,1|1200). Das erste Beispiel wird sicherlich öfter Anklang finden, da beim Testen versucht wird auch die Grenzbereiche (0/64) ausreichend zu testen.

Der Black-Box-Test ist nämlich im industriellen Einsatz deutlich bedeutender als der White-Box-Test. Hierbei ist keine notwendige Kenntnis über die internen Abläufe und Ausführungspfade der Software notwendig. Ebenso werden hierbei auch Implementierungsdetails, wie z.B. IF-Anweisungen außer Acht gelassen. Entscheidend ist bei dieser Testvariante die Kenntnis über das, was die Software im Endeffekt leisten soll.

Ein Black-Box-Test sieht in allgemeiner Form wie folgt aus: Im ersten Schritt erfolgt eine genaue Analyse der Anforderungen oder der Spezifikation, z.B. mit Hilfe des Pflichtenheftes oder technischer Datenblätter. Anhand der gewonnenen Erkenntnisse werden Eingabeparameter ausgewählt und erwartetet Ergebnisse/Ergebniswerte definiert oder generiert. Oft werden die Eingabeparameter so gewählt, dass möglichst große Wertebereiche oder spezielle Grenzwerte abgedeckt werden. Zu beachten ist hierbei , dass bei einem Black-Box-Test nicht unbedingt alle implementierten Eigenschaften der Software allein anhand der Spezifikation erkannt werden können. Die gewählten Parameter verwendet man zur konkreten Testfalldefinition. Die Testfälle dienen als Grundlage für den eigentlichen Test. Nach jedem Testdurchlauf erfolgt die Überprüfung der Ergebnisse mittels der vordefinierten erwarteten Werte.

Der Black-Box-Test bezieht seine Vorteile aus der Tatsache, dass der Tester die Testfälle nach seinem Verständnis der Software gestalten muss und dadurch Testfälle erzeugt, die im Vergleich zu willkürlich gewählten deutlich effektiver und effizienter Fehler aufdecken können. Kritisch ist bei dieser Sichtweise wiederum der Tester selbst. Denn bei einem Black-Box-Test ist es nahezu unmöglich alle Kombinationsmöglichkeiten an Eingabeparametern abzudecken. Es bleibt also dem Tester überlassen, welche Testfälle ausgewählt werden. Diese Teilmenge fällt im Vergleich zu den Variationen sehr klein aus. Wie erfolgreich oder effizient der Test ist, hängt folgerichtig stark mit der Erfahrung des Testers, der Genauigkeit der Spezifikation und der gewählten Testfälle zusammen. Des weiteren ist Software nicht immer schlicht als Ein- und Ausgabe Maschine zu betrachten. Entscheidend sind auch die Zustände, in der sich eine Software befinden kann. Ein solches Universum an Zuständen, Eingabeparametern und erwarteten Ergebnissen ist nicht immer einfach zu überblicken.

Repräsentativ für den Black-Box-Test stehen folgende Methodiken: Äquivalenzklassen, Grenzwertanalyse, Ursache-Wirkungsgraph, Error Guessing

Zunächst einmal kann man sich natürlich fragen, worauf es beim White-Box-Test ankommt. Beim ablaufbezogenen Testen (White-Box-Test) wird das Programm gegen sich selbst getestet. Das Objekt des Testfalls ist der Ablaufgraph des jeweiligen Programms. Bei dieser Methode werden die Testfälle mit Kenntnissen über die innere Funktionsweise und der Spezifikation entwickelt.

Das Ziel ist es, die Überdeckung der möglichen und relevanten Pfade eines Programms in einem Test oder einer Testserie festzustellen.  Die Anweisungen, Zweige und Pfade lassen sich durch eine statische Analyse aus dem Programm ableiten. Bei der dynamischen Analyse des Ausführungen registriert und protokolliert.

Der Nachteil des White-Box-Test ist, dass nur eine bestimmte Klasse von Fehlern durch sie aufgedeckt werden – nämlich grobe Abbruchfehler, unerreichbare Zweige, Irrpfade, endlose Schleifen und unvollständige bzw. inkonsistente Bedingungen. Vergessene Funktionen, unberücksichtigte Daten, inkonsistente Schnittstellen, Tippfehler, IO-Fehler und Abweichungen von der Spezifikation können auch nach Ausführung aller Pfade, d.h. Überdeckung des Ablaufgraphs, unerkannt bleiben.

Den Hauptnutzen zieht der White-Box-Test daraus, dass er den Tester zwingt, sich intensiv mit dem zu testenden Objekt auseinander zu setzen. Dabei stößt dieser unwillkürlich auf logische Ungereimtheiten, da er stets bestrebt ist alle Anweisungen, Pfade und Zweige auszuführen.