Erfahren Sie, wie die Continuous Quality Platform von Parasoft dabei hilft, Testumgebungen zu steuern und zu verwalten, um zuverlässig hochwertige Software zu liefern. Für Demo registrieren >>

BLOG

Einfacheres Testdatenmanagement (TDM) mit Datensimulation

Einfacheres Testdatenmanagement (TDM) mit Datensimulation Lesezeit: 6 Minuten

Um parallele Integrationstests zu ermöglichen, die Funktionstests nach links verschieben, können Unternehmen den Ansatz von Parasoft nutzen, um Testdatenmanagement (TDM) die KI, maschinelles Lernen und virtuelle Testdaten verwendet, um den Bedarf an physischen Endpunkten und Datenbanken zu ersetzen. Lassen Sie uns untersuchen, wie es 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.

Webinar: Hör auf zu warten. Testen Sie weiter mit virtuellen Testdaten!

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 beruhen entweder auf der Erstellung einer Kopie einer Produktionsdatenbank oder genau umgekehrt auf der Verwendung synthetischer, generierter Daten. Es gibt drei traditionelle Hauptansä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.

Get Smart: Verwenden Sie Simulation, um API-Tests zu beschleunigen

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.

Lösen von Problemen beim Testdatenmanagement mit Datensimulation

Der vereinfachte und sicherere Ansatz für Testdatenverwaltung die wir bei Parasoft in unseren SOAtest, Virtualisieren, CTP Virtual Test Data Tools ist viel sicherer und löst diese traditionellen Probleme. Wie unterscheidet es sich also von den traditionellen Ansätzen?

Testen Sie den Untestable: Alaska Airlines löst das Testumgebungs-Dilemma

Der Hauptunterschied besteht darin, dass Testdaten erfasst werden, indem der Datenverkehr von API-Aufrufen und JDBC/SQL-Transaktionen während des Tests und der normalen Anwendungsnutzung erfasst wird. Die erfassten Daten werden nach Bedarf maskiert, und Datenmodelle werden generiert und in der Testdatenverwaltungsschnittstelle von Parasoft angezeigt. Die Metadaten und Datenbeschränkungen des Modells können innerhalb der Schnittstelle abgeleitet und konfiguriert werden, und es können zusätzliche Maskierungs-, Generierungs- und Untergruppenoperationen durchgeführt werden. Dies bietet ein Self-Service-Portal, in dem mehrere Einweg-Datasets können problemlos bereitgestellt werden um Testern volle Flexibilität und Kontrolle über ihre Testdaten zu geben, wie Sie in den folgenden Screenshots sehen können:

Parasofts Virtuelle Testdatenmanagement-Technologie wird durch Servicevirtualisierung ergänzt, bei der eingeschränkte Back-End-Abhängigkeiten simuliert werden können, um Testaktivitäten freizugeben. Ein gutes Beispiel wäre das Ersetzen einer Abhängigkeit von einer gemeinsam genutzten physischen Datenbank durch Austauschen mit einer virtualisierten Datenbank, die die JDBC/SQL-Transaktionen simuliert und parallele und unabhängige Tests ermöglicht, die andernfalls zu Konflikten führen würden. Die Testdaten-Management-Engine von Parasoft erweitert die Leistungsfähigkeit der Service-Virtualisierung, indem sie es Testern ermöglicht, individuell angepasste Testdaten für ihre Bedürfnisse zu generieren, zu unterteilen, zu maskieren und zu erstellen.

Durch das Ersetzen gemeinsamer Abhängigkeiten wie Datenbanken macht die Servicevirtualisierung die erforderliche Infrastruktur und Komplexität zum Hosten der Datenbankumgebung überflüssig. Dies wiederum bedeutet isolierte Testsuiten und die Möglichkeit, Extrem- und Eckfälle abzudecken. Obwohl die virtualisierten Abhängigkeiten nicht das „echte Ding“ sind, können zustandsbehaftete Aktionen wie Einfüge- und Aktualisierungsvorgänge in einer Datenbank innerhalb des virtuellen Assets modelliert werden. Sehen Sie dies konzeptionell unten:

Der Hauptvorteil dieses Ansatzes besteht darin, dass die Komplexität und die Infrastrukturkosten des Klonens von Datenbanken vermieden werden Tests auf API-Ebene (wie Integrationstests) viel früher als bei anderen 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 zum Testen des Datenmanagements für Unternehmenssoftware basieren auf dem Klonen von Produktionsdatenbanken und deren Infrastruktur, was mit Kosten-, Datenschutz- und Sicherheitsbedenken behaftet ist. Diese Ansätze sind nicht skalierbar und führen zu einer Verschwendung von Testressourcen. Parasofts virtuelle Testdatenlösung konzentriert sich wieder auf das Testen und die bedarfsgerechte Rekonfiguration der Testdaten und ermöglicht parallele Integrationstests, die diese kritische Testphase verlassen.

Die Lösung für Ihre Probleme bei der Verwaltung von Testdaten
Geschrieben von

Jeff Peeples

Jeff Peeples ist Senior Product Manager bei Parasoft und leitet die funktionale Plattformausrichtung für SOAtest, Virtualize und CTP. Jeff verfügt über umfangreiche Erfahrung in der Definition von Lösungen und der Entwicklung von Roadmaps für Unternehmensbranchen wie Energie, Finanztechnologien und Reise-/Gastgewerbe.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.