Synthetische Testdaten in 2026: geseedet, sicher, reproduzierbar

Synthetische Daten werden aus Regeln generiert, nicht von Personen abgegriffen. Ein Name aus einer Namensliste, eine Adresse aus einem Länder-Fixture, eine Telefonnummer aus einem reservierten Block, eine E-Mail auf einer reservierten Domain: Alles davon ist erzeugt, und nichts davon verweist auf ein reales Subjekt. Reproduzierbarkeit unterscheidet sie von zufälligem Rauschen, denn ungeseedete Ausgaben lassen sich weder prüfen noch diffen noch erneut abspielen.

Anonymisierte Produktionsdaten sind nicht synthetisch. Das Maskieren einer echten Zeile behält dieselbe Verteilung und oft dasselbe Re-Identifikationsrisiko, und eine maskierte EMAIL-Spalte, die die Domain behält, verrät weiterhin den Arbeitgeber. Wenn ein Test produktionsförmige Daten braucht, ist das ein separates Gespräch über Aggregation und Zugriff, nicht etwas, das ein Generator ehrlich liefern kann.

Eine eingecheckte Fixture-Datei hat einen Vorteil: Sie ist leicht zu inspizieren. Sie hat mehrere Probleme. Sie driftet, weil niemand sie aktualisiert, wenn sich das Schema ändert. Sie bläht das Repository auf. Sie wird zwischen Projekten kopiert, bis niemand mehr weiß, welche Version aktuell ist. Und sie wird stillschweigend zu den einzigen Daten, gegen die jemand testet, sodass die Suite genau die Werte abdeckt, die jemand 2021 eingetippt hat.

Geseedete Generierung hält die Eingabe winzig und die Ausgabe groß. Der Seed plus die Generatorversion ist das Fixture. Bei Bedarf neu generieren, nur den ersten und letzten Datensatz zur Prüfung als Snapshot sichern und jede Änderung der Generatorausgabe als bewusste Änderung behandeln, die eine neue Baseline erfordert. Die einzige Voraussetzung: Der Generator muss gepinnt sein, denn ein aktualisierter Generator mit geändertem Algorithmus ist selbst beim selben Seed ein neuer Datensatz.

Mehrere Standards reservieren Werte für Dokumentation und Tests. Sie zu verwenden ist keine Stilfrage; es ist der Unterschied zwischen einem Fixture, das garantiert harmlos ist, und einem, das jemandem gehören könnte. Die reservierten Blöcke sind stabil, breit dokumentiert und werden von den meisten Validatoren als syntaktisch normal akzeptiert.

Für E-Mail verwenden Sie eine Domain unter .test, etwa example.test, die reserviert und nicht registrierbar ist. Für Telefonnummern im North American Numbering Plan ist der Block 555-0100 bis 555-0199 für fiktive Nutzung reserviert. Für IP-Adressen sind die Dokumentationsbereiche 192.0.2.0/24, 198.51.100.0/24 und 203.0.113.0/24 in IPv4 sowie 2001:db8::/32 in IPv6. Für MAC-Adressen ist der Dokumentationsbereich 00-00-5E-00-53-00 bis 00-00-5E-00-53-FF, und lokal verwaltete Adressen mit gesetztem U/L-Bit sind ebenfalls sicher für Fixtures.

Die meisten Systeme brauchen mehr als eine Entität. Eine Bestellung hat einen Kunden, eine Lieferadresse und eine Rechnungsadresse, und die drei müssen in einer Weise übereinstimmen, die das Schema erzwingt. Wenn die Rechnungsadresse in den Vereinigten Staaten und die Lieferadresse in Japan liegt, müssen Steuerberechnung und Carrier-Auswahl diese Kombination akzeptieren, sonst schlägt der Test aus einem Grund fehl, der nichts mit dem getesteten Verhalten zu tun hat.

Generieren Sie Beziehungen, keine Zeilen. Leiten Sie Kind-Seeds vom Eltern-Seed ab, damit die Bestellung und ihre Adressen als Einheit reproduzierbar sind. Legen Sie bewusst fest, welche Felder übereinstimmen müssen: Das Land zwischen Liefer- und Rechnungsadresse ist meist gleich, die Postleitzahl muss zur Stadt im Fixture passen, die Währung muss zum Land passen. Kodieren Sie diese Einschränkungen in der Factory, damit ein defektes Fixture zur Generierungszeit fehlschlägt und nicht in einer Assertion drei Schichten tiefer.

