Wer für Softwaretests Testdaten generieren will, hat vier Wege: handgeschriebene Fixtures, regelbasierte Generierung, statistische oder ML-basierte Synthese und die maskierte Produktionskopie. Für Bankanwendungen ist die regelbasierte Generierung aus dem Datenmodell oft der sicherere Standard. Die maskierte Kopie passt zu Migrationstests und zu Datenkonstellationen, die über Jahre gewachsen sind. ML-Synthese liefert realistische Verteilungen und ein Restrisiko: Laut NIST ist das Offenlegungsrisiko vollständig synthetischer Datensätze nicht null (NIST SP 800-188, 2023). Handgeschriebene Fixtures reichen für Komponententests mit wenigen Datensätzen. Welche Variante passt, hängt am Testziel.

Kurz gefasst: Synthetische Testdaten für Softwaretests entstehen am sichersten regelbasiert aus dem Datenmodell, mit festem Seed und fixierter Generator-Version. Maskierte Produktionskopien lohnen sich für Migrationen und historische Datenkonstellationen. ML-Synthese braucht eine eigene Datenschutzprüfung: Laut NIST haben vollständig synthetische Datensätze kein Offenlegungsrisiko von null (NIST SP 800-188, 2023).

Abbildung 1: Vier Wege, Testdaten zu generieren, nach Testziel (eigene Darstellung)

Was sind synthetische Testdaten?

Synthetische Testdaten sind künstlich erzeugte Testdaten für Softwaretests, die laut GTB-Lehrplan „keinerlei inhaltlichen Bezug zu Produktivdaten“ haben (GTB-Lehrplan Test Data Specialist V1.1, 2021). Sie entstehen aus Metadaten: Datenmodell, Wertebereiche, Formate und Geschäftsregeln. Laut Lehrplan werden sie „häufig in frühen Teststufen eingesetzt“.

Nach ihrer Herkunft stellt der GTB diesen Daten drei weitere Arten gegenüber: Produktivdaten, anonymisierte und pseudonymisierte Daten, dazu Mischformen. Praktisch heißt das: Entweder Sie erzeugen Daten neu, oder Sie verfremden einen Abzug aus der Produktion.

Regulatorisch sieht der GTB keine Hürde: „Bei richtiger Anwendung bestehen keine regulatorischen Hinderungsgründe für den Einsatz synthetischer Testdaten.“ Die Qualität hängt an den Metainformationen. Ein lückenhaftes Datenmodell liefert lückenhafte Daten. Wie die Herkunftsarten in den Gesamtprozess passen, beschreibt unser Überblick zum Testdatenmanagement.

Welche vier Wege gibt es, Testdaten zu generieren?

Vier Wege haben sich etabliert: handgeschriebene Fixtures, regelbasierte Generatoren, statistische oder ML-basierte Synthese und die maskierte Produktionskopie. Keiner gewinnt in allen Kriterien. Die Unterschiede zeigen sich bei Realismus, Datenschutzrisiko und der Frage, ob ein Testlauf morgen dieselben Daten sieht wie heute.

Abbildung 2: Vier Wege im Vergleich, Einschätzung auf Basis der Dokumentation, keine Messwerte

• Handgeschriebene Fixtures: Ein Tester legt wenige Datensätze von Hand an, meist als CSV oder JSON. NIST beschreibt Testdaten, die „syntactically valid but do not convey accurate information when analyzed“ sind, als geeignet für die Softwareentwicklung (NIST SP 800-188, 2023).

• Regelbasierte Generierung: Eine Bibliothek wie Faker erzeugt Werte nach Regeln. Mit der Locale `de_CH` liefert sie Adressen mit Kantonen, IBAN und AHV-Nummern (Faker-Dokumentation de_CH, 2026).

• Statistische oder ML-Synthese: Ein Modell lernt Verteilungen aus echten Daten und erzeugt neue Zeilen. Der HMA-Synthesizer von SDV (Synthetic Data Vault) modelliert laut Herstellerdokumentation jede Tabelle und ihre Verbindungen (SDV-Dokumentation, 2026).

