Datengetriebenes Testen trennt die Testlogik eines automatisierten Tests von seinen Testdaten: Ein Skript beschreibt den Ablauf einmal, eine Tabelle liefert die Datensätze, und jede Zeile läuft als eigener Testfall. So prüfen Sie dieselbe Überweisung mit 20 Beträgen, ohne 20 Skripte zu pflegen. Der Weg dorthin hat acht Schritte, vom stabilen Ablauf bis zum lesbaren Report. Grundlage sind das offizielle ISTQB-Glossar, der ISTQB-Lehrplan Test Automation Engineering v2.0, der GTB-Lehrplan Test Data Specialist und die Dokumentation von pytest, JUnit, TestNG und Playwright. Planung, Rollen und Bereitstellung der Daten behandelt der Leitfaden zum Testdatenmanagement.

Kurz gefasst: Datengetriebenes Testen (DDT) ist laut ISTQB ein Testautomatisierungsansatz, der Testdaten vom Testskript trennt. Sie automatisieren einen stabilen Ablauf einmal und speisen ihn aus einer Tabelle mit Eingaben und Soll-Ergebnissen, abgeleitet aus Äquivalenzklassen, Grenzwerten und Negativfällen. Belastbare Studien zur Einsparung gibt es bisher nicht; der Nutzen zeigt sich, wenn ein Ablauf viele Varianten hat.

Abbildung 1: Ein Skript beschreibt den Ablauf einmal, jede Tabellenzeile läuft als eigener Testfall

Was ist datengetriebenes Testen?

Datengetriebenes Testen (DDT) ist ein Testautomatisierungsansatz, der Testdaten vom Testskript trennt, damit dasselbe Skript wiederholt mit wechselnden Daten laufen kann. Das offizielle ISTQB-Glossar definiert DDT als „A test automation approach in which test data is separated from a test script to allow its repeated execution with various test data.“ (ISTQB Glossary, 2026) Der ISTQB-Lehrplan Test Automation Engineering v2.0 ordnet den Ansatz ein: „Data-driven testing (DDT) builds upon the structured scripting approach.“ (ISTQB CTAL-TAE v2.0, 2024)

Wie wird aus einem abstrakten Testfall eine Reihe von Testfallvarianten?

Ein abstrakter Testfall wird zur Reihe von Testfallvarianten, wenn Sie seine Parameter mit verschiedenen Werten aus dem erlaubten Wertebereich füllen; der GTB-Lehrplan Test Data Specialist beschreibt diese Logik. Ein abstrakter Testfall enthält Parameter als Platzhalter, konkrete Werte machen ihn zum konkreten Testfall. Dann heißt es: „Durch Einfügen verschiedener Werte innerhalb des erlaubten Wertebereichs eines Parameters wird aus einem einzelnen konkreten Testfall eine Reihe von Testfallvarianten.“ (GTB-Lehrplan Test Data Specialist (V1.1), 2021)

Eine Datentabelle schreibt genau diese Reihe auf. Jede Spalte ist ein Parameter, jede Zeile eine Testfallvariante. Ein sauber geschriebener Testfall mit Vorbedingungen und erwartetem Ergebnis zeigt sofort, welche Werte variieren dürfen und welche fest bleiben.

Wann lohnt sich datengetriebenes Testen?

DDT lohnt sich, sobald ein stabiler Ablauf mit vielen Wertekombinationen geprüft werden muss. Der ISTQB-Lehrplan TAE v2.0 nennt als Vorteil „Allows quick and easy test case expansion through data feeds“ und schreibt: „The cost of adding new automated tests can be significantly reduced“ (ISTQB CTAL-TAE v2.0, 2024).

Gute Kandidaten erkennen Sie an diesen Merkmalen:

• Gleiche Schritte, wechselnde Eingaben: Login mit verschiedenen Rollen, Gebührenberechnung, Pflichtfelder.

• Fachregeln mit Grenzen, etwa Überweisungslimiten, Altersgrenzen oder Zinsstufen.

• Varianten pro Land, Sprache oder Mandant im selben Prozess.

Braucht dagegen jede Zeile einen anderen Klickpfad, steckt Logik in Steuerspalten. Dann sind getrennte Tests klarer.

Wie viel Aufwand DDT spart, ist nicht belastbar gemessen. Ein Registered Report der MSR 2026 zu parametrisierten Tests (PTs) hält fest: „there is still no large-scale empirical evidence on how PTs are used within modern JUnit-based ecosystems.“ (MSR 2026, 2026) Die geplante Studie über mehr als 260 Apache-Java-Projekte hat noch keine Ergebnisse.

Wie setzen Sie datengetriebenes Testen Schritt für Schritt um?

Sie setzen DDT in acht Schritten um. Die Reihenfolge zählt. Jede Zeile erbt die Schwächen des Skripts, und ein wackliger Ablauf mit 20 Zeilen scheitert 20-mal.

Abbildung 2: Datengetriebenes Testen in acht Schritten

1. Stabilen Ablauf wählen. Nehmen Sie einen Ablauf, der heute schon zuverlässig automatisiert läuft, etwa Login oder Zahlungserfassung.

