Dieser Ast ist für allgemeine QF-Test Einstellungen zuständig.

		Abbildung 29.2:  Allgemeine Optionen

Fragen vor Schließen (User)

Wurde eine Testsuite oder ein Protokoll modifiziert, wird vor dem Schließen eines Fensters oder dem Beenden von QF-Test normalerweise gefragt, ob die Daten gespeichert werden sollen. Diese Abfrage kann durch Ausschalten dieser Optionen, getrennt für Testsuiten und Protokolle, verhindert werden, was gefährlich ist, da die Änderungen dann einfach verworfen werden.

Fragen vor Überschreiben (User)

Wenn Sie eine Testsuite oder ein Protokoll abspeichern oder einen Report, Testdoc oder Pkgdoc Dokumentation generieren und die Zieldatei bzw. das Verzeichnis bereits existiert, wird normalerweise rückgefragt, ob Sie die Datei überschreiben wollen. Durch ausschalten der entsprechenden Optionen können Sie diese Frage für jeden Dateityp getrennt unterbinden.

Letzte Sitzung beim Start wiederherstellen (User)

Ist diese Option gesetzt und wird QF-Test in der Workbench-Ansicht geöffnet, wird die letzte Sitzung wieder hergestellt indem die zuletzt geöffneten Testsuiten geladen werden und der zuletzt selektierte Knoten in der jeweiligen Suite selektiert wird. Sind ein oder mehrere Testsuiten auf der Kommandozeile angegeben, werden diese zusätzlich geladen und erhalten nach dem Start den initialen Fokus.

Leere Suite nach Laden schließen (User)

Bei der täglichen Arbeit ist die erste Aktion nach dem Starten von QF-Test meistens das Laden einer Testsuite. Die leere Ausgangssuite wird meist nicht mehr benötigt. Durch setzen dieser Option kann diese Suite automatisch geschlossen werden.

Wie viele zuletzt besuchte Dateien im Menü (User)

Im »Datei« Menü können Sie schnell auf die Testsuites und Protokolle zugreifen, die Sie zuletzt bearbeitet haben. Diese Option legt die Zahl derartiger Menüeinträge fest.

Voreingestellte Sprache für Skript Knoten (User)

Diese Option kann die Werte "Jython" oder "Groovy" annehmen und legt die Standardeinstellung für das Attribut 'Skriptsprache' in neu erstellten 'Server Skript' oder 'SUT Skript' Knoten fest.

Standard-Zeichenkodierung für Jython (System)

Diese Option legt die Standard-Zeichenkodierung für Jython Skripte in 'Server Skript' und 'SUT Skript' Knoten sowie den interaktiven Jython Terminals für QF-Test und das SUT fest. Die Standard-Kodierung für Jython ist normalerweise 'ascii'. Um die Migration zu erleichtern und die wechselseitige Kompatibilität mit älteren QF-Test Versionen zu verbessern, verwendet QF-Test standardmäßig die Kodierung 'latin-1'. Sie können auch mit anderen Einstellungen experimentieren, die besser zu Ihren Spracheinstellungen passen.

Hintergrundinformationen finden Sie unter http://docs.python.org/library/codecs.html.

Hinweis Diese Option hat keinen Einfluss auf die Kodierung von Python Modulen in separaten Dateien. Wenn ein Modul nicht geladen werden kann, weil keine explizite Kodierung angegeben wurde, müssen Sie vermutlich eine Zeile der Form

# coding: latin-1

im Kopf der Datei angeben. Weitere Informationen hierzu finden Sie unterhttp://www.python.org/peps/pep-0263.html.

Alte GNU Regexps verwenden (vor QF-Test Version 3.1) (System)

Server oder SUT Skript Name: OPT_USE_GNU_REGEXP

Seit Version 3.1 verwendet QF-Test die standard Java Syntax für reguläre Ausdrücke. Falls bei älteren Tests dadurch Probleme mit regulären Ausdrücken auftreten, können Sie über diese Option zurück zum GNU Regexp Package wechseln. Weitere Informationen zu regulären Ausdrücken finden Sie in Abschnitt 36.4.

Diese Einstellungen betreffen das Editieren von Knoten im Baum und in der Detailansicht.

		Abbildung 29.3:  Editieren

Warnen wenn eine nicht speicherbare Testsuite modifiziert wird (User)