• Maskierte Produktionskopie: Ein Abzug aus der Produktion mit verfremdeten personenbezogenen Feldern. Die Techniken behandelt der Beitrag zur Datenmaskierung für Testdaten.

Die Bewertungen in der Tabelle sind unsere Einschätzung auf Basis der verlinkten Dokumentation, keine Messwerte.

Wann ist eine maskierte Produktionskopie die bessere Wahl?

Eine maskierte Produktionskopie ist die bessere Wahl, wenn der Test echte Altbestände braucht: bei Datenmigrationen und bei historisch gewachsenen Konstellationen. Der GTB-Lehrplan nennt den Produktionsabzug „aus datenschutzrechtlichen Gründen problematisch, aber nicht zwangsweise unzulässig“ und führt ihn für Migrationstests an (§2.4.1, GTB-Lehrplan V1.1, 2021).

Unsere Begründung: Eine Migration muss mit den Daten zurechtkommen, die tatsächlich in der Altdatenbank liegen. Dazu gehören Formate früherer Systemversionen, leere Pflichtfelder aus der Zeit vor einer Prüfregel und Codes, die kein aktuelles Datenmodell mehr kennt.

Historische Konstellationen folgen derselben Logik. Beispiel: ein Kunde mit Konto seit 1987, drei Adresswechseln, einer abgelösten Hypothek und einer Vollmacht. Ein Generator erzeugt solche Kombinationen nur, wenn jemand sie vorher als Regel aufschreibt. Oft kennt sie im Team niemand mehr.

Die Kopie hat ihren Preis. Bei Teilabzügen nennt der GTB die „Beibehaltung der referentiellen Integrität“ als Herausforderung, Systemketten verlangen nach „einem einheitlichen Zeitstempel im Datenabzug“. Gegen veraltete Bestände helfen laut Lehrplan Datenalterung, Zeitreise oder gesetzte Umgebungszeit.

Für EU-Finanzunternehmen schreibt die delegierte Verordnung (EU) 2024/1774 zur EU-Verordnung DORA in Art. 16(5) vor, dass in Nichtproduktionsumgebungen „nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten gespeichert werden“ dürfen (EUR-Lex, 2024). Was das für DSGVO und Schweizer Datenschutzrecht heißt, erklärt der Beitrag zu DSGVO-konformen Testdaten.

Wie sicher sind synthetische Testdaten aus ML-Modellen?

Testdaten aus ML-Modellen tragen ein Restrisiko: NIST schreibt, dass vollständig synthetische Datensätze „do not have a zero-disclosure risk“ (NIST SP 800-188, 2023). Der Grund laut NIST: Sie enthalten Informationen aus nicht öffentlichen Daten. Ein Modell, das echte Kundendaten gesehen hat, kann Teile davon wiedergeben.

Abbildung 3: SDV HMA ist für rund 5 Tabellen ausgelegt, ein Bankmodell liegt darüber (SDV-Dokumentation 2026, NIST SP 800-188)

Stadler, Oprisanu und Troncoso (EPFL und UCL) zeigen, dass synthetische Daten entweder Inferenzangriffe nicht verhindern oder ihren Nutzwert verlieren. Ihr Fazit: Sie seien „far from the holy grail of privacy-preserving data publishing“ (Stadler et al., USENIX Security, 2022). Einen besseren Kompromiss als klassische Anonymisierung fanden sie nicht.

Dazu kommen praktische Grenzen. Laut Herstellerdokumentation ist der HMA-Synthesizer von SDV „optimized for smaller datasets with around 5 tables and 1 level of depth“ (SDV-Dokumentation, 2026). Ein Bankmodell mit Kunde, Konto, Vertrag, Buchung, Limite und Vollmacht liegt bereits darüber. Der SDV-Diagnosebericht prüft, ob kontinuierliche Werte im Min-/Max-Bereich der echten Daten bleiben (SDV-Diagnose, 2026). Grenzwerte knapp außerhalb dieses Bereichs schreiben Sie am sichersten als eigene Regel.

