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.