2. Parameter bestimmen. Markieren Sie jeden Wert, der variieren darf: Betrag, Währung, Rolle, Kontozustand. Alles andere bleibt fest im Skript.

3. Zeilen ableiten. Schreiben Sie eine Zeile je Äquivalenzklasse und je Grenzwert. Ergänzen Sie Negativfälle mit ungültigen Eingaben, etwa leere Pflichtfelder oder falsche Formate.

4. Soll-Daten eintragen. Jede Zeile enthält ihr erwartetes Ergebnis, etwa „gebucht“ oder die konkrete Fehlermeldung.

5. Quelle wählen. CSV für kleine, versionierte Tabellen, XLSX für den Fachbereich, JSON für verschachtelte Strukturen, Datenbank oder API für aktuelle Zustände.

6. Daten binden. Nutzen Sie den Mechanismus Ihres Frameworks (Tabelle unten) oder Variablen im Testwerkzeug.

7. Zeilen benennen. Jede Zeile bekommt eine ID, die im Report erscheint, etwa „UEB-05 Betrag über Tageslimit“.

8. Ausführen und auswerten. Prüfen Sie jede rote Zeile: Liegt der Fehler in der Anwendung, in den Daten oder im Soll-Wert?

Beispiel: Datentabelle für eine Überweisung mit Tageslimit

Schritte 3 und 4 für eine Inlandsüberweisung mit angenommenem Tageslimit von CHF 10’000 (Beispielwerte, keine reale Bankregel):

Die Spalte „Herkunft der Zeile“ braucht nur das Review: Sie verhindert, dass jemand eine Grenzwertzeile als Dublette löscht.

Welche Mechanismen bieten pytest, JUnit, TestNG und Playwright?

pytest, JUnit Jupiter (JUnit 5/6), TestNG und Playwright Test binden Datenzeilen über Decorator, Annotation, Data Provider oder Schleife (Zitate aus der offiziellen Dokumentation, Stand 2026).

Das Gegenstück zu allen vier Mechanismen sind Werte, die fest im Skript stehen (Hardcoding). Der TAE-Lehrplan v2.0 schreibt dazu: „It can be avoided by using data-driven testing, so the test data comes from a common source“ (ISTQB CTAL-TAE v2.0, §4.3.1, 2024).

Was unterscheidet datengetriebenes von schlüsselwortgetriebenem Testen und BDD?

DDT variiert Daten bei festen Schritten, schlüsselwortgetriebenes Testen (KDT) beschreibt die Schritte als Folge von Schlüsselwörtern, und BDD schreibt Akzeptanzkriterien im Given-When-Then-Format. Laut ISTQB-Glossar enthalten KDT-Testskripte „keywords and supporting files that contain scripts that implement those keywords“ (ISTQB Glossary, 2026).

Abbildung 3: DDT, KDT und BDD nach Kernidee und typischem Artefakt (ISTQB CTAL-TAE v2.0)

Welche Fehler machen datengetriebene Tests unzuverlässig?

Vier Fehler machen datengetriebene Tests unzuverlässig: zu viele Zeilen, unlesbare Testnamen, geteilte veränderliche Daten und Daten, die altern. Der TAE-Lehrplan v2.0 warnt: „Proper test data management may be necessary“ (ISTQB CTAL-TAE v2.0, 2024).

Abbildung 4: Vier Fehler, die datengetriebene Tests unzuverlässig machen

Zu viele Zeilen

Vollständige Kombinatorik wächst multiplikativ: Vier Parameter mit je fünf Werten ergeben 5 × 5 × 5 × 5 = 625 Zeilen. Die pflegt niemand. Meist reicht ein Repräsentant pro Äquivalenzklasse plus die Grenzwerte. Kombinationen prüfen Sie nur dort, wo Parameter fachlich zusammenhängen.

Unlesbare Testnamen

Ohne eigene IDs bauen Frameworks Testnamen aus den Werten. Die pytest-Dokumentation zeigt das selbst: „The test test_eval[1+7-8] passed, but the name is autogenerated and confusing.“ (pytest Docs, 2026) Abhilfe schaffen `pytest.param` mit eigener ID und in JUnit Jupiter das Attribut `name` mit `{index}` und `{arguments}`.

Geteilte, veränderliche Daten

Zwei Zeilen, die denselben Kunden verändern, beeinflussen sich, sobald Tests parallel oder in anderer Reihenfolge laufen. Die Selenium-Dokumentation braucht dafür fünf Wörter: „Do not share test data.“ (Selenium Docs, 2026) Wie Sie Daten pro Test trennen, zeigt die Checkliste zur Testdaten-Isolation.

Daten, die altern

Feste Datumswerte oder abgelaufene Tokens färben grüne Tests nach Wochen rot. Das DORA-Forschungsprogramm von Google (dora.dev) nennt als typischen Fehler „Relying on data that is out of date or no longer relevant.“ (dora.dev, 2026) Der GTB-Lehrplan nennt relative Werte, etwa „heute“ minus einen Tag. Frische Zustände erzeugen Sie per API oder Generator, die Verfahren vergleicht der Beitrag Testdaten generieren.

