Testdaten-Isolation heißt: Jeder automatisierte Test arbeitet mit Daten, die nur ihm gehören, und kein anderer Test oder Prozess verändert sie. Erst dann liefern Tests parallel, in beliebiger Reihenfolge und beim zehnten Lauf dasselbe Ergebnis wie beim ersten. Das DORA-Forschungsprogramm von Google (dora.dev) nennt isolierte Testdaten „a prerequisite for tests to run in parallel“ (dora.dev, Test data management, 2026). Wie oft es daran fehlt, zeigt eine Python-Studie: Abhängigkeiten von der Testreihenfolge verursachten 59 % von 7571 Flaky Tests (Gruber et al., 2021). Die Checkliste unten ergänzt den Leitfaden zum Testdatenmanagement um 12 Prüfpunkte.

Kurz gefasst: Isolierte Testdaten gehören genau einem Test oder einem Worker. Legen Sie Daten pro Lauf mit eindeutigen IDs über die APIs der Anwendung an, geben Sie Gutscheine und Tokens nur einmal aus und räumen Sie nur eigene Datensätze weg. Ob die Isolation hält, zeigt ein Vergleich der Suite mit einem und mit mehreren Workern.

Abbildung 1: Geteilte Daten machen Tests voneinander abhängig, eigene Daten pro Worker nicht.

Was ist Testdaten-Isolation?

Testdaten-Isolation ist eine Eigenschaft automatisierter Tests, bei der jeder Test eigene Daten besitzt, die kein anderer Test liest oder ändert. dora.dev verlangt, dass die Daten eines Tests ausdrücklich diesem Test zugeordnet sind und kein anderer Test oder Prozess sie verändert (dora.dev, 2026).

Testisolation ist der weitere Begriff. Playwright fordert für jeden Test eigenen Local Storage, Session Storage, eigene Daten und Cookies. Laut Dokumentation macht Isolation Tests reproduzierbar, erleichtert das Debugging und verhindert kaskadierende Fehlschläge (Playwright-Dokumentation, 2026). Den Browser trennt das Framework selbst. Datenbanken, Konten und Queues bleiben Ihre Aufgabe.

Der Grund steht bei dora.dev: Änderungen an Datenbankdaten bleiben über Tests hinweg bestehen. Wie Sie Tests auf Worker verteilen und wie viele Worker sinnvoll sind, behandelt der Beitrag zur parallelen Testausführung.

Warum brechen geteilte Testdaten parallele und wiederholte Testläufe?

Geteilte, veränderbare Testdaten machen das Ergebnis eines Tests davon abhängig, welcher andere Test dieselben Daten vorher oder gleichzeitig verändert hat. Oft zeigt sich der Fehler erst parallel, in zufälliger Reihenfolge oder im zweiten Lauf auf derselben Umgebung.

Abbildung 2: 19 von 161 untersuchten Korrekturen betrafen Test Order Dependency (Luo et al. 2014).

Polluter und Victim

Gruber et al. beschreiben das Muster mit zwei Rollen. Ein Polluter ist ein Test, der einen geteilten Zustand so ändert, dass ein anderer Test beim Lesen scheitert; dieser Test ist das Victim (Gruber et al., 2021). Beispiel: Test A storniert Bestellung 4711, Test B will sie bezahlen. Läuft B zuerst, sind beide grün. Läuft A zuerst, ist B rot.

Die zweite Variante ist der Brittle Test: Er braucht einen anderen Test, der ihm den gemeinsamen Zustand einrichtet, und scheitert allein gestartet. Typischer geteilter Zustand in funktionalen Testsuiten:

• Datenbankzeilen mit festen IDs, etwa Kunde 1001 oder Bestellung 4711

• ein gemeinsames Testkonto mit Warenkorb, Einstellungen oder Sperrstatus

• statische und globale Variablen im Testcode

• Queues, Caches, Postfächer und Dateien

• Einmal-Daten wie Gutscheincodes, Registrierungen und Tokens

Wie häufig sind Abhängigkeiten zwischen Tests?

