Verfahren der Testfall-Generierung

Wie ein Testfall entsteht, hängt stark davon ab, welches Verfahren dahintersteht. Im ersten Teil unserer Serie „KI im Software-Testing“ wurden Verfahren wie BDD, TDD, DDT usw. nur kurz und ausschließlich im KI-Kontext gestreift. Dieser Beitrag geht unabhängig davon in die Tiefe: Er stellt die gängigsten Verfahren zur systematischen Ableitung von Testfällen vor, jeweils mit kurzer Erklärung, einem Beispiel, typischen Einsatzmöglichkeiten sowie Vor- und Nachteilen und Grenzen. Keines dieser Verfahren schließt die anderen aus; in der Praxis werden meist mehrere davon kombiniert.

Bevor wir jedes Verfahren im Detail vorstellen, eine erste Orientierung, welches Problem welches Verfahren eigentlich löst:

• Design und Zusammenarbeit während der Entwicklung: TDD, BDD

• Klärung von Anforderungen vor der Umsetzung: ATDD

• Strukturierung bestehender Testabläufe: DDT, KDT

• Testfälle aus einem Modell oder einer Eigenschaft ableiten: MBT, Property-Based Testing

• Reduktion der Testfallzahl bei vielen Parametern: Pairwise Testing

Test-Driven Development (TDD)

Bei TDD wird der Test vor dem eigentlichen Produktivcode geschrieben. Der Zyklus „Red – Green – Refactor“ bestimmt den Ablauf: Ein zunächst fehlschlagender Test (Rot) wird durch minimalen Code zum Bestehen gebracht (Grün), anschließend wird der Code überarbeitet, ohne den Test zu brechen (Refactor). Für eine noch nicht existierende Funktion berechneRabatt() wird dazu zuerst ein Unit-Test geschrieben, der einen Rabatt von 10 % bei einem Bestellwert über 100 € erwartet; der Test schlägt zunächst fehl, da die Funktion fehlt, und erst danach wird sie implementiert, bis der Test grün ist.

Einsatz. Vor allem auf Unit-Test-Ebene bei komplexer Geschäftslogik und bei Neuentwicklungen, wo Design und Testbarkeit von Anfang an mitgedacht werden sollen.

Vorteil. Das Verfahren fördert eine hohe Testabdeckung von Beginn an, unterstützt testbares, entkoppeltes Design und liefert schnelles Feedback bei Änderungen.

Grenze. Es erfordert eine gewisse Lernkurve und anfänglichen Mehraufwand und eignet sich wenig für explorative oder stark UI-lastige Aufgaben. Zudem prüft TDD nur, ob der Code das tut, was Entwickler*innen beim Schreiben des Tests angenommen haben, nicht zwingend, ob diese Annahme fachlich korrekt ist: Bei einem Missverständnis der Anforderung entstehen konsistent falsche, aber grüne Tests.

Behavior-Driven Development (BDD)

BDD erweitert TDD um die Perspektive des beobachtbaren Verhaltens aus fachlicher Sicht: Szenarien werden in natürlicher, aber strukturierter Sprache formuliert (Gherkin-Syntax: Given – When – Then) und sind damit sowohl für Fachbereich als auch für Entwicklung und Test lesbar. Ein Szenario wie „Given ein Kunde hat drei Artikel im Warenkorb, When er den Rabattcode SUMMER10 eingibt, Then wird der Gesamtpreis um 10 % reduziert“ lässt sich mit Tools wie Cucumber oder SpecFlow direkt gegen die Anwendung ausführen.

Einsatz. Vor allem bei Akzeptanztests, zur Abstimmung zwischen Fachbereich, Entwicklung und Test sowie als lebende, stets aktuelle Dokumentation des Systemverhaltens.

Vorteil. Die Szenarien schaffen eine gemeinsame Sprache zwischen Business und Technik und dienen gleichzeitig als Test und Dokumentation.

Grenze. Die zusätzliche Abstraktionsebene der Step-Definitionen muss gepflegt werden, und es entsteht eine Gefahr von Scheingenauigkeit, wenn ein gut lesbares Szenario technisch schlecht automatisiert ist. Ohne Disziplin bei der Modularisierung entsteht zudem dieselbe Wartungsproblematik wie bei klassischem Testcode, und bei zu vielen oder zu technischen Szenarien geht der Lesbarkeitsvorteil von Gherkin verloren.

Acceptance Test-Driven Development (ATDD)

Bei ATDD werden konkrete Akzeptanzkriterien gemeinsam von Product Owner*in, Entwicklung und Test formuliert, bevor die Umsetzung einer User Story beginnt; diese Kriterien bilden zugleich die Basis für die spätere Abnahme. Für die Story „Als Kund*in möchte ich meine Bestellung stornieren können“ wird so etwa vorab das Akzeptanzkriterium „Stornierung ist bis 24 Stunden vor Versand möglich“ als überprüfbarer Test formuliert, noch bevor die Entwicklung beginnt.

