Um Ihre eigene Anwendung, die wir als System Under Test (SUT) bezeichnen werden, mit QF-Test zu testen, muss diese aus QF-Test heraus gestartet werden. Wie im vorhergehenden Kapitel beschrieben, hängen die Voraussetzungen hierzu von der Art der Anwendung ab.

Normalerweise verbindet sich QF-Test automatisch mit AWT/Swing Anwendungen, sofern Sie nicht die Option Ohne JDK Instrumentierung verbinden (Swing) deaktivieren oder mit nicht-standard JDKs arbeiten. In diesen Sonderfällen müssen zunächst das JDK instrumentieren, mit dem das SUT ausgeführt wird.

Hinweis Um ein JDK instrumentieren zu können, benötigen Sie Schreibrechte auf einige seiner Unterverzeichnisse, so dass Sie für diesen Schritt QF-Test gegebenenfalls mit Administratorrechten ausführen müssen. Details zur Accessibility-Schnittstelle und der Instrumentierung finden Sie in Kapitel 31. Dieser Abschnitt befasst sich damit, wie Sie die (De-)Instrumentierung mit QF-Test durchführen können und wie QF-Test die Informationen darüber verwaltet, welche JDKs bereits instrumentiert wurden.

Nachdem Sie QF-Test gestartet haben, öffnen Sie bitte über den Menüeintrag »Extras«-»Instrumentierung der JDKs verwalten...« folgenden Dialog:

		Abbildung 4.1:  Dialog zur JDK Instrumentierung

Hinweis Falls Sie eine Warnung bekommen, dass die Datei zur Verwaltung der JDKs gegenwärtig gesperrt ist, liegt das normalerweise daran, dass ein anderer Anwender die selbe QF-Test Installation verwendet und gerade JDKs instrumentiert. Versuchen Sie es in diesem Fall kurze Zeit später noch einmal. Wenn die Sperre nicht verschwindet obwohl augenscheinlich niemand mit der JDK Instrumentierung arbeitet, können Sie diese auch einfach ignorieren.

Der Dialog zur Instrumentierung zeigt die Liste der JDKs und JREs, die QF-Test bekannt sind. Anfangs enthält diese Liste nur ein JDK, nämlich das, mit dem QF-Test selbst läuft. Wenn Ihr SUT mit einem anderen JDK oder JRE gestartet wird, müssen Sie QF-Test dessen Ort mitteilen. Öffnen Sie dazu über den Button "JDK/JRE Suchen" den Dateiauswahldialog und wählen Sie darin ein Verzeichnis aus. QF-Test durchsucht dieses Verzeichnis sowie alle direkten oder indirekten Unterverzeichnisse und fügt alle dabei gefundenen JDKs zur Liste hinzu.

Falls Sie nicht wissen mit welchem JDK Ihr SUT ausgeführt wird, instrumentieren Sie zunächst nur das eine JDK, das immer verfügbar ist, und probieren Sie, ob es damit funktioniert. Wenn es nicht funktioniert, bemerken Sie das daran, dass nach dem Start des SUT der Aufnahmeknopf nicht aktiviert wird. In diesem Fall können Sie entweder Ihre Entwickler fragen oder selbst nach dem JDK suchen. Unter Windows ist C:\Programme\Java ein aussichtsreicher Kandidat. Unter Unix gibt es verschiedene Möglichkeiten, üblich sind z.B. /usr/lib/java, /usr/share/java, /usr/local/java, etc. Es kann aber auch sein, dass Ihre Anwendung mit einem eigenen JRE ausgeliefert wird. Daher empfiehlt es sich, QF-Test auch das Verzeichnis des SUT durchsuchen zu lassen.

In der Spalte 'Typ' steht normalerweise 'JDK' oder 'JRE' bzw. '---' im Falle eines ungültigen Pfades. Diese Typ Information ist nur der Vollständigkeit halber vorhanden und nicht wirklich von Bedeutung. Wichtig ist hingegen die Spalte 'Status'. Hier sind folgende Werte möglich:

Nicht instrumentiert

Das JDK ist in seinem initialen, unmodifizierten Zustand.

Instrumentierung aktuell

Das JDK wurde instrumentiert und die dabei installierte jar Datei entspricht der aktuellen Version von QF-Test.

Instrumentierung veraltet

