Seit Version 1.07 ist die Instrumentierung des JDK oder JRE in dem das SUT läuft die primäre Methode, um die Verbindung zwischen QF-Test und dem SUT herzustellen. Dieses Kapitel beschreibt die technischen Details der Vorgänge beim Instrumentieren des JDK und beim Start des SUT in einem instrumentierten JDK.

3.1.4+ Normalerweise müssen Sie standard JDKs nicht instrumentieren, da QF-Test die gleichen Informationen nun über Umgebungsvariablen an das JDK des SUT übergibt. Für Sonderfälle kann eine Instrumentierung aber dennoch nötig sein und die Informationen in diesem Kapitel sind weiterhin gültig.

Zur Instrumentierung des JDK nutzt QF-Test das offizielle accessibility Interface, das von Java zu eben diesem Zweck zur Verfügung gestellt wird. Mit seiner Hilfe können accessibility und capture/replay Werkzeuge mit Java Anwendungen interagieren, ohne dass diese Anwendungen davon wissen oder gar modifiziert werden müssen.

Um dieses Interface zu aktivieren erstellt oder modifiziert QF-Test die Datei .../lib/accessibility.properties in der JDK Installation und fügt die Klasse de.qfs.apps.qftest.start.Connector zur Property "assistive_technologies" hinzu. Dies hat den Effekt, dass diese Klasse immer instantiiert wird, wenn das AWT Toolkit in einer Java Anwendung oder einem Applet in dieser Java VM initialisiert wird.

Um sicherzustellen dass diese Klasse immer gefunden werden kann ohne den CLASSPATH zu modifizieren, wird die Datei qfconnect.jar, welche die Connector Klasse enthält, in das Verzeichnis .../lib/ext für Java Erweiterungen kopiert.

Beim Deinstumentieren des JDK löscht QF-Test zunächst seinen Eintrag aus der assistive_technologies Property in accessibility.properties, so dass die Connector Klasse nicht mehr verwendet wird. Anschließend versucht QF-Test qfconnect.jar aus dem .../lib/ext Verzeichnis zu löschen. Unter Windows ist dies nicht möglich, falls QF-Test selbst in dieser Java VM läuft. Löschen Sie in diesem Fall die Datei von Hand. Dies ist allerdings nicht unbedingt nötig, da diese keinerlei Einfluss mehr auf das JDK hat nachdem accessibility.properties angepasst wurde.

Wenn die Klasse de.qfs.apps.qftest.start.Connector bei der Initialisierung des AWT Toolkits in einer Java Anwendung instantiiert wird überprüft sie zunächst, ob die Anwendung aus QF-Test heraus gestartet wurde, d.h. ob es sich dabei um ein System Under Test handelt oder um eine normale Anwendung. In letzterem Fall unternimmt die Connector Klasse nichts und hat keinerlei weiteren Einfluss auf die Anwendung.

Im Falle eines SUT wird ein spezieller ClassLoader eingerichtet, der die Klassen der Wrapper Schicht lädt, die QF-Test um das SUT legt. Dieser Wrapper stellt nach seiner Initialisierung die RMI Verbindung mit QF-Test her, genau wie die alte Wrapper Schicht.

Es gibt einige feine Unterschiede zwischen dieser Technik und der alten Technik, bei der die Kommandozeile des SUT modifiziert wurde:

• Der Prozess des SUT wird direkt von QF-Test gestartet ohne dazwischen liegende Prozesse wie qfclient oder QF-Test's java Envelope.
• Die Klassen des QF-Test Wrappers um das SUT werden alle durch den speziellen ClassLoader geladen, so dass diese völlig von den normalen Klassen des SUT getrennt sind. Selbst wenn das SUT und QF-Test die gleichen Softwarepakete in verschiedenen Versionen nutzen sollten, dürften daraus keine Probleme entstehen.
• Dieser ClassLoader sorgt außerdem dafür, das der QF-Test Wrapper alle benötigten Rechte besitzt. Änderungen an policy Dateien sind damit überflüssig.
• Mit dieser Technik ist es möglich auch Anwendungen zu testen, die direkt aus einem Programm gestartet werden. Ebenso können Java WebStart basierte Anwendungen ohne Änderungen an jnlp Dateien getestet werden und selbst auf Applets, die im Java Plugin in einem Browser laufen besteht damit Zugriff.

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