Richtlinie: Testdaten
Diese Richtlinie ist eine Einführung in das Design von Testdatengruppen
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Erläuterung

Das Testdesign benennt und beschreibt zwei wichtige Artefakte: Test-Scripts und Testfälle. Diese beiden Artefakte können ohne Testdaten weder implementiert noch ausgeführt werden. Sie sind lediglich Beschreibungen von Bedingungen, Szenarien und Pfaden ohne konkrete Werte, die sie näher charakterisieren würden. Die Testdaten selbst sind kein eigenständiges Artefakt, haben aber dennoch entscheidenden Einfluss auf den Erfolg (oder Misserfolg) von Tests. Tests können nicht ohne Testdaten implementiert oder ausgeführt werden, denn Testdaten sind für Folgendes erforderlich:

  • Eingaben zur Erzeugung eines Zustands
  • Ausgaben zur Bewertung einer Anforderung
  • Unterstützung (eine Vorbedingung für den Test)

Es ist daher ausgesprochen wichtig, beim Erarbeiten von Testfällen die zugehörigen Daten anzugeben. (Vergleichen Sie hierzu die Abschnitte Arbeitsergebnis: Testfall und Richtlinie: Testfall.)

Beim Spezifizieren der eigentlichen Testdaten müssen vier Merkmale berücksichtigt werden:

Jedes dieser Merkmale ist in den folgenden Abschnitten detaillierter erläutert:

Datentiefe

Die Verschachtelungstiefe ist der Umfang oder die Menge der für Tests verwendeten Daten. Zu wenig Daten können unter Umständen nicht die realen Bedingungen widerspiegeln, zu viele Daten sind dagegen nur schwer zu steuern und zu verwalten. Daher kommt der Datentiefe eine hohe Bedeutung zu. Im Idealfall wird zu Testbeginn nur eine kleine Datengruppe verwendet, die die kritischen Testfälle (positiven Testfälle) unterstützt. Wenn sich die Verlässlichkeit der Daten während der Tests zunehmend bestätigt, kann die Datenmenge vergrößert werden, bis die Datentiefe für die implementierte Umgebung repräsentativ ist (oder bis eine angemessene/realisierbare Datentiefe erreicht ist).

Schwankungsbreite

Die Schwankungsbreite gibt an, in welchem Ausmaß die Testdatenwerte variieren. Die Datentiefe lässt sich einfach durch das Erstellen weiterer Datensätze steigern. Dies ist oft eine gute Lösung, berücksichtigt jedoch nicht die Schwankungsbreite, die bei tatsächlichen Daten zu erwarten ist. Ohne diese Datenvariationen können bestimmte Mängel unter Umständen nicht erkannt werden (schließlich werden an einem Bankautomaten nicht immer nur ein Betrag von € 50,00 abgehoben). Die Testdatenwerte müssen deshalb die in der implementierten Umgebung vorkommenden Werte widerspiegeln, z. B. eine Abhebung von € 10,00 oder € 120,00. Außerdem sollten die Testdaten Informationen aus dem realen Leben enthalten. Dazu gehören unter anderem:

  • Namen mit Titeln, numerische Werte, Interpunktion uns Suffixe:
    • Dr. Jochen Bandin, Frl. Susanne Schmitt und Dipl.-Ing. Jochen P. Mayer
    • Johannes Paul II, Stefan Wittbach jun. und Karl Ebstein, General aD
    • Ellen Jonas-Schmied, Britta L. Telenius
  • Adressen mit mehreren Zeilen, z. B.:
    • 6500 Broadway Street
      Suite 175
    • 1550 Broadway
      Floor 17
      Mailstop 75A
  • Postleitzahlen von Städten (und Landescodes/Bundesländer) sowie echte Telefonnummern mit der richtigen Vorwahl
    • Lexington, MA, USA + 01 781 676 2400
    • Kista, Schweden +46 8 56 62 82 00
    • Paris, Frankreich +33 1 30 12 09 50

Die Testdatenwerte können reale Daten physisch oder statistisch repräsentieren, um eine ausreichende Schwankungsbreite zu erzielen. Beide Methoden sind wertvoll und zu empfehlen.

