Testdatenmanagement bei Applikationstests

Die richtige Teststrategie während der Entwicklungsphase von Software hilft nicht nur, die Qualität der fertigen Anwendung sicherzustellen. Sie kann auch schon in der Frühphase der Entwicklung Probleme und Designfehler aufdecken, die zu einem späteren Zeitpunkt nur mit hohen Kosten gelöst werden können. Doch die Testentwicklung und Qualitätssicherung können sich sehr schnell so kompliziert wie die ganze Anwendungsentwicklung selbst erweisen – und damit das Budget der Softwareentwicklung sprengen.

Komplexität beim Testen mit relationalen Daten

Den ersten Schritt beim Testen datenbankgestützter Anwendungen bildet die Erstellung der Testdatenbank. Da „reale“ Testdaten natürlich ideal geeignet sind, ist die Testdatenbank normalerweise ein Klon der Produktionsdatenbank. Doch die meisten Anwendungen bauen auf relationalen Datenbanken auf und sind daher entsprechend komplex: Dutzende, Hunderte oder gar Tausende Tabellen unterhalten zahlreiche Beziehungen untereinander und können damit die Navigation im Datenmodell erschweren. Dabei müssen es keine Großsysteme sein, die das Navigieren in zahlreichen Tabellen, Zeilen und Spalten zur echten Herausforderung werden lassen. Bereits ein Dutzend Tabellen können so zahlreiche Beziehungen enthalten, dass es schwierig wird, die benötigten Datenbankdaten zu erstellen, zu ändern und ständig zu aktualisieren.

Um Testdaten erstellen zu können, greifen die Entwickler häufig auf komplexe Extraktionsprogramme zurück. Da diese aber alle definierten und umgesetzten Beziehungen berücksichtigen müssen, sind sie recht kompliziert zu entwickeln. Außerdem gibt es nach dem Testlauf meist keine klare und einfache Methode, um die Ergebnisse auf Korrektheit zu überprüfen.

Ein umfassendes Testsystem muss in der Lage sein, die Abhängigkeiten in relationalen Datenbanken zu bewältigen und sie auch bei jeder Extraktions-, Vergleichs- oder Aktualisierungsoperation zu berücksichtigen. Je nachdem, aus welchen Datenbanktypen die Testdaten stammen, ergeben sich dabei andere Anforderungen an das Testsystem. Im Folgenden werden sie kurz skizziert:

Testdaten aus verschiedenen Datenbanken

Die meisten Unternehmen speichern ihre Datenbestände in verschiedenen relationalen Datenbanken wie DB2, DB2 UDB, Oracle, SQL Server, Sybase und Informix. Aber auch hierarchische oder nicht relationale Formate wie VSAM-Dateien und IMS-Datenbanken enthalten oft Unternehmensdaten, auf die die neu entwickelte Anwendung zugreifen soll.

Beim Testen komplexer Anwendungen werden folglich Daten aus relationalen und nicht relationalen Datenquellen benötigt. Die Integration verschiedener Systeme ist hier eine typische Anforderung. Aber auch Qualitätstests müssen Daten aus verschiedenen Datenbankmanagementsystemen auf unterschiedlichen Plattformen handhaben können.

Testdaten aus homogenen Datenbanken

Bei homogenen Datenbanken ist die Technologie der Live-Datenbank und der Testdatenbank identisch oder zumindest kompatibel. Eine der Herausforderungen bei der Erstellung von Testdaten ist die Extraktion kompletter Subsets von zusammengehörigen Daten und die Aufrechterhaltung der Referenzen zwischen diesen Daten. Deshalb müssen alle Beziehungen im Datenmodell durchforstet werden, wobei es keine Rolle spielt, ob diese in der Datenbank oder in der Anwendung definiert sind (siehe Abbildung 1).

Testdaten aus heterogenen Datenbanken

Umgebungen mit heterogenen Datenbanken können unterschiedliche Hardwarekomponenten, Betriebssysteme und Datenmodelle sowie syntaktische und semantische Unterschiede aufweisen. Hier können vor allem Probleme bei der Datenkompatibilität und -umsetzung auftreten. In der Regel passiert das bei der Migration einer Anwendung auf eine andere Datenbank oder Testumgebung. Beispielsweise kann es erforderlich sein, Datenteilmengen aus einer DB2-UDB-Produktionsdatenbank zu extrahieren und in eine Oracle-Testdatenbank einzufügen. Diese Verlagerung kann zu Problemen bei Sonderregistern oder Datums- und Zeitmarken führen, die von jeder DBMS unterschiedlich gehandhabt werden (siehe Abbildung 2).

Neben der Extraktion von Daten-Subsets mit intakten Referenzen müssen also auch Kompatibilitätsunterschiede automatisch gemanagt werden.

Verteilte Testdaten aus unterschiedlichen relationalen Datenbanken