Unsere Folgerung für Banktests: Regelbasierte Generierung aus dem Datenmodell ist oft der sicherere Standard. NIST hält fest, dass realistische Testdaten, die nicht aus vertraulichen Daten entwickelt wurden, deren Inhalt nicht kompromittieren (NIST SP 800-188, §4.4.3, 2023). Ein Faker-Generator mit Regeln aus dem Datenmodell sieht nie einen echten Kunden.

Wie generieren Sie Testdaten in acht Schritten?

Reproduzierbare Testdaten generieren Sie in acht Schritten: vom Datenmodell über Grenzwerte, referentielle Integrität, Seed und Prüfung bis zur Bereitstellung pro Umgebung. Die Reihenfolge gilt für regelbasierte Generatoren.

Abbildung 4: Reproduzierbare Testdaten in acht Schritten (eigene Darstellung)

1. Datenmodell und Regeln erfassen. Halten Sie Tabellen, Felder, Wertebereiche, Pflichtfelder und Geschäftsregeln fest. Beispiel: Ein Konto gehört zu genau einem Kunden.

2. Grenz- und Negativwerte ableiten. Aus Äquivalenzklassen und Grenzwertanalyse entstehen gezielte Zeilen: Alter 17 und 18, Betrag 0,00 und -0,01, eine IBAN mit falscher Prüfziffer. Zufallswerte treffen solche Grenzen selten.

3. Referentielle Integrität über Tabellen und Systeme sichern. Erzeugen Sie zuerst Elterndatensätze, dann abhängige Zeilen. Gemeinsame Schlüssel, etwa die Kundennummer in CRM und Kernbankensystem, kommen aus einer Quelle.

4. Festen Seed setzen und Generator-Version fixieren. Laut Faker-Dokumentation gilt: „A Seed produces the same result when the same methods with the same version of faker are called.“ Fixieren Sie die Version „down to the patch number“ (Faker-Dokumentation, 2026).

5. Offensichtlich künstliche Namen verwenden. NIST empfiehlt „FIRSTNAME1 LASTNAME2“ statt „JOHN SMITH“, damit niemand Testdaten mit vertraulichen Daten verwechselt (NIST SP 800-188, 2023).

6. Gegen Geschäftsregeln prüfen. Ein automatischer Check stellt sicher, dass jedes Konto einen Kunden hat und Summen aufgehen. Kontrollieren Sie, ob Faker-IBAN und AHV-Nummern Ihre Prüfziffernlogik bestehen, wo der Test gültige Werte erwartet.

7. Generator-Konfiguration versionieren. Regeln, Seed und Versionsnummer liegen in Git neben den Tests. So lässt sich jeder alte Lauf mit denselben Daten wiederholen.

8. Pro Umgebung bereitstellen. DEV braucht andere Mengen und Zustände als STAGING. Wie Sie Umgebungen sauber trennen, beschreibt der Beitrag zur Testumgebung.

Die erzeugten Zeilen speisen danach datengetriebene Tests, bei denen ein Testfall nacheinander mit vielen Datensätzen läuft.

Wie messen Sie Datensparsamkeit mit dem Testdatenkoeffizienten?

Der Testdatenkoeffizient ist eine Kennzahl, die den Anteil der genutzten an den vorhandenen Testdaten angibt: Bei 100 GB vorhandenen und 20 GB genutzten Daten liegt er bei 20 % (GTB-Lehrplan V1.1, 2021). Der Lehrplan führt ihn als Messgröße für Datenminimierung.

Ein niedriger Wert heißt: Sie halten Daten vor, die kein Test braucht. Bei einer maskierten Vollkopie ist das der Normalfall, und jede ungenutzte Tabelle mit Personenbezug erhöht das Risiko. Generierte Daten erreichen nach unserer Einschätzung meist höhere Werte: Sie erzeugen nur, was ein Testfall anfordert. Messen Sie den Koeffizienten pro Umgebung und pro Release.

Welche Rolle spielt Autemos beim Generieren von Testdaten?

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. Es erzeugt selbst keine synthetischen Daten, maskiert keine Produktivdaten und erstellt keine Teilabzüge.