Einsatz. Vor allem beim Backlog Refinement und Sprint Planning in agilen Teams, insbesondere zur Klärung unscharfer Anforderungen vor der Umsetzung.

Vorteil. Das Verfahren reduziert Missverständnisse zwischen Fachbereich und Entwicklung und schafft klare gemeinsame Erfolgskriterien von Anfang an.

Grenze. Es erfordert aktive, zeitliche Mitwirkung von Product Owner*in bzw. Fachbereich, die in der Praxis nicht immer verfügbar ist. ATDD funktioniert zudem nur, wenn Fachbereich, Entwicklung und Test tatsächlich gemeinsam an den Kriterien arbeiten; wird diese Zusammenarbeit nicht gelebt, verkommen die Akzeptanzkriterien zu nachträglicher Dokumentation ohne echten Nutzen.

Data-Driven Testing (DDT)

Bei DDT wird die Testlogik von den Testdaten getrennt: Derselbe Testablauf wird mit unterschiedlichen, extern gepflegten Datensätzen (z. B. aus CSV, Excel oder einer Datenbank) wiederholt ausgeführt. Ein Login-Test etwa durchläuft eine Tabelle aus 20 Kombinationen von Benutzername und Passwort (gültig, ungültig, leer, Sonderzeichen), ohne dass der Testcode für jede Kombination dupliziert werden muss.

Einsatz. Vor allem für Regressionstests mit vielen ähnlichen Eingabevarianten sowie für Validierungs- und Formulartests.

Vorteil. Hohe Abdeckung bei geringem Codeaufwand, und die klare Trennung von Logik und Daten erleichtert die Wartung.

Grenze. Umfangreiche Datentabellen werden selbst schnell unübersichtlich und pflegeaufwendig. Zudem prüft DDT primär die Variation von Eingaben, nicht die Ablauflogik selbst: Ist die Prüflogik fehlerhaft, schlägt sie bei allen Datensätzen gleichermaßen falsch oder richtig aus. Der Fehler in der Prüfung selbst bleibt unentdeckt.

Model-Based Testing (MBT)

Bei MBT werden Testfälle automatisiert aus einem formalen Modell des Systemverhaltens abgeleitet, etwa einem Zustandsautomaten, Aktivitätsdiagramm oder einer Entscheidungstabelle; ändert sich das Modell, lassen sich die Tests neu generieren. Ein Zustandsdiagramm eines Bestellprozesses (Warenkorb → Bezahlung → Versand → Abgeschlossen) wird dazu etwa in einem MBT-Werkzeug wie GraphWalker hinterlegt, welches daraus automatisch alle relevanten Pfade als Testfälle generiert, einschließlich Randfälle wie einem Abbruch vor der Bezahlung.

Einsatz. Für Systeme mit klar abgrenzbaren Zuständen oder Workflows, für sicherheitskritische oder regulierte Bereiche (z. B. Embedded, Automotive) sowie für Regressionstests bei häufig wechselnden Anforderungen.

Vorteil. Eine systematischere, lückenlosere Abdeckung möglicher Pfade als manuell erdachte Tests, und die Tests bleiben bei Modelländerungen konsistent.

Grenze. Ein hoher initialer Aufwand für die Modellerstellung, der spezialisiertes Werkzeug und Know-how erfordert. Die Testqualität hängt zudem vollständig von der Qualität des Modells ab: Ein unvollständiges oder von der Realität abweichendes Modell erzeugt entsprechend lückenhafte oder irreführende Tests, und bei häufig wechselnden Anforderungen wird die Modellpflege selbst zum Aufwandstreiber.

Keyword-Driven Testing (KDT)

Bei KDT werden Testabläufe aus wiederverwendbaren, benannten Aktionen („Keywords“ wie Login, KlickeButton, PrüfeText) zusammengesetzt, häufig in Tabellenform; ein Interpreter im Hintergrund übersetzt jedes Keyword in ausführbaren Code. Bekannte Umsetzungen sind etwa Robot Framework. Der Testfall „Bestellung aufgeben“ lässt sich so als Tabelle beschreiben: OeffneSeite(shop.de), Login(user1, pass1), FuegeZumWarenkorbHinzu(Artikel123), PrüfeWarenkorbAnzahl(1). Fachtester*innen können diese Tabelle ohne Programmierkenntnisse erstellen und pflegen.

Einsatz. Für Teams mit gemischten Kompetenzen, in denen Fachtester*innen ohne Programmierkenntnisse Testfälle erstellen sollen, sowie für Regressionssuiten mit wiederkehrenden Abläufen.

Vorteil. Die Einstiegshürde für nicht-technische Tester*innen ist niedrig, und die Keywords lassen sich gut wiederverwenden.