Das JDK wurde instrumentiert, die aktuelle QF-Test Version beinhaltet jedoch eine aktuellere jar Datei, so dass Sie das JDK erneut instrumentieren müssen.

Instrumentierung inkonsistent

Das JDK wurde nur zum Teil instrumentiert, entweder weil etwas während der (De-)Instrumentierung schiefgegangen ist, oder weil jemand (oder ein anderes Programm) das JDK modifiziert hat. Instrumentieren oder deinstrumentieren Sie das JDK nach Bedarf.

Pfad ungültig

Entweder gibt es das JDK nicht mehr, dann können Sie diesen Eintrag aus der Liste entfernen, oder es gehört - wie unten beschrieben - zu einem anderen Rechner, dann sollten Sie es einfach ignorieren.

Zum Instrumentieren, Deinstrumentieren oder Entfernen aus der Liste selektieren Sie ein oder mehrere JDKs und klicken Sie auf den entsprechenden Button. Wenn Sie fertig sind, speichern Sie die Liste und schließen Sie den Dialog.

Die Liste der QF-Test bekannten JDKs wird in der Datei qfconnect.properties in QF-Test's Wurzelverzeichnis gespeichert. Falls QF-Test auf einem Netzlaufwerk installiert ist, welches von mehreren Rechnern - eventuell mit unterschiedlichen Betriebssystemen - genutzt wird, teilen sich alle Systeme diese Datei. Wie Sie in obiger Abbildung sehen ist das kein Problem. Wenn Sie den Dialog öffnen, überprüft QF-Test, ob die gespeicherten JDKs auf diesem System existieren. Nicht vorhandene JDKs werden mit "Pfad ungültig" markiert und können ignoriert werden. Kurz gesagt können Sie z.B. zunächst auf einem Windows System Ihre Windows JDKs instrumentieren und später auf einem Unix System die dortigen JDKs, ohne dass diese miteinander in Konflikt kommen.

Sollten Sie keine Schreibberechtigung für die qfconnect.properties Datei haben, kann QF-Test zwar die Liste der JDKs nicht speichern, die Instrumentierung an sich ist davon aber nicht betroffen.

Zum Testen von SWT basierten Anwendungen mit QF-Test/swt sind spezielle Installationsschritte erforderlich. Da bei der Entwicklung von SWT die Testbarkeit von Anwendungen nicht berücksichtigt wurde müssen diese mit einer leicht modifizierten SWT Version gestartet werden. Darin haben wir SWT um die nötigen Einstiegspunkte zum Filtern von Events und Auffinden von GUI Komponenten erweitert. Die Änderungen sind transparent so dass das Verhalten einer Anwendung innerhalb und außerhalb von QF-Test nicht verändert wird.

Wenn Sie den Schnellstart Wizard von QF-Test zur Erstellung der Startsequenz für Ihr SUT verwenden (siehe Kapitel 3), wird er sich auch um die SWT Instrumentierung kümmern. Für diejenigen unter Ihnen, die nicht so gerne mit Wizards arbeiten, sei nun der händische Weg erklärt.

Die Standardbibliothek qfs.qft, die Teil der Distribution von QF-Test ist und ausführlich im Tutorial beschrieben wird, enthält im 'Package' qfs.swt.instrument eine 'Prozedur' namens setup um die SWT Instrumentierung durchzuführen. Fügen Sie vor dem Startknoten für Ihr SUT einen 'Prozeduraufruf' Knoten ein. Setzen Sie 'Name der Prozedur' auf qfs.qft#qfs.swt.instrument.setup und in den 'Variablen Definitionen' den Parameter sutdir auf das Installationsverzeichnis Ihrer Anwendung. Der Parameter plugin kann leer gelassen werden, es sei denn Ihre Anwendung folgt nicht dem üblichen Layout des Plugin-Verzeichnisses. In diesem Fall können Sie das zu instrumentierende Plugin direkt über den plugin Parameter angeben. Das ist alles. Für jene, die genau wissen möchten, was hinter den Kulissen abläuft, werden nachfolgend in diesem Kapitel die manuellen Schritte zur SWT Instrumentierung beschrieben.

Die für SWT Tests unterstützten Architekturen umfassen 32 und 64 Bit Windows und 32 und 64 Bit Linux mit Gtk. Die benötigten Dateien werden mit QF-Test in den Verzeichnissen namens .../qftest-3.2.2/swt/$ARCH/$VERSION bereit gestellt, wobei $ARCH entweder win32, win32-64, linux-gtk oder linux-gtk-64 ist und $VERSION eine der unterstützten SWT Versionen.

