Testdatenmanagement

Datenerfassung

Der erste Schritt eines Testdatenmanagements ist die Erfassung von echten vollständigen Testdaten. Im Gegensatz zur Testfallbeschreibung, die eher allgemein den Testfall als solches charakterisiert müssen nun die vollständige Datensets im Sinne einer späteren Erfassung definiert werden.

Basis kann die Testfallerstellung sein, die um weitere ergänzende Daten zu ergänzen sind. Dh. Der Schritt Testdatenmanagament beginnt vor dem Test. Oft ist aber bereits ein Test am Laufen und man will im Zuge des Test auf eine Automatisierung umschwenken. Eine andere Variante ist es daher, die über Makro-Recoder aufgezeichnete Erfassungsdaten oder die gespeicherten Auftragsdaten in den System zu nutzen, um diese Daten für eine spätere Eingabe / Verarbeitung aufzubereiten und zu nutzen.

Bearbeitung / Optimierung

Testdurchführung
Testdurchführung Hier am Beispiel des Tests einer Migration: Erfassung des "Erwarteten Ergebnis" und Prüfung der Ergebnisse an konkreten ausgewählten Testobjekten der Migration. Der Screenshot ist aus einem Excel basierten Tool für die Testdurchführung und dient als Vorstufe für eine spätere automatisierte Durchführung. Aber auch unabhängig von einer Automatisierung ist das Tool einsetzbar.

Im nächsten Schritt wird es notwendig werden, aus den gespeicherten Daten durch Routinen Testdaten zu selektieren, oder über mehrere Tage zu verteilten. Hier beginnt das Testdatenmanagement in seiner Kernfunktion. Die komplette Testdatenmenge wird über Steuertabellen in Testtage aufgeteilt, ggf. in der zeitlichen Sequenz gezielt aufgebaut, und z.T. vielleicht gar nicht in das Testdatenset eingelesen.

Die Ausgabe sind Datensets für bestimmte Verarbeitungsschritte, Buchungstage, Eingabeschnittstellen oder andere logische Einheiten.

Beispiel Gattungsdaten

Testdatenoptimierung
Testdatenoptimierung Bei jedem manuellem Test entstehen Fehler, die eine Automatisierung erschweren. Jeder Fehler in den testdaten verunreinigt das Testergebnis. Daher müssen Testdaten vor einer Automatisierung optimiert zusammengestellt werden. Hier ein Beispiel für die Mischung von Gattungsdaten aus verschiedenen Testzyklen.

In einer unserer Testsituationen gab es die Notwendigkeit ein System mit geeigneten Gattungsdaten zu befüllen. Da nicht in allen Testzyklen alle Test durchgeführt wurden, besteht als erstes der Bedarf die verschiedenen Testszyklen und damit bzgl. Ereignisdaten due dazugehörenden Transaktionen und Buchungen zu mischen. Nur durch die Verdichtung der jeweils korrekt durchgeführten Test und der dazugehörenden Testdaten konnten wir eine Basis für die Automatisierung schaffen.

Neben dem Ziel einen kompletten Testfunktionsraum zu schaffen sollten a) auch keine unnötigen Gattungen berücksichtigt werden (wegen Performance) und b) solllte die Verarbeitung von Akualisierungsmeldungen möglichst während der Automatisierung reduziert werden. Jeder Eingriff und sogar jede einzelne Aktion im Testablauf ist ein Risiko und ist damit so weit wie möglich zu vermeiden. Während a) ein einfache Filter war, galt es bei b) die aufgezeichneten Meldungen von der Dauer unseres Testzyklus über 4 Wochen auf möglichst wenige Tage zu verdichten. In einer Gattung darf aber nie aber mehr als eine Aktualisierungsmeldung pro Verarbeitungstag vorkommen. Denn nur diese Menge entspricht dem normalen Datenfluss. Bei mehreren Meldungen pro Tag, wäre die Sequenz der Verarbeitung nicht sicher gestellt. In der Konsequenz mußte das Paket "Aktualisierungsmeldungen" der WM vom Tag 2 bis Tag X in die Einzelgattungen zerlegt werden, und pro Gattung optimiert werden. Daduch wurden aus 19 Testdaten nur noch insgesamt 6 Aktualisierungspakete und 6 technische Testtage in der Automatisierung.

Als zusätzliche Komplexität war es notwendige bestimmte Meldungen gezielt an bestimmten Testtagen zu haben, um bewußt mit den Umsatzdaten aus Handelstransaktionen gezielte Testkonstellationen zu generieren. Beispiel: Eine Transaktion nutzt die vorliegenden Ereignisdaten um eine spezielle Buchung mit passenden Parametern durchzuführen. Eine anschließende, verspätete Meldung der Ereignisdaten muss synchron zur Korrkturbuchung sein. Gattungsdaten und Buchungsumsätze dürfen nicht beliebig im Testablauf einlaufen, sondern sind zu synchronisieren.

Mit einem Excel-basierten Lösung wurden die Gattungsdaten pro Tag eingelesen, die eine Steuertabelle wurde bzgl. benötigten Gattungen gepflegt. Die vorgegeben Aktualisierungsmeldungen wurden in eine Art Tabelle eingetragen. Für den Fall der synchronisierten Testfälle lautete ein Eintrag: Lese Gattung X von Einlesetag 5 und gib diese Meldung (zwangsweise) im Testpaket 4 aus. Alle anderen Gattungen wurden optimal verdichtet. Die Verdichtung der anderen Gattungen war im VBA Code integriert und war daher "pflegefrei". Lediglich ein Eintrag "Gattung xyz" in Testdatenmischung übernehmen war vorzunehmen.

Eine kleine technische Schwierigkeit war, dass die Gattungsdaten auch das Zeichen "binär #00" enthalten können, und das ist in Excel nicht einfach zu speichern ist. Für Excel ist das Zeichen "00" das Ende einer Eingabe. Beim Einlesen das Daten für das Datenmanagement mußten wir auf Dateilesebefehle zurückgreifen und konnten die Daten nicht über den "Datei öffnen Dialog" einlesen. Bei Dateizugriff wurde vor der Abspeicherung der Daten im Tool das Zeichen auf "#FF" umgewandelt und beim Erstellen der Pakete wieder auf die binäre #00 zurückgestellt.

Summary

Mit einfachsten Boardmitteln läßt sich also ein Testdatenmanagement aufbauen. Jederzeit konnten weitere Daten ergänzt werden, die als Datenmitschnitte weiterer Testtage einfach am Ende ergänzt wurden. Nur die Steuertabellen mußten jeweils dezidiert gepflegt werden. Ersetzen die neuen Testdaten vorhandene alte Testfälle, oder ergänzen sie diese?

Die Testdatenpakete wurden per Excel generiert und an die IT zum Einspielen in die System übergeben. Die entsprechenden Abläufe waren automatisiert und auf ein Raster von 10 Verarbeitungstagen ausgerichtet. Es ist damit Aufgabe des Testdatenmanagement sich zu überlegen, welche Daten an welchen Tagen welche Verarbeitung auslösen und welche Ergebnisse erwartet werden können.

Was wir nicht mehr getan haben, ist aus der Basis der Testdatenmischung auch automatisch eine Soll-Definition abzuleiten, um z.B. fehlende Testdaten zu ermitteln.


weiter zu Testvalidierung