Kategorien
Äquivalenzklassen beim Testen
Der Titel des heutigen Artikels klingt ein wenig theoretischer, als er wirklich ist. Lasst euch also nicht abschrecken. Alles was wir heute definieren wollen, ist, wie man Testfälle zusammenfasst. Dabei wird jeder Testfall in so genannte Äquivalenzklassen eingeteilt, die wie folgt definiert sind.
- Jeder Testfall gehört zu genau einer Äquivalenzklasse
- Falls der Test für Testfall a (aus Äquivalenzklasse A) fehlschlägt, so schlägt er auch für alle anderen Testfälle aus A fehl.
Ok, ist jetzt doch ein wenig theoretischer geworden, als ich gehofft habe. Aber vielleicht kann ein einfaches Beispiel helfen. Nehmen wir eine Methode, die ein Jahr entgegen nimmt und true zurück gibt, falls das Jahr ein Schaltjahr ist. Hier sollte man vier Äquivalenzklassen wählen. Die erste für alle Nichtschaltjahre. Die zweite für alle „normalen“ Schaltjahre. Dann gibt es noch zwei Sonderregeln und ich hoffe, dass ich sie so aus dem Stegreif richtig wiedergebe. Ein Jahr ist kein Schaltjahr, sobald es durch 100 teilbar ist, außer es ist durch 1000 teilbar. 1900 war eins, 2000 keins. Wir brauchen also noch eine Äquivalenzklasse für die Jahre, die durch 100 teilbar sind, aber nicht durch tausend und eine, die alle Jahrtausende zusammenfasst.
Betrachten wir die zweite Regel, so brauchen wir jetzt genau 4 Testfälle für unsere positiv Tests. Natürlich brauchen wir mehr, wenn wir noch eine Fehlerbehandlung oder ähnliches in unserer Funktion haben.
Die Testfälle könnten 2000, 1900, 2008 und 2009. Hiermit sollte ich, bei einer allzu verkorksten Implementierung alles abgedeckt haben.
Halten wir also fest. Wir brauchen immer nur einen Testfall pro Äquivalenzklasse, was die Anzahl der benötigten Tests drastisch reduzieren kann. Andersherum sollten wir auch für jede Äquivalenzklasse genau einen Testfall in unseren Tests besitzen.
Deine Schaltjahrberechnung ist etwas falsch. Ein Jahr ist ein Schaltjahr, sobald es durch 4 teilbar ist. Es sei denn es ist glatt durch 100 teilbar ohne glatt durch 400 teilbar zu sein.
Ok, dass kann natürlich auch sein. Werde es im Laufe des Tages verbessern. Vielen Dank schon mal.
Wodurch genau ist ja eigentlich auch egal – und nur der Form halber wichtig. Das Prinzip soll vermittelt werden 😉
„Falls der Test für Testfall a (aus Äquivalenzklasse A) fehlschlägt, so schlägt er auch für alle anderen Testfälle aus A fehl.“ – Diese „Definition“ ist so nicht ganz richtig.
Erstens bestehen die Äquivalenzklassen nicht aus Testfällen, sondern die Äquivalenzklassen bilden eine Zerlegung der Menge aller möglichen Eingaben. (ÄK)
Zweitens: Wie soll denn dieser Teil der „Definition“ überprüft werden? Der Sinn des methodischen Testens besteht doch gerade darin, die Repräsentanten so zu wählen, dass jede Äquivalenzklasse – im Sinne von (ÄK) – durch mindestens einen Testfall abgedeckt wird. Hier erwartet man dann einfach, dass das Testergebnis nicht von der Wahl des Repräsentanten abhängt. Für die Praxis muss dies aber nichts heißen, denn es kann durchaus sein, dass aus irgendeinem Grund ein Fehler bei einem ganz bestimmten Eingabewert auftritt, ohne dass er mit der Äquivalenzklassenmethode entdeckt würde. Allerdings ist die Wahrscheinlichkeit relativ gering, weil wir hier bereits über einen White-Box-Test reden. (Der andere Fehler wurde hoffentlich vorher im Entwicklertest entdeckt.)
Beim Testen macht es grundsätzlich Sinn, die Äquivalenzklassenbildung mit der so genannten Grenzwertanalyse zu kombinieren.
@Werner: Beim ersten hast du natürlich, die ÄK besten aus allen möglichen Eingaben. Ein Testfall ist aber meiner Meinung nach auch eine Teilmenge dieser. Besser wäre also gewesen, dass jede mögliche Eingabe zu genau einer Äquivalenzklasse gehört. Damit wäre die Aussage korrekt, aber vielleicht noch vollständig. Aber egal, ich verstehe schon deinen Punkt.
Bei deinem 2ten Punkt kann ich dich auf „Objektorientierte Softwareentwicklung“ von Bernd Brügge verweisen (hierher stammt auch die Definition). Ich würde schon sagen, dass man schon in Äquivalenzklassen denken sollte, aber vielleicht nicht die Klassen der Problemstellung, sondern der Implementierung heranziehen sollte. Denn wie du ja selbst sagst, sind wir hier im Bereich der Whitebox Tests und damit auch Herr der Implementierung.
Ein Testfall kann formal nicht einfach nur eine Teilmenge einer Äquivalenzklasse sein, denn diese besteht ja nur aus möglichen Eingaben. Für einen Testfall genügt das nicht, denn dieser benötigt mindestens noch das erwartete (Soll-)Ergebnis, anhand dessen im Rahmen der Testdurchführung zu entscheiden ist, ob eine Abweichung (zwischen Soll und Ist) existiert. Von den Vor- und Nachbedingungen ganz zu schweigen.
„Besser wäre also gewesen, dass jede mögliche Eingabe zu genau einer Äquivalenzklasse gehört.“ (*)
Das wäre die Konsequenz aus der in der Mathematik gebräuchlichen Definition.
Eine Äquivalenzrelation ~ auf der Menge A ist bestimmt durch:
(1) a ~ a (Reflexivität)
(1) a ~ b => b ~ a (Symmetrie)
(3) a ~ b und b ~ c => a ~ c (Transitivität)
Die Äquivalenzklasse [a] ist definitiert als die Menge aller x aus A, für die x ~ a gilt. Man kann zeigen, dass a ~ b [a] = [b] gilt. Dies bedeutet nichts anderes als (*), die Menge „zerfällt“ in ihre Äquivalenzklassen.
Bezogen auf unser Testszenario betrachten wir letztlich nichts anderes als die Äquivalenzrelation ^ auf der Menge aller möglichen Eingaben. ^ lässt sich also wie folgt definieren:
a ^ b : Das Testobjekt soll bei der Eingabe von a und b dasselbe Ergebnis liefern
Ein Test ohne eine genaue Spezifikation der zu erwartenden Ergebnisse ist also sinnlos. Ungeachtet dessen kommt er in der Praxis immer noch zu häufig vor. 😉
Oben fehlt leider zwei Mal das Äquivalenzzeichen (weil es offensichtlich als HTML-Tag interpretiert und daher unterdrückt wurde). Es muss heißen
a ~ b genau dann, wenn [a] = [b]
und
a ^ b genau dann (per Definition), wenn: Das Testobjekt …
Na gut, dann kapituliere ich einfach mal und ziehe meinen mathematischen Hut. Ich hoffe trotzdem, dass die Grundidee hinter der Sache allen klar geworden ist.
Ist sie. Ich finde es sehr gut, dass an dieser Stelle auch mal ein wichtiges Thema wie das Testen behandelt wird.
Ach ja: Frohes Fest und einen guten Rutsch! 🙂
Hallo, kann mir bitte jemand helfen? Habe mich durch eine Prüfung als Certified Tester gequält und eine Aufgabe lautete: Wie viele Äquivalenzklassen braucht man, um zu prüfen, ob eine Postleitzahl fünfstellig eingegeben wurde. 1, 2, 3 oder 4?
Die Eingabe ist dann richtig, wenn sie mindestens 5-stellig ist, m.E. kann auch an der ersten Stelle dann durchaus eine Null eingeben werden.
Wer kann das lösen? Ich musste da leider passen, hab es nicht beantworten können.
Danke schon mal vorab!
Naja, kommt ganz auf die Methode an, denke ich. Die PLZ muss kleiner 10000 sein und größer 9999. Das wären meine zwei Kriterien, falls sie wirklich 5 Stellen haben muss. Dies würde 2 Äquivalenzklassen bedeuten.
Irgendwie wiederspricht sich die letzte Aussage. Wenn die Zahl kleiner 10000 sein muss, aber größer als 9999, sind wir wieder bei einer fünfstelligen Zahl. Die fünfstellige Zahl ist doch ok, und somit eine gültige Klasse. Will heissen, die fünfstellige Zahl wäre korrekt (gültige Klasse) und die vierstellige wäre eine ungültige Klasse. Somit ist die Aussage mit 2 Äquvivalenzklassen richtig, nur die Erklärung finde ich an der Stelle nicht ganz korrekt, ausser ich sehe das irgendwie falsch. Auf eine Rückantwort würde ichmich freuen. Vielen Dank.
Sven
Hallo Leute,
ich sehe 3 Äquivalenzklassen, wenn die PLZ rein numerisch sein muss.
1. Eingabe hat weniger als 5 Zeichen
2. Eingabe hat mehr als 4 Zeichen, alle numerisch
3. Eingabe hat mehr als 4 Zeichen, (mind.) eins nicht numerisch
Falsch gedacht?
Grüße an alle da draußen!
FK