Richtlinie: Automatisierte Testscripts programmieren
Diese Richtlinie beschreibt die Prinzipien einer effektiven Entwicklung von automatisierten Testscripts.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Struktur von Testscripts

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.

Aufzeichnungstechnik

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.

Datengesteuerte Tests

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.

Fehlerbehandlung

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.

Synchronisation und Planung von Testscripts

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.

Testscripts testen und debuggen

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.