Antwort.

Das Management von Testdaten ist eines der ältesten Probleme der Automatisierung. Bereits zu Beginn der Automatisierung (Testskripte in Excel, Makros, alte QTP) wurden die Daten oft "im Kopf" des Testautors oder direkt im Code gespeichert. Mit der Entwicklung von CI/CD und parallelen Ausführungen waren neue Strategien erforderlich: Wie vermeidet man Rennbedingungen, wenn mehrere Tests gleichzeitig dieselben Daten verwenden, und gewährleistet die Wiederholbarkeit der Ergebnisse?

Problem: Gemeinsame (shared) Testdaten führen schnell zu Kollisionen und unvorhersehbaren Ergebnissen. Tests werden instabil, sind schwer zu debuggen, und Datenteile "verstopfen" Datenbanken, während parallele Ausführungen zu Fehlern (data race) führen.

Lösung — Einführung der Strategien "Daten pro Test" (Test Data Per Test):

Verwendung von einzigartigen oder parametrisierten Testdaten für jeden Test
Generierung/Bereinigung von Daten vor und nach dem Test (setup/teardown, Fixtures)
Trennung von Testumgebungen durch Namespaces, Tenants, Benutzer
Verwendung von In-Memory-Datenbanken mit Reinitialisierung pro Test

Wesentliche Merkmale:

Generierung einzigartiger Daten (UUID, Timestamp), automatische Löschung nach dem Test
Verwendung von Vorlagen und Fabriken für Testdaten (Test Data Factories)
Arbeiten mit isolierten Sandbox-Umgebungen

Fangfragen.

Ist es in Ordnung, Produktionsdaten als Testdaten zu verwenden?

Nein! Das ist riskant für die Sicherheit, Vertraulichkeit, und führt zu unvorhersehbaren Testergebnissen aufgrund der Variabilität der Daten.

Reicht es aus, setUp und tearDown zur Bereinigung von Daten zu verwenden?

Nicht immer. Sie helfen, Risiken zu minimieren, aber parallele Ausführungen können Tests zusammenstoßen, wenn die Daten global bleiben oder nicht einzigartig sind.

Kann man dieselben Testdaten in Smoke- und Regressionstests verwenden?

Besser nicht. Smoke-Tests sollten möglichst unabhängig sein, während Regressionstests eine umfassende Vorbereitung der Daten erfordern, anderenfalls sind fehlerhafte Auslösungen möglich.

Typische Fehler und Anti-Patterns

Verwendung gemeinsamer, "magischer" Daten, die zufällig für viele Tests passen
Nicht bereinigte Datenartefakte nach dem Test
Doppelte Verwendung derselben Datensätze in allen Tests

Beispiel aus der Praxis

Negativer Fall

In der Firma gab es einen gemeinsamen Login und mehrere "shared" Benutzer und Bestellungen, die in allen automatisierten Tests verwendet wurden. Parallele Ausführungen führten dazu, dass Tests Bestellungen gegenseitig überschrieben oder den Status einer Bestellung in mehreren Threads änderten.

Vorteile:

Schnell und einfach mit einer kleinen Anzahl von Tests umzusetzen
Keine zusätzliche Infrastruktur erforderlich

Nachteile:

Unklare Fehler, Schwierigkeiten bei der Fehlersuche
Tests können nicht sicher parallel oder in verschiedenen Umgebungen ausgeführt werden

Positiver Fall

Testdatenfabriken wurden implementiert: Vor dem Start jedes Tests wurde für jedes Szenario eine einzigartige Bestellung und ein Benutzer erstellt, der nach Abschluss des Tests gelöscht wurde, und die Sandbox-Umgebung wurde reinitialisiert.