![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
Version 5.2.3 |
| Skripting (Jython, Groovy und JavaScript) |
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 12.
| Pfad für das Laden der Module |
Der Loadpath für Module werden in den Skriptsprachen aus verschiedenen Teilen in folgender Reihenfolge zusammengesetzt:
qftest/qftest-5.2.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-5.2.3/<Name der 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 unter "Hilfe"->"Info"->"Systeminfo".
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.
| Das Plugin Verzeichnis |
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 45.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. Sie können über "Hilfe"->"Info"->"Systeminfo" das aktuell verwendete Plugin-Verzeichnis unter "dir.plugin" herausfinden.
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
.
| Der Package Cache (Jython) |
Jython verwaltet einen Cache mit Package Informationen, um schnell
auf Java Klassen zugreifen zu können. Dieser liegt normalerweise
im Verzeichnis qftest/jython/cachedir
. Falls dieses
Verzeichnis nicht beschreibbar ist, wird stattdessen
jython-cachedir
im
benutzerspezifischen Konfigurationsverzeichnis
verwendet. Sie können das Verzeichnis für den Cache auch
mit der System Property python.cachedir
selbst
definieren.
Wenn Sie QF-Test nach der Installation starten, werden Sie vielleicht einige Meldungen der folgenden Form sehen:
*sys-package-mgr*: processing...
Später sollten diese Meldungen nur dann auftauchen, wenn Sie ein jar
Archiv auf dem CLASSPATH
geändert oder neue hinzugefügt
haben. Es kann vorkommen, dass Jython einen Schluckauf bekommt und
für manche jar Archive den Cache jedes mal neu erzeugt. In diesem
Fall können Sie einfach das gesamte Verzeichnis
qftest/jython/cachedir
oder
jython-cachedir
im
benutzerspezifischen Konfigurationsverzeichnis
löschen, womit das Problem beseitigt sein sollte.
| Initialisierung (Jython) |
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 Namespace Umgebung für Skript Knoten (Jython) |
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 API des Runcontexts |
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)
.
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Das 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)
.
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Image API |
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.
| Die 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 45.2: Image API in Jython |
Das gleiche mit Groovy:
|
|
|||
| Beispiel 45.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.
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Exceptions |
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.
| Debuggen von Skripten (Jython) |
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: 9.3.2021 Copyright © 1999-2021 Quality First Software GmbH |