Zunächst müssen Sie herausfinden ob Ihre Anwendung eine eigenständige SWT Anwendung ist oder auf Eclipse basiert. Werfen Sie dazu einfach einen Blick auf die Verzeichnisstruktur Ihrer Anwendung. Wenn Sie ein Verzeichnis namens plugins finden das eine Datei namens org.eclipse.swt.win32.win32.x86_X.Y.Z.jar (unter Windows) oder org.eclipse.swt.gtk.linux.x86_X.Y.Z.jar (unter Linux) enthält, wobei X.Y.Z einer Versionsnummer wie 3.2.0 entspricht, basiert Ihre Anwendung auf Eclipse. Bei einer eigenständigen SWT Anwendung sollten Sie dagegen eine Datei namens swt.jar finden, üblicherweise in einer Verzeichnis namens lib.

Ersetzen Sie einfach die Datei mit dem SWT Plugin durch ein von QF-Test instrumentiertes Plugin. Um dieses zu erstellen, führen Sie einmal die oben beschriebene 'Prozedur' qfs.qft#qfs.swt.instrument.setup aus. Geben Sie dabei Ihr original Plugin (oder eine Kopie davon) im Parameter plugin an. QF-Test erstellt eine Kopie des Originals namens _org.eclipse.swt....jar.orig. Kopieren Sie dann die instrumentierte Datei in das plugin Verzeichnis Ihrer Anwendung. Die SWT Plugin Dateien enden mit Versionsinformation der Form ...X.Y.Z.jar, z.B. org.eclipse.swt.win32.win32.x86_3.2.0.jar. Um die entsprechende Datei aus QF-Test verwenden zu können, muss der X.Y Teil exakt übereinstimmen. Die Unterversion Z muss in der QF-Test Variante größer oder gleich dem Original sein.

Zum Abschluss starten Sie Ihre Anwendung einmal von der Kommandozeile mit dem Argument -clean um den Plugin Cache der Anwendung zu aktualisieren:

eclipse -clean

Die Programmdatei Ihrer Anwendung heißt eventuell nicht eclipse, aber alle Eclipse basierten Anwendung sollten das Argument -clean unterstützten.

Bei einer eigenständigen SWT Anwendung ersetzen Sie die Datei swt.jar mit der gleichnamigen Datei aus dem oben erwähnten Verzeichnis von QF-Test. Machen Sie dabei zunächst eine Sicherheitskopie vom Original.

LinuxAuf Linux Systemen müssen Sie außerdem die Datei libqfswt-gtk-xxxx.so in das Verzeichnis mit den Shared Libraries von SWT kopieren, wobei xxxx eine Versionsnummer ist. Dieses Verzeichnis heißt üblicherweise bin und kann leicht an Hand der anderen Bibliotheken identifiziert werden, die alle Namen der Form libswt-...-xxxx.so haben.

Hinweis Falls Sie die Version Ihrer SWT Bibliotheken nicht kennen, suchen Sie zunächst nach dem Verzeichnis mit den Shared Libraries wie oben beschrieben. Unter Windows haben diese Namen der Form swt-...-win32-xxxx.dll. Die ersten beiden Ziffern der Versionsnummer xxxx entsprechen der major und medium Version der entsprechenden mit QF-Test gelieferten SWT Bibliotheken. Ist zum Beispiel die Versionsnummer 3139, finden Sie die Ersatz Bibliothek im Verzeichnis .../qftest-3.2.2/swt/win32/3.1 für Windows bzw. .../qftest-3.2.2/swt/linux-gtk/3.1 für Linux.

Mit dem Schnellstart Wizard bietet QF-Test ein Hilfsmittel, um Sie Schritt für Schritt durch den Prozess zur Erstellung einer Startsequenz für Ihr SUT zu leiten. Informationen zum Schnellstart Wizard finden Sie im Kapitel Kapitel 3.

