Synthetische Testdaten

VonDatabase Security

Synthetische Testdaten

Viele Unternehmen benötigen für Entwicklungs-, Schulungs- und Testsysteme Testdaten oder anonymisierte Daten. Je nach Anforderung müssen diese Daten sinnvolle Daten beinhalten, zum Beispiel reale Vornamen, Nachnamen oder Rechtsformen. Je nach Testszenario können auch Dummydaten erzeugt und verwendet werden.

Testdaten

Wer heute nach Lösungen zur Erstellung oder Verwendung von Testdaten sucht, hat grundsätzlich die folgenden Möglichkeiten diese zu erzeugen oder herzustellen:

  • manuelle Eingabe
  • Demodaten vom Softwarehersteller
  • Nutzung von Testdatengeneratoren und Frameworks
  • Kauf und Download von synthetischen Daten
  • Clonen von Produktionsdaten und Anonymisierung

Vor- und Nachteile der verschiedenen Verfahren:

Manuelle Eingabe von Testdaten

Dieses Vorgehen ist sehr aufwendig und wird oft aus Kostengründen an Praktikanten, Auszubildende oder Berufsanfängern vergeben. Im Ergebnis erreicht man, dass die Personen, die zu solchen Eingaben „gezwungen“ worden sind, sehr schnell erkennen, dass die kreative Dateneingaben schnell auf ein geistiges Limit treffen.

Am Ende sind Daten von Freunden, Verwandten und Bekannten, Echtdaten aus Telefonbüchern, oder Mitgliederlisten aus öffentlich zugänglichen Quellen erfasst. Zudem erfolgt eine Vermischung von Realnamen mit Dummynamen sowie verschiedenen Sprachen und Geogebieten.

Diese Testdaten sind für spätere Demosysteme oder Schulungssysteme für Kunden nicht brauchbar oder präsentierbar. Der einzige Vorteil dieses Vorgehens ist, dass die Mitarbeiter über die manuellen Dateneingaben das System sehr gut kennenlernen.

Demodaten vom Softwarehersteller

Demodaten werden seitens vieler Softwarehersteller ausgeliefert. Der Vorteil liegt in der Zeitersparnis. Nachteilig ist, dass diese Daten ggf. branchenfremd sind oder tatsächlich Echtdaten beinhalten. Je nach Datenvolumen können diese niemals komplett geprüft und die Sicherheit gegeben werden, dass diese nicht gegen Datenschutzbestimmungen verstossen.

Ebenso sind Demodaten von Softwarehersteller ideale Daten. Ideale Daten bedeutet, dass diese Datensätze valide im Sinne von Formaten, Längen, Zeichensätzen, Strukturen und Datentypen sind. Oftmals werden diese Daten über Schnittstellen (APIs) eingelesen und sind möglicherweise nicht mit manuellen Eingaben über das Anwender-GUI identisch.

Nutzung von Testdatengeneratoren

Im Internet gibt es eine Vielzahl von kostenloser Software für Testdatengeneratoren, Möglichkeiten des Downloads von Daten aus Testdatengeneratoren sowie einige spezialisierte kommerzielle Anbieter.

Bis auf die spezialisierten kommerziellen Anbieter wissen Sie eigentlich nicht, ob die generierten Daten aus kostenlosen Downloads oder Generatoren wirklich 100% Testdaten sind und nicht doch Echtdaten beinhalten.

Ebenso sind notwendige Verteilungsmuster oder Statistiken über Minimal-/Maximalwerte, Anzahl Ausprägungen von Spalten, Kardinalitäten usw. nicht oder nicht sofort ersichtlich. Der Zusatzaufwand beim Einsatz eines kostenlosen Tools für Testdaten sind nicht zu unterschätzen:

  • Download und Installation der Software
  • Check, ob Lizenz wirklich kostenlos ist
  • Einarbeitung eines Mitarbeiters in die Anwendung
  • Definition der Parameter (welche Daten werden gebraucht)
  • Erzeugung der Daten in ein verwertbares Importformat (SQL)
  • Import der Daten in verschiedenen Tabellen der Testdatenbank
  • Fehleranalyse und
  • ggf. mehrere Iterationen von Generieren und Importieren

Sehr gerne wird im Bereich DevOps oder DevSecOps auf diverse Frameworks der gängigen Programmiersprachen verwiesen, die diese Methoden beinhalten und für alle Testfälle problemlos E2E-Tests garantieren. Für reine Entwicklungstätigkeiten mit diesen Dummydaten ist dies ein sinnvolles Vorgehen. Eine Anwendung mit Dummydaten bei Kunden oder Schulungen zu präsentieren, wird aber keinen guten Eindruck hinterlassen.

Kauf und Download von synthetischen Testdaten

Eine Alternative zwischen der Erstellung der Testdaten durch manuelle Eingaben oder Testdatengeneratoren ist der Kauf von vorgenerierten synthetischen Testdaten. Typischerweise sind diese für Stammdaten von ERP-, CRM-, DWH oder DMS-Systemen verfügbar.

Unser Unternehmen bietet diese für folgende Daten an:

  • Personen, Adressen, Kommunikationsdaten, persönliche Daten und weitere Attribute
  • Unternehmen, Adressen, Rechtsformen, Kontakte und weitere Attribute
  • Produkte und Services

Unsere Angebote für Testdaten beinhalten folgende Merkmale:

  • Sprache in Deutsch, Englisch, International oder Dummydaten
  • Anzahl Datensätze: 1000, 10000, 100000, 1.000.000, usw.
  • Beschreibung der Attribute mit Format, Min-/Maxwerte, Verteilungen, Unique-ID und Datentypen.
  • verfügbar bei Kauf als Download im Format CSV und SQL

Geeignet sind unsere Testdaten insbesondere für Stammdaten, Grunddaten, Testdaten, Demodaten, Schulungsdaten, Zufallsdaten, Unternehmen, Geschäftspartner, Kunden, Lieferanten, Kundenstamm, Kundenstammdaten, Lieferantenstamm, Lieferantenstammdaten, Mitarbeiter, Mitarbeiterstamm, Mitarbeiterstammdaten, Personen und Adressen.

Klonen von Datenbanken und Anonymisierung von Daten

Das Klonen von Produktionsdatenbanken und die Anonymisierung von Daten in sogenannten After-Clone oder Masking-Skripten ist bei vielen Unternehmen weit verbreitet und wird oft als Lösung angesehen, die laut Compliance den Datenschutzrichtlinien entsprechen. Leider zeigt sich in der Praxis, dass die Auditoren sich nicht die Mühe gemacht haben, diese Skripte mal genauer anzusehen.

Damit dies funktioniert, muss garantiert werden, dass das Masking oder After-Clone Skript so aufgesetzt ist, dass nicht durch statistische Methoden auf den Ursprungswert geschlossen werden kann. Zudem setzt der Einsatz voraus, dass die Anwendung und Datenstrukturen sehr gut bekannt sind.

Beispiele für fehlerhaftes Masking und After Clone Skripte:

  • Lohndaten in Tabelle wurden komplett maskiert, die Lohnabrechnungen waren als PDF im Original gespeichert
  • Buchungsdaten für Testsysteme für Buchhaltung wurden spaltenweise geändert, Bilanzsummen und Saldovorträge waren nie mehr abstimmbar
  • Usernamen und Passworte wurden für PreProd-Umgebung neu erstellt und waren später in Produktionssystem ebenfalls vorhanden

Über den Autor

Database Security editor