Wenn Sie die Verwaltbarkeit und Wiederverwendbarkeit Ihrer Testscripts verbessern möchten, müssen Sie sie
strukturieren, bevor Sie sie implementieren. Sie werden feststellen, dass es Aktionen gibt, die im mehreren Testscripts
enthalten sind. Ein Ziel ist es, diese Aktionen zu ermitteln, so dass Sie ihre Implementierung wiederverwenden können.
Sie haben beispielsweise Testscripts, die eine Kombination unterschiedlicher Aktionen sind, die Sie für einen Datensatz
absetzen können. Diese Testscripts können beispielsweise Kombinationen von Aktionen wie Hinzufügen, Ändern und Löschen
eines Datensatzes sein:
-
Hinzufügen, Ändern, Löschen (nahe liegend)
-
Hinzufügen, Löschen, Ändern
-
Hinzufügen, Löschen, Hinzufügen, Löschen, ....
-
Hinzufügen, Hinzufügen, Hinzufügen ...
Wenn Sie diese Aktionen als separate Testscripts identifizieren und implementieren und dann in anderen Testscripts
wiederverwenden, erhöhen Sie damit die Wiederverwendbarkeit.
Ein anderes Ziel ist, die Testscripts so zu strukturieren, dass eine Änderung in der Zielsoftware eine lokalisierte und
kontrollierbare Änderung in Ihren Testscripts bewirkt. Damit werden Ihre Testscripts widerstandsfähiger gegenüber
Änderungen in der Zielsoftware. Angenommen, der Anmeldeteil der Software ändert sich. Für alle Testfälle, die den
Anmeldeteil durchlaufen, muss dann nur noch das Testscript geändert werden, das sich auf die Anmeldung bezieht.
Wenn Sie eine bessere Verwaltbarkeit Ihrer Testscripts erreichen möchten, müssen Sie sie auf eine Weise aufzeichnen,
die möglichst widerstandsfähig gegenüber Änderungen im Testziel ist. Beispielsweise gibt es für ein Testscript, das
Felder in einem Dialogfenster füllt, mehrere Möglichkeiten, von einem Feld zum nächsten zu navigieren:
-
Verwendung der Tabulatortaste
-
Verwendung der Maus
-
Verwendung von Tastaturdirektaufrufen
Von diesen Optionen reagieren einige empfindlicher auf Designänderungen als andere. Wenn ein neues Feld in die Anzeige
eingefügt wird, ist die Methode mit der Tabulatortaste nicht zuverlässig. Wenn Direktaufruftasten neu belegt werden,
machen auch sie Fehler bei der Aufzeichnung. Wenn die Methode, die die Maus verwendet, um ein Feld zu identifizieren,
geändert wird, ist auch dies keine zuverlässige Methode. Einige Testautomatisierungstools haben jedoch
Testscriptaufzeichner, die angewiesen werden können, um das Feld mit einer zuverlässigeren Methode zu identifizieren,
z. B. anhand des Objektnamens, der vom Entwicklungstool (PowerBuilder, SQLWindows oder Visual Basic) zuordnet wird. Auf
diese Weise wirken sich geringfügige Änderungen in der Benutzerschnittstelle (z. B. Layoutänderungen, Änderungen von
Feldkennsätzen, Formatierungsänderungen usw.) nicht auf das Testscript aus.
Bei vielen Testscripts müssen mehrere Gruppen von Felddaten in eine bestimmte Dateneingabeanzeige eingegeben werden, um
Funktionen für die Feldvalidierung, Fehlerbehandlung usw. zu testen. Die Vorgehensweise ist immer dieselbe, nur die
Daten sind unterschiedlich. Anstatt ein Testscript für jede Gruppe von Eingabedaten aufzuzeichnen, sollte eine einzige
Aufzeichnung erstellt und anschließend an die verschiedenen Daten angepasst werden. Beispielsweise können alle
Datengruppen, die aufgrund ungültiger Daten denselben Fehler erzeugen, dasselbe aufzeichnete Testscript verwenden. Das
Testscript wird geändert, um die Daten als variable Informationen zu berücksichtigen, die Daten aus einer Datei oder
einer anderen externen Quelle zu lesen und eine Schleife durch alle relevanten Daten zu programmieren.
Wenn Testcode oder Testscripts entwickelt wurden, um die Gruppen der Eingabe- und Ausgabedaten in einer Schleife zu
prüfen, müssen die Daten eingerichtet werden. Gewöhnlich werden diese Daten in Form von durch Kommata getrennten
Feldern in eine Textdatei geschrieben. Dieses Format ist für Testscripts und Testcode einfach zu lesen und lässt sich
einfach erstellen und verwalten.
Die meisten Datenbank- und Spreadsheet-Pakete können durch Kommata getrennte Textausgaben erzeugen. Die Verwendung
dieser Pakete für die Organisation und die Erfassung von Daten hat zwei bedeutende Vorteile. Zunächst stellen diese
Pakete eine strukturiertere Umgebung für die Eingabe und das Editieren der Daten bereit als ein Texteditor oder ein
Textverarbeitungsprogramm. Zweitens haben die meisten Pakete die Fähigkeit, vorhandene Datenbanken abzufragen und die
zurückgegebenen Daten zu erfassen, womit Daten aus vorhandenen Quellen einfach extrahiert werden können.
Das aufgezeichnete Testscript ist in seiner Ausführung sequenziell. Es gibt keine Verzweigungspunkte. Eine zuverlässige
Fehlerbehandlung in den Testscripts erfordert zusätzliche Logik, um auf Fehlerbedingungen reagieren zu können.
Beispiele für Entscheidungslogik, die beim Auftreten von Fehlern eingesetzt werden kann:
-
Verzweigung zu einem anderen Testscript.
-
Aufruf eines Scripts, das versucht, die Fehlerbedingung zu bereinigen.
-
Beenden des Scripts und Starten eines neuen.
-
Beenden des Scripts und der Software, Neustart und Wiederaufnahme der Tests bei dem Testscript, das dem
gescheiterten folgt.
Jede Fehlerbehandlungstechnik erfordert das Hinzufügen von Programmlogik zum Testscript. Diese Logik sollte, wenn
möglich, auf Testscripts der höheren Ebene beschränkt werden, die die Abfolge der Testscripts der unteren Ebene
steuern. Damit können die Testscripts der unteren Ebene vollständig aus der Aufzeichnung erstellt werden.
Bei der Durchführung von Stresstests empfiehlt es sich häufig, die Testscripts so zu synchronisieren, dass sie zu
vordefinierten Zeiten gestartet werden. Testscripts können geändert werden, so dass sie zu einer bestimmten Zeit
starten, indem das gewünschte Datum mit der Systemzeit verglichen wird. In vernetzten Systemen verwendet jede
Teststation über das Netz dieselbe Uhr. Im folgenden Beispiel (aus einem in BASIC geschriebenen Script) wurden
Anweisungen am Anfang eines Scripts eingefügt, um die Ausführung des Scripts so lange auszusetzen, bis die gewünschte
Zeit erreicht ist.
InputFile$ = "TIME.DAT"
Open InputFile$ For Input As 1
Input #1, StartTime$
Close #1
Do While TimeValue(StartTime$) > Time
DoEvents
Loop
[Start script]
In diesem Beispiel ist die gewünschte Startzeit in einer Datei gespeichert. Auf diese Weise kann die Startzeit geändert
werden, ohne das Testscript zu ändern. Die Zeit wird gelesen und in einer Variablen mit dem Namen
StartTime$ gespeichert. Die Do While -Schleife wird so lange ausgeführt, bis die Startzeit
erreicht ist. Die Anweisung DoEvents ist wichtig: Sie ermöglicht die Ausführung von Hintergrund-Tasks,
während die Ausführung des Testscripts ausgesetzt ist und auf die Startzeit gewartet wird. Ohne die Anweisung
DoEvents würde das System so lange nicht reagieren, bis die Startzeit erreicht ist.
Wenn die neu aufgezeichneten Testscripts in derselben Software ausgeführt werden, in der sie aufgezeichnet wurden,
dürften keine Fehler auftreten. Die Umgebung und die Software haben sich im Vergleich mit dem Aufzeichnungszeitpunkt
nicht geändert. Es kann Fälle geben, in denen die Testscripts nicht fehlerfrei ausgeführt werden. Wenn Sie die
Testscripts testen, finden Sie diese Fälle und können die Scripts korrigieren, bevor sie in echten Tests verwendet
werden. Im Folgenden werden zwei typische Probleme beschrieben:
-
Wenn die Methoden, die für die Auswahl der Elemente in einer Benutzerschnittstelle verwendet werden, nicht
eindeutig sind, können sich die Testscripts beim Abspielen unterschiedlich verhalten. Beispiel: Zwei Elemente, die
an ihrem Text (oder Titel) erkannt werden, haben denselben Text. Dies führt zu einer Mehrdeutigkeit, wenn das
Script ausgeführt wird.
-
Testlauf- oder Sitzungsspezifische Daten werden aufgezeichnet (z. B. Zeiger, Datumsmarke oder Zeitmarke oder andere
vom System generierte Datenwerte), die sich beim Abspielen des Scripts aber anders verhalten.
Taktungsunterschiede zwischen Aufzeichnung und Wiedergabe können zu Problemen führen. Die Aufzeichnung eines Testscript
ist per se ein langsamerer Prozess als die Ausführung. Diese Zeitabweichungen können manchmal dazu führen, dass ein
Testscript der Software "vorausläuft". In diesen Fällen können Wartezustände eingefügt werden, um das Testscript auf
die Geschwindigkeit der Software zu drosseln.
|