Trotzdem soll hier auch der "händische" Weg erklärt werden, wie Sie einen Startknoten für Ihr SUT erstellen können. Es gibt im Wesentlichen zwei Methoden zum Start einer Java Anwendung aus QF-Test als SUT. Die erste entspricht einem normalen java ... Aufruf über die Kommandozeile, wobei es dabei Varianten zum Start einer Klasse oder einer jar Datei gibt. Die Alternative ist ein Skript oder ein ausführbaren Programm, das dann die Java VM startet. Indirekte Methoden wie der Start des SUT über ant fallen ebenso in diese Kategorie wie Java WebStart und Applets, die im Java Plugin eines Web Browsers ausgeführt werden.

Im Folgenden werden einige typische Konstellationen beispielhaft erläutert. Für nähere Informationen zu den auszufüllenden Werten folgen Sie bitte den entsprechenden Verweisen in den Referenzteil. Das Tutorial enthält weitere Beispiele zu diesem Thema.

Unabhängig davon wie Sie das SUT starten, der jeweilige Knoten sollte normalerweise direkt von einem 'Warten auf Client' Knoten mit identischem 'Client' Attribut gefolgt werden. Auch hierzu finden Sie weiterführende Informationen im Referenzteil.

Wird Ihre Anwendung im Normalfall durch ein Skript oder ein ausführbares Programm gestartet, erstellen Sie einen 'SUT Client starten' Knoten wie folgt:

		Abbildung 4.2:  Starten des SUT aus einem Skript oder ausführbaren Programm

• Fügen Sie einen 'SUT Client starten' Knoten ein.
• Geben Sie dem SUT im 'Client' Attribut einen Namen.
• Setzten Sie das Attribut 'Ausführbares Programm' auf das Skript oder das Programm, mit dem das SUT gestartet wird. Wenn sich das Skript oder Programm nicht auf dem PATH befindet, muss es mit vollem Pfad angegeben werden.
• Legen Sie im 'Verzeichnis' Attribut das Arbeitsverzeichnis der Anwendung fest.
• Im Falle eines Skripts sollten Sie eine eventuell vorhandene Ausgabeumleitung (z.B. >ausgabe.log) beim java Aufruf entfernen, damit die Ausgabe bei QF-Test ankommt und im Protokoll aufgezeichnet werden kann. Ebenso behindert unter Windows ein vorangestellter start Befehl das Aufzeichnen der Ausgaben des SUT.

Mit dem neuen Verbindungsmechanismus kann das SUT mittels Java WebStart direkt über QF-Test gestartet werden, ohne dass Änderungen am JNLP Deskriptor nötig sind (verwenden Sie also nicht »Extras«-»WebStart SUT Client Starter erstellen...«). Erstellen Sie stattdessen direkt einen 'SUT Client starten' Knoten wie folgt:

		Abbildung 4.3:  Starten des SUT mittels Java WebStart

• Fügen Sie einen 'SUT Client starten' Knoten ein.
• Geben Sie dem SUT im 'Client' Attribut einen Namen.
• Setzten Sie das Attribut 'Ausführbares Programm' auf das Java WebStart Programm. Dieses heisst normalerweise javaws und befindet sich innerhalb des JDK oder JRE. Sie werden vermutlich den vollständigen Pfad angeben müssen.
• Für Java WebStart ist das 'Verzeichnis' Attribut normalerweise ohne Bedeutung. Allerdings sucht Java WebStart beim Start in diesem Verzeichnis nach der Datei .javaws, in der zum Beispiel Einstellungen zu Debugging Ausgaben vorgenommen werden können.
• Erstellen Sie in der 'Parameter' Tabelle für das Programm eine Zeile mit der URL für den JNLP Deskriptor der Anwendung.

Mit dem neuen Verbindungsmechanismus können Applets direkt im Web Browser getestet werden, sofern ein aktuelles Java Plugin (Version 1.3 oder höher) im Browser installiert ist. Alternativ können Applets auch im Appletviewer getestet werden, Näheres hierzu finden Sie in Abschnitt 33.3. Zum Start des SUT als Applet in einem Web Browser erstellen Sie einen 'SUT Client starten' Knoten wie folgt:

		Abbildung 4.4:  Starten des SUT als Applet in einem Web Browser

• Fügen Sie einen 'SUT Client starten' Knoten ein.
• Geben Sie dem SUT im 'Client' Attribut einen Namen.
• Setzten Sie das Attribut 'Ausführbares Programm' auf den Browser, den Sie starten wollen, z.B. firefox, iexplore, mozilla, netscape oder opera, um nur einige zu nennen. Eventuell müssen Sie den vollständigen Pfad angeben.
• Für das Starten des Applets ist das 'Verzeichnis' Attribut normalerweise ohne Bedeutung.
• Erstellen Sie in der 'Parameter' Tabelle für das Programm eine Zeile mit der URL für die Webseite des Applets.

