Hinweis Diesen Kapitel beschreibt den alten Mechanismus zur Verbindung mit dem SUT aus der Zeit vor QF-Test Version 1.07. Er sollte normalerweise nicht mehr eingesetzt werden, ausser wenn Sie das JDK aus irgendwelchen Gründen nicht instrumentieren können oder wollen.

Um den unterschiedlichen Bedürfnissen der Anwender gerecht zu werden, gibt es verschiedene Möglichkeiten, eine Applikation aus QF-Test heraus zu starten. Je nachdem, wie komplex Ihre Applikation ist, welche Umgebung sie benötigt und ob Sie unter Unix oder Windows arbeiten, gibt es unterschiedliche Vorgehensweisen.

Zunächst sollten Sie bereits vor dem Starten von QF-Test sicherstellen, dass alle Umgebungsvariablen, die Ihre Applikation benötigt, korrekt gesetzt sind, insbesondere CLASSPATH (um seine eigenen jar Archive kümmert sich QF-Test selbst). Zumindest unter Unix ist es außerdem sinnvoll, das bin Verzeichnis des JDK im PATH zu haben.

Es folgt eine Aufstellung der vier gängigsten Vorgehensweisen zum Starten des SUT. Welche die geeignetste ist, hängt davon ab, auf welche Weise Ihre Applikation ohne QF-Test gestartet wird. Bringen Sie das zunächst in Erfahrung und folgen Sie dann den Anweisungen, die am besten dazu passen.

Zum Starten einer Applikation durch Java WebStart oder eines Applets im Appletviewer dienen besondere Varianten dieser Methoden, die in den nächsten Abschnitten beschrieben werden.

Start mittels java -jar <Archiv>

		Abbildung 35.1:  Starten des SUT aus einem jar Archiv

• Legen Sie in QF-Test einen 'Java SUT Client starten' Knoten an. Geben Sie dem SUT im 'Client' Attribut einen Namen. Wenn nötig, ändern Sie das Attribut 'Ausführbares Programm'. Sein Standardwert ${qftest:java}, ist das java Programm mit dem QF-Test gestartet wurde.
• Legen Sie im 'Verzeichnis' Attribut das Arbeitsverzeichnis Ihrer Applikation fest.
• Erstellen Sie zwei Zeilen in der 'Parameter' Tabelle für das Programm. Setzen Sie die erste Zeile auf -jar und die zweite auf den Namen des jar Archivs. Die Angabe des vollen Pfades ist nötig, wenn sich das Archiv nicht im oben angegebenen 'Verzeichnis' befindet.

Start mittels java -classpath <Pfad> <Startklasse>

		Abbildung 35.2:  Starten des SUT über die Startklasse

• Legen Sie in QF-Test einen 'Java SUT Client starten' Knoten an. Geben Sie dem SUT im 'Client' Attribut einen Namen. Wenn nötig, ändern Sie das Attribut 'Ausführbares Programm'. Sein Standardwert ${qftest:java}, ist das java Programm mit dem QF-Test gestartet wurde.
• Legen Sie im 'Verzeichnis' Attribut das Arbeitsverzeichnis Ihrer Applikation fest.
• Setzen Sie das Attribut 'Klasse' auf den vollen Namen der Startklasse, so wie er auch für das java Kommando angegeben wird.
• Wenn die Umgebungsvariable CLASSPATH beim Start von QF-Test nicht Ihrer Applikation entsprechend gesetzt ist, müssen Sie den Classpath wie folgt angeben: Erstellen Sie zwei Zeilen in der 'Parameter' Tabelle für das Programm. Setzen Sie die erste Zeile auf -classpath und die zweite auf die Liste der jar Archive und Verzeichnisse, aus denen sich der Classpath zusammensetzt. Für jar Archive, die sich nicht im oben angegebenen 'Verzeichnis' befinden, muss dabei der volle Pfad angegeben werden. Dieses Argument kann sehr lang werden und ist dadurch nur mühsam direkt in der Tabelle zu editieren. In Abschnitt 2.2.5 ist beschrieben, wie Sie komfortabel in einem Dialog arbeiten können.

Start aus einem eigenständigen Skript

		Abbildung 35.3:  Starten des SUT aus ein Skript