Wenn Sie Testdaten erstellen möchten, die implementierte Daten physisch repräsentieren, stellen Sie für jedes Datenelement der implementierten Datenbank fest, welche Werte (Bereiche) zulässig sind, um für jedes Datenelement zu gewährleisten, dass mindestens ein Datensatz der Testdaten jeden zulässigen Wert enthält.

Beispiele:

  Kontonummer (Bereich) PIN
(ganze Zahl)
Kontostand
(Dezimalzahl)
Kontoart
(Zeichenfolge)
(S) 0812 0000 0000 bis
0812 9999 9999

(G) 0829 0000 0000 bis
0829 9999 9999

(X) 0799 0000 0000 bis
0799 9999 9999

0000 - 9999 -999.999,99 bis 999.999,99 S, G, X
Datensatz 1 0812 0837 0293 8493 -3.123,84 S
Datensatz 2 0812 6493 8355 3558 8.438,53 S
Datensatz 3 0829 7483 0462 0352 673,00 G
Datensatz 4 0799 4896 1893 4896 493.498,49 X

Die obige Matrix enthält die minimale Anzahl von Datensätzen, mit denen die akzeptablen Datenwerte physisch dargestellt werden können. Unter 'Kontonummer' gibt es einen Datensatz für jeden der drei Bereiche, alle PINs liegen innerhalb des angegebenen Bereiches und es gibt mehrere verschiedene Kontostände, sogar einen im Sollbereich. Außerdem gibt es Datensätze für jede der unterschiedlichen Kontoarten. Dies sind wie gesagt nur die Mindestdaten. Zu empfehlen wären Datenwerte an den Grenzen der einzelnen Bereiche und innerhalb der Bereiche. (Lesen Sie hierzu den Abschnitt Richtlinie: Testfall.)

Der Vorteil einer physischen Darstellung besteht darin, dass die Größe der Stichprobe begrenzt und einfach zu verwalten ist, da sie sich im Wesentlichen auf die akzeptablen Werte beschränkt. Der Nachteil ist, das tatsächliche Daten aus dem realen Leben nicht vollkommen wahlfrei sind. Reale Daten neigen dazu, statistische Profile zu bilden, die das Leistungsverhalten beeinflussen. Dies lässt sich anhand einer physischen Darstellung jedoch nicht beobachten.

Testdaten, die reale Daten statistisch repräsentieren, sind nach einem statistischen Stichprobenverfahren aus den Produktionsdaten ausgewählte Testdaten. Wenn wir für die Analyse der Produktionsdatenbank dieselben Datenelemente wie oben verwenden, kommen wir zu folgenden Ergebnissen:

  • Gesamtanzahl der Datensätze: 294.031
  • Gesamtanzahl Konten der Art S: 141.135 (48 % aller Konten)
  • Gesamtanzahl Konten der Art G: 144.075 (49 %)
  • Gesamtanzahl Konten der Art X: 8.821 (3 %)
  • Die Kontonummern und PINs sind gleichmäßig auf den Bereich möglicher Werte verteilt.

Unsere Testdaten aus der statistischen Stichprobenentnahme würden 294 Datensätze umfassen (im Gegensatz zu den vier Datensätzen bei der obigen physischen Darstellung).

  Testdaten (0,1 Prozent der Produktionsdaten)
Anzahl der Datensätze Prozentsatz
Gesamtanzahl der Datensätze 294 100
Kontonummern
(S) 0812 0000 0000 bis
0812 9999 9999
141 48
Kontonummern
(G) 0829 0000 0000 bis
0829 9999 9999
144 49
Kontonummern
(X) 0799 0000 0000 bis
0799 9999 9999
9 3

Die obige Matrix berücksichtigt nur die verschiedenen Kontoarten. Bei der Entwicklung optimaler Testdaten für eine statistische Repräsentation müssten Sie alle signifikanten Datenelemente einbeziehen. Hierzu würden in unserem Beispiel auch die einzelnen Kontostände gehören.