Windows Mit dem Internet Explorer unter Windows gibt es vereinzelt Probleme, die den Aufbau der Verbindung vom Applet zu QF-Test verhindern. Dies liegt an einer falschen Registry Einstellung, von der abhängt, ob Windows jede Instanz des Internet Explorers in einem eigenen Prozess ausführt oder einen gemeinsamen Prozess verwendet. Letzteres funktioniert mit QF-Test nicht, da das Java Plugin damit nur einmal beim Start des Systems initialisiert wird.

Eigentlich sollte der Internet Explorer bei seiner Installation diesen Registry Wert abhängig vom verfügbaren Speicher setzen, wobei bei mehr als 32MB ein eigener Prozess für jede Instanz verwendet werden sollte. Dies gilt also eigentlich für jeden Rechner der größer ist als ein PDA. Leider ist dies durch einen Fehler in der Installation aber nicht immer der Fall. Um das zu beheben, muss der Registry Schlüssel

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\BrowseNewProcess

eine Zeichenfolge namens "BrowseNewProcess" mit dem Wert "yes" enthalten. Wir liefern dazu die Registry Datei namens ...\qftest\qftest-3.2.2\misc\HKLM_BrowseNewProcess.reg mit, die Sie einfach durch einen Doppelklick ausführen können, um diese Einstellung vorzunehmen. Eventuell müssen Sie den Rechner neu starten, damit die Einstellung wirksam wird.

Eventuell ist dies noch nicht ausreichend, falls Sie entweder nicht die Rechte zur Änderung von Schlüsseln unter HKEY_LOCAL_MACHINE besitzen, oder falls es einen analogen Schlüssel unter HKEY_CURRENT_USER mit dem Wert "no" gibt, der diesen übertrifft. Der komplette Schlüssel lautet

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\BrowseNewProcess

Falls die HKEY_LOCAL_MACHINE Einstellung korrekt ist, können Sie den Schlüssel unter HKEY_CURRENT_USER entfernen. Falls Sie die nötigen Rechte haben oder nicht verstehen, was damit gemeint ist, führen Sie einfach die zweite von uns bereitgestellte Registry Datei namens ...\qftest\qftest-3.2.2\misc\HKCU_BrowseNewProcess.reg aus, welche den Wert unter HKEY_CURRENT_USER auf "yes" ändert. Damit sollte es in jedem Fall funktionieren (gegebenenfalls erst nach einem Neustart), allerdings nur für Sie selbst. Ein anderer Anwender auf dem selben Rechner muss eventuell ebenfalls die Einstellungen ändern.

Hinweis Firefox 2.0 hat eine eingebaute Funktion zur Wiederherstellung von Sessions, die zu Konflikten mit QF-Test führt. Wenn QF-Test ein Applet und damit den Browser beendet, wird dies von Firefox als Absturz gewertet. Beim nächsten Start öffnet Firefox einen Dialog in dem angeboten wird, die letzte Session fortzusetzen. Dieser Dialog kann von QF-Test nicht kontrolliert werden, so dass der Test nicht unbeaufsichtigt fortgesetzt werden kann.

Um dieses Problem zu umgehen müssen Sie zunächst ein neues Benutzerprofil anlegen, wie unter http://kb.mozillazine.org/Profile_Manager beschrieben. Starten Sie Firefox aus QF-Test immer mit diesem Benutzerprofil. Verwenden Sie hierzu den Befehl firefox -P <Profile>. Schalten Sie anschließend das Wiederherstellen der Sitzung für dieses Profil aus. Dazu editieren Sie wie unter http://kb.mozillazine.org/Editing_configuration beschrieben die Benutzereinstellungen. Sie müssen eine Option namens browser.sessionstore.resume_from_crash anlegen und diese auf false setzen.

Wird Ihre Anwendung im Normalfall durch ein Kommando der Form java -jar <Archiv> gestartet, erstellen Sie einen 'Java SUT Client starten' Knoten wie folgt:

		Abbildung 4.5:  Starten des SUT aus einem jar Archiv