Wie unterstützt Autemos datengetriebene Tests?

In Autemos pflegen Sie Datenzeilen als Datasets und binden sie zur Laufzeit als Variablen an einen visuellen Test-Workflow. Autemos ist eine KI-gestützte Software für funktionale Testautomatisierung über Web, Mobile, API und Desktop. Autemos ist kein Werkzeug für Datenmaskierung oder Testdatengenerierung. Welche Zeilen in eine Tabelle gehören, entscheidet Ihr Team im Testdesign.

Datasets legen Sie in Autemos an oder importieren sie als CSV, XLSX oder JSON und verwenden sie in mehreren Workflows, laut Produktseite etwa für Login-Benutzer, Referenzdaten oder „einfache datengetriebene Tests“ (Test Data Handling). Externe Quellen wie REST-APIs, JSON-Dateien, Excel oder Datenbanken binden Sie pro Umgebung an (DEV, TEST, STAGING, PROD).

Die Abläufe bauen Sie per Drag and Drop in visuellen Test-Workflows, und Testanalysten ändern Zeilen ohne Code. Der TAE-Lehrplan beschreibt dieselbe Arbeitsteilung: „Test analysts can specify automated tests by populating one or more test data files that describe the tests“ (ISTQB CTAL-TAE v2.0, 2024).

Testingenieure ergänzen Codeblöcke oder binden bestehende Playwright-Tests ein, und Web-Tests exportiert Autemos als Playwright-Code in Java oder TypeScript, per Git synchronisiert und ohne Autemos lauffähig. One-Time Use markiert verbrauchte Voucher oder Tokens, damit parallele Läufe sie nicht doppelt erhalten.

Häufig gestellte Fragen

Ist parametrisiertes Testen dasselbe wie datengetriebenes Testen?

Parametrisierte Tests sind der Mechanismus im Framework, datengetriebenes Testen ist der Ansatz dahinter. `@pytest.mark.parametrize` oder `@ParameterizedTest` setzen die ISTQB-Idee auf Ebene einzelner Testfunktionen um. Bei UI- und API-Tests liegen die Daten meist außerhalb des Codes, etwa in CSV-Dateien.

Welche Datenquelle eignet sich für datengetriebene Tests?

CSV eignet sich für kleine, versionierte Tabellen, XLSX für Tabellen, die der Fachbereich pflegt, JSON für verschachtelte Strukturen und Datenbank oder API für Zustände, die aktuell sein müssen. Der ISTQB-Lehrplan TAE v2.0 nennt .csv- und .xlsx-Dateien und Datenbank-Dumps als Beispiele für Datenquellen von Testskripten.

Wie viele Datenzeilen braucht ein datengetriebener Test?

Für die Zeilenzahl eines datengetriebenen Tests gibt es keine feste Größe. Pro Äquivalenzklasse reicht meist ein Repräsentant, dazu kommen die Grenzwerte an jedem Rand und einige Negativfälle. Im Überweisungsbeispiel oben decken sieben Zeilen zwei Parameter ab. Vollständige Kreuzprodukte, bei vier Parametern mit fünf Werten 625 Zeilen, lohnen sich selten.

Gehört das erwartete Ergebnis in die Datentabelle?

Ja, jede Zeile sollte ihr erwartetes Ergebnis mitführen. Der GTB-Lehrplan Test Data Specialist führt Soll-Daten als eigene Testdatenart neben Eingabe-, Zustands- und Ausgabedaten. Ein Skript, das Soll-Werte selbst berechnet, wiederholt im Zweifel den Rechenfehler der Anwendung und meldet am Ende Grün.

Spart datengetriebenes Testen messbar Aufwand?

Belastbare Zahlen zur Einsparung durch datengetriebenes Testen gibt es bisher nicht. Der TAE-Lehrplan v2.0 sagt nur, die Kosten für neue automatisierte Tests könnten deutlich sinken. Ein Registered Report der MSR 2026 stellt fest, dass großflächige empirische Belege zu parametrisierten Tests fehlen. Messen Sie es selbst. Ein guter Wert ist die Zeit für eine neue Testvariante vor und nach der Umstellung.

Fazit

Datengetriebenes Testen lohnt sich dort, wo ein stabiler Ablauf viele fachliche Varianten hat. Der größte Teil der Arbeit ist Testdesign: Parameter bestimmen, Zeilen aus dem Testdesign ableiten und in jede Zeile ein Soll-Ergebnis schreiben. Für die Bindung reichen die Bordmittel von pytest, JUnit Jupiter, TestNG oder Playwright. Halten Sie Tabellen klein, geben Sie jeder Zeile einen lesbaren Namen und teilen Sie keine veränderlichen Datensätze zwischen Tests. Prozentversprechen zur Einsparung stützt bisher keine belastbare Studie. Prüfen Sie den Effekt am eigenen Testportfolio. Wenn Sie sehen möchten, wie Datasets und visuelle Workflows in Autemos mit Ihren Abläufen aussehen, sprechen Sie mit unserem Team.