Ein Nachteil der statistischen Darstellung ist, dass sie nicht immer das gesamte Spektrum akzeptabler Werte widerspiegelt.

Normalerweise werden beide Methoden der Testdatenauswahl angewendet, um sicherzustellen, dass alle Werte und Leistungs-/Verteilungsfragen berücksichtigt werden.

Die Schwankungsbreite der als Eingabe verwendeten Testdaten ist ebenso wichtig wie die unterstützenden Testdaten (vor dem Test vorhandene Daten).

Umfang

Der Umfang zeigt die Relevanz der Testdaten für das Testziel und steht in Beziehung zur Datentiefe und zur Schwankungsbreite. Die Verwendung vieler Daten ist keine Gewähr dafür, dass es auch die richtigen Daten sind. Wie bei der Schwankungsbreite müssen wir auch beim Umfang sicherstellen, dass die Testdaten für das Testziel von Relevanz sind, d. h., dass es Testdaten gibt, die unser spezifisches Testobjekt unterstützen.

In der folgenden Matrix repräsentieren die ersten vier Testdatensätze beispielsweise die akzeptablen Werte für jedes Datenelement. Es sind jedoch keine Datensätze für die Bewertung negativer Kontostände bei den Kontoarten G und X vorhanden. Die Testdaten enthalten zwar eine Kontoüberziehung (gültige Schwankungsbreite), sind aber dennoch unzureichend, denn sie erlauben nicht das Testen von negativen Kontoständen bei allen Kontoarten. Es müssten demnach weitere Datensätze für Kontoüberziehungen der verschiedenen Kontoarten hinzugefügt werden, um einen ausreichenden Umfang zu erhalten.

Kontonummer (Bereich) PIN
(ganze Zahl)
Kontostand
(Dezimalzahl)
Kontoart
(Zeichenfolge)
(S) 0812 0000 0000 bis
0812 9999 9999

(G) 0829 0000 0000 bis
0829 9999 9999

(X) 0799 0000 0000 bis
0799 9999 9999

0000 - 9999 -999.999,99 bis 999.999,99 S, G, X
Datensatz 1 0812 0837 0293 8493 -3.123,84 S
Datensatz 2 0812 6493 8355 3558 8.438,53 S
Datensatz 3 0829 7483 0462 0352 673,00 G
Datensatz 4 0799 4896 1893 4896 493.498,49 X
Neuer Datensatz 1 0829 3491 4927 0352 -995.498,34 G
Neuer Datensatz 2 0799 6578 9436 4896 -64.913,87 X

Der Umfang der als Eingabe verwendeten Testdaten ist ebenso wichtig wie die unterstützenden Testdaten (vor dem Test vorhandene Daten).

Architektur

Die physische Struktur der Testdaten ist nur für die bereits vorhandenen, vom Testobjekt zur Testunterstützung verwendeten Daten wichtig, z. B. für die Datenbank oder Regeltabelle einer Anwendung.

Nach einmaliger Ausführung sind die Tests keineswegs abgeschlossen. Innerhalb der Iterationen und zwischen den Iterationen werden die Tests wiederholt. Im Interesse einer konsistenten, zuverlässigen und effektiven Testdurchführung sollten die Testdaten vor Ausführung der einzelnen Tests in ihren ursprünglichen Zustand zurückversetzt werden. Dies gilt ganz besonders für automatisierte Tests.

Die Integrität, Zuverlässigkeit und Effizienz von Tests kann nur gewährleistet werden, wenn die Testdaten frei von externen Einflüssen sind und vor dem Test, während des Tests sowie nach dem Test einen bekannten Status haben. Zur Erreichung dieses Testziels müssen die beide folgenden Probleme gelöst werden:

  • Instabilität / Absonderung - Fernhalten jeder externen Beeinflussung der Testdaten
  • Anfangsstatus - Kenntnis des spezifischen Anfangsstatus der Daten und die Fähigkeit, diesen Status wiederherzustellen

Jedes dieser Probleme wirkt sich auf die Verwaltung der Testdatenbank, das Design Ihres Testmodells und die Interaktion mit anderen Testrollen aus.

