Synthetische Testdaten sind maschinell generierte Eingabedaten, die aus formalen Schemas wie XML- oder JSON-Schemas abgeleitet werden, ohne Produktivdaten zu verwenden. Sie erfüllen Datenschutzvorgaben, bilden komplexe Strukturen korrekt ab und decken systematisch Extremwerte sowie strukturelle Sonderfälle ab, um Fehler in Software zu finden, die manuell erstellte Testdaten übersehen würden.
Das Wichtigste in Kürze
- Synthetische Testdaten aus Schemas zu generieren löst zwei Kernprobleme gleichzeitig: komplexe Datenstrukturen lassen sich automatisiert erzeugen, und Datenschutzvorgaben nach DSGVO sind erfüllt, weil keine Produktivdaten benötigt werden.
- Bei jedem System, das bisher mit diesen generierten Testdaten geprüft wurde, wurden Fehler gefunden, weil nicht automatisiert getestete Software fast immer unentdeckte Defekte enthält.
- Gültige elektronische Rechnungen werden von verbreiteten Implementierungen wie Mustang als ungültig abgewiesen, zum Beispiel wegen nicht implementierter Rundungsfaktoren für bestimmte Währungen, was zu unbezahlten Rechnungen und unerwarteten Mahnungen führt.
- Neben reiner Datenmenge optimiert der Ansatz den Informationsgehalt pro Testdatenpaket: Extremwerte, leere Felder und strukturelle Varianten werden gezielt eingestreut, sodass bereits 1.000 Datensätze hohe Abdeckung erreichen können.
Warum Testdaten so oft zum Engpass werden
Testdaten sind eines der wiederkehrenden Probleme in Software-Projekten. Sie verursachen Aufwand, blockieren Pipelines und liefern am Ende oft nicht die Aussagekraft, die man sich von ihnen erhofft. Das hat zwei Hauptgründe.
Der erste Grund ist Komplexität. Wer ein System mit realistischen Eingaben testen will, muss Daten bauen, die einem oft hochkomplexen Format folgen. Ein Beispiel ist die elektronische Rechnung, die im B2B-Bereich schrittweise verpflichtend wird. Wer sich den zugrunde liegenden Standard ansieht, erkennt schnell, dass solche Datensätze manuell zu erzeugen extrem aufwendig ist.
Der zweite Grund ist Datenschutz. Eine Rechnung verweist auf Menschen, also auf personenbezogene Daten. Nach DSGVO lässt sich damit nicht ohne Weiteres testen. Die übliche Reaktion: Daten verfremden, Felder auf null setzen, Werte durch generische Platzhalter ersetzen, Datensätze durchmischen.
Genau hier entsteht ein Dilemma. Verfremdet man zu wenig, steht man rechtlich mit einem Bein im Gefängnis. Verfremdet man stark, findet man kaum noch neue Fehler, weil die Daten in ähnlicher Form schon einmal existierten. Daten, die nichts Neues enthalten, lösen auch kein neues Verhalten aus.
Synthetische Testdaten aus Schemas statt aus Produktivdaten
Ein alternativer Ansatz erzeugt Testdaten direkt aus Schemas, nicht aus Produktivdaten. Grundlage sind strukturierte Datenformate wie XML-Schemas, JSON-Schemas oder tabellarische Strukturen aus Datenbanken. Aus dieser Beschreibung lassen sich massenhaft Daten generieren, die korrekt aussehen und die nötige Integrität besitzen.
Der Vorteil liegt im Datenschutz. Wer nur die Beschreibung eines Formats braucht, braucht keine Produktivdaten. Damit ist der Prozess vollständig datenschutzkonform, weil keine echten personenbezogenen Daten im Spiel sind. Das unterscheidet diesen Weg von Verfahren, die KI-Modelle auf Produktivdaten trainieren.
Dieser Unterschied ist mehr als eine technische Feinheit. Trainiert ein Modell auf echten Daten, bleibt intransparent, was am Ende in die generierten Testdaten einfliesst, gerade bei grossem Umfang. Wer von vornherein keine Produktivdaten verarbeitet, kann diesen Fehler gar nicht machen.
Wir brauchen keine Produktivdaten, wir brauchen nur ein Schema. Deswegen können wir auch keinen Unfug treiben.
Dominic Steinhöfel
Wie aus einer Formatbeschreibung Testdaten werden
Im Kern wird ein Schema in ein formales Modell übersetzt, auf dem die Generierung stattfindet. Dieses Modell beschreibt die Syntax des Datenformats und zugleich alle Arten von Einschränkungen. Alles, was an Anforderungen dazukommt, wird in dieses Modell hineinprojiziert, und auf dem Modell wird dann gelöst.
Auf das reine Schema lassen sich zusätzliche Bedingungen draufsetzen. Ein Feld muss einen bestimmten Wert haben, ein Name eine Mindestlänge einhalten. Solche Vorgaben kann der Nutzer spezifizieren, und sie fliessen in die Generierung ein.
Für XML lassen sich auch komplexe Constraints über sogenannte Schematron-Regeln lösen. Ein konkretes Beispiel: Die einzelnen Posten einer Rechnung müssen sich zur korrekten Summe aufaddieren, inklusive Rundungsfaktor und Steuersatz. Solche Rechenbedingungen, Summen und Maxima lassen sich in gewissem Umfang auflösen.
Die Hürde liegt nicht in der Technik, sondern in der Bedienbarkeit. Schematron zu beherrschen ist anspruchsvoll, das lässt sich von normalen Anwendern nicht erwarten. Die offene Aufgabe besteht darin, die Lücke zwischen einer einfachen Anforderung wie “die IBAN soll gültig sein” und der dahinterliegenden formalen Regel zu schliessen. Aktuell übersetzen das noch Menschen im direkten Kontakt mit den Pilotpartnern in Post-Processing oder Schematron-Regeln.
Was eine gute Abdeckung bei Testdaten ausmacht
Masse allein macht keine guten Testdaten. Entscheidend ist, wie viel ein Datenpaket abdeckt. Deshalb wird getrackt, was bisher schon variiert wurde, um pro Datenpaket möglichst viel Information unterzubringen, statt blind tausende ähnliche Datensätze zu erzeugen.
Daraus lassen sich Abdeckungsgarantien ableiten. Eine Aussage kann lauten, dass alle strukturellen Feinheiten eines Formats getestet wurden, oder bei sehr grossen Formaten etwa 70 Prozent davon. Diese Messbarkeit hebt die Qualität der Testdaten über reines Mengen-Generieren hinaus.
Interessant ist die Praxiserfahrung mit der Menge. Nicht jeder will riesige Datenbestände, weil jede Eingabe durch die eigene Pipeline laufen und jede Ausgabe analysiert werden muss. Manche Teams nennen tausend Eingaben als ihr Maximum. Wer wenig generiert, aber dabei viel abtestet, spart sich die Auswertung von Bergen redundanter Daten.
Testmethodik: Zufall und Extremwerte gehören zusammen
Gute Testdaten mischen Zufall mit gezielten Extremwerten. Rein kontrollierte Daten übersehen Fehler, deshalb ist der Zufall eine Art Superpower. Gleichzeitig braucht es gezielte Grenzfälle, denn dort stecken oft die Bugs.
Für XML wurde dazu eine Domain-Analyse der primitiven Datentypen gemacht, um gezielt Extremwerte einzustreuen. Klassische Methoden der Grenzwertanalyse sind so abgedeckt: Felder, die bisher nicht leer waren, werden leer gesetzt, ein Fliesskomma-Wert, der noch nicht unendlich war, wird auf unendlich gesetzt.
Sicherheit ist Teil des Ansatzes, aber nicht der Kern. Innerhalb der Rahmenbedingungen eines Formats lassen sich in Stringfelder dokumentierte Angriffsmuster einbauen, etwa SQL-Injections oder XML-Attacken aus Katalogen wie denen der OWASP. Der Schwerpunkt liegt aber auf Robustheit: ein System gezielt zum Absturz bringen, damit das im Produktivbetrieb nicht passiert.
Damit besetzt der Ansatz eine eigene Nische zwischen zwei Polen. Er testet das, woran Entwickler nicht denken, und das, was Pentester nicht abdecken, weil diese gezielt nach ihren Hintertürchen suchen. Pentester und ihre Werkzeuge behalten ihre Berechtigung, der Rest dazwischen bleibt sonst oft ungetestet.
Warum jedes ungetestete System Fehler enthält
Eine pragmatische Faustregel: Wer mit synthetischen Testdaten gegen ein System antritt, das nie automatisiert getestet wurde, findet Fehler. In bisher allen getesteten Systemen wurden welche gefunden. Wenn keine Fehler auftauchen, ist die Software meist schlicht nicht interessant genug.
Das gilt selbst bei hohem Qualitätsanspruch. Ein Pilotpartner aus dem Telekommunikationsbereich testet ein XML-Protokoll für die Rufnummern-Mitnahme, das früher noch per Fax lief. Trotz eines Anspruchs weit über dem Üblichen tauchen Fälle auf, bei denen das Team feststellt, dass etwas nicht hätte passieren dürfen.
Elektronische Rechnungen: ein Praxisfall mit realem Schaden
Bei elektronischen Rechnungen zeigt sich, wie teuer schlecht getestete Verarbeitung wird. Getestet wurde unter anderem das öffentlich verfügbare Werkzeug Mustang aus dem Umfeld des ZUGFeRD-Formats, eines der beiden deutschen Formate für elektronische Rechnungen neben der X-Rechnung.
Die gefundenen Fehler reichen von kleinen Ungenauigkeiten bis zu Abstürzen oder dem Abweisen gültiger Rechnungen. Ein konkretes Beispiel: Bei Summen ist ein Rundungsfaktor von 0,05 zulässig. Für den ungarischen Forint liegt dieser Faktor deutlich höher, weil die Währung weniger wert ist. Genau das war nicht implementiert.
Die Folge ist ein realer Schaden im Geschäftsalltag. Eine gültige Rechnung aus Ungarn wird vom Empfängersystem ohne Rückmeldung fallen gelassen. Der Rechnungssteller bekommt sein Geld nicht rechtzeitig. Der Empfänger erhält stattdessen eine Mahnung und versteht nicht, warum, obwohl eigentlich alles funktioniert haben sollte.
Solche Fälle gewinnen an Brisanz, weil elektronische Rechnungen schrittweise zur Pflicht werden. Im B2B-Bereich wird das bis 2028 verbindlich. Wer Rechnungen verschickt oder empfängt, will mit so etwas keinen Stress haben. Der neue Prozess soll mindestens so zuverlässig funktionieren wie der alte.
Abhängigkeiten, Referenzen und Protokolle als nächste Stufe
Komplexe Testdaten brauchen mehr als isolierte Werte. Über die formale Modellierung lassen sich Schlüssel, Abhängigkeiten und Referenzen einkodieren. In XML gibt es etwa ID-Felder, die untereinander stimmig sein müssen, und genau solche Beziehungen lassen sich auflösen.
Eine eigene Schwierigkeit sind Protokolle. Hier bestehen Abhängigkeiten zwischen verschiedenen Paketen, was Protokolltesten zu einem anspruchsvollen Feld mit viel Forschung dahinter macht. Was als Nächstes umgesetzt wird, richtet sich nach dem konkreten Bedarf der Pilotpartner.
Die Bandbreite der Praxisfälle zeigt, wie unterschiedlich die Anforderungen sind. Getestet werden umfangreiche OpenAPI-Spezifikationen für Cloud-Dienste sowie das CAMT-Format aus dem Cash Management, zu dem auch SEPA-Überweisungen gehören, praktischerweise ebenfalls ein XML-Format.
Wenn in Daten mehr Logik steckt als gewollt
Ein heikler Punkt bleibt die Herausgabe von Schemas. Der Ansatz versteht sich als Test Data as a Service, bei dem das Schema vom Kunden kommen muss. Vertraulichkeit wird über NDAs geregelt, ein Betrieb der Lösung in der Inhouse-Infrastruktur des Kunden ist nicht vorgesehen.
Das Argument: Übertragen wird das Datenformat, also Struktur und Anforderungen, nicht die echten Daten, die meist die eigentlichen Geschäftsgeheimnisse enthalten. Für viele Fälle senkt das die Hürde deutlich.
Doch dieser Trennstrich ist nicht immer sauber zu ziehen. Gerade in gewachsenen Altsystemen steckt in der Datenstruktur manchmal mehr Logik, als einem lieb ist. Wer Schemas externalisiert, sollte vorab prüfen, wie viel fachliches Wissen die blosse Formatbeschreibung schon preisgibt.