Autemos setzt dort an, wo fertige Testdaten in Testabläufe kommen. Sie verbinden externe Datenquellen: REST-APIs, JSON-Dateien, Excel, Datenbanken und die Datenquelle iSynth. Runtime-Bindings laden die Daten zur Laufzeit und stellen sie als Variablen bereit, etwa Kunden, Bestellungen oder Tokens.

Bindings legen Sie pro Umgebung fest (DEV, TEST, STAGING, PROD). Ein Faker-Datensatz für TEST und ein maskierter Abzug für STAGING hängen so am selben Testablauf. One-Time Use markiert verbrauchte Voucher oder Testbenutzer, damit parallele Läufe sie nicht doppelt erhalten. Details zeigt die Seite zum Test Data Handling in Autemos.

Häufig gestellte Fragen

Was unterscheidet synthetische Testdaten von anonymisierten Daten?

Synthetische Testdaten haben laut GTB-Lehrplan keinen inhaltlichen Bezug zu Produktivdaten, anonymisierte Daten stammen aus der Produktion und wurden verfremdet. Anonymisierte Daten tragen damit ein Reidentifikationsrisiko, wenn die Anonymisierung Lücken hat. Der GTB führt beide als eigene Herkunftsarten (GTB-Lehrplan V1.1, 2021).

Kann Faker Schweizer Testdaten erzeugen?

Ja, Faker bringt die Locale `de_CH` mit Providern für Adressen mit Kantonen und Postleitzahlen, Personen, Telefonnummern, Firmen, IBAN und AHV-Nummern mit (Faker-Dokumentation de_CH, 2026). Ob die Werte jede Prüfziffernregel bestehen, kontrollieren Sie im eigenen Prüfschritt. Für Negativtests ist eine ungültige Prüfziffer sogar erwünscht.

Warum liefert derselbe Seed plötzlich andere Testdaten?

Meist hat sich die Generator-Version geändert. Laut Faker-Dokumentation sind Ergebnisse „not guaranteed to be consistent across patch versions“ (Faker-Dokumentation, 2026). Fixieren Sie die Version bis zur Patch-Nummer und versionieren Sie Seed und Konfiguration im selben Repository wie die Tests.

Wann lohnt sich ML-Synthese mit Werkzeugen wie SDV?

ML-Synthese lohnt sich, wenn realistische Verteilungen wichtiger sind als Grenzfälle, etwa beim Test von Auswertungen auf kleinen Schemas. SDV beschreibt seinen HMA-Synthesizer als ausgelegt auf rund 5 Tabellen und eine Ebene Tiefe (SDV-Dokumentation, 2026). Planen Sie eine Datenschutzbewertung ein: Das Modell lernt aus Echtdaten.

Was ist eine Mischform aus anonymisierten und synthetischen Testdaten?

Eine Mischform kombiniert einen anonymisierten Produktionsbestand mit gezielt generierten Datensätzen. Der GTB-Lehrplan schreibt: „In der Praxis hat sich häufig eine Mischform aus anonymisierten Testdaten und synthetischen Testdaten bewährt.“ (GTB-Lehrplan V1.1, 2021) Typisch deckt der Abzug historische Konstellationen ab, der Generator ergänzt Grenzwerte und Negativfälle.

Fazit

Testdaten generieren beginnt mit dem Testziel. Für Grenzwerte, Negativfälle und wiederholbare Läufe in Banken sind regelbasierte Generatoren aus dem Datenmodell oft die sicherere Wahl: kein Produktivbezug, fester Seed, fixierte Version, versionierte Regeln. Die maskierte Produktionskopie behält ihren Platz bei Migrationen und historischen Konstellationen, mit Aufwand für referentielle Integrität und Freigabe. ML-Synthese liefert realistische Verteilungen und ein Restrisiko, das NIST und die Forschung klar benennen. Eine Mischform verbindet Abzug und Generator. Mit dem Testdatenkoeffizienten sehen Sie, ob Ihre Bestände schlanker werden. Wenn Sie sehen möchten, wie Autemos generierte oder maskierte Datensätze pro Umgebung an funktionale Testabläufe bindet, sprechen Sie mit unserem Team.