Instabilität / Absonderung

Testdaten können aus folgenden Gründen instabil werden:

  • Modifikation durch externe, nicht testbezogene Einflüsse
  • Unkenntnis von Testern darüber, welche Daten von anderen Testern verwendet werden

Die Zuverlässigkeit und Integrität von Tests kann nur gewahrt bleiben, wenn die Testdaten ständig kontrolliert und die genannten Einflüsse unterbunden werden. Für die Absonderung der Testdaten gibt es unter anderem folgende Strategien:

  • Getrennte Testumgebungen: Jeder Tester arbeitet in seiner eigenen, physisch von anderen Testern getrennten Umgebung. Die Tester nutzen nichts gemeinsam, d. h., jeder verwendet ein eigenes Testobjekt und eigene Testdaten. Zu diesem Zweck könnte jeder Tester beispielsweise an einem eigenen PC arbeiten.
  • Separate Instanzen der Testdatenbank: Jeder Tester verwendet seine eigene Instanz der Daten, die von allen anderen Einflüssen abgeschirmt ist. Die Tester könnten sich eine physische Umgebung teilen oder sogar dasselbe Testobjekt verwenden. Solange jeder Tester mit seiner eigenen Instanz der Daten arbeitet, ist das Risiko einer Manipulation der Testdaten kalkulierbar.
  • Partitionierung der Testdaten/-datenbank - Alle Tester nutzen die Datenbank gemeinsam und wissen, welche Daten die jeweils anderen Tester verwenden. Ein Tester könnte beispielsweise mit den Datensätzen 0-99 arbeiten und ein anderer mit den Datensätzen 100-199 oder ein Tester kümmert sich um die Kunden, deren Nachnamen mit Aa-Kz beginnen, während sich ein anderer mit den Kundennamen befasst, die mit La-Zz beginnen.

Anfangsstatus

Das zweite Problem bei der Testdatenarchitektur ist das des Anfangsstatus, den die Daten zu Beginn der Testausführung haben müssen. Dieses Problem ist besonders brisant, wenn Tests automatisiert ausgeführt werden. Die Testdaten müssen ebenso wie das Testobjekt selbst einen bekannten Sollstatus haben, wenn die Testausführung beginnt. Auf diese Weise wird eine Wiederholgenauigkeit erreicht und die Verlässlichkeit, dass jeder Test so wie der vorherige ausgeführt wird.

Dieses Problem wird in der Regel mit vier Strategien gelöst:

  • Datenaktualisierung
  • Reinitialisierung der Daten
  • Zurücksetzen der Daten
  • Aktualisierendes Wiederherstellen der Daten

Jede dieser Strategien ist nachfolgend genauer beschrieben.

Welche Methode Sie verwenden, ist von mehreren Faktoren abhängig, z. B. von den physischen Merkmalen der Datenbank, der technischen Kompetenz der Tester, der Verfügbarkeit von externen (nicht testbezogenen) Rollen und dem Testobjekt.

Datenaktualisierung

Die wünschenswerteste Methode der Rückversetzung von Testdaten in ihren Anfangsstatus ist die Datenaktualisierung. Bei dieser Methode wird eine Kopie der Datenbank in ihrem Anfangsstatus erstellt und gespeichert. Nach (oder vor) der Testausführung wird die archivierte Kopie der Testdatenbank in die Testumgebung kopiert und kann dort verwendet werden. Auf diese Weise ist sichergestellt, dass der Anfangsstatus der Testdaten zu Beginn jedes Tests derselbe ist.

Diese Methode hat den Vorteil, dass die Daten mit mehreren verschiedenen Anfangsstatus archiviert werden können. Sie können die Testdaten beispielsweise in ihrem Status am Ende eines Tages, am Ende einer Woche oder am Ende eines Monats archivieren. Der Tester kann mit dieser Methode somit schnell einen bestimmten Status zur Unterstützung eines Tests wiederherstellen, z. B. für die Tests der Anwendungsfälle, die das Monatsende betreffen.

