Testdatengenerierung für Datenbanken
Realistisches, referenziell korrektes Schema aufstellen
Herausforderungen
DBAs und Datenarchitekten die versuchen Testdatenbanken zu füllen, verlassen sich oft auf unsichere und unzureichende Schutzdaten. Es gibt eine Reihe von Problemen mit diesem Ansatz, einschließlich:
Unzulänglichkeit der Daten
Das Testen mit Produktionsdatenbanken ist aus mehreren Gründen keine gute Strategie:
- Der Zugriff auf die Datenbank selbst kann aufgrund der darin enthaltenen personenbezogenen Daten oder anderer Informationen eingeschränkt sein
- Die Datenbank existiert möglicherweise noch nicht
- Die aktuellen Werte in der Datenbank spiegeln nicht den zukünftigen Umfang der zu testenden Daten wider
- Selbst wenn sie maskiert sind, können die falschen Datenmaskierungsfunktionen dazu führen, dass die Testdaten unrealistisch sind oder nicht mehr den Vorschriften entsprechen
Datenrealismus
DBAs und Anwendungsentwickler benötigen Testdaten, die den charakteristischen Inhalt, das Format und die Beziehungen zukünftiger Produktionsdaten aufweisen. Nur so kann überprüft werden, ob jeder Anwendungsschritt und jede Abfrage noch funktioniert.
Gleichzeitigkeit & Sicherheit
Entwickler benötigen Daten die sicher sind (d.h. nicht gegen die Datenschutzbestimmungen verstoßen) und nicht von anderen Entwicklern oder Entwicklungsphasen abhängig sind, um die Daten zu produzieren die sie für ihre Phase benötigen. Möglicherweise muss die Entwicklung auch ausgelagert werden und gleichzeitig an verschiedenen Standorten stattfinden.
Neben der Realitätsnähe und Anonymität der Testdaten ist auch die Verfügbarkeit ein Thema. Eine weitere zentrale Herausforderung für Datenbanktestlösungen besteht darin, wie die Testdaten für die Verwendung bereitgestellt werden. Sie müssen in den erforderlichen Formaten und Silos (oder DevOps-Pipelines) zugänglich sein und im Falle von Änderungen konsistent oder wiederherstellbar bleiben.
Lösungen
Auf dem Markt gibt es mehrere Tools zur Generierung von Datenbank-Testdaten. Die flexibelsten, schnellsten und robustesten Testdatenlösungen werden mit der IRI RowGen-Software erstellt.
Mit RowGen können Sie die Verwaltung von Datenbanktests aus jedem beliebigen Blickwinkel angehen, der für Ihren Anwendungsfall am besten geeignet ist. Die primäre Methode zur Erzeugung von Testdaten ist die Datensynthese, d.h. RowGen erzeugt synthetische, aber äußerst realistische Datenbanktestdaten. Alternativ können Benutzer der IRI RowGen-, FieldShield- oder Voracity-Plattformen ihre Lizenz für das Subsetting von Datenbanken (mit oder ohne Datenmaskierung) verwenden. Unabhängig von Ihrer Strategie sind die Eclipse-Benutzeroberfläche, die Job-Metadaten und die Engine, die hinter all dem steht, dieselben.
Die Software arbeitet datenbankübergreifend mit denselben einfach zu definierenden und wiederverwendbaren Regeln für die Testdatengenerierung. Ihre Regeln für die Generierung (oder Maskierung) von Testdaten gelten in der Regel konsistent für alle Datenklassen (z. B. Spalten) und nutzen entweder die Generierung von Zufallswerten oder die Auswahl von Zufallswerten aus anderen Datensätzen. Sobald Sie die Regeln genehmigt haben, können Sie ihre Anwendung mit einem Assistenten automatisieren, der Ihren Datenbank-Testdatenauftrag erstellt.
Bevor Sie den Assistenten ausführen, sollten Sie sich über einige der größeren Themen Gedanken machen, die bei der Festlegung Ihrer Testdatenanforderungen zu berücksichtigen sind. Lesen Sie die Artikelserie über die Verwaltung von Datenbanktestdaten und die Bereitstellung von Testdaten im IRI-Blog, die hier beginnt. Dann erfahren Sie, warum das RowGen-Testdatenprodukt - oder die IRI Voracity-Datenmanagementplattform, die es beinhaltet - seit 2004 das beste Testdatengenerierungswerkzeug zur Erreichung dieser Ziele ist.
Keine Produktionsdaten erforderlich
Die IRI RowGen-Software erzeugt genaue und sichere Testdaten, die die Tabellenformate, Größen, Wertebereiche und Einschränkungen der Produktionsdatenbank widerspiegeln - ohne Produktionsdaten. RowGen verwendet Ihre DDL-Informationen, um große, strukturell und referenziell korrekte Testtabellen schnell und automatisch zu erstellen und zu laden. Weitere Informationen finden Sie unter:
Blog > Testdaten > RowGen automatisiert die Generierung von Testdaten für die Datenbank
Blog > Testdaten > Wie man DB-Testdaten generiert
Video > Eine Datenbank von Grund auf mit realistischen Testdaten füllen
Testdaten-Realismus
Gültige Testtabellen müssen die gesamte Bandbreite an Werten, Datentypen, Zeilenlayouts und primären Fremdschlüsselbeziehungen enthalten, auf die sich die DB-Anwendung stützt. Für Informationen darüber, wie RowGen den Datenrealismus bewahrt, siehe:
Gleichzeitige Entwicklung
Durch die Generierung von Testdaten für jede Phase der Entwicklung können Sie Phasen gleichzeitig und unabhängig von anderen Phasen anlegen. Zum Beispiel:
Schritt 1 - Lesen Sie eine Personaltabelle und verbinden Sie die Falldaten der Krankenkasse zu einer Statusdatei.
Schritt 2 - Lesen Sie die Statusdatei und erstellen Sie eine Liste der Ärzte.
Schritt 3 - Erstellen Sie eine webfähige Abrechnungsübersicht, die nach Patient sortiert ist.
RowGen kann die Eingabetabelle für Schritt 1, die Statusdatei für Schritt 2 und den Webreport in Schritt 3 erzeugen - alles ohne echte Daten oder Daten aus den anderen Schritten zu benötigen.
Sichere Entwicklung
RowGen bietet Ihnen die Möglichkeit, jede Art, Größe, jedes Layout und jede Menge sicherer Testdaten zu synthetisieren, damit Sie eine sicherere Entwicklungsumgebung erstellen und bereitstellen können.
Alternativ können Sie mit IRI FieldShield echte Daten verwenden, die durch Funktionen auf Feldebene (z.B. Verschlüsselung) geschützt sind. Weitere Informationen finden Sie unter: Lösungen > Datenmaskierung
Beide Werkzeuge existieren nebeneinander in der IRI Workbench GUI, die auch ein automatisches DB-Subsetting mit Maskierung bietet. So oder so, mit sicheren Daten ist es nicht notwendig Ihre ausgelagerten Anwendungsentwickler zu zertifizieren oder zu binden.
Nahtloser Übergang zur Produktion
RowGen zeigt Ihnen, wie die realen Daten aussehen können und wie die Transformations- und Berichtsanwendung aussehen kann. Denn sowohl RowGen als auch das Programm SortCL in IRI CoSort und Voracity verwenden die gleichen Metadaten, um Datenmanipulationen und Tabellenlayouts zu definieren.
Dies bedeutet, dass RowGen auch die gleichen Datentransformationen und Berichtsfunktionen ausführen kann, die Sie normalerweise im gleichen I/O-Pass und Job-Skript ausführen würden, das die Testdatengenerierung durchführt. Es bedeutet auch, dass dieselben Layouts (und sogar Transformationen), die für Datensyntheseaufträge erstellt wurden, sofort für Datenintegration, Maskierung, Migration, Reporting und andere Datenverarbeitungsaufträge bereit sind, wenn und sobald echte Daten verfügbar sind.
Wenn Sie nur RowGen verwenden, können Sie ganz einfach auf CoSort oder Voracity aktualisieren, um die realen Daten zu transformieren und zu berichten (wenn sie verfügbar sind). Mit dem gleichen Job-Skript RowGen, mit dem Sie Testdaten definieren und transformieren, können Sie reale Daten im gleichen Format transformieren.
Virtualisierung und Bereitstellungsoptionen
IRI-Testdatenersteller können den Testern Testdaten auf verschiedene Arten zur Verfügung stellen, darunter:
- Ad-hoc-Tabellen (oder Dateien in verschiedenen Formaten) in persistenten oder föderierten (View-)Schemata
- Goldene Kopien von Testdaten in bestehenden unteren Umgebungen sowie die Möglichkeit, neue Tabellen zu erstellen
- Während des Klonens von Datenbanken in Tools wie Windocks, Actifio (Google) und Commvault
- Innerhalb von DevOps-Pipelines wie Amazon CodePipeline, Azure DevOps, Jenkins, GitLab, etc.
- Direkt über Testdatenmanagement (TDM) Hubs von Cigniti oder ValueLabs
Auf den Seiten DevOps und Virtuelle Testdaten in diesem Abschnitt erfahren Sie mehr und finden Links zu weiteren Informationen über diese Optionen. Vergleichen Sie diese Methoden und Kosten mit teureren und proprietären Lösungen, die spezielle Treiber oder das Aufsetzen ephemerer Datenbanken erfordern.
Verwandte Lösungen
