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:
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).
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).
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).
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.
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.
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.
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.
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.
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.
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.
|