Grenze. Die Keyword-Bibliothek selbst ist Code und muss entsprechend gepflegt werden, und die Fehlersuche über mehrere Ebenen (Tabelle → Keyword → Code) ist aufwendiger. Bei schlecht gepflegter oder zu granularer Keyword-Bibliothek wächst der Pflegeaufwand schnell auf das Niveau von unstrukturiertem klassischem Testcode, und komplexe Logik mit Bedingungen oder Schleifen lässt sich in reinen Keyword-Tabellen nur eingeschränkt abbilden.

Property-Based Testing

Statt einzelner konkreter Beispiele wird bei Property-Based Testing eine allgemeine Eigenschaft („Property“) definiert, die für beliebige Eingaben gelten muss; ein Test-Framework generiert selbstständig eine große, oft zufällige Zahl an Eingaben, um diese Eigenschaft zu widerlegen. Für eine Sortierfunktion lässt sich so etwa die Eigenschaft definieren: „Für jede beliebige Liste gilt nach dem Sortieren, dass jedes Element kleiner oder gleich dem nächsten ist.“ Frameworks wie Hypothesis (Python) oder QuickCheck (Haskell) generieren dazu hunderte zufällige Listen und ermitteln bei einem Fehlschlag über „Shrinking“ die kleinstmögliche fehlschlagende Eingabe.

Einsatz. Für Algorithmen und Funktionen mit klar formulierbaren, strukturellen Eigenschaften, etwa Sortierung, Serialisierung/Deserialisierung oder Parser.

Vorteil. Deckt Randfälle auf, an die man manuell nicht denkt. Wenige Properties ersetzen so viele einzelne Beispieltests.

Grenze. Das Formulieren sinnvoller Properties erfordert Übung und ein anderes Denken als klassisches, beispielbasiertes Testen. Für rein fachliche oder UI-lastige Anforderungen ohne klar formulierbare Eigenschaft ist das Verfahren kaum anwendbar. Ist eine Property zu schwach formuliert, bleiben zudem fehlerhafte Implementierungen unentdeckt, obwohl der Test durchläuft.

Combinatorial/Pairwise Testing

Combinatorial Testing bzw. Pairwise Testing reduziert die Anzahl der Testfälle bei vielen Eingabeparametern mit mehreren möglichen Werten: Statt aller Kombinationen, deren Zahl exponentiell wächst, wird nur sichergestellt, dass jede paarweise (oder n-weise) Wertekombination mindestens einmal abgedeckt ist. Ein Formular mit vier Parametern (3 Browser, 3 Betriebssysteme, 4 Sprachen, 3 Zahlungsarten) hätte bei vollständiger Kombinatorik 108 Testfälle; ein Pairwise-Werkzeug wie PICT reduziert das auf rund 12 bis 15 Testfälle, die weiterhin jede Parameter-Paar-Kombination mindestens einmal abdecken.

Einsatz. Für Konfigurationstests über Browser-, Betriebssystem- oder Geräte-Matrizen sowie für Formulare mit vielen unabhängigen Eingabefeldern.

Vorteil. Reduziert den Testaufwand bei vielen Parameterkombinationen drastisch. Pairwise Testing zielt darauf ab, mit deutlich weniger Fällen einen großen Teil relevanter Interaktionen abzudecken.

Grenze. Fehler, die erst bei einer spezifischen Drei- oder Mehrfachkombination auftreten, können übersehen werden, da nicht alle Kombinationen abgedeckt sind. Zudem setzt das Verfahren voraus, dass die Parameter tatsächlich unabhängig voneinander sind: Bei starken Abhängigkeiten zwischen Parametern (manche Kombinationen sind fachlich gar nicht zulässig) muss die Parameterliste vorab bereinigt werden, sonst generiert das Werkzeug ungültige Kombinationen.

Fazit

Keines dieser Verfahren ist universell einsetzbar. TDD und BDD setzen auf der Ebene der Entwicklung an und wirken sich vor allem auf Design und Zusammenarbeit aus, DDT und Keyword-Driven Testing strukturieren die Ausführung bestehender Abläufe, MBT und Property-Based Testing leiten Testfälle aus einem formalen Modell bzw. einer Eigenschaft ab, und Pairwise Testing reduziert gezielt die Zahl der Testfälle bei vielen Parametern.

Die Wahl hängt vom jeweiligen Kontext ab: von der Art des Systems, der Testebene, der Zusammensetzung des Teams und davon, wie klar sich Anforderungen oder Eigenschaften im Vorfeld formulieren lassen. In der Praxis schließen sich die Verfahren nicht gegenseitig aus. Viele Projekte kombinieren etwa BDD auf Akzeptanztest-Ebene mit TDD auf Unit-Test-Ebene und setzen Pairwise Testing gezielt dort ein, wo die Zahl der Parameterkombinationen sonst nicht mehr handhabbar wäre.

Sie überlegen, wie viel Testtiefe Ihr Projekt tatsächlich braucht und wo sich welcher Ansatz lohnt? In einem unverbindlichen Austausch schauen wir uns das gemeinsam an.

Kontaktieren Sie uns unter: office@gruener-it.at