Testdaten-Generator QDATA

Weniger Testausprägungen und höhere Testqualität mittels Datengenerierung und -optimierung

Hier lesen Sie, wie ...

  • Testdatengenerierung Ihre Testqualität erhöht und gleichzeitig die Testaufwände reduziert,
  • Sie realistische Last-/Performancetest durchführen,
  • Sie Testdaten generieren und in Ihr IT-System migrieren.
Die zunehmende Komplexität von IT-Systemen stellt die Qualitätssicherung vor neue Herausforderungen. Für die Durchführung von Funktions- und Lasttests werden entsprechende Testdaten als Eingabedaten für die Benutzeroberfläche und entsprechende BackEnd-Daten für das zu testende IT-System benötigt. Ziel ist es, alle Funktionen vollständig bzw. das Verhalten einzelner Komponenten des IT-Systems unter Last zu testen.
In der Praxis stehen Testteams nur selten Testdaten zur Verfügung. Zum einen sind bei der Neuentwicklung von IT-Systemen keine Produktionsdaten vorhanden und zum anderen können beim Test von existierenden IT-Systemen die Produktionsdaten aus Gründen des Datenschutzes oft nicht eingesetzt werden. Die allgemein angenommene Anonymisierung von Produktionsdaten reicht nicht aus, da aus den Daten noch Profile (bspw. Bewegungsprofile) abgeleitet werden können. Eine notwendige Modifizierung ist konzeptionell und technisch sehr aufwendig und dem Autor kein Beispiel aus der Praxis bekannt.
Eine Lösung bietet hier die Generierung von Testdaten. Größte Herausforderung ist dabei die Daten in Struktur, Kontext und Quantität generieren zu können (synthetisch, realistische Daten). Das heißt, dass die Datenwerte der realen Welt entsprechen. So sollte ein Name als 'Peter Meier' und nicht nur eine Zeichenfolge 'V1 N1' ausgeprägt sein. Je realistischer die Daten sind, umso intuitiver können diese für Testzwecke eingesetzt und mögliche Fehlermaskierung vermieden werden.

Szenario A: Massendaten für Last- und Performancetests

Massendaten werden benötigt, um alle in der Produktion möglichen Zustände eines IT-Systems und das Verhalten der technischen Komponenten eines IT-Systems unter produktionsnaher Last testen zu können. Abstrakte Daten führen meist zu deutlich geringeren Datenvolumina und Datenkonstellationen, die zu nicht praxisrelevanten Optimierungsmöglichkeiten der Datenbanken bei der Index-Erstellung führen. Dadurch werden die Testergebnisse eines Lasttest verfälscht.
Abbildung 1 zeigt grob das Datenmodell der SAP-Lösung cProjects. Für den Test eines solchen Systems sind Testdaten mit allen möglichen Zuständen für alle einzelnen sechs Entitäten sowie alle Beziehungen zwischen diesen Entitäten zu erstellen. Des Weiteren sollte die Wartung und Pflege dieser für weitere Testiterationen nicht bedacht werden. Dies ist aus Gründen des Aufwandes und der Fehleranfälligkeit manuell nicht zu realisieren. Eleganter ist hier die Erstellung und Anpassung eines Datenmodells, aus welchem die Testdaten zeitnah und ortsunabhängig bereitgestellt werden können.
Datenmodell Messdaten
Abbildung 1: Datenmodell SAP cProjects

Szenario B: Mittels des Pairwise-Ansatzes Testfälle optimieren

