QF-Test
Handbuch

50.1 Fortgeschrittene Skript-Konzepte

50.1.1 Pfad für das Laden der Module

Der Loadpath für Module werden in den Skriptsprachen aus verschiedenen Teilen in folgender Reihenfolge zusammengesetzt:

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-10.0.0/<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.

50.1.2 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.: 

from java.util import Date
            from java.text import SimpleDateFormat
            print SimpleDateFormat("yyyy-MM-dd").format(Date())
Beispiel 50.1:  Zugriff auf Java-Klassen mittels Jython

Zugriff gibt es auf alle Klassen im Java-Klassenpfad, das heißt die der Standard Java-API sowie QF-Test's eigene Klassen. Beachten Sie, dass die Umgebungsvariable CLASSPATH von QF-Test ignoriert wird; falls nötig, kann aber QFTEST_CLASSPATH mit demselben Wert definiert werden. 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 Pluginverzeichnis 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.

Hinweis Eine praktische Einführung in QF-Test Plugins finden Sie in unserem Blogbeitrag Einführung in die Plugin-Entwicklung für QF-Test.

50.1.3 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.

50.1.4 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.

50.1.5 Exceptions

Alle QF-Test Exceptions werden in den Skriptsprachen automatisch importiert und stehen zum Beispiel für try/except zur Verfügung: 

try:
            com = rc.getComponent("someId")
            except ComponentNotFoundException:
            ...
Beispiel 50.2:  Beispiel für das Abfangen einer ComponentNotFoundException in Jython

In Groovy erfolgt dies über try/catch: 

try {
            com = rc.getComponent("someId")
            } catch (ComponentNotFoundException) {
            ...
            }
Beispiel 50.3:  Beispiel für das Abfangen einer ComponentNotFoundException in Groovy

Explizit sollten aus Skriptcode nur die folgenden Exceptions geworfen werden (mit raise bzw. throw new):

50.1.6 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 dies zu Vereinfachen bietet QF-Test Konsolenfenster für die Kommunikation mit allen Interpretern an. Informationen hierzu finden Sie am Ende des "Allgemeines".

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 die gesamte Java-API erhalten Sie auf diesem Weg sogar eine ganz allgemeine interaktive Debugging-Schnittstelle zu Ihrer Applikation.