• Legen Sie in QF-Test einen 'SUT Client starten' Knoten an. Geben Sie dem SUT im 'Client' Attribut einen Namen und setzten Sie das Attribut 'Ausführbares Programm' auf das Skript, aus dem das SUT gestartet wird. Wenn sich das Skript nicht auf dem PATH befindet, muss es mit vollem Pfad angegeben werden.
• Legen Sie im 'Verzeichnis' Attribut das Arbeitsverzeichnis Ihrer Applikation fest.
• Wenn Ihr Skript die PATH Umgebungsvariable nicht verändert und Ihre Applikation durch den Aufruf von java oder javaw ohne explizite Pfadangabe startet, sollte es damit bereits funktionieren.
• Andernfalls müssen Sie das Skript (oder besser eine Kopie) editieren, und an der Stelle des java Aufrufs den Befehl qfclient voranstellen. Ändern Sie z.B.

  <Pfad-zu-Java>/java ... <Startklasse>

  in

  qfclient <Pfad-zu-Java>/java ... <Startklasse>

• WindowsUnter Windows müssen Sie in jedem Fall darauf achten, dass das Skript die Applikation nicht mittels start im Hintergrund startet, was die Kommunikation mit QF-Test unterbinden würde. Entfernen Sie gegebenenfalls das start Kommando vor dem java oder qfclient Aufruf.
• Es ist grundsätzlich sinnvoll, jede Art von Ausgabeumleitung (z.B. > ausgabe.log) beim java Aufruf zu entfernen. Dadurch wird sichergestellt, dass die Ausgaben des SUT bei QF-Test landen und dort protokolliert werden.

Start aus einem ausführbaren Programm

Diese Situation ist knifflig. Betrachten Sie das Programm als ein Skript, das nicht editierbar ist und folgen Sie den obigen Anweisungen. Wenn das Programm intern mit Methoden arbeitet, die das Verbinden mit QF-Test verhindern, müssen Sie auf eine andere Vorgehensweise ausweichen.

Wenn Sie am Ende dieses Abschnitts angelangt sind und Ihre Applikation sich immer noch weigert, aus QF-Test heraus zu starten oder Verbindung mit QF-Test aufzunehmen, sollten Sie Abschnitt 35.5 im Referenzteil lesen. Dort finden Sie detaillierte Informationen über die internen Vorgänge beim Start des SUT, die Ihnen vielleicht weiterhelfen. Ein zusätzliches Hilfsmittel zur Problemdiagnose ist das Kommandozeilenargument -dbg. Beim Start von QF-Test angegeben, bewirkt es zusätzliche Ausgaben sowohl von QF-Test selbst, als auch beim Start des SUT. Letztere finden Sie im Terminal unter dem »Clients« Menü (vgl. Abschnitt 4.4).

Hinweis Der alte Verbindungsmechanismus funktioniert nicht zuverlässig mit Java WebStart. Für ein Java WebStart basiertes SUT müssen Sie daher zwingend wie in Abschnitt 4.3 beschrieben vorgehen.

Hinweis Die folgende Methode funktioniert nur mit JDK 1.3 und höher.

Um ein Applet zu starten benötigen Sie einen 'Java SUT Client starten' Knoten. Setzen Sie das Attribut 'Verzeichnis' auf das Verzeichnis in dem sich die HTML Datei für Ihr Applet befindet. Setzen Sie das Attribut 'Klasse' auf den Wert sun.applet.Main.

Wechseln Sie als nächstes zum Reiter Klasse im 'Parameter' Attribut und fügen Sie zwei Werte ein: -Xnosecurity und den Namen der HTML Datei für Ihr Applet.

Die folgende Abbildung zeigt ein entsprechendes Beispiel.

		Abbildung 35.4:  Starten eines Applets im Appletviewer

Es gibt eventuell einen weiteren Punkt der eines manuellen Eingriffs bedarf. Wenn Ihre Applikation einen SecurityManager einsetzt, müssen Sie QF-Tests Klassen uneingeschränkten Zugriff auf das System erlauben. Andernfalls erhalten Sie beim Start des SUT eine SecurityException.

Um diesen Zugriff zu gewähren, müssen Sie die Policy Datei Ihrer Applikation anpassen. Der Name der Datei wird der Applikation üblicherweise auf der Kommandozeile über ein Argument der Form -Djava.security.policy=... übergeben. Editieren Sie diese Datei und fügen Sie die folgenden Zeilen hinzu:

grant codeBase "file:${qftest.home}/-" {
    permission java.security.AllPermission;
  };

Achtung: Sie können ${qftest.home} verwenden, wenn Sie das SUT aus einem 'Java SUT Client starten' Knoten oder mit Hilfe von qfclient starten. Andernfalls müssen Sie hier den kompletten Pfad zu QF-Tests Wurzelverzeichnis angeben. Die Angabe von "/-" am Ende der codeBase ist wichtig. Auch unter Windows muss '/' als Trennzeichen verwendet werden.

Dieser Abschnitt beschreibt im Detail, was sich beim Starten des SUT mit dem alten Verbindungsmechanismus aus QF-Test heraus abspielt. Er erklärt, warum es verschiedene Möglichkeiten zum Starten der Applikation gibt, wie sie funktionieren und worin sie sich unterscheiden. Dies ist zwangsläufig etwas technisch und wenn alles läuft können Sie diesen Abschnitt getrost überspringen. Wenn Sie aber Probleme beim Starten Ihrer Applikation haben, sollten Sie hierher zurückkehren und weiter lesen.

Wie bereits erwähnt, benötigt QF-Test freien Zugriff auf die Java VM des SUT, um Events aufzeichnen und wiedergeben zu können, oder um den Zustand von Komponenten auszuwerten. Dies wird von einer kleinen Programmschicht bewerkstelligt, die QF-Test zwischen das SUT und die Java VM legt. Diese Schicht ersetzt die System EventQueue durch QF-Tests eigene und stellt die RMI Verbindung zu QF-Test her, bevor sie die Kontrolle an die Starterklasse des SUT abgibt.

Da QF-Test versucht, ohne Modifikationen am SUT auszukommen, schafft es stattdessen eine spezielle Startumgebung für das SUT indem es:

• Seine eigenen jar Archive lokalisiert und in den CLASSPATH aufnimmt.
• Seine eigene Starterklasse anstelle der des SUT ausführt.
• Einen Weg schafft, auf dem diese Starterklasse den Hostnamen und TCP port übermittelt bekommt, an dem QF-Test bereit ist, die RMI Verbindung aufzunehmen, sowie den Client Namen der dem SUT zugewiesen wurde. Dies ist notwendig, um mehrere gleichzeitig laufende Instanzen von QF-Test zu ermöglichen, die ihrerseits mit mehreren SUT Clients kommunizieren können.

Java Applikationen werden normalerweise auf eine von zwei Arten gestartet:

• Einfache Applikationen werden direkt über das java Programm ausgeführt.
• Komplexere Applikationen werden häufig aus einem Skript oder Programm gestartet, welches das Zusammenstellen der Parameter übernimmt.

Der erste Fall stellt kein Problem dar. Im zweiten Fall kann es allerdings schwierig werden, da QF-Test keine Informationen über das Startskript besitzt.

Um dieses Problem zu lösen, verwendet QF-Test eine Hülle um das java Programm aus seinem bin/envelope Verzeichnis. Für Unix enthält dieses ein Skript namens java, für Windows binäre Programme namens java.exe und javaw.exe. Diese ersetzen keinesfalls die normalen Java Startprogramme - Suns Lizenz würde das gar nicht erlauben - sondern werten lediglich die Argumente der Kommandozeile aus und stellen diese um, bevor sie das eigentliche java oder javaw Programm aufrufen.

Damit diese Hülle überhaupt zum Einsatz kommt, stellt QF-Test das bin/envelope Verzeichnis beim Start an erster Stelle in den PATH. Dies wirkt sich ausschließlich auf Programme aus, die aus QF-Test heraus gestartet werden. Auch wenn diese Hülle im normalen Betrieb völlig transparent ist, sollten Sie das bin/envelope Verzeichnis nicht in den normalen PATH aufnehmen.

Es gibt Situationen, in denen das SUT diese Java Hülle selbst beim Start aus QF-Test heraus nicht ausführt. Zum einen ist das der Fall, wenn das Startskript bzw. -programm des SUT selbst den PATH manipuliert oder ein explizites java Programm mit vollem Pfad nutzt. Zum anderen gibt es für ein Windows Programm verschiedene Möglichkeiten zum Start eines anderen Programms, wobei eventuell das Systemverzeichnis von Windows vor dem PATH durchsucht wird, so dass das dort installierte java.exe bzw. javaw.exe zum Einsatz kommt.