Die durch Kombinatorik von Äquivalenzklassen ableitbaren Testfälle können schnell eine nicht mehr durchführbare Anzahl von Testfällen überschreiten. Das Unternehmen Telcordia Technologies hat in einer Untersuchung herausgefunden, dass Fehler zu über 90% durch Wertepaare entstehen. Daraus kann man ableiten, dass Testfälle nur noch (bedingt) ausgeführt werden müssen, wenn deren einzelne Wertepaare bereits durch andere Testfälle verifiziert wurden. Bspw. werden für den vollständigen Funktionstest der Amazon-Suchmaske ca. 74.000 Testfälle benötigt. Mit der Anwendung des Pairwise-Ansatzes kann diese enorme Anzahl auf 69 Testfälle reduziert werden. Das heißt, dass durch den Einsatz von Testdatengeneratoren und des Pairwise-Ansatzes die Testabdeckung erhöht und gleichzeitig der Testaufwand drastisch reduziert werden kann.
Der Pairwise-Ansatz wird im Folgenden an einem Beispiel erläutert (siehe Abbildung 2). Eine Eingabemaske mit drei Eingabeparametern und jeweils zwei möglichen Äquivalenzklassen soll getestet werden. Für den vollständigen Test der Eingabemaske ergeben sich daraus acht Kombinationen (Testfälle, linke Tabelle). Diese enthalten Wertepaare, die mehrfach in den unterschiedlichen Testfällen vorkommen (siehe blaue Markierung). Um den Testaufwand zu reduzieren werden nun die Kombinationen entfernt, die aus bereits bekannten Paarkombinationen bestehen (siehe rechte Tabelle). Man beachte, dass sich die Anzahl der zu testenden Eingabekombinationen in diesem Fall halbiert hat, ohne die Testabdeckung zu verringern. Mit zunehmender Anzahl an Testfällen verstärkt sich der Effizienzgrad der Pairwise-Optimierung. Die Optimierung selbst ist nur bei einer sehr geringen Anzahl an Testfällen manuell möglich.
Testdaten Pairwise Methode
Abbildung 2: Beispiel Pairwise-Optimierung

QDATA - Das Werkzeug

QMETHODS bietet Ihnen den Testdatengenerator QDATA in der Version 2.5 für die Generierung von realistischen Massendaten und zur Optimierung von Testfällen an. Die Konfiguration der zu generierenden Daten erfolgt in einer einfach strukturierten XML-Datei, die mit jedem beliebigen Texteditor bearbeitet werden kann (siehe Abbildung 4). QDATA besteht aus dem Generator, aus einem Pool von unterschiedlichen Datenquellen und entsprechenden Wissensdatenbanken (siehe Abbildung 3). Der Generator verarbeitet die XML-Konfiguration und bedient sich hierfür unterschiedlicher Datenquellen, die entsprechende Datenwerte zur Verfügung stellen. Mittels Kombinatorik kann so eine große Anzahl unterschiedlicher Daten erzeugt werden. Durch eine definierte Plugin-Schnittstelle können individuelle Datenquellen erstellt und in den QDATA-Testdatengenerator integriert werden. Das Ergebnis eines Datengenerierungslaufes ist eine Textdatei mit kommaseparierten Werten (CSV-Datei). Diese können direkt für die Parametrisierung von Testskripten in Testautomationswerkzeugen eingesetzt werden.
Mittels des Pairwise-Optimizers können Daten für Testfälle optimiert werden, wodurch einerseits die Testabdeckung erhöht (Test aller möglichen Eingabekombinationen) und gleichzeitig der Testaufwand reduziert (Test aller Wertepaare) werden kann (Details zum Pairwise Testing siehe Szenario B)..
Testdatengenerator Architektur
Abbildung 3: Architektur des QDATA-Testdatengenerators
Die Bereitstellung und Pflege von Wissensdatenbanken mit in der Praxis häufig benötigten Daten ist ein wichtiger und permanenter Bestandteil der Weiterentwicklung des Testdatengenerators. Die Datenqualität ist von entscheidender Bedeutung, da Fehler in den Daten und damit Fehlfunktionen sehr schwer zu identifizieren sind. Kundenspezifische Wissensdatenbanken können mittels Datei- oder SQL-Datenquelle in den Generationsprozess einfach eingebunden werden. Folgende Wissensdatenbanken stehen Ihnen derzeit zur Verfügung:
  • Nachnamen (2900) sowie männliche und weibliche Vornamen (2450)  
  • Straßennamen (550), Ortsnamen mit zugehörigen Postleitzahlen, Telefonvorwahlen sowie GeoDaten (15.800)  
  • Staaten und Länder sowie deren eindeutige Kurzformen (300)  
  • Banknamen und deren Bankleitzahlen (21.000)  
  • Flughäfen und deren eindeutige Kurzform (340)  
  • Länderkennung für Autokennzeichen (406)  
  • Rollenbezeichnungen (30) und Qualifikationen (280)  

Migration Ihrer BackEnd-Daten in ein IT-System

