Einfacheres Testdatenmanagement (TDM) mit Datensimulation

Haben Sie sich jemals gefragt, wie Sie das Testdatenmanagement (TDM) mithilfe von Testsimulationen am besten vereinfachen können? Erfahren Sie, wie Ihnen die virtuelle Testdatenlösung von Parasoft dabei helfen kann.

Um parallele Integrationstests zu ermöglichen, die funktionale Tests vorverlegen, können Unternehmen den Ansatz von Parasoft für das Testdatenmanagement (TDM) nutzen . Dieser Ansatz verwendet KI, maschinelles Lernen und virtuelle Testdaten, um physische Endpunkte und Datenbanken überflüssig zu machen. Sehen wir uns an, wie das funktioniert.

Das Testdatenproblem

Die Validierung und Überprüfung von Software bleibt einer der zeitaufwändigsten und kostspieligsten Aspekte der Entwicklung von Unternehmenssoftware. Die Industrie hat akzeptiert, dass das Testen schwierig ist, aber die Hauptursachen werden oft übersehen. Das Erfassen, Speichern, Verwalten und Verwenden von Testdaten zum Testen ist eine schwierige Aufgabe, die zu viel Zeit in Anspruch nimmt.

Aus Branchendaten geht hervor, dass bis zu 60% der Anwendungsentwicklungs- und Testzeit für datenbezogene Aufgaben aufgewendet werden können, von denen ein großer Teil das Testdatenmanagement ist. Verzögerungen und Budgetausgaben sind nur ein Teil des Problems - das Fehlen von Testdaten führt auch zu unzureichenden Tests, was ein viel größeres Problem darstellt und zwangsläufig dazu führt, dass sich Fehler in die Produktion einschleichen.

Herkömmliche Lösungen auf dem Markt für TDM haben den Stand der Testdatenherausforderungen nicht erfolgreich verbessert. Schauen wir uns einige davon an.

Die 3 traditionellen Ansätze zum Testen des Datenmanagements

Die traditionellen Ansätze basieren entweder auf der Erstellung einer Kopie einer Produktionsdatenbank oder auf dem genauen Gegenteil, der Verwendung synthetischer, generierter Daten. Es gibt drei hauptsächliche traditionelle Ansätze.

1. Klonen Sie die Produktionsdatenbank.

Tester können die Produktionsdatenbank klonen, um etwas zum Testen zu haben. Da dies eine Kopie der Produktionsdatenbank ist, muss auch die erforderliche Infrastruktur dupliziert werden. Die Einhaltung von Sicherheits- und Datenschutzbestimmungen erfordert, dass vertrauliche personenbezogene Daten streng geschützt werden. Daher wird häufig eine Maskierung verwendet, um diese Daten zu verschleiern.

2. Klonen Sie eine Teilmenge der Produktionsdatenbank.

Eine Teilmenge der Produktionsdatenbank ist ein Teilklon der Produktionsdatenbank, der nur den zum Testen erforderlichen Teil enthält. Dieser Ansatz erfordert weniger Hardware, erfordert jedoch wie die vorherige Methode auch eine Datenmaskierung und eine ähnliche Infrastruktur wie die Produktionsdatenbank.

3. Generieren/synthetisieren Sie die Daten.

Durch die Synthese von Daten besteht keine Abhängigkeit von Kundendaten, aber die generierten Daten sind immer noch realistisch genug, um zum Testen nützlich zu sein. Die Synthese der Komplexität einer Legacy-Produktionsdatenbank ist eine große Aufgabe, beseitigt jedoch die Herausforderungen in Bezug auf Sicherheit und Datenschutz, die mit Klonmechanismen verbunden sind.

Probleme mit traditionellen Ansätzen für TDM

Betrachten wir zunächst den einfachsten (und überraschend häufigsten) Ansatz für Unternehmens-TDM, bei dem eine Produktionsdatenbank mit oder ohne Teilmenge geklont wird. Warum ist dieser Ansatz so problematisch?