Sind Daten in verschiedenen relationalen Datenbanken gespeichert, gestaltet sich die Testdatengewinnung komplexer. So können Lohnbuchhaltungsdaten beispielsweise in einer DB2-UDB-Datenbank und Mitarbeiterdaten in einer Oracle-Datenbank gespeichert sein (siehe Abbildung 3).

Nun müssen nicht nur die referenzielle Integrität und Datenkompatibilität gewahrt und umgesetzt, sondern auch der Zugriff auf die verteilten Daten ermöglicht werden. Ziel ist es, über einen einzelnen Extraktionsprozess relationale Daten aus verschiedenen Datenbanken zu extrahieren.

Verteilte Testdaten aus nicht relationalen und relationalen Testdaten

Anwendungen mit relationalen und nicht relationalen Daten bereiten beim Testen noch mehr Probleme. Eine Anwendung zur Auftragserfassung erfordert beispielsweise Produktdaten aus einer VSAM-Bestandsdatei und Kundendaten aus einer DB2-Auftragserfassungstabelle. Allerdings können VSAM-Dateien oder IMS-Datenbanken wegen ihrer unterschiedlichen Strukturen nicht ohne Weiteres in relationale Daten integriert werden (siehe Abbildung 4).

Eine wirksame Teststrategie muss hier präzise Subsets von realistischen verteilten Testdaten aus nicht relationalen und relationalen Datenbanken erstellen können. Um Daten zwischen komplexen nicht relationalen und relationalen Quellen zu ergänzen, wird ein Tool benötigt, das dies leistet. Aufgrund der geringen Flexibilität von VSAM- und IMS-Datenbanken ist es schwierig, Datenteilmengen ohne Auswahlkriterien zu extrahieren. Die Möglichkeit, solche Kriterien dynamisch anzugeben, würde den Verarbeitungsaufwand aber deutlich reduzieren und die Qualität der Testdaten erheblich verbessern.

Testdatenbank erstellen

Zu den gängigeren Ansätzen beim Aufbau von Testdatenbanken gehören das Klonen der Produktionsdatenbank(en) und das Schreiben angepasster Programme für das Extrahieren von Testdatenteilmengen. Diese Verfahren sind jedoch arbeitsintensiv, fehlerbehaftet und erfordern umfangreiche CPU- und Netzressourcen.

Wer eine ganze Produktionsdatenbank mit Hunderten oder sogar Tausenden von Tabellen nur für Testzwecke klont, steht zunächst vor einem Kapazitätsproblem, dann vor einem Qualitätsproblem. Denn bei großen Testdatenbanken lassen sich spezielle Testfälle nur schwer verfolgen und bewerten.

Außerdem verzögert das Klonen einer kompletten Produktionsdatenbank auch die Ausführung von Testzyklen, da die Datenmenge meist sehr groß ist. Das Testen mit kleineren, realistischen Datenteilmengen ist deutlich schneller und belastet den Testprozess erheblich weniger.

Um Daten aus der Produktionsdatenbank in eine Testdatenbank zu kopieren, müssen sie durch Auswahlkriterien, Zufallsauswahl, Datenpartitionierung/-gruppierung oder Eingrenzung der Daten nach Tabelle oder Beziehung identifiziert werden. Ohne eine allgemein gültige Lösung setzen jedoch all diese Verfahren das Schreiben angepasster Programme voraus.

Referenzielle Integritätsbedingungen (RI)

Sogenannte RI-Bedingungen können von der Datenbank und/oder der Anwendung umgesetzt werden. In der Regel ist die anwendungsspezifisch umgesetzte RI-Bedingung deutlich komplexer. So kann die Anwendung beispielsweise Beziehungen beinhalten, die kompatible, aber nicht identische Datentypen, modulare und partielle Spalten und datengesteuerte Beziehungen verwenden. Das Extraktionsprogramm muss daher über entsprechende Funktionen zur Bearbeitung jedes dieser Beziehungstypen verfügen.

Vervielfältigung von Testdaten

Sehr häufig wird beim Erstellen neuer Testdaten für einzelne oder mehrere Benutzer ein kleiner Teil der „richtigen Testdaten“ in weitere Datensets „vervielfältigt“. Das klingt einfach, birgt jedoch zahlreiche Herausforderungen.

Zunächst müssen die Primärschlüsselwerte geändert werden, um zu verhindern, dass doppelte Zeilen erstellt werden. Dann müssen die geänderten Primärschlüsselwerte in einer übergeordneten Tabelle (oder Eignertabelle) auf alle untergeordneten Tabellen verteilt werden, um die referenzielle Integrität beizubehalten. Ohne die Möglichkeit, Daten zu verteilen und die referenzielle Integrität präzise zu erhalten, kann die Qualität der Testdaten nicht gewährleistet werden.

Testdaten maskieren und deidentifizieren

