There are a lot of command line arguments when running QF-Test in batch mode; an overview can be found in chapter 40. Here we will present examples showing the most important of them.
The examples are written for the Windows operating system, but you may easily adapt them
for the Linux platform. What is different is the path specification and also the syntax
for placeholders (subsection 40.2.4): On Linux you can use +X as well as
%X. On Windows there's a separate console application
contrast to its GUI variant
qftest.exe, it waits until the execution of
QF-Test has terminated and also displays print output from a 'Server script'. You
qftestc.exe in place of
qftest.exe wherever you'll find
Let's start with the most simple QF-Test command to execute a test:
|Example 22.1: Test execution from the command line|
-batch makes QF-Test start without a graphical user interface.
The second argument,
-run, is the specifier for test execution. Finally, at
the end of the command line, you find the test-suite to be executed.
Note The argument
-run is optional, i. e. the test
execution is defined as default for the batch mode.
When running the above command, all top-level 'Test-case' and
'Test-set' nodes of
suiteA.qft will be executed one after another.
After the test-run you will find a run-log file in the current directory; it has the
same name as the test-suite (except from the extension, which can be
.qzp). The run-log file shows the
result of the test-run.
-nolog you can suppress the creation of a run-log. Probably
this only makes sense, if you have extended your test by your own log output (written
to a file). Otherwise you'd have to check the result code of QF-Test, whereas 0 means
that everything is alright. A positive value in contrast indicates that warnings,
errors or exceptions occurred during the test-run (see section 40.3). That's why in most situations you'll probably prefer to create
a run-log and save it at a fixed place in the file system. This can be achieved with
|Example 22.2: Test execution with run-log creation|
A run-log file
suiteA.qrz will now be created in the specified directory
c:\mylogs. The placeholder
+b is responsible for its name
being identical with that of the test-suite. The additional switch
prevents the run-log from growing too large: Only the nodes needed for a report and
those immediately before an error or an exception are kept in the run-log. Especially in
case of very long test-runs this may help to reduce the amount of required memory.
The newer method of using split run-logs is even more powerful. For more
information about that see section 7.1.
Note Whether the file is indeed created as compressed run-log (to be
distinguished from the above "compact") with extension
depends on the system settings. To force the creation of a particular format you can
set the file extension explicitly. With
-runlog c:\mylogs\+b.qrl, for
example, an uncompressed XML file will be produced.
Sometimes you may want to execute not the whole test-suite but only parts of it. By
using the parameter
-test you can run a specific node of the test-suite:
|Example 22.3: Executing a specified node|
-test expects the 'QF-Test ID' attribute of the node to follow or
the qualified name of a 'Test-case' or 'Test-set'. If you want to execute several nodes,
you can define
-test <ID> multiple times. Apart from the node's 'QF-Test ID',
-test accepts also the numerical index of a top-level node. For example,
-test 0 will run the first child of the 'Test-suite' node.
The run-log provides a rather technical view of the test-run; it is helpful mainly when analyzing errors (cf. section 7.1). The report in contrast contains a summary of the executed test-cases and errors (cf. chapter 21) in XML or HTML format. It is created from the run-log either in a separate step after running the test or automatically with the test-run:
|Example 22.4: Creating a report|
In this example the XML and HTML files are saved in a directory which name consists of
the test-suite and a timestamp like
replacing the argument
-report.html respectively, only an XML or HTML report will be created.
Test-cases often uses variables to control the execution of the test. For example, you
may have defined the variable
myvar in the 'Test-suite' node of the
suite. You can overwrite its default value when running the test-suite from the
|Example 22.5: Test execution with variables|
If needed, you can specify
-variable <name>=<wert> multiple
times to set values for different variables.
Running tests from the command line is fundamental for integrating QF-Test in
test management systems (see Interaction with Test Management Tools). Otherwise, living
without such a tool, you may find it convenient to embed the command for the
test execution into a script. A simple Windows batch script (
looks like this:
|Example 22.6: Batch script |
Now you can simply run that script with only the file name of the test-suite as parameter.
Everything else is done automatically: The test-suite will be executed, the run-log
file stored in
logdir and finally the script will print out the state of the
test-run (depending on the QF-Test result code).
Since version QF-Test 3 the language Groovy is part of the release (cf. chapter 11). It is meant mainly for scripting inside QF-Test (Server and SUT
scripts), but it can, like Jython, also be used outside of QF-Test. Groovy is probably
well suited to create a little test execution management system by yourself. By the
way, Groovy simplifies working with Ant, too: Instead of dealing with bulky XML files,
which makes it hard to define conditions, you can work with the Groovy
AntBuilder. However, that's out of scope here, the following example
doesn't rely on Ant but only on the basic Groovy features:
|Example 22.7: Groovy script |
If you have Groovy installed on your computer independently of QF-Test, you can run the
example test-suite simply via
groovy QfExec c:\mysuites\suiteA.qft.
Otherwise you can use the Groovy jar file from the QF-Test installation, preferably again
with help of a batch script:
|Example 22.8: Batch script |
Now execute the test-suite with
|Last update: 5/17/2022|
Copyright © 1999-2022 Quality First Software GmbH