·
9 min
Äquivalenzklassen und Grenzwertanalyse: Testfälle Schritt für Schritt ableiten
Roman Kirchmeier - Autemos
Äquivalenzklassen und Grenzwertanalyse leiten Testfälle direkt aus der Spezifikation ab: Sie teilen die möglichen Werte in Klassen, die das System gleich behandeln soll, testen je Klasse einen Vertreter und prüfen danach gezielt die Ränder. Beide Verfahren zählen im ISTQB-Lehrplan zu den Black-Box-Testverfahren; die Grenzwertanalyse funktioniert nur für geordnete Klassen wie Beträge oder Datumswerte. Das durchgehende Beispiel ist ein Überweisungsbetrag im E-Banking mit 5 Klassen, 4 Testwerten in der 2-Wert-Variante und 8 in der 3-Wert-Variante. Wo die Verfahren im Gesamtbild stehen, zeigt unser Überblick zum funktionalen Testen.
Kurz gefasst: Äquivalenzklassenbildung teilt Eingaben in Klassen, die das System gleich verarbeiten soll; ein Test je Klasse genügt. Die Grenzwertanalyse prüft zusätzlich die Ränder geordneter Klassen, laut ISTQB-Lehrplan 4.0.2 in der 2-Wert- oder der gründlicheren 3-Wert-Variante. Im illustrativen E-Banking-Beispiel ergeben sich 5 Klassenvertreter sowie 4 beziehungsweise 8 Testwerte an den Klassengrenzen.
Abbildung 1: Äquivalenzklassen und Grenzwerte für einen Überweisungsbetrag (illustratives Beispiel)
Was sind Äquivalenzklassen und Grenzwertanalyse?
Äquivalenzklassenbildung (Equivalence Partitioning) ist ein Black-Box-Testverfahren, das Daten in Klassen aufteilt, deren Elemente das Testobjekt auf die gleiche Weise verarbeiten soll. Aus dieser Annahme folgt laut deutschem Lehrplan: „Daher reicht ein Test je Klasse aus.“ Dieselbe Stelle legt fest: „Die Klassen dürfen sich nicht überschneiden und müssen nicht-leere Mengen sein.“ (ISTQB-Lehrplan CTFL 4.0.2, 2025).
Die Grenzwertanalyse (Boundary Value Analysis) ist ein Black-Box-Testverfahren, das die Ränder dieser Klassen prüft. Sie funktioniert nur für geordnete Klassen, das heißt für Werte mit einer Reihenfolge wie Beträge, Datumswerte oder Feldlängen.
Der aktuelle Lehrplan nennt vier Black-Box-Testverfahren: Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellentest und Zustandsübergangstest (ISTQB CTFL v4.0.1, 2024). Der Anwendungsfalltest stand in Version 3.1 noch auf dieser Liste. Die Abgrenzung zu White-Box-Verfahren erklärt unser Beitrag zum Black-Box-Test.
Warum passieren Fehler so oft an Grenzwerten?
Fehler häufen sich an Grenzwerten, weil jede Grenze im Code ein Vergleich ist und ein falscher Operator oder ein um eins verschobener Wert nur genau an dieser Stelle auffällt. Der Lehrplan begründet den Fokus der Grenzwertanalyse: Sie konzentriert sich auf die Grenzwerte der Klassen, „weil Entwicklern bei diesen Grenzwerten eher Fehlhandlungen unterlaufen“ (ISTQB-Lehrplan CTFL 4.0.2, 2025).
Der QS-Baukasten des deutschen Bundesverwaltungsamts kommt zum selben Schluss: „Werte, die an den Grenzen der Klassen liegen, werden häufiger fehlerhaft verarbeitet als solche innerhalb der Klassen.“ (Bundesverwaltungsamt, QS-Baukasten). MITRE führt das zugehörige Muster als CWE-193 Off-by-one Error: Ein Produkt berechnet oder verwendet einen Maximal- oder Minimalwert, der um 1 größer oder kleiner ist als der korrekte (MITRE CWE-193, CWE 4.20).
Dobslaw, Feldt und Gomes de Oliveira Neto schreiben in PeerJ Computer Science: „Testing it on the boundaries between these sub-domains is critical to ensure high-quality software.“ (Dobslaw et al., PeerJ Computer Science, 2023).
Eine geprüfte Zahl dazu, welcher Anteil aller Fehler an Grenzen liegt, haben wir nicht gefunden.
Wie bilden Sie Äquivalenzklassen Schritt für Schritt?
Äquivalenzklassen bilden Sie, indem Sie eine Bedingung aus der Anforderung in gültige und ungültige Klassen ohne Überschneidung teilen, für geordnete Klassen die Grenzwerte bestimmen und alle Werte mit erwartetem Ergebnis in eine Tabelle für einen parametrisierten Test schreiben. Der Ablauf hat acht Schritte:
Abbildung 2: In acht Schritten von der Anforderung zur Testtabelle
Bedingung wählen: eine Eingabe- oder Ausgabebedingung aus der Anforderung, etwa den Überweisungsbetrag.
Klassen bilden: gültige und ungültige Klassen, ohne Überschneidung und ohne leere Klasse.
Ordnung prüfen: Hat die Klasse eine Reihenfolge? Nur dann folgt Schritt 4.
Grenzwerte bestimmen: in der kleinsten fachlich sinnvollen Schrittweite, bei Frankenbeträgen CHF 0.01.
Variante wählen: 2-Wert- oder 3-Wert-Grenzwertanalyse, abhängig vom Risiko.
Überdeckungselemente notieren: jeden Wert zusammen mit dem erwarteten Ergebnis.
Eingaben kombinieren: mehrere Parameter mit Each-Choice-Überdeckung, dabei nur ein ungültiger Wert pro Test (etablierte Praxis, siehe unten).
Werte als Tabelle ablegen: und an einen parametrisierten Test binden.
Die Grenzen selbst gehören in die Anforderung. Stehen sie in den Akzeptanzkriterien einer User Story, prüft der Abnahmetest später dieselben Werte aus fachlicher Sicht.
Wie misst man die Überdeckung von Äquivalenzklassen?
Die Überdeckung ist die Zahl der Klassen, die mindestens ein Testfall ausführt, geteilt durch die Gesamtzahl der identifizierten Klassen, ausgedrückt in Prozent. Für 100 % müssen die Testfälle laut Lehrplan „alle identifizierten Klassen (einschließlich ungültiger Klassen) mindestens einmal ausführen“ (ISTQB-Lehrplan CTFL 4.0.2, 2025). Testet ein Team von 5 Klassen nur 4, liegt die Überdeckung bei 80 %.
Was bedeutet Each-Choice-Überdeckung?
Each-Choice-Überdeckung verlangt, dass jede Klasse jedes Parameters in mindestens einem Testfall vorkommt; Kombinationen der Klassen berücksichtigt sie nicht (ISTQB CTFL v4.0.1, 2024). Kommt zum Betrag mit 5 Klassen eine Währung mit 3 Klassen hinzu (CHF, EUR, ungültiger Code), genügen 5 Testfälle. Alle Kombinationen ergäben 15.
Was unterscheidet die 2-Wert- von der 3-Wert-Grenzwertanalyse?
Die 2-Wert-Grenzwertanalyse testet je Grenzwert zwei Überdeckungselemente, den Grenzwert und seinen engsten Nachbarn in der angrenzenden Klasse; die 3-Wert-Grenzwertanalyse testet den Grenzwert und seine beiden Nachbarn (ISTQB-Lehrplan CTFL 4.0.2, 2025).
Abbildung 3: 2-Wert- und 3-Wert-Grenzwertanalyse am Lehrplan-Beispiel x ≤ 10
Die 3-Wert-Variante ist gründlicher. Der Lehrplan zeigt das an der Bedingung „if (x ≤ 10)“, die fälschlich als „if (x = 10)“ umgesetzt wurde (ISTQB CTFL v4.0.1, 2024):
Variante | Testwerte für x ≤ 10 | Findet die Fehlimplementierung x = 10? |
|---|---|---|
2-Wert-Grenzwertanalyse | 10, 11 | Nein: 10 ergibt wahr, 11 ergibt falsch, beides wie erwartet |
3-Wert-Grenzwertanalyse | 9, 10, 11 | Wahrscheinlich: 9 müsste wahr ergeben, die fehlerhafte Bedingung liefert falsch |
Die 3-Wert-Analyse zählt pro Grenzwert, und zwischen zwei angrenzenden Klassen fallen mehrere Überdeckungselemente zusammen. Drei Tests pro Grenze sind es deshalb selten, wie die Praxisartikel von trendig (2023) und Valamatsas (2025) zeigen.
Unsere Empfehlung: 3-Wert dort, wo eine Grenze Zahlungen, Freigaben oder Gebühren auslöst, 2-Wert für Felder mit geringem Schadenspotenzial.
Wie sieht ein Beispiel aus dem Zahlungsverkehr aus?
Ein Überweisungsbetrag im E-Banking mit erlaubten Beträgen von CHF 0.01 bis 10’000.00 ergibt 5 Äquivalenzklassen, 4 Testwerte in der 2-Wert-Grenzwertanalyse und 8 unterschiedliche Werte in der 3-Wert-Variante. Das Beispiel ist illustrativ und keine reale Bankregel; gültige Beträge haben höchstens zwei Dezimalstellen.
Klasse (illustrativ) | Bereich oder Regel | geordnet? | Vertreter | 2-Wert-Grenzwertanalyse | 3-Wert-Grenzwertanalyse |
|---|---|---|---|---|---|
K1 ungültig: zu klein | ≤ 0.00 | ja | -50.00 | 0.00 | -0.01, 0.00 |
K2 gültig | 0.01 bis 10’000.00 | ja | 2’500.00 | 0.01, 10’000.00 | 0.01, 0.02, 9’999.99, 10’000.00 |
K3 ungültig: zu groß | ≥ 10’000.01 | ja | 25’000.00 | 10’000.01 | 10’000.01, 10’000.02 |
K4 ungültig: mehr als 2 Dezimalstellen | z. B. 100.005 | nein | 100.005 | entfällt | entfällt |
K5 ungültig: keine Zahl | „abc“, leeres Feld | nein | „abc“ | entfällt | entfällt |
K1 bis K3 gelten nur für Zahlen mit höchstens zwei Dezimalstellen, K4 und K5 prüfen das Format. So überschneiden sich die Klassen nicht.
Für 100 % Klassenüberdeckung reichen 5 Testwerte, einer je Klasse. Die 2-Wert-Analyse ergibt 4 Werte: 0.00, 0.01, 10’000.00 und 10’000.01. Die 3-Wert-Analyse erzeugt an denselben 4 Grenzwerten 12 Überdeckungselemente, von denen nur 8 verschieden sind: -0.01, 0.00, 0.01, 0.02, 9’999.99, 10’000.00, 10’000.01 und 10’000.02. Lässt die Eingabemaske -0.01 gar nicht zu, prüfen Sie den Wert an der Schnittstelle, siehe API-Testing.
Wie automatisieren Sie Äquivalenzklassen mit parametrisierten Tests?
Äquivalenzklassen automatisieren Sie als Datentabelle, die ein einziger parametrisierter Test Zeile für Zeile ausführt, mit Eingabewert, Klasse und erwartetem Ergebnis in jeder Zeile. Ein neuer Grenzwert bedeutet dann eine neue Zeile, und der Testcode bleibt unverändert.
Abbildung 4: Aus der Klassentabelle wird ein parametrisierter Test (illustrative Werte)
Framework | Mechanismus | Dokumentation |
|---|---|---|
JUnit 6 (Java) | @ParameterizedTest mit @CsvSource, @CsvFileSource oder @MethodSource; benötigt junit-jupiter-params | |
Playwright Test | Schleife über die Datensätze, ein test()-Aufruf pro Eintrag mit eindeutigem Testnamen; CSV-Dateien über csv-parse | |
pytest (Python) | Dekorator pytest.mark.parametrize an der Testfunktion | |
Autemos | Datasets aus CSV, XLSX oder JSON, Laufzeit-Bindings als typisierte Variablen, Markierung für Einmal-Daten |
JUnit ist aktuell in Version 6.1.3 vom 7. August 2026 verfügbar, mit Java 17 als Mindestversion (JUnit Release Notes, 2026). Anleitungen, die noch auf JUnit 5.7.0 verweisen, sind veraltet. pytest steht bei Version 9.1.1 (pytest Docs).
In Autemos, der KI-gestützten Testautomatisierung von selementrix, wird die Klassentabelle zu einem Dataset aus CSV, XLSX, JSON oder einer externen Quelle wie einer REST-API oder Datenbank. Zur Laufzeit stehen die Spalten als typisierte Variablen bereit, je Lauf, Projekt oder Mandant und je Umgebung konfigurierbar. Einmal verwendbare Daten sind markiert, damit parallele Läufe sie nicht doppelt nutzen.
Exportierte Tests laufen als Playwright- oder Appium-Code auch ohne Autemos. Die Klassenanalyse bleibt menschliches Testdesign: Autemos leitet keine Äquivalenzklassen automatisch ab. Für reale Kundendaten gilt, was wir zu DSGVO-konformen Testdaten beschrieben haben.
Einmal angelegt, läuft die Tabelle bei jeder Änderung im Regressionstest mit. Codeüberdeckung misst Autemos nicht; den Unterschied zur Klassenüberdeckung erklärt der Beitrag zur Testabdeckung.
Welche Fehler machen Teams bei Klassen und Grenzwerten?
Lücken bei Äquivalenzklassen und Grenzwerten entstehen an sechs typischen Stellen: ungeordnete Klassen, Dezimalzahlen, Zeitzonen, unklare Grenzen, Kombinationen und maskierte Fehler.
Grenzwerte für ungeordnete Klassen: Kontoarten oder Währungscodes haben keinen „nächsten Nachbarn“. Sie bekommen je einen Vertreter.
Geldbeträge als Gleitkommazahl: Die Python-Dokumentation warnt: „most decimal fractions cannot be represented exactly as binary fractions“ (Python Docs). In Java ist new BigDecimal(0.1) nicht exakt 0.1, und equals() wertet 2.0 und 2.00 als verschieden (Oracle Java SE 21 API). Erwartete Beträge gehören als Text in die Tabelle, werden als BigDecimal eingelesen und mit compareTo() verglichen, das 2.0 und 2.00 als gleich wertet.
Zeitzonen und Annahmeschluss: Legen Sie die Zeitzone im Test fest, in Playwright über test.use mit timezoneId (Playwright Docs), und testen Sie die Minute vor und nach der Grenze.
Inklusiv oder exklusiv: „Bis 10’000“ lässt offen, ob 10’000.00 noch gültig ist. Dort entstehen Off-by-one-Fehler nach CWE-193. Klären Sie das in der Anforderung.
Kombinationen übersehen: Hängt das Ergebnis von mehreren Bedingungen zugleich ab, etwa Betrag und Kundensegment, gehört die Regel in einen Entscheidungstabellentest. Dort wächst die Zahl der Regeln exponentiell mit der Zahl der Bedingungen (ISTQB CTFL v4.0.1, 2024).
Mehrere ungültige Werte in einem Test: Scheitert ein Test mit zu hohem Betrag und ungültiger Währung, bleibt unklar, welche Prüfung gegriffen hat. Die Regel „ein ungültiger Wert pro Test“ stammt aus dem Lehrplan 2018 (CTFL 2018 v3.1, 2018) und ist etablierte Praxis, nicht Teil des Abschnitts zur Äquivalenzklassenbildung in v4.0.1.
Häufig gestellte Fragen
Wie viele Testfälle braucht die Äquivalenzklassenbildung?
Für 100 % Klassenüberdeckung ist mindestens ein Testfall je Klasse nötig, ungültige Klassen eingeschlossen (ISTQB-Lehrplan CTFL 4.0.2, 2025). Im E-Banking-Beispiel sind das 5 Testfälle.
Wann reicht die 2-Wert-Grenzwertanalyse?
Die 2-Wert-Grenzwertanalyse reicht, wenn ein unentdeckter Grenzfehler wenig Schaden anrichtet. Sie findet etwa ein „<“ statt „≤“, übersieht aber eine Umsetzung von x ≤ 10 als x = 10, die erst der dritte Wert zeigt (ISTQB CTFL v4.0.1, 2024). Für Beträge, Limits und Gebühren empfehlen wir die 3-Wert-Variante.
Kann man eine Grenzwertanalyse ohne Äquivalenzklassen durchführen?
Nein, Grenzwerte sind die Ränder von Klassen, und diese Klassen müssen zuerst gebildet werden. Der Lehrplan beschreibt die Grenzwertanalyse als Verfahren für die Grenzwerte der Klassen und erlaubt sie nur für geordnete Klassen (ISTQB-Lehrplan CTFL 4.0.2, 2025).
Gehört das Schema „min-1, min, min+1, nominal, max-1, max, max+1“ zum ISTQB-Standard?
Nein, das Sieben-Werte-Schema mit Nominalwert steht nicht im ISTQB-Lehrplan. Der Lehrplan beschreibt die 2-Wert- und die 3-Wert-Grenzwertanalyse, jeweils gezählt pro Grenzwert, und kennt keinen Nominalwert als Überdeckungselement.
Erzeugt Autemos Äquivalenzklassen automatisch?
Nein, Autemos leitet keine Äquivalenzklassen oder Grenzwerte ab; die Analyse bleibt Aufgabe des Testdesigns. Autemos führt die fertige Wertetabelle als Dataset aus. KI-entworfene Testschritte laufen erst, nachdem Ihr Team jeden Schritt freigegeben hat.
Fazit
Äquivalenzklassenbildung und Grenzwertanalyse machen aus einer Anforderung eine kurze, begründbare Liste von Testwerten. Die Klassen liefern je einen Vertreter, die Grenzwertanalyse prüft die Ränder geordneter Klassen in der 2-Wert- oder 3-Wert-Variante nach ISTQB. Im illustrativen E-Banking-Beispiel sind das 5 Vertreter und 4 beziehungsweise 8 Testwerte an den Klassengrenzen.
Die Aussagekraft hängt an Details: exakte Dezimalwerte, eindeutige Grenzen, eine festgelegte Zeitzone und ein ungültiger Wert pro Test. Die Werte gehören in eine Tabelle, die ein parametrisierter Test in JUnit, Playwright oder pytest abarbeitet, oder in ein Dataset der Testdatenverwaltung von Autemos. Die Klassen entwirft Ihr Team, die Wiederholung übernimmt die Automatisierung.
Sie wollen Grenzwerttests für Ihre Zahlungsstrecken automatisieren? Sprechen Sie mit uns.