Aus Datenschutzgründen wird es immer wichtiger, sensible Daten umwandeln und deidentifizieren zu können. Angesichts der Komplexität jedoch keine leichte Aufgabe! Um Quellen- und Zielspalten sowie Transformationsfunktionen zuordnen zu können, sind flexible Lösungen nötig. Kundenkennnummern lassen sich relativ einfach mit einer Zufallszahlfunktion deidentifizieren. Sozialversicherungsnummern, in der das Geburtsdatum des Versicherungsnehmers steckt, sind schon schwieriger, da sie auch nach der Entschlüsselung realistisch aussehen sollen. Möglichkeiten bieten Unterzeichenfolgen, fortlaufende Zahlen, Prioritätssteuerung nach Verweildauer bei Datumsangaben, Währungsumrechnungen oder Tabellensuchfunktionen oder auch die Einbindung von benutzerdefinierten Datenkonvertierungsprogrammen.

Um jedoch die referenzielle Integrität der umgewandelten Daten zu erhalten, muss ein maskiertes Datenelement in einer übergeordneten Tabelle auch in allen zugehörigen untergeordneten Tabellen in der Datenbank gleich maskiert werden. Andernfalls wird die Beziehung zwischen übergeordneten und untergeordneten Tabellen unterbrochen, die Testdaten sind unpräzise, und die Anwendungstests geben ungültige Ergebnisse aus.

Fehlerbedingungen erzwingen

Als Einstieg für Tests empfiehlt es sich, realistische Daten-Subsets aus einer relationalen Produktionsdatenbank zu ziehen. Mit einem Editor lassen sich mit den extrahierten Daten bestimmte Fehlerbedingungen oder spezielle Verarbeitungsfunktionen prüfen. Außerdem erleichtert der Editor das Durchsuchen/Anzeigen von Daten und das Lösen von Problemen, womit sich vor allem im relationalen oder geschäftlichen Kontext Datenbeziehungen und die Struktur des Datenmodells gut darstellen lassen.

Testergebnisse bewerten

Bei einer wirksamen Teststrategie müssen sich die Testdaten vor und nach einem Testlauf automatisch vergleichen lassen. Änderungen wie Einfügungen, Löschungen und Aktualisierungen, die über Hunderte von Tabellen verteilt sind, müssen berücksichtigt werden. Bei einer manuellen Analyse werden Unregelmäßigkeiten, etwa überflüssige Zeilen, oft nicht erkannt.

Testumgebung verwalten

Die Qualität der Testumgebung ist genauso kritisch wie die Qualität der Testdaten. Hier kommt es vor allem darauf an, dass sich die Testdatenbank durch die Funktionen Sichern /Wiederverwenden aktualisieren lässt, um auch in späteren Testläufen präzise Ergebnisse zu erzielen. Durch die Einbindung von Metadaten in den Extraktionsprozess wird außerdem sichergestellt, dass man die Testdaten reproduzieren und Änderungen am Datenmodell schnell und präzise vornehmen kann.

Fazit

Mit einem Testdatenmanagement und automatisierten Tests lässt sich jede Phase im Testprozess verbessern. Die Vorteile: Zeiteinsparungen, höhere Genauigkeit, kürzere Markteinführungszeiten, Kostensenkungen. Zudem lassen sich mit einem Testdatenmanagementsystem effiziente Teststrategien umsetzen und so die Zuverlässigkeit komplexer Anwendungen sicherstellen.

Ein umfassendes Testdatenmanagement mit entsprechendem Funktionsumfang muss dabei Folgendes ermöglichen:

• Erstellung realistischer, referenziell intakter Subsets von Produktionsdaten aus verschiedenen Datenquellen

• Unterstützung komplexer Datenmodelle und Navigation in datenbank- und/oder anwendungsdefinierten Beziehungen

• Sicherung, Wiederverwendung und gemeinsame Nutzung von Verarbeitungsspezifikationen, um Testdatenbanken schnell und präzise aktualisieren und eine konsistente Testumgebung verwalten zu können

• Durchsuchen und Bearbeiten von Testdaten in deren relationalem Kontext, um spezielle Testfälle erstellen und Fehlerbedingungen erzwingen zu können

• Automatischer Vorher-/Nachher-Vergleich der Testergebnisse, um Probleme und Unregelmäßigkeiten zu erkennen

• Integration automatisierter Tests in das Testdatenmanagement, um die Anwendungsfunktionalität unter realistischen Bedingungen und mit optimaler Datengenauigkeit testen zu können

• Umfangreiches Funktionsspektrum zur Deidentifizierung von vertraulichen und personenbezogenen Daten

Selbstverständlich müssen diese Funktionen für alle in den Entwicklungs- und Testprozess eingebundenen Personen verfügbar sein. Eine Lösung, die diese Herausforderungen adressiert, ist beispielsweise die IBM Optim Testdata-Management-Solution. Sie bietet bewährte Mechanismen zur Segmentierung und zum Editieren von Testdaten sowie zum Bewerten der Testergebnisse. (ala)