Handbuch
Handbuch
 |  |  |  |  |  |  |  |
| Version 6.0.3 |
Dieser Abschnitt erläutert die technischen Details der Integration von Jython, Groovy und JavaScript in QF-Test. Er enthält eine vollständige Referenz der API, die Jython, Groovy und JavaScript Skripten zur Interaktion mit QF-Test zur Verfügung steht. Eine weniger technische Einführung finden Sie in Kapitel 11.
Der Loadpath für Module werden in den Skriptsprachen aus verschiedenen Teilen in folgender Reihenfolge zusammengesetzt:
qftest/qftest-6.0.3/<Name der Skriptsprache>Zusätzlich wird dem Pfad während der Ausführung eines 'Server Skript' oder 'SUT Skript' Knotens das Verzeichnis der Testsuite vorangestellt.
Das Verzeichnis
qftest/qftest-6.0.3/<Skriptsprache> enthält
interne Module der jeweiligen Skriptsprache. Sie sollten diese Dateien nicht
modifizieren, da sie sich jederzeit ändern können und auf die
jeweilige Version von QF-Test zugeschnitten sind.
Ihre eigenen Module sollten Sie in das benutzerdefinierte Skript-Verzeichnis legen.
Die Pfade zu diesen Verzeichnissen finden Sie via
»Hilfe«-»Info«
unter "Systeminfo" als dir.<Skriptsprache>.
Dabei müssen die Module die jeweilige Endung haben
(.py für Jython, .groovy für Groovy und .js für JavaScript) haben.
In Jython können Sie die System Property
python.path nutzen, um weitere Verzeichnisse zum Loadpath hinzuzufügen.
Mit den Skriptsprachen kann auch auf Java Klassen und Methoden zugegriffen werden, die nichts speziell mit QF-Test zu tun haben, indem diese Klassen einfach importiert werden, z.B.:
| ||||
| Beispiel 46.1: Zugriff auf Java Klassen mittels Jython | ||||
Zugriff gibt es auf alle Klassen, die sich beim Start von QF-Test bzw. des SUT auf dem
CLASSPATH befinden, alle Klassen des Standard Java API, sowie QF-Test's
eigene Klassen. Für das SUT hängt vieles vom verwendeten ClassLoader Konzept ab.
Insbesondere bei WebStart und Eclipse/RCP ist es schwierig, Klassen des SUT direkt zu
importieren.
Zusätzlich gibt es Plugin Verzeichnisse, in die Sie einfach eine jar
Datei stellen können, um sie in Skripten verfügbar zu machen. QF-Test sucht dazu nach einem
plugin Verzeichnis.
Das aktuell verwendete Plugin-Verzeichnis finden Sie via »Hilfe«-»Info« unter "Systeminfo" als dir.plugin.
Das Plugin-Verzeichnis kann auch über das Kommandozeilenargument -plugindir <Verzeichnis>
geändert werden.
Jar Dateien im primären Plugin Verzeichnis stehen sowohl
'Server Skript', als auch 'SUT Skript' Knoten zur
Verfügung. Um eine jar Datei ausschließlich für
'Server Skripte' oder ausschließlich für
'SUT Skripte' bereitzustellen, stellen Sie diese
stattdessen in das zugehörige Unterverzeichnis namens
qftest bzw. sut.
Beim Start von QF-Test und des SUT wird ein Jython Interpreter
erzeugt und in die Applikation eingebettet. Für QF-Test wird dabei das
Modul qftest geladen, für das SUT das Modul
qfclient. Beide basieren auf dem Modul
qfcommon, das den gemeinsamen Code enthält. Diese
Module werden benötigt, um die Schnittstelle zum Runcontext und den
globalen Namespace bereitzustellen.
Anschließend wird der Loadpath sys.path nach Ihren
persönlichen Modulen für die Initialisierung durchsucht. Für QF-Test
wird die Datei qfserver.py geladen, für das SUT die
Datei qfsut.py. In beiden fällen werden die Dateien
mittels execfile ausgeführt, womit der Inhalt der
Dateien direkt im globalen Namespace landet. Dies ist für
Initialisierungsdateien von Vorteil, da alle Module, die von diesen
importiert werden, direkt für 'Server Skript' und
'SUT Skript' Knoten zur Verfügung stehen. Bedenken Sie bei
Ihren Initialisierungsdateien, dass zu diesem Zeitpunkt noch kein
Runcontext und kein Testsuite-spezifisches Verzeichnis in
sys.path zur Verfügung stehen.
Die Umgebung in der 'Server Skripte' oder 'SUT Skripte' ausgeführt werden, wird durch den globalen und lokalen Namespace bestimmt, die während der Ausführung definiert sind. Namespaces sind Jython Dictionaries, welche die Bindungen für die globalen und lokalen Variablen beinhalten.
Der globale Namespace wird von allen Skripten, die in demselben
Jython Interpreter laufen, gemeinsam genutzt. Er enthält zunächst
nur die Klassen TestException und
UserException, das Modul qftest bzw.
qfclient für QF-Test bzw. das SUT, und alles, was in
qfserver.py bzw. qfsut.py definiert und
importiert wurde. Wenn Sie in einem Skript eine Variable mit Hilfe
des global Statements als global deklarieren und ihr
einen Wert zuweisen, wird diese in den globalen Namespace
aufgenommen und steht damit für weitere Skripte zur
Verfügung. Zusätzlich nimmt QF-Test automatisch alle Module in den
globalen Namespace auf, die während der Ausführung eines Skripts
importiert werden.
Der lokale Namespace wird für jedes Skript neu erstellt. Beim Aufruf
des Skripts enthält er das Objekt rc, die Schnittstelle
zu QF-Tests Runcontext, sowie true und false
mit den Werten 1 und 0 zur besseren
Integration mit QF-Test.
Für den Zugriff auf und das Setzen von Variablen in einem fremden
Jython Interpreter, stehen die Runcontext Methoden
fromServer, fromSUT, toServer
und toSUT zur Verfügung.
Das Runcontext Objekt rc ist die Schnittstelle
zum Ausführungszustand des laufenden Tests in QF-Test. Die Verwendung
einer zusätzlichen Schicht erlaubt Änderungen an der Implementierung von
QF-Test, ohne die Schnittstelle für Skripte zu gefährden.
Es folgt eine alphabetische Aufstellung aller Methoden des
Runcontext Objekts rc. Die verwendete Syntax ist ein
Gemisch aus Java und Python. Python unterstützt zwar selbst
keine statische Typisierung, die Parameter werden jedoch an Java
weitergereicht, so dass falsche Typen Exceptions auslösen können.
Folgt einem Parameter ein '=' Zeichen und ein Wert, ist dies der
Defaultwert des Parameters und eine Angabe beim Aufruf ist
optional.
Hinweis
Die Groovy Syntax für Keyword-Parameter unterscheidet sich von Jython. Groovy verwendet
':' statt '='. Dies ist besonders tückisch, weil z.B. rc.logMessage("bla",
report=true) durchaus legaler Groovy Code ist, der allerdings nicht den
gewünschten Effekt hat. Das '=' ist hierbei eine Zuweisung mit dem Wert true, der dann
ganz einfach als zweiter Parameter übergeben wird, so dass der Aufruf äquivalent ist zu
rc.logMessage("bla", true). Hierbei wird true aber für
dontcompactify statt report verwendet. Die korrekte Version
für Groovy lautet rc.logMessage("bla", report:true).
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
qf Modul
In manchen Fällen ist kein Runcontext verfügbar, insbesondere wenn eines der in den
folgenden Abschnitten beschiebenen Interfaces zur Erweiterung von QF-Test implementiert
wird. Das Modul qf ermöglicht Logging auch in diesen Fällen und bietet
weitere allgemein hilfreiche Methoden, die keinen Runcontext benötigen. Es folgt eine
alphabetische Aufstellung aller Methoden des qf Moduls. Sofern nicht anders
angegeben sind die Methoden in Jython und Groovy sowohl für 'Server Skript' als
auch 'SUT Skript' Knoten verfügbar.
Hinweis
Die Groovy Syntax für Keyword-Parameter unterscheidet sich von Jython. Groovy verwendet
':' statt '='. Dies ist besonders tückisch, weil z.B. qf.logMessage("bla",
report=true) durchaus legaler Groovy Code ist, der allerdings nicht den
gewünschten Effekt hat. Das '=' ist hierbei eine Zuweisung mit dem Wert true, der dann
ganz einfach als zweiter Parameter übergeben wird, so dass der Aufruf äquivalent ist zu
qf.logMessage("bla", true). Hierbei wird true aber für
dontcompactify statt report verwendet. Die korrekte Version
für Groovy lautet qf.logMessage("bla", report:true).
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Die Image API stellt Klassen und Interfaces bereit, um Bildschirmabbilder zu erstellen, Bilder in Dateien zu speichern oder zu aus Dateien zu laden. Es können auch eigene Bildvergleiche durchgeführt werden. The image API ist so konzipiert, dass im Allgemeinen keine Exceptions geworfen werden. Um dennoch auf mögliche Fehler eingehen zu können, werden Warnungen geloggt.
ImageWrapper Klasse
Um Bildschirmabbilder zu erstellen, können Sie die Jython Klasse ImageWrapper aus dem
Modul imagewrapper.py verwenden. Dieses Modul wird mit dem
QF-Test Installationspaket mitgeliefert.
Hier sehen Sie ein kleines Jython Beispiel, um die Verwendung der Image API darzustellen:
| ||||
| Beispiel 46.2: Image API in Jython | ||||
Das gleiche mit Groovy:
| ||||
| Beispiel 46.3: Image API in Groovy | ||||
Es folgt eine alphabetische Aufstellung aller Methoden der
ImageWrapper Klasse. Die verwendete Syntax ist ein
Gemisch aus Java und Python. Python unterstützt zwar selbst
keine statische Typisierung, die Parameter werden jedoch an Java
weitergereicht, so dass falsche Typen Exceptions auslösen können.
Folgt einem Parameter ein '=' Zeichen und ein Wert, ist dies der
Defaultwert des Parameters und eine Angabe beim Aufruf ist
optional.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alle QF-Test Exceptions, die in Kapitel 39
aufgeführt sind, werden in Jython automatisch importiert und stehen in
Skripts für try/except zur Verfügung, z.B.:
try:
com = rc.getComponent("someId")
except ComponentNotFoundException:
...In Groovy müssen die Exceptions erst importiert werden:
import de.qfs.apps.qftest.shared.exceptions.
ComponentNotFoundException
try {
com = rc.getComponent("someId")
} catch (ComponentNotFoundException) {
...
}
Explizit sollten aus Skriptcode nur die folgenden Exceptions
geworfen werden (mit raise bzw. throw new):
UserException("Irgendeine Meldung...") dient
als Signal für eine außergewöhnliche Fehlersituation.
BreakException() oder raise
BreakException("loopId") kann dazu verwendet werden, um aus
einer 'Schleife' oder einem 'While'
Knoten auszubrechen. Die Variante ohne Parameter unterbricht die
innerste Schleife, mit der QF-Test ID als Parameter kann gezielt eine
bestimmte Schleife abgebrochen werden.
ReturnException() oder ReturnException("value")
kann - mit oder ohne Rückgabewert - zur Rückkehr aus einer 'Prozedur'
verwendet werden, analog zu einem 'Return' Knoten.
Wenn Sie mit Jython Modulen arbeiten, müssen Sie nach der Änderung
eines Moduls QF-Test oder das SUT nicht neu starten sondern können
mit Hilfe von reload(<Modulname>) das Modul
erneut laden.
Das Debuggen von Skripten in einem eingebetteten Interpreter kann etwas mühsam sein. Um es zu vereinfachen bietet QF-Test Terminalfenster für die Kommunikation mit allen Jython Interpretern an. Diese Terminals sind über das »Clients« Menü oder über »Extras«-»Jython Terminal...« zugänglich.
Alternativ können Sie eine Netzwerkverbindung zu einem Jython Interpreter aufbauen, um
eine interaktive Kommandozeile zu erhalten. Dies funktioniert sowohl mit QF-Test als auch
mit dem SUT. Um dieses Feature zu aktivieren, müssen Sie QF-Test mit dem
Kommandozeilenargument -jythonport <Nummer> starten, mit dem Sie die Portnummer für den
Zugang zum Jython Interpreter angeben. Für das SUT definieren Sie diese mit Hilfe
eines 'Programm-Parameter' in der "Extra" Tabelle des
'Java SUT Client starten' oder 'SUT Client starten' Knotens. Setzen Sie dieses auf
-jythonport=<Portnummer>. Anschließend können Sie sich mittels
telnet localhost <Portnummer>
mit dem entsprechenden Jython Interpreter verbinden. Dank Jythons Möglichkeiten zum Zugriff auf das gesamte Java API erhalten Sie auf diesem Weg sogar eine ganz allgemeine interaktive Debugging-Schnittstelle zu Ihrer Applikation.
| | | | | | | Letzte Änderung: 6.9.2022 Copyright © 1999-2022 Quality First Software GmbH |