• Komplexität und Kosten der Infrastruktur. Legacy-Datenbanken sind wahrscheinlich der größte Nachteil traditioneller TDM-Ansätze und befinden sich möglicherweise auf einem Mainframe oder bestehen aus mehreren physischen Datenbanken. Das Duplizieren nur eines einzigen Produktionssystems für ein Team ist ein teures Unterfangen.
• Datenschutz und Sicherheit. Datenschutz und Sicherheit sind bei der Verwendung von Produktionsdatenbanken immer ein Problem, und Testumgebungen entsprechen häufig nicht den erforderlichen Datenschutz- und Sicherheitskontrollen. Das Maskieren ist die übliche Lösung, um diese Probleme zu lösen und vertrauliche Informationen so zu ändern, dass keine persönlich identifizierbaren Informationen preisgegeben werden. Leider ist das Maskieren fast unmöglich ohne das Risiko, dass private Informationen verloren gehen, da es trotz der besten Bemühungen des besten Testteams möglich ist, Testdaten zu de-anonymisieren. Unternehmen, die beispielsweise die DSGVO einhalten müssen, haben möglicherweise Schwierigkeiten, die Aufsichtsbehörden davon zu überzeugen, dass ihre geklonte Testumgebung die erforderlichen Datenschutzbestimmungen erfüllt.
• Fehlende Parallelität und Datenkollisionen. Angesichts der Infrastrukturkosten steht nur eine begrenzte Anzahl von Testdatenbanken zur Verfügung, und die parallele Ausführung mehrerer Tests wirft Bedenken hinsichtlich Datenkonflikten auf. Tests können beispielsweise Datensätze löschen oder ändern, auf die sich andere Tests stützen. Dieser Mangel an Parallelität führt dazu, dass das Testen weniger effizient wird und die Tester sich nach jeder Testsitzung um die Datenintegrität sorgen müssen.
• Subsetting hilft nicht viel. Obwohl es möglich sein könnte, eine verwaltbare Teilmenge zu erstellen, die weniger Infrastruktur erfordert, ist dies ein komplexer Prozess. Die referenzielle Integrität muss gewahrt bleiben, und Datenschutz- und Sicherheitsprobleme bleiben in den Teilmengen bestehen.
• Die Synthese von Daten behebt Datenschutzbedenken, erfordert jedoch viel Datenbank- und Domänenexpertise. Das Erstellen und Auffüllen einer realistischen Version einer Testdatenbank erfordert genaue Kenntnisse der vorhandenen Datenbank und die Fähigkeit, eine synthetische Version mit Daten zu erstellen, die zum Testen geeignet sind. Während dieser Ansatz viele Sicherheits- und Datenschutzprobleme löst, erfordert die Erstellung der Datenbank viel mehr Entwicklungszeit. Infrastrukturprobleme bleiben bestehen, wenn die Testdatenbank groß ist, und die Parallelität kann eingeschränkt sein, je nachdem, wie viele Testdatenbanken gleichzeitig verwendet werden können.

Entdecken Sie Best Practices für das Testdatenmanagement, um das Untestbare zu testen.

Lösen von Problemen beim Testdatenmanagement mit Datensimulation

Der vereinfachte und sicherere Ansatz für das Testdatenmanagement , den wir bei Parasoft mit unseren virtuellen Testdatentools SOAtest, Virtualize und CTP anbieten, ist deutlich sicherer und löst diese herkömmlichen Probleme. Worin besteht also der Unterschied zu den traditionellen Ansätzen?

Der entscheidende Unterschied besteht darin, dass Testdaten durch die Erfassung des Datenverkehrs von API-Aufrufen und JDBC/SQL-Transaktionen während des Testens und der normalen Anwendungsnutzung gesammelt werden. Die erfassten Daten werden bei Bedarf maskiert, und Datenmodelle werden generiert und in der Testdatenverwaltungsoberfläche von Parasoft angezeigt. Die Metadaten und Datenbeschränkungen des Modells können innerhalb der Oberfläche abgeleitet und konfiguriert werden, und zusätzliche Maskierungs-, Generierungs- und Teilmengenoperationen können durchgeführt werden. Dies bietet ein Self-Service-Portal, über das mehrere temporäre Datensätze einfach bereitgestellt werden können, um Testern volle Flexibilität und Kontrolle über ihre Testdaten zu geben , wie Sie in den folgenden Screenshots sehen können:

Die Technologie von Parasoft zur Verwaltung virtueller Testdaten wird durch Servicevirtualisierung erweitert. Dadurch lassen sich eingeschränkte Backend-Abhängigkeiten simulieren, um Testaktivitäten zu ermöglichen. Ein gutes Beispiel hierfür ist der Ersatz einer gemeinsam genutzten physischen Datenbank durch eine virtualisierte Datenbank, die die JDBC/SQL-Transaktionen simuliert. Dies ermöglicht parallele und unabhängige Tests, die andernfalls zu Konflikten führen würden. Die Testdatenmanagement-Engine von Parasoft erweitert die Möglichkeiten der Servicevirtualisierung, indem sie Testern erlaubt, individuelle, bedarfsgerechte Testdaten zu generieren, zu filtern, zu maskieren und zu erstellen.

Durch den Ersatz gemeinsam genutzter Abhängigkeiten wie Datenbanken macht die Servicevirtualisierung die Infrastruktur und Komplexität für das Hosting der Datenbankumgebung überflüssig. Dies wiederum ermöglicht isolierte Testsuiten und die Möglichkeit, Extremfälle und Sonderfälle abzudecken. Obwohl die virtualisierten Abhängigkeiten nicht der Realität entsprechen, können zustandsbehaftete Aktionen wie Einfüge- und Aktualisierungsvorgänge in einer Datenbank innerhalb der virtuellen Ressource modelliert werden. Nachfolgend sehen Sie eine konzeptionelle Darstellung:

Der entscheidende Vorteil dieses Ansatzes besteht darin, dass er die Komplexität und die Infrastrukturkosten des Klonens von Datenbanken vermeidet und somit API-Tests (wie Integrationstests) viel früher ermöglicht als andere Testdatenmethoden.

Einige andere Vorteile dieses Ansatzes sind:

• Da es keine zugrunde liegende Datenbankinfrastruktur erfordert, kann es normalerweise lokal auf den Workstations von Entwicklern und Testern ausgeführt werden.
• Isolierte Testumgebungen, die für jeden Tester einzigartig sind, bedeuten, dass für eine gemeinsam genutzte Testdatenbank keine Datenkollisionen oder Bedenken hinsichtlich der Datenintegrität bestehen. Das Testen wird sehr parallel, wodurch Wartezeiten und verschwendete Zyklen herkömmlicher Ansätze vermieden werden.
• Tester können in einer Testdatenbank problemlos Eckfälle abdecken, die zu Korruption und anderen Problemen führen können. Da jede Testumgebung isoliert ist, können Tester problemlos Destruktions-, Leistungs- und Sicherheitstests durchführen, ohne die Integrität einer gemeinsam genutzten Ressource zu beeinträchtigen.
• Es ist einfach, Tests und Daten im Team zu teilen, um Doppelarbeit zu vermeiden. API-Tests können für andere Zwecke wie Sicherheits- und Leistungstests angepasst werden.
• Durch die Verwendung virtualisierter Server wird die Komplexität des zugrunde liegenden Datenbankschemas eliminiert. Stateful Testing ist verfügbar, um realistische Szenarien bereitzustellen.
• Wenn Sie nur die Daten erfassen, die Sie mit dynamischer Maskierung benötigen, benötigen Sie keine geklonte Datenbank mehr. Der Schwerpunkt der Integrationstests liegt auf den APIs, anstatt eine gemeinsam genutzte, geklonte Datenbank zu verwalten.

Tests an der physischen Datenbank sind weiterhin erforderlich, jedoch nur gegen Ende des Softwarebereitstellungsprozesses, wenn das gesamte System verfügbar ist. Dieser Ansatz zum Testen von Daten macht das Testen mit der realen Datenbank nicht vollständig überflüssig, verringert jedoch die Abhängigkeit von der Datenbank in den früheren Phasen des Softwareentwicklungsprozesses, um den Funktionstest zu beschleunigen.

Zusammenfassung

Herkömmliche Ansätze für das Testdatenmanagement von Unternehmenssoftware basieren auf dem Klonen von Produktionsdatenbanken und deren Infrastruktur, was mit hohen Kosten, Datenschutz- und Sicherheitsrisiken verbunden ist. Diese Ansätze sind nicht skalierbar und führen zu verschwendeten Testressourcen. Die virtuelle Testdatenlösung von Parasoft rückt das Testen und die bedarfsgerechte Rekonfiguration der Testdaten wieder in den Mittelpunkt und ermöglicht so parallele Integrationstests, wodurch diese kritische Testphase in frühere Phasen verlagert wird.