• Fügen Sie einen 'Java SUT Client starten' Knoten ein.
• 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 der Anwendung 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' befinden sollte.

Wird Ihre Anwendung im Normalfall durch ein Kommando der Form java -classpath <Pfad> <Startklasse> gestartet, erstellen Sie einen 'Java SUT Client starten' Knoten wie folgt:

		Abbildung 4.6:  Starten des SUT über die Startklasse

• Fügen Sie einen 'Java SUT Client starten' Knoten ein.
• 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 der Anwendung fest.
• Setzen Sie das Attribut 'Klasse' auf den vollen Namen der Startklasse (die Klasse mit der main() Methode), so wie er auch für das java Kommando angegeben wird.
• 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.

Hinweis Aktuell benötigt QF-Test für das Testen einer Webanwendung zwingend einen 32-Bit Browser. Da es kaum Bedarf für mehr als 4GB Speicher für einen Browser-Prozess gibt, sind 64-Bit Browser wzar noch die Ausnahme aber auf einem 64-Bit Linux System kann der Standard-Browser durchaus 64-Bit sein. In diesem Fall müssen Sie zusätzlich einen 32-Bit Firefox installieren. Außerdem ist auf 64-Bit Systemen oft nur ein 64-Bit JDK bzw. JRE installiert. In diesem Fall müssen Sie zusätzlich ein 32-Bit JDK/JRE installieren und QF-Test damit starten. Hierzu stellen Sie das 32-Bit JDK bei der Installation von QF-Test oder über QF-Test's Java Konfiguration ein, oder Sie starten QF-Test von der Kommandozeile mit -java <Programm>. Falls Sie einen 32-Bit Browser und ein 32-Bit JDK verwenden und der Browser trotzdem nicht aus QF-Test heraus startet, stellen Sie bitte sicher, dass es sich um ein original JDK von Sun oder openJDK handelt.

Wie bei Swing und SWT wird der Browser für ein Web-SUT als separater Prozess aus QF-Test heraus gestartet. Um Zugriff auf die Interna des Browsers und die darin dargestellte Webseite mit ihrem Document Object Model (DOM) zu erhalten, bettet QF-Test standard Browser wie Internet Explorer und Mozilla in eine eigene Hülle ein. Die Technologie zur Einbettung und für den Zugriff auf die Browser ist von der itCampus GmbH lizenziert. Sie zeichnet sich aus durch besonders effizienten Zugriff auf das DOM, weit über die üblichen Browser-Schnittstellen hinaus und bietet dafür eine einheitliche Schnittstelle, welche die Unterschiede zwischen den Browsern versteckt. Dies ermöglicht QF-Test - und damit Ihnen - eine Anwendung in allen unterstützten Browsern und auf mehreren Plattformen mit nur einem Satz von Tests zu automatisieren.

		Abbildung 4.7:  Starten einer Webanwendung im Browser

Ein Browser wird mit Hilfe eines 'Browser starten' Knotens gestartet. Ein SUT Web Client-Prozess kann mehrere Browserfenster gleichzeitig öffnen, darunter sogar eine Mischung aus Internet Explorer und Mozilla Fenstern. Zusätzliche Fenster in einem bereits laufenden Prozess können über einen 'Browser starten' Knoten mit gesetztem Attribut 'Neues Browser-Fenster in bestehendem Prozess öffnen' geöffnet werden, oder als Ergebnis eines Klicks auf einen Link in einer Webseite, der ein Popup-Fenster öffnet.

Hinweis Grundsätzlich arbeitet QF-Test mit allen Mozilla basierten 32Bit Browsern ab Version 1.8 zusammen, insbesondere SeaMonkey ab Version 1.0 und Firefox ab Version 1.5. Auf einem 64Bit System müssen Sie eine 32Bit Version des Browsers installieren, mit dem Sie testen wollen.

Ein gewichtiger Unterschied zwischen obigen Browsern unter Windows ist, dass Firefox bis einschließlich Version 2 als speziell optimierte Version mit statisch gelinkten Bibliotheken ausgeliefert wurde. SeaMonkey und Firefox 3 sind dagegen dynamisch gelinkt. Damit QF-Test einen installierten Browser einbetten kann, müssen dessen Komponenten dynamisch zur Laufzeit gelinkt werden können, was bei einem Browser ohne modulare Komponenten, wie Firefox 2, nicht möglich ist. Wir empfehlen daher SeaMonkey oder Firefox 3 anstelle von Firefox 1 oder 2 für Ihre Tests zu verwenden.