Falls das Speichern von Testsuites nicht erlaubt ist, z.B. wenn Sie ohne Lizenz arbeiten, gibt QF-Test nach der ersten Änderung an einer Suite die Warnung aus, dass Sie Ihre Änderungen nicht speichern können. Durch Ausschalten dieser Option können Sie diese Warnung unterdrücken.

Vor implizitem Übernehmen von Änderungen in den Details nachfragen (User)

Wenn Sie Änderungen an den Attributen eines Knotens in der Detailansicht des Editors vornehmen und vergessen, diese mit OK zu bestätigen, bevor Sie in der Baumansicht zu einem anderen Knoten wechseln, kann QF-Test die Änderungen wahlweise automatisch übernehmen oder zunächst einen Dialog mit der Detailansicht zur Bestätigung öffnen. Folgende Optionen stehen zur Auswahl:

Immer

Werte nicht implizit übernehmen sondern immer bestätigen lassen.

Nur wenn Werte ungültig oder suspekt sind

Werte implizit ohne Bestätigung übernehmen sofern sie gültig und nicht suspekt sind. Aktuell ist "suspekt" mit Leerzeichen am Beginn oder Ende eines Wertes gleichzusetzen, was zu subtilen Problemen führen kann, deren Ursache schwer zu erkennen ist.

Niemals

Alle gültigen Werte implizit ohne weitere Bestätigung übernehmen.

Das ausdrückliche Verwerfen von Änderungen mit Hilfe des entsprechenden Buttons oder durch drücken von [Escape] wird hiervon nicht beeinflusst.

Anzahl der zurücknehmbaren Änderungen pro Suite (User)

Hiermit legen Sie fest, wieviele Bearbeitungsschritte Sie in einer Testsuite oder einem Protokoll rückgängig machen können.

Intelligentes Scrollen in Bäumen (User)

Die Standardmethoden von Swing für die Interaktion mit Bäumen lassen einiges zu wünschen übrig. So führt zum Beispiel das Bewegen der Selektion zu unnötigem horizontalen Scrolling. Zusätzlich hat Swing die Tendenz, den selektierten Knoten so zu positionieren, dass nur wenig Kontext darum herum zu sehen ist.

Da die Navigation in Bäumen für QF-Test von zentraler Bedeutung ist, gibt es eine alternative Implementierung einiger dieser Methoden, die eine natürlichere Bedienung ermöglichen und sicherstellen, dass immer genug Kontextinformation um den selektierten Knoten herum zu sehen ist. Da derartige Dinge Geschmackssache sind, können Sie durch Deaktivieren dieser Option wieder zurück auf das Standardverhalten von Swing schalten.

Mindestgröße für Fonts (pt) (User)

Diese Option erlaubt Ihnen das Setzen der minimalen Font-Größe (gemessen in Punkten), die in QF-Test verwendet wird. Eine geänderte Einstellung wird erst nach dem Neustart von QF-Test wirksam.

Zeilennummern in Skriptknoten anzeigen (User)

Mit Hilfe dieser Option lässt sich die Anzeige von Zeilennummern in Knoten vom Typ 'SUT Skript' und 'Server Skript' steuern.

3.1+Nach Refactoringschritten betroffene Knoten anzeigen (User)

Diese Option spezifiziert, ob eine Liste angepasster Referenzen nach einer Refactoringaktion angezeigt werden soll. Die Liste wird angezeigt nach Umbenennung einer 'Prozedur', einer 'Abhängigkeit', eines 'Package', eines 'Testfall', eines 'Testfallsatz' sowie einer Komponente. Der Dialog wird ebenso nach Verschieben der oben genannten Knoten und auch bei ID Anpassungen nach Aktualisieren von Komponenten angezeigt.

3.4+Vor dem Löschen auf Referenzen prüfen (User)

Wenn diese Option gesetzt ist, dann wird beim Löschen eines Knoten geprüft, ob es Referenzen auf diesen Knoten gibt. Falls es Referenzen gibt, wird eine Liste der Referenzen geöffnet.

Projekte sind ein neues Feature, an dem aktuell entwickelt wird und das noch nicht aktiv geschalten ist. Die zugehörigen Optionen haben noch keinen Effekt.

Hier können Sie Ihre Lesezeichen bearbeiten, eine Liste von Dateien und Knoten, auf die schnell über das Menü »Datei«-»Lesezeichen« zugegriffen werden kann.

		Abbildung 29.4:  Lesezeichen