Nach der Generierung der Daten sind diese in das gewünschte IT-System zu migrieren. Im Folgenden werden drei mögliche Vorgehensweisen erläutert:
  • Testautomationswerkzeuge
    Die einfachste Variante ist die Verwendung von Werkzeugen zur Automation von Tests. Diese können Daten sehr einfach über die Benutzer- oder Programmschnittstelle eines IT-Systems einbringen. Der Vorteil dieser Variante ist, dass mögliche Funktionalitäten, die zur Anreicherung oder zur Veränderung der Ursprungsdaten führen, ausgeführt werden. Beispielhaft seien an dieser Stelle die Produkte LoadRunner, QuickTest oder WinRunner der Firma Mercury erwähnt.  
  • Produktspezifische Schnittstellen und Werkzeuge
    Einige Produkthersteller bieten speziell für Ihre Produkte konzipierte Datenimport- und -exportschnittstellen bzw. -werkzeuge an. Als Beispiel sei hier die Legacy System Migration Workbench (LSMW) des SAP für die R/3-Umgebung erwähnt, die für die Datenmigration von Altsystemen in das SAP-System konzipiert wurde.  
  • Via SQL in die Datenbank
    Wenn keine andere Variante zur Verfügung steht, kann man die Daten auch direkt in die Datenbank des IT-Systems einbringen. In den meisten Fällen wird es sich um eine relationale Datenbank und die Verwendung von SQL handeln. Problematisch bei dieser Variante ist, dass Daten verändernde Funktionalitäten in den Daten selbst nachzubilden sind, entsprechende Schlüssel und Datensätze für die Abbildung von Beziehungen zwischen Entitäten (Datensätzen) einzufügen sind sowie die Konsistenz- und Integritätsbedingungen der Datenbank sicherzustellen sind.  

Ein "Hello World"-Beispiel

In Abbildung 4 ist ein Beispiel einer XML-Konfiguration für die Generierung von 10.000 Mitarbeiterinformationen dargestellt. Für jeden Mitarbeiter wird eine eindeutige Benutzeridentifikation, ein Vor-/Nachname sowie eine Privatadresse generiert. Name, Vorname und Ort werden mittels Kombinatorik erstellt. Die Anzahl der Kombinationen ist gleichzeitig die maximale Anzahl der möglichen zu generierenden Testdaten. In Abbildung 5 ist die Eingabekonsole der Datengenerierung dargestellt und Abbildung 6 zeigt einen Ausschnitt der generierten Testdaten.
 <qdata name="employee address" number="10000">   <item name="UserID" datasource_ref="Integer" type="UNIQUE">     <parameter name="prefix" value="D"/>     <parameter name="from" value="10000"/>     <parameter name="to" value="99999"/>   </item>   <item name="Name" datasource_ref="File" type="COMBINATION">     <parameter name="file" value="name.dat"/>   </item>   <item name="Vorname" datasource_ref="File" type="COMBINATION">     <parameter name="file" value="surname.dat"/>   </item>   <item name="Ort,PLZ" datasource_ref="File" type="COMBINATION">     <parameter name="file" value="city-zip.dat"/>     <parameter name="index" value="0"/>     <parameter name="index" value="1"/>   </item>   <item name="Strasse" datasource_ref="File" type="VARIABLE">     <parameter name="file" value="street.dat"/>   </item>   <item name="Nr." datasource_ref="Integer" type="VARIABLE">     <parameter name="from" value="1"/>     <parameter name="to" value="200"/>     <parameter name="access" value="random"/>   </item> </qdata> 
Abbildung 4: XML-Konfiguration für die Generierung einer Angestelltenliste
Datengenerierung
Abbildung 5: Ausführung einer Datengenerierung
 UserID,Name,Vorname,Ort,PLZ,Strasse,Nr. .... D13560,Paetz,Alon,60596,Darmstadt,Frankendamm,59 D13561,Schauer,Andre,07987,Mohlsdorf,Am Umspannwerk,10 D13562,Bargmann,Ann-Katrin,99885,Ohrdruf,Anklamer Straße,113 D13563,Spenke,Friedrich,36404,Martinroda,Svendborger Straße,5 D13564,Linde,Gabriele,13089,Berlin,Gentzkowstraße,108 D13565,Leister,Gebhard,54675,Obergeckler,Grünhufer Bogen,63 D13566,Leifers,Henry,96489,Oberfranken,Kornwinkel,68 D13567,Schiemann,Kai-Luca,27243,Weser-Ems,Klosterstraße,62 D13568,Hagemeier,Roberto,95346,Oberfranken,Drigger Weg,145 D13569,Scheibler,Sophie,73272,Stuttgart,Kolpingplatz,30 .... 
Abbildung 6: Ausschnitt aus den generierten Daten