Falls es unbedingt nötig ist, Ihre Tests mit Firefox 2 auszuführen, können Sie eine dynamisch gelinkte Version für Windows herunterladen, die unsere Partnerfirma itCampus unter http://www.web2test.de/download/firefox_2012.zip bereitstellt.

Hinweis Beim Erstellen Ihrer Startsequenz mit dem Schnellstart-Assistenten - oder beim manuellen Setzen des Attributs 'Verzeichnis der Mozilla Installation' - versuchen Sie QF-Test auf eine aktuelle Firefox oder SeaMonkey Installation zu verweisen. Falls Sie die Meldung erhalten, dass das Gecko Runtime Environment (GRE) nicht erkannt werden kann, stellen Sie bitte sicher, dass Sie einen 32Bit Browser installiert haben. Unter Linux kann der Standard-Browser Ihrer Installation an verschiedenen Orten installiert sein. Ein gängiges Verzeichnis ist /usr/lib/xulrunner-<Version>.

Dies ist eine knifflige Konstellation, die mit QF-Test vor Version 1.7 nicht möglich war. Wird eine zweite Java VM aus einem bereits verbundenen SUT gestartet, erkennt QF-Test beim Verbindungsaufbau, dass es sich um einen Kindprozess des ersten SUT handelt und vergibt automatisch einen neuen Client Namen. Hierzu wird dem Namen des ersten SUT ':2' angefügt, was betont, dass es sich um den zweiten Prozess für diesen Client handelt. Einem weiteren derart gestarteten SUT wird ':3' an den Namen angefügt, es sei denn, das zweite SUT ist bereits beendet, so dass ':2' wieder verfügbar ist.

Eine Sequenz zum indirekten Start eines SUT besteht also üblicherweise aus einem Event Knoten der z.B. einen Buttonklick oder eine Menüauswahl auslöst und das erste SUT zum Start des zweiten SUT veranlasst, gefolgt von einem 'Warten auf Client' Knoten für den um ':2' erweiterten Client Namen.

Die Ausgaben aller von QF-Test gestarteten Prozesse werden von QF-Test umgeleitet und im Protokoll unter dem Knoten gespeichert, der den Prozess gestartet hat. Dabei macht QF-Test keinen Unterschied zwischen SUT Clients und sonstigen Prozessen oder Shellskripten, die mittels eines 'Programm starten' oder 'Shellkommando ausführen' Knotens gestartet wurden.

Das Hauptfenster enthält ein gemeinsames Terminal für die Ausgaben aller Prozesse, die von einem Test aus diesem Fenster gestartet wurden. Das Untermenü »Ansicht«-»Terminal« enthält einige Menüeinträge, mit deren Hilfe Sie das Terminal ein- und ausschalten oder festlegen können, ob lange Zeilen umgebrochen werden und ob automatisch an das Ende gescrollt werden soll, wenn neue Ausgaben eintreffen. Außerdem können Sie das Terminal löschen oder seinen Inhalt in eine Datei speichern. Die maximale Größe des Terminals wird über die Option Maximalgröße des gemeinsamen Terminals (kB) festgelegt.

Zusätzlich zum gemeinsamen Terminal gibt es für jeden aktiven Prozess und die letzten beendeten Prozesse ein individuelles Terminalfenster, das ebenfalls die Ausgaben des Prozesses anzeigt. Terminalfenster sind über das »Clients« Menü zugänglich. Das gemeinsame Terminal dient hauptsächlich dazu, auf das Eintreffen neuer Ausgaben aufmerksam zu machen, während die individuellen Terminalfenster besser zum gründlichen Studieren der Ausgaben geeignet sind.

Über das »Clients« Menü können Prozesse auch beendet werden, entweder einzeln oder alle auf einmal mittels »Clients«-»Alle beenden«.

Die Anzahl der beendeten Prozesse, die im »Clients« Menü verfügbar sind, wird über die Option Wie viele beendete Clients im Menü festgelegt (Standard ist 4). Wenn Ihre Prozesse sehr viele Ausgaben erzeugen, kann es sinnvoll sein, diese Zahl zu reduzieren um Speicher zu sparen.

Letzte Änderung: 14.07.2010 Copyright © 1999-2010 Quality First Software GmbH