Sie können neue Lesezeichen zwar auch manuell erstellen, einfacher geht es aber über den Menüeintrag »Datei«-»Zu Lesezeichen hinzuzufügen«, um ein Lesezeichen für eine Testsuite oder ein Protokoll zu erstellen, oder durch Auswahl des Eintrags »Zu Lesezeichen hinzuzufügen« im Kontextmenü eines Knotens in einer Testsuite, um ein Lesezeichen für diesen speziellen Knoten zu erstellen.

Die folgenden Optionen legen fest, welche externe Programme QF-Test für verschiedene Zwecke aufruft.

		Abbildung 29.5:  Optionen für Externe Programme

Kommando für externen Editor (User)

Skripte können durch Drücken von [Alt-Eingabe] oder Klicken des Buttons oberhalb des Textfeldes in einem externen Editor bearbeitet werden. Dazu wird der Inhalt des Textfeldes in einer temporären Datei gespeichert und der externe Editor wird aufgerufen, um diese Datei zu bearbeiten. Es wird empfohlen, dem Skript vorher einen Namen zu geben (siehe Warnen wenn der externe Editor ohne Dateinamen gestartet wird), andernfalls wird eine zufällig gewählte Zahl als Dateiname verwendet, was die Arbeit mit mehreren gleichzeitig in einem externen Editor geöffneten Skripten erschwert.

Änderungen am Skriptcode über den externen Editor werden automatisch von QF-Test übernommen. Je nach gewählten Einstellungen wird eine Warnung angezeigt, sobald das passiert (Warnen wenn die Testsuite durch einen externen Editor verändert wird). Sollte der Skriptcode parallel zum externen Editor auch in QF-Test bearbeitet werden: Diese Änderungen werden ebenfalls in der temporären Datei gespeichert. Texteditoren wie jEdit sind ihrerseits in der Lage, diese zu bemerken und laden die Datei automatisch neu.

Diese Option legt das Kommando zum Aufruf des externen Editors fest. Es gibt hierzu zwei Varianten: Die einfache Angabe einer ausführbaren Datei oder einen komplexen Befehl einschließlich Optionen. Letztere zeichnet sich dadurch aus, dass der Name der externen Datei durch den Platzhalter $(file) angegeben werden muss. Zusätzlich kann dabei über $(line) auch die aktuelle Zeile angegeben werden.

Hinweis Die Syntax $(file)/$(line) wird ausschließlich verwendet, um nicht wieder eine neue Konvention für variable Attribute einzuführen. Es findet keine standard QF-Test Variablenexpansion für $(...) Ausdrücke statt.

Einfache Kommandos müssen nicht durch Anführungsstriche geschützt werden, z.B.:

• emacsclient
• notepad
• C:\Program Files\Crimson Editor\cedt.exe

Komplexe Kommandos benötigen eventuell Anführungsstriche, insbesondere unter Windows. Um die Anführungsstriche für das $(file) Argument kümmert sich QF-Test selbst:

• javaw.exe -jar C:\Programme\jEdit4.2\jedit.jar -reuseview $(file)
• "C:\Program Files\Crimson Editor\cedt.exe" $(file)
• xterm -e vi +$(line) $(file)

Ist diese Option leer, wird der Wert der Umgebungsvariablen EDITOR verwendet, sofern diese beim Start von QF-Test definiert ist.

Warnen wenn die Testsuite durch einen externen Editor verändert wird (User)

Bei Änderung eines Skripts durch einen externen Editor wird eine Warnung angezeigt (siehe Kommando für externen Editor).

Warnen wenn der externe Editor ohne Dateinamen gestartet wird (User)

Es wird gewarnt, wenn ein namenloses Skript im externen Editor geöffnet werden soll (siehe Kommando für externen Editor).

Kommando für externes Grafikprogramm (User)

Das 'Abbild' eines 'Check Abbild' Knotens kann in einem externen Grafikprogramm bearbeitet werden. Dazu wird die Grafik im PNG Format in einer temporären Datei gespeichert und das externe Grafikprogramm wird aufgerufen, um diese Datei zu bearbeiten. Nach dem Speichern der Datei und Beenden des Programms, lädt QF-Test die Daten aus der Datei zurück in das Abbild.

