QF-Test is available in three installation options: The qftest-3.4.7.tar.gz archive for Unix only, the executable setup file qftest-3.4.7.exe for Windows only and the qftest-3.4.7.zip archive for both Unix and Windows.

Basically it is possible to have different versions of QF-Test installed in parallel. Existing configuration files will not be overwritten in this process.

Note Both QF-Test and the SUT require Java version 1.5 or higher.

In section 24.2 you can find best practices about the QF-Test installation.

First select a convenient directory that will contain this release of QF-Test as well as future updates. Common choices are /opt or /usr/local. Make sure you have write access to this directory and change to it. When upgrading to a new QF-Test version, use the same directory again.

Unpack either the .zip archive with unzip qftest-3.4.7.zip or the .tar.gz archive with tar xfzv qftest-3.4.7.tar.gz. This will create a directory named qftest, which we will refer to as the main or root directory of QF-Test. When the qftest product family grows, this directory will become the home for other products as well.

After unpacking a QF-Test archive for the first time, QF-Test's root directory will hold only the version-specific subdirectory qftest-3.4.7. When upgrading, a new subdirectory for the current version will be added.

To finish the installation, change to the specific directory for the current QF-Test version with cd qftest/qftest-3.4.7 and run one of the two setup scripts provided. setup.sh is a plain Bourne shell script while setup.ksh is written for the Korn shell. On Solaris you must run ./setup.ksh. On other Unix systems both scripts should work equally well but the Bourne shell version ./setup.sh is preferred. Note that if you need to use the Korn shell scripts and want to create you own link or start QF-Test directly from its bin directory, you need to use the qftest.ksh start script instead of the plain qftest script.

These setup scripts will create the directories log and jython under QF-Test's root directory if they don't already exist. Additionally they will offer to create a symbolic link from the /usr/local/bin directory (or /usr/bin if there is no /usr/local/bin) to the respective Bourne shell or Korn shell run script for the qftest command. You need to have write permission to the /usr/local/bin directory for the link to be created.

Subsequently the default java program for QF-Test is determined. This can be overridden later with the -java <executable> argument. The setup script searches PATH and proposes to use the first java program it detects. If you want to use a different program or if none was found, you can enter one. The script determines the JDK version automatically.

Next setting to perform is the maximum amount of memory to be used by QF-Test. As default 256MB are taken. Alternatively QF-Test can be started with the -J-XmxZZZm command line argument, where ZZZ defines the memory in MB.

Finally the language for QF-Test can be configured. By default the language depends on the system settings, but you can also choose to always use the English or the German version. Note that this setting will affect all QF-Test users. Alternatively you can run QF-Test with the -J-Duser.language=XX option using en for English or de for German.

Those of the above settings that differ from the default are written to the file launcher.cfg in QF-Test's root directory. This file is read by the qftest launch-script and also evaluated during an update of QF-Test.

On Windows you can install QF-Test using either the Windows specific qftest-3.4.7.exe or the archive qftest-3.4.7.zip.

Installing QF-Test from qftest-3.4.7.exe follows the standard setup procedures for Windows. You will be asked to accept the license agreement and select the root directory for QF-Test. When upgrading to a new version, make sure you select the same directory again (this will be the default).

To install QF-Test from the qftest-3.4.7.zip archive, first extract the archive in a convenient place. The default location is C:\Program Files\qfs. This will create a directory called qftest which we will refer to as the root directory of QF-Test. When the qftest product family grows, this directory will become the home for other products as well. After extracting the archive, run the executable file called setup.exe in the version-specific directory qftest-3.4.7 under QF-Test's root directory. This will take you through the same setup steps as qftest-3.4.7.exe, except that no files will be extracted. If you later want to uninstall QF-Test you'll have to remove its files by hand after running the uninstaller.

Note Make sure that you select QF-Test's root directory as the target directory for the setup.

