Der Automated GUI Recorder von TPTP ist ein Werkzeug zur automatisierten Steuerung der grafischen Bestandteile der Entwicklungsumgebung Eclipse. Er bietet grundlegend die Funktion des Mitschneidens von Interaktionen mit den Bedienelementen und erstellt daraus XML-basierte Makros, welche anschließend wieder abgespielt werden können.
Als Grundlage für die Tests mit "TPTP Automated GUI Recorder" wurde das Tutorial auf eclipse.org verwendet, um zunächst ein einfaches Beispielszenario zu konstruieren.
Die Anleitung beschreibt verständlich das Mitschneiden der Erstellung eines ersten Projektes und führt den Leser zu Themen wie
die Nutzung von sog. "Datapools" und "Verification Hooks" als hilfreiche Erweiterung des Szenarios.
Die Vorgehensweise ist gut verständlich mit passenden Screenshots dargestellt. Das Dokument ist jedoch nicht mehr ganz aktuell,
so dass sich diverse Bearbeitungsmasken bzgl. der im Tutorial verwendeten Version von TPTP geändert haben, jedoch die gewünschte Funktion nicht eingeschränkt wird.
Dieses Szenario soll nun nachgestellt und an folgendem Beispiel des automatischen Erstellens eines Projekts in der Entwicklungsumgebung Eclipse vertieft werden:
Das "TPTP Automated GUI Recorder-Plugin" ist weder im Standardpaket von TPTP noch im "All TPTP plugins" Paket enthalten und muss separat heruntergeladen und installiert werden: TPTP PlugIns.
In dem Ordner "test-ressources" sollte jetzt die Testsuite "AutomatedGUISuite.testsuite" vorhanden sein. Nach einem Doppelklick auf diese Datei können nun über das sich öffnende Fenster neue Testfälle angelegt und bearbeitet werden:
Es gibt am unteren Ende der Testsuite-Ansicht (letzter Screenshot) drei Reiter:
Ein neuer Testfall wird über "Test Cases" -> Roter 'Aufnahme'-Button erstellt.
In dem sich öffnenden Eingabefenster wird der Testfall mit "Create Project" benannt und "*.ui.JavaPerspective" (die Standard Java-Ansicht im Eclipse-Workspace)
als Startpunkt gewählt.
Der "Starting Point" gibt somit an wo die Aufnahme beginnen soll. Wird z.B. als Startpunkt "*.DebugPerspective" gewählt, wird bei späterer
Ausführung des Makros automatisch in die Eclipse Debugger-Ansicht gewechselt.
Nun sollte dieses Fenster erscheinen:
Alle durchgeführten Aktionen werden ab sofort aufgenommen. Ist ein Neustart des Mitschnitts gewünscht, kann dazu der "Restart Button" gedrückt werden und die Aufzeichnung beginnt wieder von Neuem.
Ausführen der aufzuzeichnenden Aktionen:
Ein neues Java-Projekt mit dem Namen "Java-Project" wird manuell im Workspace angelegt. Im Kontrollfenster des AGR wird im Eingabefeld "Verification Hooks" nun beispielsweise "projectinit" eingegeben und mit "Insert" bestätigt.
Somit ist nun der Aktion "Anlegen des Projekts Java-Project" der Verification Hook "projectinit" zugeordnet.
D.h. ein Verification Hook benennt im Allgemeinen einen Entwicklungsabschnitt und speichert die bis dorthin aufgezeichneten Interaktionen
mit der Entwicklungsumgebung unter dem angegebenen Namen.
Der Status wechselt daraufhin von "recording" in einen Wartezustand, bis
eine nächste Benutzeraktion im GUI registriert wird. Hier wird zwischen folgenden Fokusbereichen unterschieden, um korrekt an die vom Benutzer
übermittelten Daten heranzukommen:
Des Weiteren wird im angelegten Projekt noch ein Package und eine Klasse erstellt und in beiden Fällen noch ein Verification Hook gesetzt.
Nach Ausführung aller Schritte wird die Aufnahme mit der "Terminate"-Taste beendet.
Der neue Testcase erscheint nun im Fenster der Testsuite. Außerdem wurde im Package "org.eclipse.tests.verification.hooks" eine neue Klasse namens "VerificationClass.java" angelegt.
In dieser befinden sich die zu den bei der Aufnahme gesetzten Verification Hooks gehörenden Methoden, in welchen bei Erreichen der jeweiligen Stelle mit beliebigem Code reagiert werden kann.
In diesem Test soll es genügen, Konsolenausgaben zu erzeugen, welche Auskunft darüber geben, an welcher Stelle das Makro sich gerade befindet:
/**
* @throws Exception
*/
public void projectinit(org.eclipse.ui.IViewPart arg0)
throws Exception
{
System.out.println("in projectinit");
}
/**
* @throws Exception
*/
public void packageinit(org.eclipse.ui.IViewPart arg0)
throws Exception
{
System.out.println("in packageinit");
}
/**
* @throws Exception
*/
public void classinit(org.eclipse.ui.IEditorPart arg0)
throws Exception
{
System.out.println("in classinit");
}
Um das aufgenommene Makro zu testen, muss das neu erstellte Projekt wieder gelöscht werden und das Makro kann daraufhin im "Quickmode" abgespielt werden.
Daraufhin sollte das Projekt wieder im aktiven Workspace vorhanden sein.
(Anmerkung: Diese schnelle Ausführmethode wird in der Regel nur benutzt, um das aufgenommene Makro zu testen.)
Schlägt das Makro fehl und das Projekt ist nicht vollständig angelegt, dann wurde bei der Aufnahme nicht sorgfältig jeder Menüpunkt bzw. jedes Button der Reihe nach bedient. Der Agent schneidet kontextbezogen die Interaktionen mit und erkennt z.B. keine vorausgewählten Felder. Der AGR kann somit Bedienschritte schnell übersehen!
Für einen ausführlicheren Test ist es notwendig, das Verhalten der Testfälle festzulegen. Dazu bietet die Testsuite unter dem Reiter "Behavior" die Möglichkeit, festzulegen, welcher Testfall in welcher Reihenfolge ausgeführt werden soll.
Ein TestCase wird hier mit "Insert" in die Behavior-Liste hinzugefügt. Zur Auswahl stehen dabei "invocation", wobei der Test nur einmal und "loop", wobei er in einer Schleife ausgeführt wird.
Wird auf der Testsuite-Datei (hier: "AutomatedGUISuite.testsuite") nun über "Run as" -> "Run Configurations" gewählt, erscheint das Konfigurations-Fenster, in welchem die Testkonfiguration angepasst werden kann.
Mit "Run" wird das Makro im "Standard-Mode" (im Gegensatz zum vorher verwendeten "Quick-Mode") ausgeführt, d.h. es wird innerhalb eines neuen Workspace ausgeführt und alle Ereignisse in einer Datei "AutomatedGuiSuite.execution" mitgeschnitten. Diese Datei beinhaltet daraufhin die Informationen zu dem ausgeführten Testlauf innerhalb folgender zwei Reiter:
In "Events" kann das Ergebnis jeder Test-Ausführung überprüft werden.
Wurden alle Tests problemlos ausgeführt, dann sind die drei Zustände "start", "pass" und "stop" zu sehen und das Textfeld ist leer.
Ist es in einem Test (wie in folgender Ansicht dargestellt) zu einem Fehler gekommen, wird statt "pass" "fail" angezeigt und im Textfeld von "fail"
wird der Stack-Dump ausgegeben. Die oberste Zeile gibt meist Auskunft über die Fehlerursache
und weist auf die jeweilige Zeile im Makro hin, an welcher der Fehler produziert wurde.
Zudem können diverse Bugs auch über "Defects" direkt über Bugzilla veröffentlicht werden.
Mit Hilfe von Datapools lassen sich Usereingaben einfach individualisieren. Die Datapooleinträge werden dort eingefügt, wo eigentlich Usereingaben erwartet werden. So werden in diesem Beispiel mit dem bereits erstellten Makro zwei Projekte mit zwei unterschiedlichen Namen angelegt.
Zu allererst wird eine Datapool-Datei benötigt:
Dazu Rechtsklick auf "Test-ressources" -> "New" -> "Other" -> "Test" -> "Test Assetts" -> "Datapool" -> Name: "AutoGuiDatapool"
In dem geöffneten Datapool gibt es wiederum zwei Reiter. In "Overview" ist es möglich, neue Variablen und Äquivalenzklassen zu erstellen.
Neue Äquivalenzklassen sind neue Datasheets, in denen Variablen angelegt und verwaltet werden können.
Mit "Variables" -> "Add" wird eine neue Variable angelegt. Mit Doppelklick kann diese umbenannt werden, in diesem Fall zu "Projectname".
Unter dem Reiter "EquivalenceClass1" muss nun im Feld 0 "Custom Project" eingegeben werden.
Damit wurde der Variable
"Projectname" der Wert "Custom Project" zugewiesen. Es können einer Variablen auch mehrere Werte zugewiesen werden (siehe Bild).
Dieser Wert wird, nach der Verlinkung, automatisch einem Eingabefeld zugewiesen.
(Hier als Beispiel mit einem Eintrag mehr, für dieses Tutorial nicht notwendig.):
Nun kann innerhalb der AGR-Testsuite unter "Behavior" -> "Detailed Properties Datapools" zum ausgewählten "Behavior" verlinkt werden. Für dieses Beispiel muss jedoch zunächst ein neues Behavior über "Add" -> "Invocation" hinzugefügt werden. Diesem muss dann per "Link to Datapool" die Variable "Projectname" zugewiesen werden. (Hier als Beispiel zu oben mit mehreren Auswahlmöglichkeiten.):
Wird nun der Test gestartet, werden 2 neue Projekte erstellt, "Java Project" und "Custom Project". Wie man anhand dieses Beispiels leicht erkennen kann, wurde durch die Datapoolverlinkung beim zweiten Behavior-Aufruf statt "Java Project" "Custom Project" als Name aus unserem Datapool gewählt und wie gewünscht ein Projekt mit diesem Namen angelegt.
Die im Tutorial benannte "Variable Substitution" beschreibt die Ersetzung von im Userkontext festgelegten Werten
durch z.B. globale Variablen mit Hilfe der GUI Automation.
Im Beispiel wird eine Datei namens "MyTestResource.txt" aus dem Pfad "D:\Temp" (unter Windows, analog "/tmp" unter Linux) in das Projekt eingebunden
und anschließend in den Ordner "TestContainer" -> "test-ressources" verschoben.
Dieser Schritt wird ohne das Verschieben als TestCase namens "Import Ressource Relatively" mitgeschnitten und daraufhin im Behavior-Bereich als "invocation"-Test eingefügt. Im "User-Input"-Fenster rechts wird
der Eintrag "/tmp" gewählt und auf "Link to custom input" geklickt. Der Text im sich öffnenden Fenster wird dann durch "%testsuiteProjectLocation%" ersetzt.
Wird das Makro nun ausgeführt, wird die Textdatei nicht mehr von "/tmp", sondern über die globale Pfadvariable aus dem TestContainer-Ordner in das Java-Project eingebunden.
Der AGR ist ein mächtiges Hilfswerkzeug, welches wiederkehrende Aufgaben in der Eclipse Laufzeitumgebung sehr vereinfachen kann, als "GUI-Tester" für das Testen von eigenen
Javaprogrammen lässt sich dieses Tool jedoch nicht anwenden.
Die Usability dieses Tools ist mit all seinen Möglichkeiten beschränkt und erst nach längerer Verwendung intuitiv.
Um hinter die Mechanismen der einzelnen Funktionalitäten des AGR zu blicken, ist viel Einarbeitungszeit nötig, auch wenn die einzelnen Teilaspekte teils trivial erscheinen.
Die Rekonstruktion des im Tutorial dargestellten Beispiels war fast problemlos möglich, nur leider nicht so einfach auf ein individuelles Programm wie gewünscht übertragbar.
Zudem fehlen zu manchen Themengebieten ausführliche funktionale Erklärungen.