Diese Option legt das Kommando zum Aufruf des externen Grafikprogramms fest. Es gibt hierzu zwei Varianten: Die einfache Angabe einer ausführbaren Datei oder einen komplexen Befehl einschließlich Optionen. Letztere zeichnet sich dadurch aus, dass der Name der externen Datei durch den Platzhalter $(file) angegeben werden muss.

Hinweis Die Syntax $(file)/$(file) wird ausschließlich verwendet, um nicht wieder eine neue Konvention für variable Attribute einzuführen. Es findet keine standard QF-Test Variablenexpansion für $(...) Ausdrücke statt.

Einfache Kommandos müssen nicht durch Anführungsstriche geschützt werden, z.B.:

• gimp
• mspaint
• C:\Windows\System32\mspaint.exe

Komplexe Kommandos benötigen eventuell Anführungsstriche, insbesondere unter Windows. Um die Anführungsstriche für das $(file) Argument kümmert sich QF-Test selbst:

• gimp --no-splash $(file)
• "C:\Windows\System32\mspaint.exe" $(file)

HTML Browser (nur Unix) (User)

Für Unix Systeme legt diese Option den HTML Browser fest, der für die kontextsensitive Hilfe verwendet wird. Sie können ein komplexes Kommando angeben, mit '$url' als Platzhalter für die anzuzeigende URL, z.B.
netscape -remote openURL($url)
oder ein einfaches Kommando wie
firefox
dem dann die URL als letztes Argument übergeben wird. Unter Windows wird in jedem Fall der System-Browser verwendet.

Anzeigeprogramm für PDF (nur Unix) (User)

Für Unix Systeme legt diese Option das Programm zur Anzeige von PDF Dateien fest. Damit kann das Handbuch im PDF Format direkt aus dem »Hilfe« Menü heraus angezeigt werden. Unter Windows wird automatisch das Programm verwendet, das mit der Dateiendung .pdf verknüpft ist.

Beim Speichern einer Testsuite oder eines Protokolls ist es möglich, automatisch Sicherungskopien von bereits vorhandenen Dateien zu erstellen. Mit Hilfe der folgenden Optionen legen Sie fest, unter welchen Bedingungen Sicherungskopien angelegt werden und wie deren Name gebildet wird.

		Abbildung 29.6:  Optionen für Sicherungskopien

Sicherungskopien für Testsuiten erstellen (User)

Nur wenn diese Option aktiviert ist, werden Sicherungskopien von Testsuiten erstellt. Bedenken Sie bitte, wieviel Arbeit in einer guten Testsuite steckt und wie leicht die Daten zerstört werden könnten, wenn Sie keine Kopie haben. Deaktivieren Sie diese Option daher nur, wenn Sie anderweitig für eine Sicherung gesorgt haben, z.B. durch den Einsatz eines Versionskontrollsystems.

Sicherungskopien für Protokolle erstellen (User)

Ein Protokoll ist im Allgemeinen weit weniger "wertvoll" als eine Testsuite, daher können Sie hiermit separat festlegen, ob Sie auch beim Speichern von Protokollen Sicherungskopien erstellen wollen.

Wie oft Sicherungskopien erzeugen (User)

Es gibt zwei Varianten für die Häufigkeit, mit der Sicherungen ihrer Dateien angelegt werden:

Eine Sicherungskopie pro Sitzung bedeutet, dass nur beim ersten Speichern einer Testsuite, der Stand der letzten Sitzung gesichert wird. Bei jedem weiteren Speichern wird die neue Version überschrieben, die Kopie des alten Standes bleibt erhalten. Erst wenn Sie eine neue Testsuite laden, wird beim nächsten Speichern wieder kopiert. Diese Einstellung ist sinnvoll, wenn Sie nur eine Sicherungskopie pro Testsuite vorhalten.

Wenn Sie dagegen mehrere Sicherungen für eine Testsuite erstellen, empfiehlt es sich, bei jedem Speichern eine Kopie anzulegen.

Name der Sicherungskopie (User)

Wie vieles andere unterscheiden sich auch die Konventionen für die Namensgebung von Sicherungskopien in Unix und Windows Umgebungen. Unter Windows wird vorrangig die Endung .bak an den Dateinamen angehängt, während es unter Unix verschiedene Varianten gibt. Sehr häufig ist jedoch das Anhängen einer Tilde '~' anzutreffen.

Anzahl der Sicherungskopien (User)