Luo et al. untersuchten Korrekturen von Flaky Tests in 51 Open-Source-Projekten. 19 von 161 untersuchten Korrekturen (12 %) betrafen Test Order Dependency, nach Async Wait mit 74 (45 %) und Concurrency mit 32 (20 %) (Luo et al., 2014). Die Autoren halten fest, dass alle Tests einer Suite im Prinzip „properly isolated and independent of one another“ sein sollten.

In Python liegt das Gewicht anders: 59 % der 7571 Flaky Tests im Datensatz von Gruber et al. gingen auf die Reihenfolge zurück. Zhang et al. analysierten 96 reale abhängige Tests aus 5 Issue-Trackern; 59 davon (61 %) entstanden durch geteilte statische Variablen, 10 (10 %) durch Datenbankzugriffe (Zhang et al., 2014). Die Studien messen unterschiedlich, ihre Zahlen lassen sich nicht direkt vergleichen.

Parallele Tests laufen in Playwright in getrennten Worker-Prozessen und „cannot share any state or global variables“ (Playwright Parallelism, 2026). Das trennt statische Variablen zwischen Workern; Tests im selben Worker teilen sie weiter. Datenbankzeilen, Konten und Queues liegen außerhalb der Prozesse und bleiben geteilt.

Checkliste: 12 Prüfpunkte für Testdaten-Isolation

Die 12 Punkte prüfen, wem Testdaten gehören, wie sie entstehen, wie sie verbraucht werden und wer sie entfernt. Jeder Punkt lässt sich im Code-Review mit Ja oder Nein beantworten.

Abbildung 3: Die 12 Prüfpunkte für Testdaten-Isolation auf einen Blick.

1. Jeder Test besitzt seine Daten. Ein Test legt Kunden, Konten und Bestellungen selbst an und liest keine fremden Datensätze. Gemeinsame Stammdaten bleiben unverändert: Eine spätere Änderung der Seed-Daten kann laut Microsoft bestehende Tests brechen (Microsoft EF Core, 2026).

2. Eindeutige IDs enthalten Lauf-ID und Worker-Index. Ein Name wie `kunde-<lauf-id>-w3-0042` kollidiert weder mit dem Nachbar-Worker noch mit dem gestrigen Lauf. Playwright vergibt jedem Worker einen eindeutigen Index ab 0 (Playwright Parallelism, 2026), pytest-xdist eine `worker_id` wie „gw2“ (pytest-xdist, 2026).

3. Zustand entsteht im Setup über die APIs der Anwendung. dora.dev empfiehlt, dass Tests den nötigen Zustand im Setup selbst über die APIs der Anwendung anlegen. Die API durchläuft die Geschäftsregeln; ein direkter SQL-Insert umgeht sie.

4. Einmal-Daten werden nie ein zweites Mal ausgegeben. Gutscheincodes, Registrierungen, Einmal-Tokens und Bestätigungslinks sind nach dem ersten Test verbraucht. Der GTB-Lehrplan spricht vom „Verbrauch von Testdaten“ bei irreversiblen Konstellationen (GTB-Lehrplan Test Data Specialist (V1.1), 2021). Markieren Sie jeden Datensatz als verbraucht, bevor ein zweiter Test ihn erhält.

5. Jeder Worker hat ein eigenes Testkonto. Playwright trennt Benutzerdaten in der Datenbank über den Worker-Index zwischen Workern (Playwright Parallelism, 2026); pytest-xdist empfiehlt ein eigenes Konto pro Worker (pytest-xdist, 2026). Ändert ein Test Kontoeinstellungen, setzt er sie im Teardown zurück.

6. Transaktions-Rollback nur dort, wo er greift. EF Core beschreibt, den Test in eine Transaktion zu packen und am Ende zurückzurollen. Nutzt der getestete Code eigene Transaktionen, klappt das nicht: Ohne verschachtelte Transaktionen müssen Sie aufräumen und die Parallelisierung abschalten (Microsoft EF Core, 2026).

7. Schreibende Tests bekommen ein Schema oder eine Datenbank pro Worker. Microsoft rät, Tests mit Schreibzugriff über mehrere Datenbanken zu parallelisieren. Das pytest-xdist-Beispiel zu `testrun_uid` legt pro Testlauf eine eigene Datenbank an. Der Preis ist Setup- und Migrationszeit.