Um das zu umgehen, kommt QF-Test mit einem weiteren Hilfsprogramm namens qfclient in seinem normalen bin Verzeichnis, welches QF-Test beim Start ebenfalls in den PATH aufnimmt. Dieses Programm erwartet als Argumente die ganz normale Java Kommandozeile, mit dem auszuführenden java Programm als erstem Argument, gefolgt von den weiteren Argumenten. qfclient tut nichts anderes, als explizit QF-Tests java Hülle aufzurufen, so dass diese die Kommandozeile anpassen und an das eigentliche java Programm weiterreichen kann.

Wie passt das nun alles zusammen? Für eine einfache Applikation verwenden Sie einen 'Java SUT Client starten' Knoten mit den entsprechenden Attributen. Bei seiner Ausführung startet QF-Test das qfclient Programm, welches über den Umweg der java Hülle das SUT startet. Als nützlichen kleinen Nebeneffekt dieses Konstrukts, kann qfclient vorher noch das Verzeichnis wechseln, so dass das Setzen des 'Verzeichnis' Attributs auch für JDK Versionen vor 1.3 funktioniert, die das normalerweise nicht unterstützen.

Für eine komplexe Applikation, die aus einem Skript oder Programm gestartet wird, dient der 'SUT Client starten' Knoten. Bei seiner Ausführung startet QF-Test direkt das angegebene Programm und vertraut darauf, dass dieses nach seinen Vorarbeiten java oder javaw aufruft, um die Applikation auszuführen und dabei über den PATH auf QF-Tests java Hülle verwiesen wird. Wenn das Startskript des SUT wie beschrieben den PATH manipuliert oder ein explizites java Programm aufruft, merken Sie das daran, dass das SUT zwar startet, jedoch keine Verbindung zu QF-Test herstellt (der "Aufnahme" Button wird nicht aktiv). In diesem Fall müssen Sie von Hand in das Startskript eingreifen, allerdings nur ganz leicht. Bei einem binären Startprogramm bleibt dann allerdings nur der Weg über den 'Java SUT Client starten' Knoten.

Um das Startskript anzupassen, machen Sie zunächst eine Kopie speziell für den Start aus QF-Test. Suchen Sie dann nach der Zeile, die das java Programm aufruft, etwa

/usr/local/jdk1.3.1/bin/java -Duser.language=de some.package.MainClass
bzw.
exec /usr/local/jdk1.3.1/bin/java -Duser.language=de some.package.MainClass

und ändern Sie diese in

qfclient /usr/local/jdk1.3.1/bin/java -Duser.language=de some.package.MainClass
bzw.
exec qfclient /usr/local/jdk1.3.1/bin/java -Duser.language=de some.package.MainClass

Geben Sie nun das modifizierte Skript im 'Ausführbares Programm' Attribut an.

Bleibt noch die Frage, wie QF-Test die zusätzlichen Argumente für Hostname, TCP Port, und Client Name übergibt. Leider erlaubt es Java nicht - oder nur sehr unzureichend - Umgebungsvariablen für gestartete Prozesse zu definieren und bei einem 'SUT Client starten' Knoten kann QF-Test nicht selbst die Kommandozeile erweitern, da sonst das Startskript des SUT durcheinander geriete. Daher bedient sich QF-Test der standard Ein- und Ausgabekanäle des Programms, die es sowieso kontrolliert. Es schreibt die zusätzlichen Argumente in die Standardeingabe des SUT von wo sie ausgelesen werden, bevor die Kontrolle an die Starterklasse des SUT übergeben wird. Dadurch kommt es nur dann zu Konflikten, wenn das Startskript des SUT selbst von der Standardeingabe zu lesen versucht. Für eine GUI Applikation wäre das allerdings sehr ungewöhnlich.

Wenn Sie es bis hierher geschafft haben und immer noch Probleme mit dem Starten Ihrer Applikation haben, können Sie zur weiteren Problemdiagnose QF-Test mit dem Argument -dbg aufrufen. Damit geben nicht nur QF-Test selbst, sondern auch das qfclient Programm und die java Hülle ausführliche Debugmeldungen aus. Hilft auch das nicht weiter, ist es wohl Zeit um Rat zu fragen.

Letzte Änderung: 27.01.2012 Copyright © 1999-2012 Quality First Software GmbH