Mit dieser Option legen Sie fest, wie viele Sicherungskopien Sie für jede Datei vorhalten wollen. Wenn Sie nur eine Datei wählen, wird deren Name wahlweise durch Anhängen von .bak oder einer Tilde '~' gebildet. Jedes mal, wenn eine weitere Sicherungskopie erstellt wird, wird die alte Sicherungskopie überschrieben.

Wenn Sie dagegen mehrere Sicherungskopien wählen, erhält der Name zusätzlich eine Nummer nach folgendem Schema: bak1, bak2... für die Windows Konvention und ~1~, ~2~... andernfalls. Die aktuellste Sicherungskopie hat immer die Nummer 1. Beim Erstellen der nächsten Kopie, wird diese zur 2 und die neue Kopie erhält die 1. Ist die Maximalzahl erreicht, werden jeweils die ältesten Sicherungskopien gelöscht.

Zeitabstand für automatische Speicherung (s) (User)

Legt den Zeitabstand fest, nach dem eine modifizierte Testsuite automatisch gesichert wird. Ein Wert von 0 schaltet die automatische Sicherung aus, andere Werte unter ca. 20 Sekunden sind nicht sinnvoll. Protokolle werden grundsätzlich nicht automatisch gesichert. Auto-save Dateien werden im selben Verzeichnis wie die Testsuite abgelegt, oder - im Fall von neuen Suites, die noch nie gespeichert wurden - im Verzeichnis .qftest unterhalb des Heimatverzeichnisses des Anwenders.

		Abbildung 29.7:  Bibliothekspfad Option

Verzeichnisse mit Testsuite Bibliotheken (System)

Hierbei handelt es sich um eine Liste von Verzeichnissen, die durchsucht werden, wenn eine Referenz auf eine Testsuite als relative Datei angegeben wird und nicht relativ zur aktuellen Suite aufgelöst werden kann. Das gilt für das 'Name der Prozedur' Attribut eines 'Prozeduraufruf' Knotens oder die Referenz der 'Id' einer 'Komponente' ebenso, wie für Testsuites, die über das Attribut 'Include Dateien' des 'Testsuite' Knotens eingebunden werden.

Das zur aktuellen Version von QF-Test gehörende include Verzeichnis wird immer automatisch (und unsichtbar) an das Ende des Bibliothekspfads gestellt. Dadurch ist sichergestellt, dass die Bibliothek qfs.qft eingebunden werden kann, ohne ihren exakten Ort zu kennen, und dass ihre Version der von QF-Test entspricht.

Hinweis Ist das Kommandozeilenargument -libpath <Pfad> angeben, hat es Vorrang vor dieser Option. Im interaktiven Modus wird der Wert des Kommandozeilenarguments hier angezeigt. Er wird aber nicht in der Systemkonfiguration gespeichert, es sei denn, der Wert wird manuell verändert.

		Abbildung 29.8:  Lizenz Optionen

Normalerweise beinhalten QF-Test Lizenzen eine homogene Mischung von GUI Engines. Ein Bündel von QF-Test/swing Lizenzen unterstützt z.B. nur die AWT/Swing Engine, QF-Test/suite Lizenzen beinhalten sowohl AWT/Swing als auch SWT für alle Instanzen. Für derartige Lizenzen spielen diese Lizenz-Einstellungen keine Rolle.

Ein kleines Problem entsteht im Fall von gemischten Engine-Lizenzen, bei denen eine GUI Engine nur von einem Teil der Lizenzen unterstützt wird. Ein Beispiel für eine solche Lizenz ist ein Lizenzbündel, das früher für qftestJUI angeschafft wurde, mit QF-Test 2.0 auf QF-Test/suite aktualisiert und später um weitere QF-Test/swing Lizenzen ergänzt wurde, sagen wir zwei Lizenzen für QF-Test/suite und zwei für QF-Test/swing. Eine solche Lizenz erlaubt den Start von vier QF-Test Instanzen, von denen aber nur zwei SWT unterstützen. Der Versuch mehr als zwei Instanzen mit Nutzung der SWT Engine zu starten führt zu einem Lizenzkonflikt.

Wenn QF-Test eine solche gemischte Lizenz zum ersten mal erkennt, fragt es Sie, welche GUI Engines Sie benötigen. Die dort getroffene Entscheidung kann hier jederzeit korrigiert werden. Außerdem können Sie QF-Test mit dem Kommandozeilenargument -engine <Engine> starten um für diese Ausführung die GUI Engines explizit festzulegen.

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