8. Externe Ressourcen sind getrennt. Queues, Cache-Schlüssel, Postfachadressen und Dateipfade tragen die Lauf-ID oder liegen in eigenen Instanzen. Was sich nicht trennen lässt, bekommt eine Sperre, etwa JUnit `@ResourceLock` für geteilte Ressourcen mit synchronisiertem Zugriff (JUnit, 2026).

9. Cleanup löscht nur eigene Daten, ein Job entfernt Waisen. Der Teardown löscht nach Lauf-ID, nie per `TRUNCATE` auf einer geteilten Umgebung. Abgebrochene Läufe hinterlassen Datensätze; ein geplanter Job löscht Lauf-IDs, die älter als ein Tag sind. Der GTB-Lehrplan zählt die „Löschung nicht mehr benötigter Datenbestände“ zum TDM in der Testautomatisierung.

10. Kein Test setzt eine Reihenfolge voraus. Playwright garantiert keine Reihenfolge der Testausführung über Dateien hinweg. Laut Martin Fowler lassen sich sauber isolierte Tests in jeder Reihenfolge ausführen (Martin Fowler, 2011). Lassen Sie die Suite regelmäßig in zufälliger Reihenfolge laufen.

11. Testdaten sind pro Umgebung getrennt. Eine ID aus TEST existiert auf STAGING oft nicht. Der GTB-Lehrplan nennt Testdaten „unauflöslich mit den Testumgebungen … verbunden“. Binden Sie Datensätze an die Umgebung; feste IDs gehören nicht in den Testcode.

12. Die Isolation wird mit einem und mit N Workern geprüft. Lassen Sie die Suite einmal mit einem Worker laufen (bei pytest-xdist `-n0`) und einmal mit mehreren. Weichen die Ergebnisse ab, teilen Tests Zustand. Den Kontrolllauf hängen Sie als nächtlichen Job an Ihre CI/CD-Pipeline.

Welche Isolationsstrategie passt zu welchem Test?

Eindeutige Daten pro Test funktionieren auf jeder Teststufe; Rollback, Datenbank pro Worker und Sperren haben jeweils eine klare Grenze.

Abbildung 4: Sechs Isolationsstrategien, wofür sie passen und wo ihre Grenze liegt.

Für UI- und E2E-Tests ist ein leerer Ausgangszustand laut Fowler viel schwerer herzustellen als bei Unit-Tests (Martin Fowler, 2011). Dort tragen eindeutige Daten, Konten pro Worker und ein Cleanup nach Lauf-ID die Hauptlast.

Warum verdecken Reruns fehlende Testisolation?

Automatische Reruns machen einen datenabhängigen Test im zweiten Versuch oft grün, und der geteilte Zustand bleibt bestehen. Gruber et al. rechnen vor: Für 95 % Sicherheit, dass ein bestandener Test nicht flaky ist, wären im Schnitt 170 Wiederholungen nötig (Gruber et al., 2021). Bei Google zeigten rund 1,5 % aller Testläufe ein Flaky-Ergebnis (Google Testing Blog, 2016).

Nutzen Sie Reruns als Messpunkt: Jeder Test, der erst im zweiten Versuch besteht, kommt auf eine Liste und wird mit Prüfpunkt 12 untersucht. Rote Tests nach geänderten Selektoren haben eine andere Ursache; dafür sind Self-Healing-Locators gedacht, die an Datenkonflikten nichts ändern.

Wie unterstützt Autemos Testdaten-Isolation, und wo nicht?

Autemos unterstützt einen Teil der Checkliste: Es gibt Einmal-Daten nur einmal aus (Prüfpunkt 4), ordnet Daten einem Lauf, Projekt oder Mandanten zu und bindet sie pro Umgebung (Prüfpunkt 11). 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.

Die Produktseite beschreibt das Problem so: „Verbrauchte Voucher, doppelte Benutzer, abgelaufene Tokens oder leere Datasets führen zu Fehlern, die nichts mit der Applikation zu tun haben.“ (Autemos Test Data Handling)