In both cases, setup will create a menu shortcut and an optional desktop icon for QF-Test and create a few registry entries to associate *.qft, *.qrz and *.qrl files with QF-Test. It will also copy the qftest.exe executable to the Windows system directory and store the location of QF-Test's root directory and some version information in the registry, so qftest.exe can be run from the console or batch scripts without further ado. Information about the QF-Test version will also be fetched from the Windows registry.

When finished, the setup program will offer to configure the Java program for QF-Test. This can be done with the help of a small dialog in which you can select the Java program for QF-Test.

Furthermore, the dialog let you adjust the maximum amount of memory to be used by QF-Test. 256MB are taken by default.

The third value to be configured is the language for QF-Test. Normally the language is determined by the system settings, but you can also choose to always use the English or the German version.

The values above are stored in the Windows registry from where they are read by the qftest start program. You can run the configuration program any time from the system menu to change these settings. To remove them, clear the respective field or set is to system standard respectively and select "OK".

QF-Test requires a license file to run, which you should have received from Quality First Software GmbH. Place this file in QF-Test's root directory. Make sure it is named license with no extension. Some mail clients try to guess the file type and add an extension on their own. When upgrading to a new version you can simply keep the license file provided that it is valid for the new version.

If you need to upgrade your license, for example to increase the number of concurrent QF-Test instances or when upgrading to a new version, you will receive a file called license.new from Quality First Software GmbH which is typically not a valid license in itself but must be combined with your current license. To do so, proceed as follows:

• Place the file license.new in the same directory as the current license. Make sure that this directory and the file license are writable by you.
• Start QF-Test in interactive mode. QF-Test will detect the license update, verify its validity and offer to upgrade your license file.
• If you agree, the current license will be renamed to license.old and the new, combined license will be written to license. When you are satisfied that everything is OK, you can remove the files license.old and license.new.
• If QF-Test doesn't seem to recognize the license upgrade, make sure that the timestamp of the file license.new is newer than that of the file license. Also make sure that no other instance of QF-Test is running on your computer.

In case you need to specify a special name or location for the license file or work with more than one license, this can be achieved with help of the -license <file> argument as described in chapter 32.

QF-Test saves all of its window configuration and those global options that represent personal preferences together in one file which is usually called config and placed in the directory .qftest under your home directory (typically called Personal Files or %WINDIR%\profiles\<username> under Windows). This file is not read when QF-Test is run in batch mode (see section 1.5).

System specific options that need to be shared between users are saved in a file called qftest.cfg in the root directory of QF-Test. The locations of the configuration files can be changed with the command line arguments -usercfg <file> and -systemcfg <file> and you will have to make use of the latter if you don't have write permission for QF-Test's root directory.

QF-Test can be run in two modes. In normal mode QF-Test is the editor for test-suites and run-logs and the control center for running programs, capturing events and executing tests. When run with the -batch argument, QF-Test goes into "batch" mode. Instead of opening an editor window, the test-suites given on the command line are loaded and executed automatically without the need for supervision. The result of the test is reflected in QF-Test's exit code, optional run-logs (see section 9.1) and reports (see chapter 15).

The setup script for Unix offers to create a symbolic link from /usr/local/bin to the qftest start script in the qftest-3.4.7/bin directory under QF-Test's root directory. That way you can simply enter qftest at the shell prompt to launch the application.

On Windows a menu shortcut is created as well as an optional desktop icon. You can either launch QF-Test from one of these or by double-clicking a test-suite or a run-log, since these files are associated with the QF-Test application. To run QF-Test from the console type qftest.

When run from the command line, QF-Test offers a wide range of arguments for customization, like selecting the Java VM to use. These are explained in detail in chapter 32.

In case different versions of QF-Test are installed at the same time, a specific version can be started by calling the qftest executable directly from the respective qftest-X.Y.Z/bin directory.

On startup of QF-Test and/or the System Under Test (SUT) via QF-Test you might get a security warning from the Windows firewall asking whether to block Java or not. As QF-Test communicates with the SUT by means of network protocols, this must not be blocked by the local firewall in order to allow automated testing.

Last update: 04/23/2012 Copyright © 1999-2012 Quality First Software GmbH