Testdaten gezielt verkleinern - Teil 3
Database Subsetting & vollautomatisiertes Test Data Management
Große produktive Datenbanken vollständig in Testumgebungen zu kopieren, ist teuer, langsam und aus Datenschutzsicht riskant. Nach synthetischer Testdatengenerierung und Datenmaskierung geht es um Database Subsetting. Dabei werden aus umfangreichen Datenbeständen kleinere, fachlich sinnvolle und referenziell konsistente Ausschnitte erzeugt.
- Warum vollständige Datenbankkopien problematisch sind
- Grundlagen des Database Subsetting
- Strategien für sinnvolle Datenbankausschnitte
- Referenzielle Integrität als zentrale Voraussetzung
- Subsetting und Maskierung kombinieren
- Vollautomatisiertes Test Data Management
- Praxisbeispiel: Ein referenziell konsistentes Subset erzeugen
- Fazit
- Quellen
Überblick über die Artikelserie
Teil 1: Synthetische Testdaten richtig erzeugen – Grundlagen & Use Cases
Teil 2: Datenschutz & Maskierung in Testumgebungen
Teil 3: Database Subsetting & vollautomatisiertes Test Data Management
Die ersten beiden Teile dieser Artikelserie haben zwei grundlegende Strategien des modernen Testdatenmanagements betrachtet. Teil 1 zeigte, wie synthetische Testdaten vollständig neu erzeugt werden können, um realistische Datenbestände ohne Bezug zu produktiven Informationen bereitzustellen. Teil 2 stellte die Datenmaskierung in den Mittelpunkt und erläuterte, wie sensible Inhalte in produktionsnahen Daten so verändert werden können, dass Datenschutzanforderungen eingehalten und gleichzeitig fachliche Zusammenhänge erhalten bleiben.
In der Praxis reicht jedoch keine dieser Strategien allein aus, um alle Anforderungen moderner Entwicklungs- und Testumgebungen abzudecken. Viele Unternehmen verfügen über sehr große produktive Datenbanken, die über Jahre gewachsen sind und sehr viele Datensätze enthalten. Diese Datenbestände vollständig in Entwicklungs-, Integrations-, Schulungs- oder Abnahmesysteme zu kopieren, ist meist weder wirtschaftlich noch organisatorisch sinnvoll. Der Speicherbedarf ist hoch, die Bereitstellung dauert lange, Aktualisierungen sind aufwendig und die Angriffsfläche für sensible Informationen steigt erheblich. Genau hier setzt Database Subsetting an. Statt eine vollständige Datenbank zu duplizieren, wird ein gezielter Ausschnitt erzeugt. Dieser Ausschnitt ist deutlich kleiner, bildet aber weiterhin die relevanten fachlichen Zusammenhänge ab. Entscheidend ist dabei, dass die referenzielle Integrität erhalten bleibt. Wird beispielsweise eine Auswahl von Kunden übernommen, müssen die zugehörigen Aufträge, Rechnungen, Positionen, Zahlungen oder Servicefälle konsistent mitgeführt werden. Nur dann verhält sich die Testdatenbank fachlich wie das Originalsystem.
Database Subsetting ist ein kontrollierter Extraktionsprozess, bei dem Datenvolumen reduziert, fachliche Relevanz erhalten und Datenschutzmaßnahmen integriert werden. Moderne Plattformen wie IRI Voracity stellen hierfür Werkzeuge wie Subsetting, Maskierung, synthetische Datengenerierung und Automatisierung bereit.
Warum vollständige Datenbankkopien problematisch sind
In vielen Unternehmen war es lange üblich, produktive Datenbanken regelmäßig in Test- oder Entwicklungsumgebungen zu kopieren. Dieser Ansatz erscheint zunächst naheliegend: Die Daten sind real, vollständig und bilden alle fachlichen Sonderfälle ab. Entwickler und Tester erhalten dadurch eine Umgebung, die dem Produktivsystem sehr ähnlich ist. Bei kleinen oder isolierten Anwendungen kann dieses Vorgehen kurzfristig funktionieren. In großen Systemlandschaften entstehen jedoch schnell gravierende Nachteile. Produktive Datenbanken können enorme Größen erreichen. Werden sie vollständig in mehrere Nicht-Produktivumgebungen kopiert, vervielfacht sich der Speicherbedarf. Große Datenbankkopien lassen sich nicht beliebig oft aktualisieren. Wenn die Bereitstellung einer Testumgebung mehrere Stunden oder sogar Tage dauert, passt dieser Prozess nicht mehr zu agilen Entwicklungsmodellen, Continuous Integration oder automatisierten Regressionstests. Testdaten werden dadurch zu einem Engpass. Teams arbeiten mit veralteten Datenständen, Tests lassen sich schwer reproduzieren und Fehleranalysen werden aufwendig. Der wichtigste Nachteil betrifft den Datenschutz. Vollständige Datenbankkopien enthalten häufig personenbezogene Informationen, Geschäftsgeheimnisse usw. Je häufiger solche Kopien erzeugt und verteilt werden, desto größer wird das Risiko unkontrollierter Zugriffe. Selbst wenn Maskierung eingesetzt wird, bleibt die Frage, ob wirklich alle sensiblen Inhalte erkannt und korrekt transformiert wurden.
Grundlagen des Database Subsetting
Database Subsetting bezeichnet die Erzeugung eines kleineren, verwaltbaren und dennoch fachlich vollständigen Ausschnitts aus einer größeren Datenbank. Ziel ist es, nur die Datensätze zu übernehmen, die für einen bestimmten Test-, Entwicklungs- oder Schulungszweck benötigt werden. Der resultierende Datenbestand soll kleiner sein als das Original, aber weiterhin die relevanten Beziehungen, Datenverteilungen und Geschäftsregeln abbilden. Beim Database Subsetting beginnt man daher mit der Master-Tabelle. Von dort aus werden die abhängigen Datensätze entlang der Fremdschlüsselbeziehungen ermittelt. Wählt man beispielsweise eine definierte Menge von Kunden aus, werden alle zugehörigen Bestellungen, Positionen, Rechnungen und Zahlungen mitgeführt. Ebenso können übergeordnete Stammdaten wie Produkte, Regionen oder Tarife ergänzt werden, sofern sie für die Konsistenz erforderlich sind. Database Subsetting hat drei Ziele: Reduktion, Konsistenz und Relevanz. Reduktion bedeutet, dass das Datenvolumen deutlich kleiner wird. Konsistenz bedeutet, dass Primär- und Fremdschlüsselbeziehungen erhalten bleiben. Relevanz bedeutet, dass der Ausschnitt zum Testziel passt.
Strategien für sinnvolle Datenbankausschnitte
Die Auswahl geeigneter Daten kann nach unterschiedlichen Strategien erfolgen. Eine einfache Variante ist das prozentuale Subsetting. Dabei wird ein bestimmter Anteil der Daten übernommen, beispielsweise fünf oder zehn Prozent einer Tabelle. Diese Strategie eignet sich für erste Entwicklungs- und Funktionstests, wenn eine kleinere, aber grundsätzlich realistische Datenmenge benötigt wird. Sie ist einfach zu erklären und gut automatisierbar, liefert aber nicht immer fachlich repräsentative Ergebnisse. Seltene Fälle können verloren gehen, während häufige Standardfälle dominieren. Eine zweite Strategie ist das regelbasierte Subsetting. Hier werden fachliche Kriterien definiert, etwa alle Kunden eines bestimmten Landes, alle Aufträge eines Jahres usw. Dieser Ansatz ist nützlich, wenn konkrete Testziele verfolgt werden. Soll beispielsweise eine neue Abrechnungslogik getestet werden, kann ein Subset genau die Verträge enthalten, die für diese Logik relevant sind. Regelbasiertes Subsetting ist meist aussagekräftiger als eine reine Zufallsauswahl, erfordert aber ein gutes Verständnis des Datenmodells und der Fachprozesse. Eine dritte Strategie ist das szenariobasierte Subsetting. Dabei werden Datenbestände gezielt entlang fachlicher Prozessketten zusammengestellt. Ein Szenario kann beispielsweise aus Neukundenanlage, Bestellung, Lieferung, Rechnung, Zahlung und Reklamation bestehen. Für Tests werden dann genau jene Datensätze extrahiert, die diese Prozesskette vollständig abbilden. Eine vierte Strategie ist das risikoorientierte Subsetting. Hier werden gezielt Datenbereiche ausgewählt, die in der Vergangenheit fehleranfällig waren oder besonders kritisch sind. Dazu gehören beispielsweise Sonderrabatte, internationale Steuersätze, alte Vertragsmodelle, Migrationseffekte oder seltene Statuskombinationen. Diese Strategie erhöht die Testabdeckung, weil sie nicht nur typische Fälle berücksichtigt, sondern bewusst komplexe Randbedingungen einbezieht.
Moderne Subsetting-Werkzeuge unterstützen diese Strategien über grafische Assistenten, SQL-Filter, Regeldefinitionen oder Skripte. In der IRI Workbench können Größe, Inhalt und Sortierung eines Subsets festgelegt sowie Maskierungs- oder Transformationsregeln auf Zieltabellen angewendet werden.
Referenzielle Integrität als zentrale Voraussetzung
Relationale Datenbanken bestehen nicht aus isolierten Tabellen, sondern aus einem Netz von Abhängigkeiten (Primärschlüssel, Fremdschlüssel, Constraints, Indizes, fachliche Regeln). Ein Subset ist nur dann brauchbar, wenn diese Beziehungen im verkleinerten Datenbestand weiterhin gültig sind. Wird ein Datensatz entfernt, können an vielen Stellen verwaiste Beziehungen entstehen. Eine Testdatenbank mit solchen Inkonsistenzen führt zu Fehlern, die nicht aus der Anwendung, sondern aus den fehlerhaften Testdaten resultieren. Ein Subsetting-Verfahren muss daher die Beziehungsstruktur des Datenmodells analysieren. Es muss erkennen, welche Tabellen voneinander abhängen, in welcher Reihenfolge Daten extrahiert werden müssen und welche Stammdaten zusätzlich erforderlich sind. Häufig ist auch die Laderichtung relevant: Beim Aufbau der Zielumgebung müssen Eltern-Tabellen vor Kind-Tabellen geladen werden, damit Fremdschlüsselprüfungen nicht fehlschlagen.
Neben technischen Fremdschlüsseln existieren in vielen Anwendungen auch implizite fachliche Beziehungen. Nicht jede Abhängigkeit ist sauber im Datenbankschema modelliert. Manche Beziehungen entstehen über Codes, zusammengesetzte Schlüssel, Konfigurationswerte oder Anwendungslogik. Ein Subsetting-Prozess sollte deshalb auch fachliche Regeln einbeziehen können. IRI adressiert diese Herausforderung durch einen Wizard-Ansatz in der Workbench, bei dem ausgehend von einer Parent-Tabelle referenziell korrekte Child-Tabellen erzeugt und gleichzeitig Maskierungs- oder Mapping-Regeln angewendet werden können.
Subsetting und Maskierung kombinieren
Database Subsetting reduziert zwar die Menge produktiver Daten, beseitigt aber nicht automatisch deren Schutzbedarf. Auch ein kleiner Ausschnitt kann personenbezogene oder geschäftskritische Informationen enthalten. Deshalb sollte Subsetting in den meisten Fällen mit Datenmaskierung kombiniert werden.
Zunächst wird definiert, welche Daten für das Subset benötigt werden. Anschließend werden sensible Felder identifiziert und mit Maskierungsregeln versehen. Bei der Extraktion werden die Daten dann nicht nur verkleinert, sondern zugleich transformiert. Namen, E-Mail-Adressen, Telefonnummern, Kontodaten, Identifikatoren oder Freitextfelder können ersetzt, verschlüsselt, pseudonymisiert oder entfernt werden. Entscheidend ist auch hier die Konsistenz. Wird eine Kundennummer maskiert, muss derselbe Ersatzwert in allen abhängigen Tabellen erscheinen. Für Tests ist es nicht ausreichend, sensible Daten unkenntlich zu machen. Die maskierten Daten müssen sich weiterhin plausibel verhalten.
Ein Beispiel: In einer Bankanwendung soll ein Subset aller Kreditverträge eines bestimmten Produkttyps erzeugt werden. Die Daten enthalten Kunden, Verträge, Ratenpläne, Sicherheiten, Zahlungsverläufe und Mahnstatus. Für Entwicklung und Test sind diese Zusammenhänge fachlich wichtig. Gleichzeitig dürfen echte Namen, Kontonummern und Adressen nicht sichtbar sein. Ein kombinierter Subsetting- und Maskierungsprozess extrahiert daher nur die relevanten Kreditfälle, erhält alle Beziehungen und transformiert sensible Attribute in plausible Ersatzwerte.
Die IRI-Lösung unterstützt diese Kopplung, indem Maskierungsregeln innerhalb von Subsetting-Jobs angewendet werden können. Dabei können FieldShield-Funktionen wie Verschlüsselung oder Pseudonymisierung über die extrahierten Daten hinweg genutzt werden.
Vollautomatisiertes Test Data Management
Vollautomatisiertes Test Data Management bedeutet, dass Testdatenprozesse standardisiert, versioniert und in technische Abläufe eingebettet werden. Dazu gehören die Erzeugung synthetischer Daten, die Maskierung produktionsnaher Daten, das Subsetting großer Datenbanken, die Bereitstellung in Zielsystemen und die regelmäßige Aktualisierung. Diese Schritte sollten nicht jedes Mal neu manuell ausgeführt werden, sondern über Skripte, Jobs, Pipelines oder Self-Service-Prozesse steuerbar sein.
Ein typischer automatisierter Ablauf kann so aussehen: Nach dem Erstellen einer neuen Testumgebung wird automatisch ein Subsetting-Job gestartet. Dieser extrahiert einen definierten Datenbestand aus einer Quelle, wendet Maskierungsregeln an, lädt die Daten in eine Zielumgebung und führt anschließend Validierungen aus. Danach starten automatisierte Tests. Nach Abschluss können Datenstände archiviert, zurückgesetzt oder neu erzeugt werden. Auf diese Weise wird Testdatenbereitstellung Teil des Entwicklungsprozesses.
Test Data Management beschreibt damit den Prozess zur Erstellung, Pflege und Bereitstellung von Testdaten in kontrollierten, sicheren und konsistenten Zuständen. Zu einer vollständigen TDM-Strategie gehören unter anderem Discovery, Maskierung, Subsetting, synthetische Datengenerierung, Provisioning, Qualitätsprüfungen und Governance. In der Software IRI spielen dabei gemeinsame Metadaten eine wichtige Rolle. Regeln, Datenklassen, Maskierungsvorgaben und Jobdefinitionen können wiederverwendet werden. Wird eine Regel zentral definiert, kann sie in unterschiedlichen Jobs konsistent angewendet werden. Die Integration der Testdatenprozesse in CI/CD-Prozesse kann auf mehreren Ebenen erfolgen. Auf der einfachsten Ebene werden Subsetting- oder Maskierungsjobs per Kommandozeile gestartet. Ein Build Server ruft die entsprechenden Skripte auf, erzeugt die benötigten Daten und lädt sie in eine Testdatenbank.
Wichtig ist die Reproduzierbarkeit. Wenn ein Test fehlschlägt, muss nachvollziehbar sein, mit welchem Datenstand er ausgeführt wurde. Dazu sollten Jobdefinitionen, Auswahlkriterien, Maskierungsregeln und Versionen dokumentiert oder versioniert werden. Idealerweise werden Testdatenjobs gemeinsam mit Anwendungscode oder Infrastrukturdefinitionen verwaltet. So lässt sich später rekonstruieren, welche Datenbasis zu welchem Testergebnis geführt hat.
Praxisbeispiel: Ein referenziell konsistentes Subset erzeugen
Die Datenbank enthält Tabellen für Kunden, Adressen, Bestellungen, Bestellpositionen, Produkte, Rechnungen und Zahlungen. Ziel ist es, eine kleinere Testdatenbank bereitzustellen. Sie soll nur einen ausgewählten Teil der Kunden enthalten, aber alle abhängigen Geschäftsvorfälle vollständig abbilden. Sensible Kundendaten sollen gleichzeitig maskiert werden.
Im ersten Schritt wird das Datenmodell analysiert. Dazu gehört die Identifikation der zentralen Tabellen und Beziehungen. Die Kundentabelle bildet in diesem Beispiel den Ausgangspunkt. Von dort führen Beziehungen zu Adressen, Bestellungen und Rechnungen. Bestellungen wiederum verweisen auf Bestellpositionen und Produkte. Zahlungen beziehen sich auf Rechnungen. Im zweiten Schritt wird das Auswahlkriterium definiert. Für die Testumgebung sollen beispielsweise alle Kunden übernommen werden, die in den letzten zwölf Monaten mindestens eine Bestellung aufgegeben haben und einem bestimmten Marktsegment angehören. Alternativ könnte man eine feste Anzahl von Kunden oder einen prozentualen Anteil wählen. Im dritten Schritt werden die abhängigen Daten ermittelt. Zu jedem ausgewählten Kunden werden alle relevanten Adressen, Bestellungen, Positionen, Rechnungen und Zahlungen übernommen. Zusätzlich müssen die referenzierten Produkte enthalten sein, damit die Bestellpositionen vollständig interpretierbar bleiben. Je nach Datenmodell können weitere Stammdaten erforderlich sein, etwa Währungen, Steuersätze, Lieferarten oder Rabattgruppen. Im vierten Schritt werden Maskierungsregeln festgelegt. Namen werden durch realistische Ersatznamen ersetzt, E-Mail-Adressen syntaktisch korrekt neu erzeugt, Telefonnummern formaterhaltend transformiert und Kundennummern konsistent pseudonymisiert. Geschäftliche Kennzahlen, die für Tests relevant sind, bleiben erhalten oder werden nur kontrolliert verändert. Dadurch bleibt das Datenbild plausibel, ohne reale Personen offenzulegen. Im fünften Schritt wird das Subset erzeugt und in eine Zielumgebung geladen.
Das Ergebnis ist eine deutlich kleinere Testdatenbank, die fachlich zusammenhängende Vorgänge enthält, aber keine ungeschützten sensiblen Informationen mehr preisgibt. Diese Datenbank kann für Entwicklung, automatisierte Tests, Fehleranalysen oder Schulungen genutzt werden.
Fazit
Database Subsetting schließt eine zentrale Lücke im modernen Testdatenmanagement. Während synthetische Testdaten vollständig neue Datenbestände erzeugen und Maskierung produktionsnahe Daten schützt, ermöglicht Subsetting den gezielten Umgang mit sehr großen Datenbanken. Statt vollständige Produktionskopien in Nicht-Produktivumgebungen zu übertragen, entstehen kleinere, referenziell konsistente und fachlich relevante Ausschnitte. Der Nutzen ist unmittelbar: Testumgebungen lassen sich schneller bereitstellen, Infrastrukturkosten sinken, Datenschutzrisiken werden reduziert und Teams können gezielter testen. Entscheidend ist jedoch, Subsetting nicht isoliert zu betrachten. Erst die Kombination mit Maskierung, synthetischer Datengenerierung, Automatisierung und Governance führt zu einem ganzheitlichen Test Data Management. Plattformen wie IRI Voracity zeigen, wie diese Bausteine technisch zusammengeführt werden können: Datenklassifikation, Maskierung, Subsetting, synthetische Generierung und automatisierte Bereitstellung greifen ineinander.
[1] https://www.iri.com/solutions/test-data
[2] https://conference.eurostarsoftwaretesting.com/database-subsetting/?utm_source=chatgpt.com
[3] Arfi Siddik Mollashaik: Enterprise Test Data Management: A Comprehensive Framework for Regulatory Compliance and Security in Modern Software Development, International Journal of Scientific Research in Computer Science, Engineering and Information Technology https://www.researchgate.net/publication/388086688_Enterprise_Test_Data_Management_A_Comprehensive_Framework_for_Regulatory_Compliance_and_Security_in_Modern_Software_Development
[4] https://www.iri.com/support/data-education-center/what-is-database-subsetting