• One-Time Use: Verbrauchte Gutscheine, Registrierungen, Tokens und Testbenutzer werden automatisch markiert und kein zweites Mal ausgegeben, gedacht für parallele Läufe.

• Scopes RUN, PROJECT und TENANT: Sie legen fest, ob ein Datensatz pro Lauf, pro Projekt oder pro Mandant gilt.

• Bindings pro Umgebung: Datensätze hängen an DEV, TEST, STAGING oder PROD.

• Runtime Bindings: Kunden, Bestellungen, Benutzer oder Tokens werden zur Laufzeit aus REST-APIs, JSON-Dateien, Excel oder Datenbanken geladen und als Variablen bereitgestellt.

Datasets lassen sich in mehreren Workflows wiederverwenden; das Prinzip erklärt der Beitrag zum datengetriebenen Testen. Autemos rollt keine Datenbanken zurück und legt keine Schemas oder Datenbanken pro Worker an. Die Prüfpunkte 6 und 7 bleiben Aufgabe Ihrer Datenbank- und Pipeline-Konfiguration.

Häufig gestellte Fragen

Was unterscheidet Testisolation von Testdaten-Isolation?

Testisolation umfasst den gesamten Zustand eines Tests, von Cookies bis zu globalen Variablen; Testdaten-Isolation betrifft Daten in Datenbanken, Konten und externen Systemen. Datenbankänderungen bleiben laut dora.dev über Tests hinweg bestehen, bis jemand sie zurücksetzt.

Reicht ein Transaktions-Rollback für E2E-Tests?

Meist nicht: In E2E-Tests schreibt die Anwendung über eigene Datenbankverbindungen, die der Rollback des Tests nicht erfasst. Für E2E-Tests passen eindeutige Daten mit Cleanup nach Lauf-ID besser.

Wie viele Testkonten brauchen parallele Tests?

Parallele Tests brauchen mindestens ein Testkonto pro Worker. Das Playwright-Beispiel bindet einen Benutzer an den Worker-Index, und alle Tests dieses Workers nutzen ihn. Ändert ein Test den Kontozustand dauerhaft, etwa durch eine Sperre, braucht er ein eigenes Konto.

Darf ich für isolierte Testdaten einen Produktionsabzug nutzen?

Für Isolation brauchen Sie keinen vollständigen Produktionsabzug, und er bringt Risiken. dora.dev zählt eine vollständige Kopie der Produktionsdatenbank zu den typischen Fehlern und warnt, dass kopierte Produktivdaten sensible Informationen enthalten können (dora.dev, 2026). Sind Produktivdaten nötig, beschreibt der Beitrag zur Datenmaskierung die Verfahren.

Wie finde ich den Test, der einen anderen stört?

Starten Sie den roten Test zusammen mit je einem der Tests, die vor ihm liefen. Laut Zhang et al. lassen sich mindestens 82 % der abhängigen Tests mit höchstens zwei Tests aufdecken (Zhang et al., 2014). Ist der Polluter gefunden, geben Sie dem Victim eigene Daten.

Fazit

Isolierte Testdaten machen parallele und wiederholte Testläufe reproduzierbar. Die Studien zeigen das Ausmaß: 19 von 161 untersuchten Korrekturen bei Luo et al., 59 % der 7571 Python-Flaky-Tests im Datensatz von Gruber et al. Die Gegenmittel sind einfach. Jeder Test legt eigene Daten mit Lauf-ID und Worker-Index an, Einmal-Daten werden nur einmal ausgegeben, und der Cleanup löscht nur eigene Datensätze. Rollback und eine Datenbank pro Worker helfen dort, wo der Test die Datenbank kontrolliert.

Beginnen Sie mit Prüfpunkt 12: ein Lauf mit einem Worker, ein Lauf mit mehreren. Jede Abweichung zeigt geteilten Zustand, den Sie jetzt beheben können. Wenn Sie Einmal-Daten, Scopes und Umgebungsbindungen an Ihren eigenen Testworkflows durchspielen möchten, sprechen Sie mit dem Autemos-Team.