Reinitialisierung der Daten

Wenn die Daten nicht aktualisiert werden können, ist die programmgestützte Wiederherstellung der Daten in ihrem Anfangsstatus die am besten geeignete Methode. Die Reinitialisierung von Daten setzt voraus, dass die Testdaten durch bestimmte Anwendungsfälle und Tools auf ihre Anfangswerte zurückgesetzt werden können.

Es ist darauf zu achten, dass alle Daten, Beziehungen und Schlüsselwerte auf ihre jeweiligen Anfangswerte zurückgesetzt werden, da andernfalls Fehler eingeführt werden.

Ein Vorteil dieser Methode ist, dass auch die ungültigen Werte in der Datenbank getestet werden können. Unter normalen Bedingungen würden ungültige Werte abgefangen werden (z. B. durch eine Validierungsregel des Clients) und könnten nicht eingegeben werden. Ein anderer Akteur könnte die Daten jedoch beeinflussen (z. B. ein elektronisches Update von einem anderen System). In den Tests muss überprüft werden, ob ungültige Daten festgestellt und entsprechend behandelt werden. Dies gilt unabhängig davon, wie es zu diesen Daten kommt.

Zurücksetzen der Daten

Eine einfache Methode, Daten in ihren Anfangsstatus zurückzuversetzen, ist das Rückgängigmachen der Änderungen, die während eines Tests an den Daten vorgenommen wurden. Diese Methode hängt davon ab, dass Änderungen mit dem Testobjekt rückgängig gemacht werden können. Es müsste beispielsweise möglich sein, gelöschte Datensätze/Werte wieder hinzuzufügen, die Modifizierungen an Datensätzen/Werten rückgängig zu machen und hinzugefügte Daten zu löschen.

Mit dieser Methode sind allerdings auch Risiken verbunden. Dazu gehören unter anderem:

  • Es müssen alle Aktionen rückgängig gemacht werden, nicht nur einige.
  • Die Methode ist von Anwendungsfällen für das Testobjekt abhängig (die zunächst auf ihre Funktionalität getestet werden müssen, bevor sie für das Zurücksetzen der Daten verwendet werden können).
  • Datenbankschlüssel, -indizes und -einträge können (unter Umständen) nicht zurückgesetzt werden.

Falls in Ihrer Testumgebung nur diese Methode angewendet werden kann, sollten Sie keine Datenbankschlüssel, -indizes und -zeiger als Primärziele der Verifizierung verwenden. Wenn Sie beispielsweise feststellen möchten, ob ein Patient zur Datenbank hinzugefügt wurde, sollten Sie das Feld 'Patientenname' verwenden und keine vom System generierte Patienten-ID-Nummer.

Aktualisierendes Wiederherstellen der Daten

Die aktualisierende Wiederherstellung der Daten ist die am wenigsten wünschenswerte Methode für die Rückversetzung der Testdaten in ihren Anfangsstatus. Eigentlich kann das Problem des identischen Anfangsstatus mit dieser Methode gar nicht gelöst werden. Nach Ausführung des Tests haben die Daten vielmehr einen neuen Anfangsstatus. Dies erfordert normalerweise eine Modifizierung der Testdaten, die als Eingabe verwendet werden, und/oder der Testfälle und Testdaten, die für die Bewertung der Ergebnisse herangezogen werden.

Es gibt einige Situationen, in denen dies notwendig ist, z. B. am Monatsende. Wenn es kein Archiv der Daten unmittelbar vor dem Ende des Monats gibt, kann die Verarbeitung am Monatsende erst getestet werden, nachdem die Testdaten und Test-Scripts für jeden Tag und jede Woche ausgeführt wurden, um den Monatsendstatus zu erreichen.

Zu den Risiken dieser Methode gehören unter anderem:

  • Datenbankschlüssel, -indizes und -einträge können nicht zurückgesetzt (und nicht zur Verifizierung verwendet) werden.
  • Die Daten ändern sich konstant.
  • Die Verifizierung der Ergebnisse kann nur mit zusätzlichem Aufwand zertifiziert werden.