Ersocon.net – Science Blog

Die grundsätzliche Idee der Klassifikationsbaum-Methode is es den Eingabedatenraum des Testobjektes nach verschiedenen Test relevanten Gesichtspunkten jeweils getrennt voneinander in Klassen, die auch als Äquivalenzklassen verstanden werden können, zu zerlegen. Aus der Kombination geeigneter Klassen werden Testfälle ermittelt. Die Hauptinformationsquelle zur Findung der Klassen ist dabei die Spezifikation, die das geforderte Verhalten des Testobjektes beschreibt.

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.

Die Grenzwertanalyse stellt einen Spezialfall bzw. Verfeinerung der Äquivalenzklassenbildung dar. Bei dieser Technik werden durch Grenzwerterzeugung zusammenhängende Wertebereiche getestet. Im Gegensatz zur reinen Äquivalenzklassenbildung werden hierbei jedoch nicht beliebige Werte als Repräsentanten einer KLasse gewählt, sondern vorzugsweise die Randbereiche.

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.

Die Äquivalenzklassenbildung ist eine Technik, die zur Reduzierung der Anzahl an Testfällen verwendet wird. Hierbei werden die möglichen Werte einer Eingabegröße in Klassen eingeteilt. Dadurch kann durch eine relativ kleine Anzahl an Testfällen eine angemessene Testabdeckung erzielt werden.

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.