Die Seite generiert keine Social Security Numbers, Zahlungskartennummern, IMEI- oder IMSI-Werte, Bluetooth-Geräteadressen oder Seriennummern. Jede Ablehnung hat einen Grund. SSNs sind in den Vereinigten Staaten rechtlich eingeschränkte Identifikatoren. Kartennummern tragen eine Luhn-Prüfsumme, sodass eine plausible Nummer einen naiven Validator bestehen und dann in ein Support-Ticket eingefügt werden kann. IMEIs haben eine Prüfziffer und ein Zuteilungsregister. Bluetooth-Adressen teilen das MAC-Format, tragen aber keine Herstellerbedeutung, und eine generierte Adresse lädt genau zu der Verwechslung ein, die die MAC-Tools vermeiden sollen.

Dieselbe Logik gilt für jeden Identifikator mit Prüfsumme oder Register. Wenn ein Test wirklich einen braucht, verwenden Sie die offiziell veröffentlichten Testwerte des Prozessors oder der ausstellenden Behörde, nicht einen Generator. So bleibt der Wert für jeden, der das Testmuster kennt, offensichtlich falsch, und Ihr Screenshot bleibt aus einem Compliance-Review heraus.

Hundert Datensätze zur Testzeit zu generieren ist günstig. Zehn Millionen nicht, und das im Test-Setup zu tun, dominiert die Laufzeit. Berechnen Sie große Volumen einmalig in einen isolierten Store vor, mit dem Seed im Manifest, und halten Sie den Generator aus dem Hot Path. Bei mittleren Volumen generieren Sie in einem einzigen Batch statt pro Zeile, denn das Setup pro Zeile ist meist der eigentliche Kostenfaktor.

Determinismus hat auch eine Performance-Dimension. Parallele Worker dürfen sich keinen einzelnen sequenziellen Generator teilen, denn die Verschachtelung ändert, welcher Worker welchen Datensatz bekommt. Geben Sie jedem Worker einen eigenen Seed, abgeleitet aus dem Run-Seed und dem Worker-Index, damit der Datensatz unabhängig von der Planung stabil ist. Das macht auch einen Fehler bei Worker drei reproduzierbar, ohne die ganze Suite erneut auszuführen.

Die Gefahr guter synthetischer Daten ist, dass sie echt aussehen. Setzen Sie auf jeden generierten Datensatz eine Markierung: ein Fixture-Flag, einen dedizierten Tenant, eine E-Mail auf example.test, eine Telefonnummer im Bereich 555-01xx. Blockieren Sie diese Datensätze für den Versand von E-Mails, die Erfassung von Zahlungen und den Eintritt in Analysen. Ein Demo-Kunde, der in ein Produktions-CRM gelangt, ist ein Support-Vorfall, der darauf wartet, dass ein Vertriebsmitarbeiter ihn bemerkt.

Halten Sie generierte Daten auch aus Logs heraus, die aus Compliance-Gründen aufbewahrt werden, und aus Screenshots, die veröffentlicht werden. Auch wenn die Werte niemanden beschreiben, kann ein Leser das dem Bild nicht ansehen, und es später zu erklären ist teurer, als es jetzt zu kennzeichnen. Wenn ein Screenshot eine realistische Adresse zeigen muss, verwenden Sie einen Wert aus dem Dokumentationsbereich und fügen Sie eine sichtbare Bildunterschrift „Beispieldaten“ hinzu.

Bevor ein generierter Datensatz in einer gemeinsam genutzten Umgebung verwendet wird, müssen vier Fragen beantwortet sein. Woher stammt er, und lässt er sich neu generieren? Liegt jeder Wert in einem reservierten oder lokal verwalteten Bereich? Erfüllt er die Schema-Einschränkungen und die referenziellen Regeln? Und ist er so gekennzeichnet, dass ein menschlicher Leser ihn nicht für einen Kunden halten kann?

Wenn eine Antwort Nein lautet, ist der Datensatz nicht bereit. Das ist bewusst streng, denn die Kosten einer falschen Antwort sind asymmetrisch: Neu generieren dauert Minuten, während ein synthetischer Kunde in einem Umsatzbericht Entscheidungen für ein Quartal verzerren kann. Führen Sie die Checkliste als Teil des Reviews aus, nicht als Kommentar in einem Wiki.