BX

Functional Testing User Manual

BREDEX GmbH

April 15, 2014

April 15, 2014 1

 Functional Testing User Manual

BREDEX GmbH
Mauernstr. 33
38100 Braunschweig
Germany
Tel: +49-531 - 243 30 - 0
Fax: +49-531 - 243 30 - 99
www.bredex.de

GUIdancer is a registered trademark of BREDEX GmbH

Title: Functional Testing User Manual

Author:
File: UserManual
State: RELEASE
Version: V8.0.00170
Released by: BREDEX GmbH
Released at: April 15, 2014

2 April 15, 2014 UserManual V8.0.00170

Contents

Contents

1 Introduction 7
1.1 Comparison to other testing approaches . . . 7
1.2 How to read this manual . . . . . . . . . . . . 11

2 Samples: example tests 13

2.1 Accessing the prepared Project . . . . . . . . . 13
2.2 The structure of the example Project . . . . . . 14
2.3 Adder Tests . . . . . . . . . . . . . . . . . . . 15
2.4 DVD Tool Tests . . . . . . . . . . . . . . . . . . 18

3 Tasks 21
3.1 Starting and connecting to the AUT Agent . . 21
3.2 Starting the Integrated Test Environment (ITE) . 25
3.3 Logging into and switching databases . . . . . 27
3.4 Migrating to newer versions . . . . . . . . . . 28
3.5 Working with Projects . . . . . . . . . . . . . . 29
3.6 Defining applications under test (AUT’s) . . . . 47
3.7 Starting and configuring AUT’s . . . . . . . . . 50
3.8 Working with browsers: renaming, deleting,
using IDs, multiple browsers . . . . . . . . . . 65
3.9 Working with editors: opening, adding/delet-
ing/renaming items, commenting, extracting and
replacing, reverting changes . . . . . . . . . . 68
3.10 Working with categories in the browsers and
editors . . . . . . . . . . . . . . . . . . . . . . 77
3.11 Working with Test Cases . . . . . . . . . . . . 80
3.12 Working with test data . . . . . . . . . . . . . 91
3.13 Working with component names . . . . . . . . 116
3.14 Working with Test Suites . . . . . . . . . . . . 125
3.15 Working with Test Jobs to test multiple AUT’s . 128
3.16 Information on Test Steps . . . . . . . . . . . . 132
3.17 Working with manual Test Cases . . . . . . . . 135
3.18 Object mapping . . . . . . . . . . . . . . . . . 137
3.19 Test execution . . . . . . . . . . . . . . . . . . 154
3.20 Working with test results . . . . . . . . . . . . 159

UserManual V8.0.00170 April 15, 2014 3

 Functional Testing User Manual

3.21 Dealing with errors in tests: Event Handlers . . 164

3.22 Preferences . . . . . . . . . . . . . . . . . . . 167
3.23 Observing Test Cases . . . . . . . . . . . . . . 177
3.24 Working with the Problem View . . . . . . . . 183
3.25 Working with the Teststyle guidelines . . . . . 184
3.26 Working with Metrics . . . . . . . . . . . . . . 193
3.27 Working with external task repositories (ALM
Integration) . . . . . . . . . . . . . . . . . . . 196
3.28 Adapting the user interface . . . . . . . . . . . 206
3.29 Searching . . . . . . . . . . . . . . . . . . . . 208
3.30 Using the test executor for testing from the
command line . . . . . . . . . . . . . . . . . . 216
3.31 Using the dbtool client to import, delete and
export from the command line . . . . . . . . . 223
3.32 Working with the dashboard . . . . . . . . . . 227
3.33 Using Chronon . . . . . . . . . . . . . . . . . 232
3.34 Launch Configurations . . . . . . . . . . . . . 234
3.35 Troubleshooting . . . . . . . . . . . . . . . . . 238
3.36 Finishing up . . . . . . . . . . . . . . . . . . . 245
3.37 Producing long-term reports of test runs with
BIRT . . . . . . . . . . . . . . . . . . . . . . . 247
3.38 Working with code coverage with Java tests . . 252

4 Toolkit-specific information 259

4.1 Testing Swing AUT’s . . . . . . . . . . . . . . . 259
4.2 Testing RCP AUT’s . . . . . . . . . . . . . . . . 260
4.3 Testing GEF AUT’s . . . . . . . . . . . . . . . . 265
4.4 Testing JavaFX AUT’s . . . . . . . . . . . . . . 266
4.5 Testing HTML AUT’s . . . . . . . . . . . . . . . 268
4.6 Testing Windows (.NET) AUT’s . . . . . . . . . 271
4.7 Testing iOS AUT’s . . . . . . . . . . . . . . . . 275

5 User interface 291

5.1 Perspectives . . . . . . . . . . . . . . . . . . . 292
5.2 Browsers . . . . . . . . . . . . . . . . . . . . . 299
5.3 Editors . . . . . . . . . . . . . . . . . . . . . . 300
5.4 Views . . . . . . . . . . . . . . . . . . . . . . 302
5.5 The status bar . . . . . . . . . . . . . . . . . . 308

6 Concepts 309
6.1 Overview . . . . . . . . . . . . . . . . . . . . . 309
6.2 Testing . . . . . . . . . . . . . . . . . . . . . . 309
6.3 Architecture . . . . . . . . . . . . . . . . . . . 311
6.4 Database structure . . . . . . . . . . . . . . . 312
6.5 Approaches to testing . . . . . . . . . . . . . . 313
6.6 Test hierarchy . . . . . . . . . . . . . . . . . . 315

4 April 15, 2014 UserManual V8.0.00170

Contents

6.7 Reusability . . . . . . . . . . . . . . . . . . . . 318

6.8 Multi-lingual testing . . . . . . . . . . . . . . . 319
6.9 Object mapping . . . . . . . . . . . . . . . . . 319
6.10 Test execution . . . . . . . . . . . . . . . . . . 321
6.11 Observing user actions . . . . . . . . . . . . . 322
6.12 Event Handlers . . . . . . . . . . . . . . . . . 322
6.13 Extensibility . . . . . . . . . . . . . . . . . . . 324
6.14 Summary . . . . . . . . . . . . . . . . . . . . 324

7 Glossary 325

8 Index 331

UserManual V8.0.00170 April 15, 2014 5

 Functional Testing User Manual

6 April 15, 2014 UserManual V8.0.00170

Introduction

Chapter 1

Introduction

GUIdancer/Jubula are tools for the automated testing of Graph-

ical User Interfaces. The focus of the tool is on testing an ap-
plication’s business logic (workflows, use cases) from the user
perspective (functional, black-box, acceptance testing).
The approach used is the keyword-driven method. Tests are
automated by dragging and dropping pre-defined modules
(or Test Cases, or keywords) to make sequences of actions for
your application. Each Project contains one or more libraries
of these pre-defined modules for you to use. Test automation
with these keywords is hierarchical – using the libraries, you
can create modules of your own and reuse them to make
more complex tests and so on.
Using the keyword-driven approach has various advantages,
which are detailed in the next section ( → page 9) .

1.1 Comparison to other testing ap-

proaches
Testing is critical to the success of software projects. It is espe-
cially important to acceptance test software which is designed
for end users.
There are various ways to go about performing acceptance
testing, each with their advantages and disadvantages.

1.1.1 Manual Tests

Manual testing, although thorough, cannot keep up with the
pace of development. It is impossible to carry out complete
continuous integration and regression tests manually.

UserManual V8.0.00170 April 15, 2014 7

 Functional Testing User Manual

1.1.2 Programmed Tests

Writing tests in some kind of scripting language is certainly
powerful, but it puts a strain on the resources of a team, be-
cause the test code itself becomes a project in its own right
and also needs to be checked and maintained. The extra costs
added by programming GUI tests can be considerable.
Tests written in code also have the problem that they no longer
view the software as a black box and may miss important
aspects relating to the acceptance. In addition, automation
experts (experienced software developers) become the only
people who can write or maintain tests. It is generally inad-
visable to test your own work, but this is what can happen if
testing remains solely in the realm of the developers. Writing
tests without coding from the black box perspective not only
allows test experts to automate tests (and therefore brings the
test perspective to the forefront), but also puts developers in
the shoes of the users, which helps to focus and improve the
test.

1.1.3 Recorded Tests

Possibly the most popular approach to automated functional
testing is macro recording, that is, recording a user’s actions
for later playback. The appeal of this approach is the ap-
parently quick success that can be seen: a test script can be
quickly recorded and played back, giving the impression that
automated testing is nothing more than recording a manual
test.
However, this approach fails to meet the needs of large or
long-term software projects for the following reasons:

• Test specification begins very late in the development cycle,

as recording can only begin once the software is available.

• Since only the user action is recorded, checkpoints for ver-

ification of test results have to be inserted manually.

• Recorded tests can only test parts of the application which

already work.

• There is also the danger that the implementation of the

application will be tested, instead of the requirements.

• Recorded scripts are often very large and not particularly

well-structured. Making changes at a later point is there-

8 April 15, 2014 UserManual V8.0.00170

Introduction

fore difficult and requires programming skills, which fur-

ther increases costs.

• Code generated by recording generally doesn’t conform

to common software quality attributes such as reliability,
stability, portability, maintainability, and usability.

In essence, a recorded script is not an automated test. It must

be refactored to remove errors and redundancies, to make its
component parts modular and reusable and to insert the in-
telligence of the manual tester to make the test robust. Once
all this has been done, there is probably very little of the orig-
inal recording left, and a great deal of development work has
been done to refactor the script.

1.1.4 Our approach

Our approach lets you automate tests which follow the best
practices known from software development (readability, mod-
ularity and reusability to ensure maintainability), but without
any programming effort.
This gives the following advantages:

1.1.5 Early test creation

Tests are created before the AUT is available. This is a rad-
ical advantage over capture-replay tools, which force testers
to wait until an application is ready to begin with testing. The
specification of modular, flexible GUI tests begins early (even
as early as at the requirements stage) and continues alongside
software development.
The benefit of this is that every version of an AUT can be
tested as soon as it becomes available. Testing keeps up with
development, so you waste no time in your test process. Ear-
lier testing lets you find issues when they are cheaper and
easier to fix and encourages collaboration and communica-
tion within the team.

1.1.6 Code-free automation

Tests are automated completely from the user perspective and
require no programming effort.

UserManual V8.0.00170 April 15, 2014 9

 Functional Testing User Manual

This means that those who understand the user perspective

best are able to fully automate tests. There is no need to wait
for input (e.g. programmatic creation of test modules) from
other team members to automate a test. If developers are
writing tests, the black box perspective encourages them to
think like a user would when faced with the software. Code-
free tests also have the advantage that they are readable by
the whole team and also by users or customers.

1.1.7 Manual tester intelligence

The wide range of keywords available include high-level ac-
tions which can be meaningfully used by testers. There is also
a wide range of check and synchronization actions to incor-
porate the necessary robustness into a test.

10 April 15, 2014 UserManual V8.0.00170

Introduction

1.2 How to read this manual

We have designed this tool to make testing easier and faster.
However, it is a powerful application, and some of its features
are quite sophisticated. We therefore recommend having a
look at this manual. You can also access the manual from
within the ITE by pressing »F1«.
In the reference manual, you will find information on more
technical aspects, such as a description of the supported com-
ponents and actions. The reference manual is also shown in
the context-sensitive help when you press »F1«.

1.2.1 Layout
This manual is divided into the following chapters:

1. The Chapter ”Introduction” ( → page 7) provides a back-

ground and introduction.
2. The Chapter ”Samples: example tests” ( → page 13) ex-
emplifies the capabilities of the tool, using Project exam-
ples. We recommend this chapter if you learn best by ex-
ample.
3. The Chapter ”Tasks” ( → page 21) provides step-by-step
instructions for performing most of the common tasks for
writing and executing tests. This chapter is best suited for
those who learn by doing.
4. The Toolkit-specific information chapter ( → page 259)
gives advice and hints on working with AUT’s written in
the different supported toolkits.
5. The Chapter ”User interface” ( → page 291) presents the
user interface, describing its flexible design. This chapter is
useful if you are not yet familiar with the GUI concept of
the Eclipse platform.
6. The Chapter ”Concepts” ( → page 309) introduces the
concepts behind of the tool. It will familiarize you with the
structure, components, and functionality of the tool. This
chapter is useful (and recommended) for gaining in-depth
knowledge of how everything works.
7. Finally, the Chapter ”Glossary” ( → page 325) provides
explanations of all technical terms and abbreviations used
throughout this manual.

UserManual V8.0.00170 April 15, 2014 11

 Functional Testing User Manual

1.2.2 Conventions Used

Throughout the manual, particular conventions are used to
improve readability and clarity:

1.2.2.1 Typesetting Conventions

• Menu paths are shown with a grey background:

Test → Open

• Buttons and menu options are italicized and in inverted

commas:
”OK”

• Input statements are shown in typewriter format:

Hello

• Keyboard shortcuts and commands are in French brackets:

»ENTER«

In addition, important warnings and informative tips are marked

as follows:

This is a warning.

This is a tip.

12 April 15, 2014 UserManual V8.0.00170

Samples: example tests

Chapter 2

Samples: example tests

The aim of this chapter is to present several tests highlighting

some features. The following applications under test (AUT’s)
will be used:

SimpleAdder A simple calculator tool, Adder. This tool is

available as a Swing AUT, a JavaFX AUT, an SWT AUT and
as a HTML AUT.

DVDTool A DVD organization tool, DVD Manager. With this

Swing tool, film categories can be added and browsed, and
DVD’s and various details about each DVD can be entered.

If you want to use these AUT’s to try out your own tests,
you can find them under jubula/examples/AUTs.

2.1 Accessing the prepared Project

You can find the Project containing the tests in the installation
directory under the subdirectory:
examples/projects.
You can import the Project into the ITE as follows:

1. Select:
Test → Import .

2. Browse to the examples/projects directory in the installa-

tion directory.

3. Select both the samples Project and the bound_modules_samples

Project.

UserManual V8.0.00170 April 15, 2014 13

 Functional Testing User Manual

4. Select ”OK” in the Import Project dialog.

Once the Projects have been imported, open the samples Project.
Connect to the embedded AUT Agent ( → page 21) , and
start the AUT ( → page 154) .
When working on one machine, it is a good idea to automati-
cally minimize the ITE during test execution. This can be done
via :
Window → Preferences .
In the Test preferences. Alternatively, the client window can
be reduced so that both the client and the AUT can be seen.

2.1.0.1 Result Reports

A result report of the test will be automatically saved into the

database when the test has run. The summary of the reports
can be viewed in the Test Result Summary View ( → page
160) .

2.2 The structure of the example Project

The Project contains a variety of Test Cases and Test Suites.
The Test Cases are grouped according to which AUT they test,
and are also further grouped into categories corresponding to
individual tests.

2.2.1 The reused Projects

The Project unbound_modules_concrete is reused in this Project.
This Project is a library of actions that are relevant cross-toolkit.
The Project bound_modules_samples is also reused. This con-
tains Test Cases which are reused in the samples tests.

We do not recommend making any changes in these

Projects.

2.2.2 The categories

Executable Test Cases: This category contains Test Cases which
are ready to be executed. Each Test Case corresponds to

14 April 15, 2014 UserManual V8.0.00170

Samples: example tests

one Test Suite, and is named accordingly. The executable

Test Case contains all the Test Cases necessary for a partic-
ular test, and includes all the data.

Tests with the Simple Adder: This category contains the Test
Cases which test the Simple Adder program ( → page 15)
.

Tests with the DVD Tool: This category contains the Test Cases
which test the DVD Tool program ( → page 18) .

2.3 Adder Tests

2.3.1 Sample 1: using the Swing Simple Adder

You can start the Swing SimpleAdder using the configurations
for the SimpleAdder AUT. For Windows and Linux, you can
choose whether you want to use the JRE installed with the ITE
or your system JRE. Mac users can use the Mac configuration
to start the SimpleAdder with their default Java version.

2.3.1.1 Sample 1.1: creating a Test Case from Test Steps

This category contains one Test Case. The Test Case contains
four Test Steps, which test an addition in the Simple Adder.
The parameter values in the Test Steps have been referenced,
and a data set has been added.
This is an example of a test written with Test Steps. However,
we recommend using the library of Test Cases to write tests,
as shown in the next examples.

2.3.1.2 Sample 1.2: creating a Test Case using the li-

brary

This category contains one Test Case. The Test Case has ref-
erenced another Test Case, with four reused Test Cases, which
have been reused from the Project unbound_modules_concrete.

Press »F6« to find where a particular Test Case was orig-

inally specified.

UserManual V8.0.00170 April 15, 2014 15

 Functional Testing User Manual

The Test Cases carry out the same steps as in the previous ex-
ample ( → page 15) . The differences here are:

• The steps to enter a value both reuse the same Test Case,
with different referenced parameters, and a different com-
ponent name.

• The components used in the reused Test Cases are abstract

components ( → page 123) . This means that the Test
Cases are easier to reuse, making tests more robust and
maintainable.

This Test Case is reused in the executable Test Case 1.2_SIM-

PLE_ADDER_TEST, which is nested in the Test Suite of the
same name.

2.3.1.3 Sample 1.3: using Event Handlers

This category has four subcategories. Each subcategory con-

tains a test which reuses a Test Case to execute a calculation
in the Simple Adder which will cause an error. After the error,
a reset is carried out.
An Event Handler has been specified in the bound_modules_samples
Project. The Event Handler has been added to the Test Case,
and checks that text in the result field is jackpot.
The four tests are as follows:

Continue
The Event Handler in this test has the reentry property con-
tinue. When the error occurs, the Event Handler is activated.
Once the check has been carried out, the test continues, and
the reset is performed.
Exit
The Event Handler in this test has the reentry property exit.
When the error occurs, the Event Handler is activated. Once
the check has been carried out, the test finishes. The reset is
not performed.
Pause
The Event Handler in this test has the reentry property pause.
When the error occurs, the Event Handler is activated. Once
the check has been carried out, the test pauses. By un-pausing
the Test Suite in the client, the test continues.
Retry
The Event Handler in this test is different to the Event Handler

16 April 15, 2014 UserManual V8.0.00170

Samples: example tests

in the other tests. It contains the same steps as the test itself,
but the parameter references have been switched. This essen-
tially changes the order in which the numbers are entered into
the Simple Adder. The Event Handler has the reentry property
retry. When the error occurs, the Event Handler is activated.
The calculation is redone with the switched values. The failed
Test Step (i.e. the original check) is retried, and there is no
error. The test is marked as successful.

2.3.2 Sample 2: using the SWT Simple Adder

You can start the SWT SimpleAdder using the configurations
for the SimpleAdderSWT AUT. There are configurations for
Windows and Linux to use the JRE installed with the ITE or
your system JRE.

2.3.2.1 Sample 2: Simple Adder SWT Test

The test for the Simple Adder SWT reuses the test that uses
the actions from the library of unbound modules.

2.3.3 Sample 3: using the HTML Simple Adder

There is one AUT configuration for the Simple Adder HTML,
which starts the Simple Adder with Internet Explorer.

2.3.3.1 Sample 3: HTML test with the library

This test for the reuses the test that uses the actions from the
library of unbound modules.

2.3.3.2 Sample 3.2: HTML test with multiple data sets

This test shows how a Test Case can be executed multiple

times by adding more data sets.

2.3.4 Sample 4: using the JavaFX Simple Adder

You can start the JavaFX SimpleAdder using the configura-
tions for the SimpleAdderJavaFX AUT. The configurations for
Windows and Mac can be used without adapting them. The

UserManual V8.0.00170 April 15, 2014 17

 Functional Testing User Manual

configuration for Linux must be adapted to use a Java 8 JRE.

Enter the path to your Java 8 installation in the Executable File
Name field of the AUT configuration dialog ( → page 50) , in
place of the placeholder.

2.3.4.1 Sample 4: Simple Adder JavaFX test using li-

brary

The test for the Simple Adder JavaFX reuses the test that uses
the actions from the library of unbound modules.

2.4 DVD Tool Tests

2.4.1 Sample 2.1: testing the menu bar and

dialog boxes
This category and the ones following it contain Test Cases
which are used in the executable Test Case 2_DVD_TOOL_FULL_TEST
and the Test Suite of the same name.
The Test Case in this category contains a reused Test Case from
the bound_modules_samples Project. It contains Test Cases to
add a category to the DVD Tool via the menu. The parameter
for the category name has been referenced, as has a variable
to read the category name entered for use later in the test.
The original Test Case in the bound_modules_samples Project
had no data. When it was reused here, three data sets were
added. This means that the Test Case is executed three times,
each time entering a different category name, and storing the
name as a variable.

2.4.2 Sample 2.2: testing trees

This category contains a Test Case which checks that a tree
node exists, based on its textpath. Three data sets have been
entered, which use the variables stored in the previous Test
Case to complete the textpath.
For example, one of the stored variables was CATEGORY1.
The textpath to test is entered as Category/${CATEGORY1}.

18 April 15, 2014 UserManual V8.0.00170

Samples: example tests

2.4.3 Sample 2.3: testing tables

This category contains a Test Case which contains two Test
Cases. The first selects a category node in the tree and then
selects the option from the context menu to add a DVD. The
second Test Case enters text into the cells in the table. This
Test Case has four data sets, so that the four cells can be filled
with one Test Case.

2.4.4 Sample 2.4: testing tabbed panes, lists,

combo boxes
This category contains four Test Cases. The first two, Fill in
the Content Tab and Fill in the Technics Tab contain Test Cases
reused from the unbound_modules_concrete Project and the
bound_modules_samples Project. These Test Cases execute
various actions on the tabbed panes in the DVD Tool. There
is a lot of reuse of Test Cases, especially on different compo-
nents. The Enter a Text Detail Test Case, for example, is reused
three times, with a different component name each time. The
Fill in the Technics Tab Test Case also contains an Event Han-
dler to check a checkbox if it isn’t already done so. Many of
the parameters in these Test Cases have been referenced so
that values can be entered for them later.
The last two Test Cases each contain a Test Case to select a
DVD, and then contain the Fill in the Content Tab and Fill in
the Technics Tab Test Cases. Because the values in these Test
Cases were left empty, different data can be entered for each
Test Case.

UserManual V8.0.00170 April 15, 2014 19

 Functional Testing User Manual

20 April 15, 2014 UserManual V8.0.00170

Tasks

Chapter 3

Tasks

This chapter provides step-by-step instructions on designing,

writing, executing and analyzing tests. For more details about
individual tasks, read the Chapter ”Concepts” ( → page 309)
or Chapter ”User interface” ( → page 291) .

3.1 Starting and connecting to the

AUT Agent
The AUT Agent is the server component. It runs on the same
machine as the AUT and allows the ITE to communicate with
the AUT and control it during test execution. You must be
connected to a running AUT Agent in order to be able to per-
form object mapping, to observe tests, and to execute tests.
There are two options for working with an AUT Agent:

• You can connect to an embedded AUT Agent that does

not have to be started in advance ( → page 23) . This
option is only available if you are starting your AUT on the
same machine as the ITE. It can also be used with the test
executor: the testexec can start an embedded AUT Agent
for use during the test.

• You can start an AUT Agent on a machine (local or remote)

and connect to it using the ITE or the Test Executor ( →
page 21) .

3.1.1 Starting the AUT Agent

You can start the AUT Agent on your local machine (the same
machine as the ITE) or on a remote machine in the network.

UserManual V8.0.00170 April 15, 2014 21

 Functional Testing User Manual

The AUT Agent is started by default without a console.

If you want to see the console, you must adapt the au-
tagent.ini file. In the -vm parameter, use java instead of
javaw to see the console.

3.1.1.1 Windows users

1. Start the AUT Agent via the start menu:

Start → GUIdancer or Jubula → Start AUT Agent .

2. The AUT Agent is started on port number 60000 unless

you enter a different port number as a parameter ( →
page 22) .
You can see and stop the AUT Agent in the system tray.
Once the AUT Agent is started, you can connect to it from
the ITE ( → page 23) .

3.1.1.2 Linux users

Use the script:

./autagent (-p <port number>).
You can see and stop the AUT Agent in the system tray. Once
the AUT Agent is started, you can connect to it from the ITE
( → page 23) .

You must wait for the AUT Agent to be running before

you can connect to it.

The AUT Agent uses the current directory as its working

directory on Linux systems.

3.1.1.3 Starting the AUT Agent from the command

line: options and parameters

1. Start the AUT Agent from the Windows command line

with this command:
autagent.exe (-p <port number>)

22 April 15, 2014 UserManual V8.0.00170

Tasks

2. If no port number argument is given, the AUT Agent will

start on the default port 60000.

3. You can use the following parameters when starting the

AUT Agent:

-p: Port number. Enter the port number you wish to start
the AUT Agent on.

You can also use the environment variable

”TEST_AUT_AGENT_PORT” to set the port number
that should be used as a default when you start the
AUT Agent.

-l: Lenient mode. The lenient mode for the AUT Agent
allows AUT’s launched by other AUT’s to be tested ( →
page 129) . You can also change the mode of the cur-
rently running AUT Agent via the system tray. Right-click
the AUT Agent icon and (de)select Strict AUT Manage-
ment from the menu.

The default mode for the AUT Agent is strict.

-v: Verbose mode. You will see a dialog to tell you

whether the AUT Agent has started successfully or not.
-q: Quiet mode. You will see no dialog if the AUT Agent
starts successfully. If the AUT Agent does not start suc-
cessfully, the error is written to the console.
-h: Help. Enter this parameter to see a list of options for
the AUT Agent.

4. The AUT Agent can be started multiple times – either on

the same machine (using a different port number for each
instance) or on multiple machines for distributed testing.

3.1.2 Connecting to the AUT Agent

You can connect to an AUT Agent you have started ( → page
21) on a local or remote machine, or you can connect an
embedded AUT Agent on your local machine.

UserManual V8.0.00170 April 15, 2014 23

 Functional Testing User Manual

When using a separate AUT Agent, you must wait for

the AUT Agent to be running before you can connect to
it.

1. On the toolbar, click on the arrow next to the ”Connect to

connect to AUT AUT Agent ” button.
Agent
2. In the drop down list, you can choose an AUT Agent to
connect to:

• Select the embedded AUT Agent option to connect to

an AUT Agent that is automatically started for you on
your machine.

The embedded AUT Agent uses port 60001 by default in

the ITE. You can change the port that should be used for
the embedded AUT Agent in the preferences ( → page
169) .

• Select an AUT Agent host and port number to connect

to from the list. The list of hosts and ports available
in this list can be configured in the preferences ( →
page 168) . If you have set the environment variable
TEST_AUT_AGENT_PORT, then you will also see the port
number you set for that variable in the drop-down list.

If you are not working with the embedded AUT Agent,

you must have started an AUT Agent on a machine in
the network ( → page 21) to be able to connect to it.

To work with the embedded AUT Agent, you do not

need to start an AUT Agent on your machine. However,
you can only work with the embedded AUT Agent for
local testing (i.e. on the same machine as the ITE). The
embedded agent is started in lenient mode ( → page
129) .

24 April 15, 2014 UserManual V8.0.00170

Tasks

3.2 Starting the Integrated Test Envi-

ronment (ITE)

3.2.1 Windows Users

1. Start the ITE from the start menu:
Start → GUIdancer or Jubula → GUIdancer or Jubula .
2. You can also start the ITE using a command line argument.

3.2.2 Unix Users

Enter the program name into the shell.

The ITE uses the current directory as its working direc-

tory on Linux systems.

3.2.3 Choosing a workspace

1. When you start the ITE, a dialog appears asking you to
choose a workspace (Figure 3.1 → page 25 ).

Figure 3.1: Workspace chooser

The workspace is where your preferences are saved.

2. Select the default workspace offered, or locate new one.

3. You can choose to always select this workspace using the
checkbox.

You can see and change your workspace options in the

preferences ( → page 174) .

UserManual V8.0.00170 April 15, 2014 25

 Functional Testing User Manual

4. Select ”OK”.

3.2.4 Restarting the ITE

You can restart the ITE with the current workspace using:
File → Restart
You can also restart the ITE with a new workspace by select-
ing:
File → Switch Workspace

3.2.5 Help system

1. The information contained within this manual is also avail-
able in the ITE.
• In Windows, press »F1« to see context-sensitive help for
the current view.
• In Unix, press »SHIFT+F1«.
• Select :
Help → Help Content to search the handbook.
2. The help preferences can be altered via:
Window → Preferences → Help .
3. See later in this chapter ( → page 174) for details.

3.2.6 Working with the AUT Agent and client

on one machine
If the ITE and AUT Agent are installed on one machine, there
are a few things to be aware of:
• Don’t use the mouse or any keyboard shortcuts during ex-
ecution. The AUT takes control of the machine it is running
on during test execution.
• Make sure that the AUT is visible during test execution:
– The ITE is minimized by default when test execution be-
gins. Make sure that the AUT is the next window to
receive focus when the ITE is minimized.
– You can change the preference to minimize the ITE via:
Window → Preferences
If you do this, make sure that the AUT can also be seen
on the screen when test execution begins.

26 April 15, 2014 UserManual V8.0.00170

Tasks

3.3 Logging into and switching

databases

3.3.1 Logging in to the database

1. Projects are stored in a database. Before you can access a
Project, you have to log in to the database.

2. The log-in dialog for the database (Figure 3.2 → page 27 )

appears automatically the first time you need it (e.g. when
you try to open or create a Project).

Figure 3.2: Database login

If you are using the default demo (embedded) database,

you will automatically be logged into the database.

We do not recommend using the embedded database

for productive use.

3. Select the database you want to use and enter your user-
name and password.

If you previously had another ITE version installed, you

may see the information that your current database ver-
sion is not compatible with the latest version. If this is
the case, please follow the migration instructions in the
Installation Manual.

UserManual V8.0.00170 April 15, 2014 27

 Functional Testing User Manual

4. If you want to save your database password, select the

checkbox to store it in the secure store. You can edit your
password settings in the preferences via:
General/Security/Secure Store.

5. Once you have opted to save your password, you can also
choose whether you want to perform an automatic login
to this database when you use this workspace. If you select
this option, then the next time you open the ITE and e.g.
select:
Test → Open
you will be automatically connected to this database with
the username and password you entered.

You cannot perform auto-login for an embedded

database unless it is the only database configured.

6. You can change your auto-login details or select another

database at any time by selecting:
Test → Select database...

3.3.2 Selecting and changing the database

connection
1. You can change the database you are connected to by se-
lecting:
Test → Select database .

2. In the dialog that appears, select the database you want to

use and enter your username and password.

3.4 Migrating to newer versions

There are various steps that need to be taken to update your
environment and your Projects to a new version. Instructions
on performing the necessary updates are online on the
Testing Resources Portal:
http://testing.bredex.de/
migration-information.html

28 April 15, 2014 UserManual V8.0.00170

Tasks

3.5 Working with Projects

The first step once the ITE has been started is to create, open
or import a Project. Once you have done this, you can specify
Test Suites, Test Cases and Test Steps.

3.5.1 Creating a new Project

1. From the ITE, select:
Test → New .

2. If you haven’t already logged into the database, a dialog

will appear to ask you to do so.
See the previous section ( → page 27) for details.

3. A wizard to create a new Project will appear (Figure 3.3 →

page 31 ).

4. In the project name field, enter a meaningful and unique

Project name. Do not use any special characters in Project
names.

5. Activate the ”reusable project” checkbox if you want to be

able to reference the Test Cases from this Project in other
Projects. This will let you use the Test Cases in this Project
as the basis or library for other Projects (see the section
later for more details on this ( → page 36) ).

6. Choose whether this Project should be protected. In a pro-

tected Projects, you cannot delete Test Cases, edit param-
eters for Test Cases, or make any changes to the column
usage of central test data sets. This is only necessary if
the Project is reused in another Project – the protection
ensures that irreversible changes cannot be made to the
reused Project that would adversely affect its dependent
Projects.

7. Select the toolkit your Project will use from the combo box.
The toolkit is the library used to create the GUI.
Toolkits for Projects
The default toolkit is concrete. Choose this if you want to
write Test Cases that can be used for different applications
(e.g. for Swing and for RCP).
Choose another toolkit if you want to write Test Cases just
for a Swing, SWT, RCP, iOS, Windows or HTML application.

UserManual V8.0.00170 April 15, 2014 29

 Functional Testing User Manual

The choice of toolkit you make here will determine what

actions are available to you to specify your tests. If you
choose concrete, you will not be able to specify tests for
components specific to e.g. HTML or SWT.

8. From the list of available languages, select the languages

supported by your AUT and move them into the ”project
language” box using the arrow button. Use »CTRL« to
select multiple languages.
You will be able to start the AUT in these languages, and
translate test data into these languages.

9. Select a default language from the combo box. The default

language is the language your Project is started in.

10. You can now click ”Next” to define an AUT for this Project
( → page 47) .

If you want to define the AUT later, you can click ”Finish” to
create the Project as it is. You can define an AUT later via the
Project properties under Test → Properties .
You can also edit the Project details later in the Project prop-
erties dialog ( → page 32) .

30 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.3: New Project Dialog

UserManual V8.0.00170 April 15, 2014 31

 Functional Testing User Manual

3.5.2 Editing the Project and AUT properties

You can open the Project properties dialog (Figure 3.4 →
page 32 ) via:
Test → Properties

Figure 3.4: Project Properties Dialog

The Project properties dialog lets you see and, in some cases,
edit information about:

1. the Project in general ( → page 33) .

2. the Project languages ( → page 34) .

3. the AUT’s ( → page 34) .

4. the Projects that you have reused in this Project ( → page

36) .

5. the connection to application lifecycle management (ALM)

repositories in this Project ( → page 200) .

32 April 15, 2014 UserManual V8.0.00170

Tasks

3.5.2.1 Editing general Project properties

Select ”General” from the tree on the left-hand side of the

Project properties dialog. In the screen that appears, you can:

1. Edit the Project name.

2. Enter a comment for the Project. The comment is visible

in the Properties View when you select the Project node in
the Test Suite Browser.

3. Edit the toolkit used by the Project (see the following sec-
tion ( → page 33) for details on this).

4. Edit whether the Project can be referenced (reused) in

other Projects.

5. Edit the protected status of the Project. A protected Project

does not allow deletion of Test Cases or editing of param-
eters.

6. See the Project version. This is useful if you have more than
one version of a Project.

7. See the GUID (global unit identification). This is a unique

ID for the Project.

8. Specify how often the full test result details ( → page 161)
should be automatically deleted from the database.

9. Configure the tracking of changes in this Project (see the

section later ( → page 44) for details on this).

3.5.2.2 Changing the toolkit settings for a Project

If you want to change the toolkit of a Project in the Project

properties dialog, the following rules apply:

1. You can change at any time from the concrete toolkits to

a more specific toolkit (e.g. RCP, HTML).

2. If your previous choice of toolkit was RCP, SWT or HTML,

you can only change to another toolkit if your Project does
not use any components specific to the originally chosen
toolkit.

UserManual V8.0.00170 April 15, 2014 33

 Functional Testing User Manual

3.5.2.3 Editing the languages for a Project

To see and edit the Project languages, select ”Project lan-

guages” from the tree on the left-hand side of the Project
properties dialog.
You can add and remove Project languages and change the
default language in this screen.

You can’t delete a language which is being used as an

AUT language.

3.5.2.4 Editing the AUT’s in a Project

To see and edit your AUT’s for a Project, select ”AUTs” from
the tree on the left-hand side of the Project properties dialog.
In the screen that appears, you can see any AUT’s you have
already added to the Project (Figure 3.5 → page 34 ). You
can choose to edit them, delete them or add a new AUT.

Figure 3.5: AUT Properties Dialog

Defining and editing AUT’s from here involves the same steps
as defining an AUT in the Project wizard ( → page 47) .

3.5.2.5 Duplicating AUT configurations

You can duplicate an existing AUT configuration from the

Project properties dialog:

34 April 15, 2014 UserManual V8.0.00170

Tasks

1. Select ”AUTs” from the tree on the left-hand side of the

Project properties dialog.

2. Select the AUT configuration you want to duplicate.

3. Click ”Duplicate”.

4. The AUT configuration dialog will open. The AUT config-

uration name and the AUT ID are automatically changed
so that they remain unique. We recommend writing more
meaningful names for the configuration and the ID, how-
ever.

3.5.2.6 Editing the AUT configurations in a Project

Select ”AUTs” from the tree on the left-hand side of the

Project properties dialog.
In the screen that appears, you can see the AUT’s you have
added to this Project. Select the AUT you want to add a con-
figuration to, and click ”Edit”.
In the next screen there is a box labelled ”AUT configura-
tions”. You can choose to add, edit or delete AUT configura-
tions.
Adding and editing AUT configurations from here involves the
same steps as adding an AUT configuration in the Project wiz-
ard ( → page 50) .

3.5.3 Reusing (referencing) whole Projects in

a Project
You can reuse (reference) Projects as libraries of Test Cases in
other Projects.
To reuse Projects:

1. Make sure that the Project you want to reuse is in the

database.

2. Select:
Test → Properties
and select Used Projects from the tree on the left of the
dialog that appears (Figure 3.6 → page 36 ).

3. A list of Projects you can reuse will be offered on the

left-hand side of the dialog. You can only reuse Projects

UserManual V8.0.00170 April 15, 2014 35

 Functional Testing User Manual

Figure 3.6: Reused Projects

which support the same toolkit as your current Project (e.g.

Swing, Concrete).

To be able to reuse a Project, you must have checked the

reusable box in the Project properties for the Project (
→ page 33) .

4. From the list of reusable Projects, select a Project and its

version to reuse in the current Project. Use the arrows to
move it to the list of reused Projects.

5. Click ”OK”.

6. The Test Cases from the Project you chose to reuse will
appear in the Test Case Browser, under a category with
the same name as the reused Project. The Test Cases will
be colored blue to distinguish them from other Test Cases
in this Project.

You cannot edit these Test Cases here – but you can
reuse them in your Test Cases for this Project and
edit certain details (referenced parameters, component
names) when they are reused in other Test Cases.

36 April 15, 2014 UserManual V8.0.00170

Tasks

7. You can change the version of the reused Project via the
Used Projects Properties dialog, by clicking on the ”change
used version” button ( → page 37) .

3.5.3.1 Changing the version of a reused Project

You can change the version of the reused Project you are using
in your tests. This is useful to update to a new version of the
unbound modules, for example.

1. In the Used Project properties, select the currently reused

Project version from the list on the right.
2. Select the new version of this Project from the list on the
left.

In order to be able to see and select the new version of

the Project, it must be in your database!

3. Click the ”Switch version” button, marked with the op-

posing arrows.
4. The version of the reused Project will be switched.

If changes have taken place, it may be necessary to up-

date your test. You should especially check for any ac-
tions that have become deprecated since the last ver-
sion, and replace them with new actions.

3.5.4 Opening Projects

1. To open a Project from the database, select:
Test → Open .
2. If you haven’t already logged into the database, a dialog
will appear to ask you to do so. See the previous section (
→ page 27) for details.
3. Choose the Project you want to open from the combo box
in the dialog which appears (Figure 3.7 → page 38 ).
4. If the Project has more than one version, choose which
version you want to open. For more information on Project
versions, see the section later ( → page 43) .

UserManual V8.0.00170 April 15, 2014 37

 Functional Testing User Manual

Figure 3.7: Open Project from database

5. The Project is opened in the ITE.

3.5.4.1 Auto loading a default Project

1. Use the checkbox in the Open Project Dialog to specify that

you want to open this Project in this version automatically
when you select:
Project → Open
This is useful if you only have one Project that you work
with.

2. Per workspace, you can have one default Project. If you

are connected to a database which does not contain the
Project, or if the Project is no longer in the database, then
you will be shown the Open Project Dialog and can choose
another Project.

3. In the Test preferences ( → page 167) , you can disable

the auto load of the Project. Doing this will mean that you
see the normal Open Project Dialog when you select
Project → Open

38 April 15, 2014 UserManual V8.0.00170

 Tasks

3.5.5 Refreshing Projects

1. To refresh a Project, first select the Project in the Test Suite
Browser.
2. Select:
File → Refresh .
This reloads the data for the Project from the database,
ensuring in a multi-user environment that all Project data
is current.

If a Project which your current Project reuses has been

changed, then you must refresh the current Project for
the changes to take effect.

3.5.6 Deleting Projects

1. To delete a Project from the database, select:
Test → Delete .
2. If you haven’t already logged into the database, a dialog
will appear to ask you to do so. See the previous section (
→ page 27) for details.
3. Choose the Project you want to delete from the combo
box in the dialog (Figure 3.8 → page 40 ).

Figure 3.8: Delete Project dialog

UserManual V8.0.00170 April 15, 2014 39

 Functional Testing User Manual

4. If there is more than one version of the Project, choose

which version you want to delete.

5. Select whether you want to keep the test result summaries

associated with this Project or not.

In productive databases where you wish to evaluate

test results over longer periods of time, we recommend
selecting the option to keep the summaries.

6. Click ”OK” to delete the selected Project.

7. Confirm the deletion in the dialog which appears.

Deleting a Project from the database cannot be undone!

3.5.7 Saving a Project as a new Project

1. To save the currently opened Project as a new Project, se-
lect:
Test → Save as... .

2. Enter the new name for the Project in the dialog that ap-
pears.

3. This creates a new Project in the database, saved under the

name you entered.

4. If no changes have been made since the previous Project

save, the new Project has the same content as the previous
one.

5. Otherwise, any modifications are saved under the new

Project name, and the old Project is kept in the state of
its last save.

6. The new Project becomes active in the ITE.

Any test result summaries for the Project are not dupli-
cated in the new Project. Tests that ran for previous ver-
sions of the Project are, however, still in the database to
be used for long term analysis.

40 April 15, 2014 UserManual V8.0.00170

Tasks

3.5.8 Importing Projects

1. To import Projects, select:
Test → Import .

2. In the dialog which appears (Figure 3.9 → page 42 ), enter

or browse to the Projects you want to import.

3. If you have entered the path to a Project, click ”Add” to

add it to the list of Projects to be imported.

Note that the ”Add” button will only be activated if the

path you have entered is correct.

If you add multiple Projects to be imported, you can

change the order they are imported in using the arrows
next to the list of Projects. You can also remove a Project
from the list of Projects to be imported.

If you are importing Projects that are dependent on

other Projects (i.e. they reuse other Projects), import
the supporting Projects first.

4. If you only want to import one Project, you can select the
option to open the Project once it has been imported.

5. When you have finished your selection, click ”OK”. The

Projects you selected will be imported in the order speci-
fied.

3.5.9 Exporting Projects

You can choose to export the currently opened Project ( →
page 43) or all of the Projects in the database ( → page 43) .
Projects are exported in .xml format so that they can be added
to e.g. version control systems.

Projects are exported along with all their test result

summaries.

UserManual V8.0.00170 April 15, 2014 41

 Functional Testing User Manual

Figure 3.9: Import Dialog

42 April 15, 2014 UserManual V8.0.00170

Tasks

3.5.9.1 Exporting the currently opened Project

1. To export a single Project from the database, the Project

you want to export must be open.

2. Select:
Test → Export .

3. Choose the location to save your Project, and the name

you want to save it under.

4. Click ”OK”.

5. The Project (including the test result summaries ( → page

160) ) will first be refreshed and then exported. It is saved
as an .xml file.

When you export a single Project, only the currently

opened version is exported.

3.5.9.2 Exporting all of the Projects from the database

1. Select:
Test → Export all .

2. Choose or create a folder where you want the Projects to

be stored.

3. Click ”OK”.

4. The Projects (including the test result summaries ( → page

160) ) will be saved as .xml files.

When you export all Projects, all versions of each Project

are exported.

3.5.10 Versioning Projects

1. To create a different version of a Project, select:
Test → Create new version .

2. An automatic suggestion for the next version number is

provided.

UserManual V8.0.00170 April 15, 2014 43

 Functional Testing User Manual

3. You can accept this version number or enter a different

one.

4. Click ”OK” to create the new version.

5. The new version of the Project becomes active in the client.

Any test result summaries for the Project are not dupli-
cated in the new version. Tests that ran for previous ver-
sions of the Project are, however, still in the database to
be used for long term analysis.

You can also create a new version using the dbtool ( →

page 225)

3.5.11 Tracking changes in a Project

In order to see when changes were made to a Test Case, Test
Suite or Test Job in a Project, you can activate the change
tracking option in the Project properties.
When this option is activated, each Test Case, Test Suite and
Test Job shows information on the timestamp of a change,
and the type of change (created or modified). You can op-
tionally enter a property which should be displayed alongside
the change type to track e.g. the user that made the change.
The changes that lead to change information being shown
are:

• The creation of a node.

• Any time an editor is saved (renaming within an editor,

adding Test Cases to an editor, removing Test Cases from
an editor, adding data or component names, using the
refactor actions from within an editor.

Project-wide refactor actions, such as those started from the

search result view, and any renaming in browsers, are not
shown in the change information.

44 April 15, 2014 UserManual V8.0.00170

Tasks

3.5.11.1 Activating change tracking

1. Open the Project properties:

Test → Properties

2. Select General from the tree on the left-hand side.

3. Activate Track changes to activate change tracking for this

Project.

4. Choose whether you want to track a certain number of

changes per node, or whether you want to keep changes
for a specific time span. Enter the amount of changes or
days.

The display for each node is updated on saving. If there

are too many changes, or some changes are outside of
the specified time span, they will be removed on saving.

5. You can (optionally) enter a system or environment prop-

erty that is displayed in the Properties View as additional
information about the change (e.g. the user that made
the change).

When change tracking is activated, the Properties View for

the original specification (not places of reuse) for Test Cases,
Test Suites and Test Jobs displays information on the changes
made Figure 3.10 → page 46 .
You can deactivate change tracking via the Project proper-
ties. To remove all current information about changes, use
the delete option ( → page 45) .

3.5.11.2 Removing change tracking information from

a Project

1. To remove all information on all nodes about changes

made, open the Project properties:
Test → Properties

2. Select General from the tree on the left-hand side.

3. Click the button ”Delete all tracked data” and confirm

when asked.

UserManual V8.0.00170 April 15, 2014 45

 Functional Testing User Manual

Figure 3.10: Tracking Changes

4. All data will be removed from the Project that were col-
lected for the change tracking.

If a node is currently locked, then the data for this node

will not be removed. You will see which nodes are
affected in a dialog. We recommend deleting change
tracking data when you are sure that no one else is us-
ing the Project.

46 April 15, 2014 UserManual V8.0.00170

Tasks

3.6 Defining applications under test

(AUT’s)
Once you have created a Project, you can define (and edit)
AUT’s. You can define a new AUT straight after creating the
Project in the Project wizard or you can do it later on via the
Project properties ( → page 32) .

If you will be starting your Java AUT with the autrun

command ( → page 55) , then you can automatically
define your AUT ( → page 55)

The AUT dialog (Figure 3.11 → page 47 ) appears when you

define or edit an AUT.

Figure 3.11: AUT Dialog

UserManual V8.0.00170 April 15, 2014 47

 Functional Testing User Manual

If you know that you will be working with multiple ver-

sions of the same AUT (e.g. a version for Windows and
Linux, or two versions that use different databases),
then define one AUT here and create multiple config-
urations ( → page 50) for this AUT. This means that
your different configurations will all share one object
map. If you are working with multiple completely dif-
ferent AUT’s, then define the different AUT’s here.

1. Enter a meaningful and unique AUT name. This is used to

easily identify the AUT later.

2. Select the toolkit the AUT uses from the combo box.

3. If you choose RCP, decide whether or not you want to gen-

erate names for components in the AUT which have not
been named by your developers ( → page 264) . We rec-
ommend leaving this option checked, as it increases the
robustness of your tests.

4. If you are starting a Java AUT and will be starting it using

the autrun command ( → page 55) , or if the AUT will be
launched from another AUT during the test ( → page 129)
, then enter the ID(s) for these AUT’s here. IDs for AUT’s
started by the autrun command
Enter the AUT IDs you will use for any AUT’s started by
the autrun command (the AUT ID for the AUT is given as a
parameter in the autrun command ( → page 55) .
IDs for AUT’s launched by other AUT’s
The AUT ID will take a specific form ( → page 129) and
must be defined as such in the AUT definition.

If you will be starting your AUT from the ITE (i.e. via an
AUT configuration ( → page 50) ) then you do not need
to enter any IDs here.

5. From the list of Project languages, select which languages

are supported by the AUT.
The languages you select are the languages the AUT can
be started in. You will be able to translate the data in your
Test Cases into these languages so that a Test Suite will test
the AUT in the right language.

48 April 15, 2014 UserManual V8.0.00170

Tasks

If you are editing the AUT and remove an AUT language

for which you have already specified data, this will re-
sult in the data for that language being lost.

6. If you want to start this AUT from the ITE, you can do so in
the Project properties ( → page 50) .

If you do not require an AUT configuration, because you will

be starting the AUT using the autrun command ( → page 55)
, then you do not need to create an AUT configuration.

UserManual V8.0.00170 April 15, 2014 49

 Functional Testing User Manual

3.7 Starting and configuring AUT’s

3.7.1 Configuring AUT’s to be started from

the ITE
Once you have created a Project ( → page 29) and defined an
AUT ( → page 47) , you can add and edit AUT configurations.
The details in the AUT configuration provide information on
how to start the AUT, e.g. on which machine.
An AUT can have multiple configurations (for example, for lo-
cal and remote testing). A configuration contains all the infor-
mation required to start the AUT, and may contain platform-
or installation-specific information such as paths to working
directories, AUT arguments, Java versions, browser choices
and activation methods.

If you want to start your Java AUT yourself, and have

the ITE connect to it, then use the autrun command to
start the AUT ( → page 55) . In this case, you do not
need to create an AUT configuration.

3.7.1.1 AUT activation

Activation makes sure that the AUT is in focus at the begin-

ning of test execution. This is acheived by clicking somewhere
in the AUT window. You can specify the activation method
(i.e. where to click) as part of a configuration for an AUT, or
you can create a Test Step within a test to do the same thing
(→Reference Manual p. 97).
The advantage of specifying an activation method here is that
it is central and affects each test execution started on this AUT
with this configuration.
Bear in mind that you may need to activate your AUT in or-
der for tests to work, especially if the AUT runs on the same
machine as the ITE.

50 April 15, 2014 UserManual V8.0.00170

Tasks

3.7.2 Basic information required for every

AUT configuration
Regardless of the type of AUT you want to start, you will al-
ways need to enter the following information in the AUT con-
figuration dialog.

• A suggested name for this AUT configuration is generated

automatically based on your AUT name and the default
AUT Agent host. You can change this name if you wish.

• The default AUT Agent host is also automatically selected.

You can select a new AUT Agent from the combo box or
add a new one by clicking ”New”. For more information
on adding and editing an AUT Agent, see the section later
( → page 168) .

• Enter the AUT ID that will be given to this AUT when it is

started.

3.7.3 Using a working directory in an AUT

configuration
In some AUT configuration dialogs, you can optionally create
a working directory to store files in. The server directory of
the installation is selected as default. To create a working
directory elsewhere, browse to and select the location.
The working directory is the root directory for any classpaths,
classnames, JAR files and binaries. If you create a working di-
rectory, you can enter the paths to these items using a relative
path, with the working directory as the root. For more in-
formation on relative paths, read the section in the reference
manual (→Reference Manual p. 383).

3.7.4 Starting Java AUT’s (Swing, SWT/R-

CP/GEF)
3.7.4.1 Two options to start Java AUT’s

There are two options to start your Java AUT for testing:

Via an AUT configuration: This option means that you cre-

ate an AUT configuration in your Project, and the AUT is
started from the ITE ( → page 52) .

UserManual V8.0.00170 April 15, 2014 51

 Functional Testing User Manual

Using the autrun command: This option lets you start an

AUT without creating a configuration. Certain start pa-
rameters are required for the AUT so that it can be located
( → page 55) .

3.7.4.2 Configuring a Java AUT to be started from the

ITE

The AUT configuration dialog for Java has three different lev-
els of detail: basic, advanced and expert.
See the sections below for information on the different levels.

3.7.4.3 Basic Java AUT configuration

You can use the basic setting (Figure 3.12 → page 53 ) to

configure your AUT if it can be started by an executable file
(e.g. .bat, .exe, .cmd, .sh etc.) and if it is written in Java 1.5
or above, and you are using a Java Standard Edition JRE.

If you are testing RCP or GEF AUT’s, there are certain

specific steps you need to take to configure them. See
the sections on RCP testing ( → page 260) , GEF testing
( → page 265) for details.

1. Enter the basic configuration details as described earlier (

→ page 51) .

2. Enter the executable file name in the Executable File Name

field. This path can be relative if you define a working
directory ( → page 58) ).

For information on the advanced properties for the AUT con-

figuration, see the next section ( → page 58) .

3.7.4.4 Advanced AUT configuration

You can use the advanced dialog (Figure 3.13 → page 62 )

if your AUT is a Java JAR which can be started with a double
click, or if your application can be started using the class name
and the classpaths to your AUT. The advanced configuration
dialog also lets you create a working directory for your AUT,
and add command-line arguments needed to start the AUT.

52 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.12: AUT configuration window: basic

You can select a JRE executable and, for SWT/RCP AUT’s, a

keyboard layout.

1. Enter the JAR path (directory and file name) into the Exe-
cutable JAR File Name field.
This path can be relative (if you define a working directory
( → page 51) ), or absolute. This JAR file must contain a
manifest file which contains the main class and the class-
path.

2. If your AUT must be started with the class name, add the
main class name and the classpaths into their relative fields.
The paths can be relative (if you have defined a working
directory), or absolute.

Add all the necessary files and directories to start the

AUT.

3. Enter any necessary command-line arguments for the AUT

in the AUT Arguments field.

UserManual V8.0.00170 April 15, 2014 53

 Functional Testing User Manual

4. Browse to a JRE executable or add a new one by clicking

”New”. The Java version used must be 1.5 or later.
Java is installed with the ITE. You can find the Java file in:
GUIdancer or Jubula → jre → bin . Use java.exe if
you want to use a console, use javaw.exe if you do not
want a console.

5. For SWT and RCP AUT’s, select which keyboard layout is

used on the machine on which the AUT will run. g

The keyboard layout is not the actual keyboard at-

tached to the computer, but is based on the regional
language settings for the operating system.

English (US) and German (DE) keyboard layouts are sup-

ported out-of-the box. If you want to use a different key-
board layout, see the reference manual for information on
creating keyboard layouts (→Reference Manual p. 391).

For information on the expert properties for the AUT config-

uration, see the next section ( → page 58) .

3.7.4.5 Expert AUT configuration

You can use the expert dialog (Figure 3.14 → page 63 )

to configure more detailed information about how the AUT
should be started.

1. Add any additional desired JRE Arguments.

2. Enter any required System Environment Variables, in the

format ”<VARNAME>=<value>”, i.e. ”PATH=C:\”. Sepa-
rate each variable with a new line by pressing »ENTER«.

Please be advised that ”embedding” the contents of

one variable into another is not supported at this time.
That is, if you have a variable named FOO whose value
is ”abc”, and set the value of a second variable BAR
to ”%FOO%def”, the second variable will not contain
”abcdef”, but rather the exact text ”%FOO%def”, with-
out evaluating it.

54 April 15, 2014 UserManual V8.0.00170

Tasks

3. Select an activation method for your AUT. More informa-

tion on AUT activation is available in the previous section (
→ page 50) .
4. If you want to perform monitoring (code coverage ( →
page 252) , Chronon recording ( → page 232) ), then
select this from the combo box.

3.7.4.6 Starting Java AUT’s with the autrun command

The autrun command can be used as an alternative to starting

your AUT from the ITE. (i.e. with an AUT configuration ( →
page 50) ). It can only be used if your AUT is written in Java
1.5 or above, and you are using a Java Standard Edition JRE.

The autrun command cannot be used for HTML or pure

SWT AUT’s.

The command allows you to start your AUT independently, on

a machine where the AUT Agent is running. The ITE, when
connected to this AUT Agent will then recognize the running
AUT as a testable application.
To use the autrun command:

1. Ensure that the AUT Agent is installed on the machine

where you will be starting the AUT.
2. Navigate to the server directory in the installation via the
command line.
3. Start your AUT via the command line by entering
autrun.exe under Windows or autrun under Linux
then the following parameters:

If your AUT is an RCP AUT, use -data’<WORKSPACE>’

after the executable file to specify the workspace the
AUT should use.

3.7.4.7 Creating an AUT definition from a running AUT

Once you have started an AUT using the autrun command,

you can automatically generate an AUT definition ( → page
47) for this AUT:

UserManual V8.0.00170 April 15, 2014 55

 Functional Testing User Manual

Detail Parameter
-h -h
Gives parameter help
-w, --workingdir -w <directory>
Enter the working directory for the AUT
-a, --autagenthost -a <hostname>
Enter the hostname for the AUT Agent
-p, --autagentport -p <port number>
Enter the port number for the AUT Agent
-swing
If the AUT is a Swing AUT
-rcp
If the AUT is an RCP AUT
-swt
If the AUT is an SWT AUT
-k, --kblayout -k <en_US>
Enter the keyboard layout for SWT/RCP AUT’s
-i, --autid -i <ID>
Enter the ID to give to this AUT
-e, --exec -e <AUT.exe>
Enter the executable file for the AUT
This must be the last parameter in the command line
-g, --generatenames (optional) -g <true/false>
For RCP AUT’s, enter whether
to generate technical names. ( → page 47)

Table 3.1: Parameters for autrun command

56 April 15, 2014 UserManual V8.0.00170

Tasks

• In the Running AUT’s View, select the AUT you want to

define (it will be marked as an unknown AUT ID).

• Select:
Create AUT Definition
from the context menu.

• The AUT definition window will appear. Complete the dia-

log ( → page 47) and click ”OK”.

3.7.5 Starting JavaFX AUT’s

You can start JavaFX AUT’s via a configuration, but not via
autrun.

3.7.5.1 Configuring a Java AUT to be started from the

ITE

The AUT configuration dialog for Java FX has three different

levels of detail: basic, advanced and expert.
See the sections below for information on the different levels.

3.7.5.2 Basic JavaFX AUT configuration

You can use the basic setting to configure your AUT if it can
be started by an executable file (e.g. .bat, .exe, .cmd, .sh etc.).
If your AUT is a JAR, then you can also use the executable file
field to enter the Java executable (i.e. java or java.exe) and
then enter the path to the JAR in the AUT Arguments field in
the advanced configuration ( → page 58) .

You must be using a Java 8 JRE to be able to start JavaFX

AUT’s.

1. Enter the basic configuration details as described earlier (

→ page 51) .

2. Enter the executable file name in the Executable File Name

field. This path can be relative if you define a working
directory ( → page 58) ).

For information on the advanced properties for the AUT con-

figuration, see the next section ( → page 58) .

UserManual V8.0.00170 April 15, 2014 57

 Functional Testing User Manual

3.7.5.3 Advanced JavaFX AUT configuration

The advanced configuration dialog lets you create a working

directory for your AUT, and add command-line arguments
needed to start the AUT. If you entered a Java executable
as the executable file name in the basic configuration, then
you can enter -jar <JARFILE> in the AUT Arguments field
(Figure 3.15 → page 64 ).
For information on the expert properties for the AUT config-
uration, see the next section ( → page 58) .

3.7.5.4 Expert JavaFX AUT configuration

You can use the expert dialog to configure more detailed in-
formation about how the AUT should be started.

1. Enter any required System Environment Variables, in the

format ”<VARNAME>=<value>”, i.e. ”PATH=C:\”. Sepa-
rate each variable with a new line by pressing »ENTER«.

Please be advised that ”embedding” the contents of

one variable into another is not supported at this time.
That is, if you have a variable named FOO whose value
is ”abc”, and set the value of a second variable BAR
to ”%FOO%def”, the second variable will not contain
”abcdef”, but rather the exact text ”%FOO%def”, with-
out evaluating it.

2. Select an activation method for your AUT. More informa-

tion on AUT activation is available in the previous section (
→ page 50) .

3.7.6 Starting Web AUT’s (HTML)

The AUT configuration dialog for HTML has three different
levels of detail: basic, advanced and expert.
See the sections below for information on the different levels.

3.7.6.1 Basic HTML AUT configuration

Use the basic setting to specify the URL and Browser you wish
to start this AUT configuration on.

58 April 15, 2014 UserManual V8.0.00170

Tasks

1. Enter the basic configuration details as described earlier (

→ page 51) .

2. You can optionally create a working directory to store files

in ( → page 51) .

3. Enter the URL of your AUT.

Relative paths to the URL cannot be used!

4. Select the browser you want to start the AUT in.

For information on the advanced properties for the AUT con-

figuration, see the next section ( → page 59) .

3.7.6.2 Advanced HTML AUT configuration

You can use the advanced dialog to enter the browser path
for your browser. This lets you use a specific version of the
browser (not available for Internet Explorer).
You can also specify whether you want to be able to use the
multi-window support in your tests for this AUT. If your AUT
has functions that open new windows, then deactivate the
Single Window Mode checkbox. Any AUT’s that are running
in multi-window mode show the Selenium console as well
as the AUT when the AUT is started. The Object Mapping
Editor for multi-window AUT’s has a button to allow switching
between multiple open windows for mapping components,
and there are actions in the HTML unbound modules to allow
you to switch between windows during the test.
For information on the expert properties for the HTML AUT
configuration, see the next section ( → page 59) .

3.7.6.3 Expert HTML AUT configuration

You can use the expert dialog to enter an ID attribute name

( → page 270) . If you have used a specific tag to name
components in your application, enter the tag in the Expert
Configuration area. This information is then used instead of
the name attribute in the object recognition.
You can also select an activation method for your AUT. See
the section on AUT activation ( → page 50) for more details.

UserManual V8.0.00170 April 15, 2014 59

 Functional Testing User Manual

3.7.7 Starting Win AUT’s (.NET, WPF)

3.7.7.1 AUT configuration for Windows desktop AUT’s

To be able to start a Windows desktop AUT, you should select

the win toolkit as the AUT toolkit in the AUT definition dialog.
You must enter the following information to be able to start
a win AUT:

1. Enter the basic configuration details as described earlier (

→ page 51) .

2. Enter the executable file name in the Executable File Name

field. This path can be relative if you define a working
directory ( → page 51) ).

3. Enter any necessary command-line arguments for the AUT

in the AUT Arguments field.

3.7.8 Starting iOS AUT’s

3.7.8.1 Connecting to the AUT Agent

The AUT Agent does not need to be started on the simulator

or device for testing iOS AUT’s. It does, however, need to
be started to ensure that the communication can take place.
The actual communication with the simulator or the device is
accomplished using a port that is defined in the test AUT (
→ page 276) and configured in the AUT configuration ( →
page 60) .

Since the place where the AUT Agent is started is not

important, we recommend starting it on localhost.

3.7.8.2 Configuring an iOS AUT

• Enter the basic configuration details as described earlier (

→ page 51) .

• The working directory currently has no effect.

• Enter the iOS Device Host: this is the address of the device
or simulator in the network that the AUT will run on. The
host will either be a hostname or an IP address.

60 April 15, 2014 UserManual V8.0.00170

Tasks

• Enter the iOS Device Port: this is the port number that
is available for communication between the AUT and the
ITE. It is defined as a part of the setup of the AUT. If no
port number has been specified in the AUT, the default of
11022 will be used, and you should enter this number.

Starting iOS AUT’s with autrun is not supported.

3.7.8.3 Starting and connecting to iOS AUT’s

Unlike other AUT’s, iOS AUT’s are not started via the ITE, nor
by the testexec. Instead, the AUT must have been made
testable ( → page 276) , had component naming added (
→ page 279) and also be started on the simulator or device
that it will be tested on. Once these prerequisites have been
completed, you can connect to the AUT from the ITE by se-
lecting the AUT from the list in the ”Start AUT” button on the
toolbar. This does not start the AUT but connects to it.

3.7.9 Starting other AUT’s

Any other details that are specific to a type of AUT are doc-
umented in the section on toolkit-specific information ( →
page 259) .

UserManual V8.0.00170 April 15, 2014 61

 Functional Testing User Manual

Figure 3.13: AUT configuration window: advanced

62 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.14: AUT configuration window: expert

UserManual V8.0.00170 April 15, 2014 63

 Functional Testing User Manual

Figure 3.15: Example JavaFX AUT configuration

64 April 15, 2014 UserManual V8.0.00170

Tasks

3.8 Working with browsers: renam-

ing, deleting, using IDs, multiple
browsers
Select an item in a browser to see read-only details in the
Properties View, Data Sets View and Component Names View
for this item.
You can rename items from the Test Case Browser, Test Suite
Browser or Component Name Browser.
You can open editors for items in certain browsers. See the
later section ( → page 68) for more details.
You can also save the ID of Test Cases and Test Suites in
browsers to the clipboard, in order to link these elements with
external systems.

3.8.1 Renaming items in browsers

To rename an item in the Test Case Browser, Test Suite
Browser or Component Name Browser:

1. Select the item you want to rename in the browser.

2. Select:
Rename
from the context-sensitive menu.

3. In the dialog which appears, enter a new name and click

”OK”.

You can also press »F2« to rename an item.

When you rename a Test Case or Test Suite, you change its
specification name.
If you have reused this Test Case or Test Suite in other Test
Cases, Test Suites or Test Jobs, the name will also be changed
in the places where you have reused it but not renamed it.

3.8.2 Deleting items from browsers

1. To delete a Test Case, Test Suite, Test Job or component
name, select it in the browser.

UserManual V8.0.00170 April 15, 2014 65

 Functional Testing User Manual

2. Select ”delete” from the context-sensitive menu.

3. You can also delete items by pressing »DELETE«

If the item you want to delete is referenced somewhere

in your test, you must first remove it from the place
where it is reused before deleting it.

3.8.3 Working with IDs for Test Cases and

Test Suites
Each Test Case and Test Suite in a Project has a unique ID
which can be used to refer to this Test Case or Test Suite within
the Project and from external systems.

3.8.3.1 Copying the ID of a Test Case or Test Suite to

the clipboard

1. Select the Test Case or Test Suite whose ID you want to use
from the Test Case Browser or Test Suite Browser.

Make sure you select the original specification of the el-

ement, not a place where it has been reused. Press »F6«
to find the original specification of a selected element.

2. Select:
Copy ID to clipboard
from the context-sensitive menu.

3. You can now paste the ID into your external system.

3.8.3.2 Opening an element based on an ID in the clip-

board

1. Copy the ID you want to find from your external system.

2. In the ITE, press »SHIFT+F9« to open the Test Case Editor

or Test Suite Editor for the element with the ID from the
clipboard.

66 April 15, 2014 UserManual V8.0.00170

Tasks

3.8.4 Opening the Test Case Browser multiple

times
To make navigation in larger Projects easier, you can open
multiple instances of the Test Case Browser. You can filter
each Test Case Browser separately to give you different views
of your Test Cases at the same time. All instances of the Test
Case Browser are kept up-to-date with any changes to Test
Cases in the Project.

1. To open a new Test Case Browser, select New Test Case

Browser from the small arrow menu in the Test Case
Browser. A new Test Case Browser will open.

2. When you have multiple browsers open, one of them will

always be marked as the main browser in its title. This
is the default browser for actions such as ”Show Specifi-
cation” and for the displaying of any search results. You
can switch the main browser using the button in the tool-
bar. If you close the Test Case Browser you have marked
as being the main browser, another Test Case Browser will
automatically be marked as the new main browser.

3.8.5 Opening the task editor for items in

browsers
Each Test Case, Test Suite and Test Job in a Project can be
joined to a task in an external repository via a task ID ( → page
196) . You can open the task for an item from the browser:

1. Select the item whose task you want to open in the

browser.

2. Right click and select:

Open with → Mylyn Task Editor

3. The task from the external repository will open in the ITE.

If no repository has been defined for the Project, or the

task ID does not exist, or the repository is not config-
ured in the workspace, then the task will not open.

UserManual V8.0.00170 April 15, 2014 67

 Functional Testing User Manual

3.9 Working with editors: opening,

adding/deleting/renaming items,
commenting, extracting and re-
placing, reverting changes
The editors for Test Cases, Test Suites and Test Jobs all let you
work in a similar way in the ITE. When you are working in an
editor, the Properties View, Data Sets View and Component
Names View on the right hand side of the screen contain in-
formation about the selected item.

3.9.1 Opening items in editors

To open an existing Test Case, Test Suite or Test Job in an
editor, you can either double-click the item you want to open
in its browser or you can select:
Open With → ... Editor
from the context-sensitive menu for the item.

If you double-click on an item in a browser that is reused

in another item (e.g. you double-click a Test Case that
is reused in another Test Case), the editor for its direct
parent will open, and the item you double-clicked is se-
lected.

You can also open an existing Test Case without having to

select it from the Test Case Browser using the Open Test Case
dialog ( → page 85) .

3.9.2 Adding items to editors

You can add (reference) Test Cases in other Test Cases and in
Test Suites. You can also add (reference) Test Suites in Test
Jobs.
To add items to an editor:

1. Open the editor by double-clicking the item you want to

add things to.
2. You can now:
A Add items via drag and drop from the browser into the
editor:

68 April 15, 2014 UserManual V8.0.00170

Tasks

Test Cases :
Test Cases can be added to other Test Cases and Test
Suites by selecting the Test Case from the Test Case
Browser and dragging it into the editor.
Test Suites :
Test Suites can be referenced in Test Jobs by selecting
the Test Suite to reference from the Test Suite Browser
and dragging it into the Test Job Editor.

Once you have added a Test Suite to a Test Job, you

must enter the AUT ID for the AUT to be tested in the
Properties View.

B For Test Cases, you can also use the Reference Existing
Test Case dialog. Using the context-sensitive menu in
the editor, select:

Reference Existing Test Case

You can also press »ENTER« in the editor to open the

Reference Existing Test Case dialog.

Using this dialog Figure 3.16 → page 70 , you can

choose a Test Case or Test Cases to add to the editor.
You can filter in through the dialog using the field at
the top. Use star * as a wild card.

Items you reference in editors are marked with a small arrow

to show that they are reused (referenced) here. The name of
the item is contained in angled brackets (< >) to show that it
is the same name that you used when you specified the Test
Case. Items can be renamed to reflect their particular use in
this editor ( → page 70) .

You can’t add items which would cause an infinite loop.

3.9.3 Deleting items from editors

1. Open the item from which you want to delete other items
in the editor

UserManual V8.0.00170 April 15, 2014 69

 Functional Testing User Manual

Figure 3.16: Add Test Case reference dialog

2. Right-click on the item(s) to be deleted (use »CTRL« to se-

lect multiple items) and select ”Delete” from the context-
sensitive menu.

3. You can also use »DELETE« to delete items.

4. Save the changes in the editor.

3.9.4 Renaming items in editors

You can rename items referenced in Test Cases, Test Suites
and Test Jobs.

1. Open the editor containing the items you want to rename.

2. Select the item you want to rename in the editor.

3. In the Properties View, enter the new name for the item in
the Reference Name field at the top of the Properties View.

4. Save the editor.

70 April 15, 2014 UserManual V8.0.00170

Tasks

The angled brackets from the item you just edited will dis-
appear from the name in the editor. This indicates that the
item has been renamed here. You will still see the original
item name behind the new name in brackets. In the pref-
erences, you can opt not to see the original name when
you have renamed an item ( → page 167) .
The original item in the browser still has its original name.
The referenced item you just renamed will keep its new
name even if you rename the original item.
If you want to reset the original specification name, empty
the Reference Name field and save the editor. The item will
redisplay the angled brackets and will have the same name
as the specification name.

3.9.5 Adding comments to items in editors

You can add comments to items via the editor for an item.
You can add comments to the item itself, or to other items
used in it.

1. Open the editor for the item you want to add comments
to.

2. Enter a comment in the comment field in the Properties

View.

3. Save the changes

4. Comments can be overwritten when an item is reused.

You can see the comment for a Test Case when you
hover over it in the Test Case Browser or the Test Suite
Browser or in the search results view.

You can also add comments to categories using the

context-menu in the browser ( → page 78) and to the
Project itself via the Project properties ( → page 33) .

UserManual V8.0.00170 April 15, 2014 71

 Functional Testing User Manual

3.9.6 Adding Task IDs to items in editors

You can add a Task ID to a Test Case, Test Suite or Test Job in
the relevant editor. You can add a task ID to the item itself,
but not to other items used in it (unless you edit them in their
own editor).

1. Open the editor for the item you want to add a task ID to.

2. Enter a task ID in the Task ID field in the Properties View.

3. Save the changes

4. Task IDs cannot be overwritten when an item is reused.

3.9.7 Commenting out items in editors

In the Test Case Editor and the Test Suite Editor, you can de-
activate and reactivate Test Cases and Test Steps.

1. Select the Test Steps or Test Cases you want to deactivate

and select:
Set as active / inactive
from the context menu.

You can also use »CTRL+7« to toggle the items as active

or inactive.

2. The items you selected will be set as inactive. They are

shown with green text and the sign // before the Test
Case or Test Step name.

3. Any inactive items are not considered in Test Suite valida-

tion, nor are they executed during a test run.

4. You can reactivate the items by selecting:

Set as active / inactive
from the context menu.

3.9.8 Extracting Test Cases from editors:

Refactoring
You can extract Test Cases from other Test Cases and from
Test Suites. This lets you create keywords even after you have
started specifying.

72 April 15, 2014 UserManual V8.0.00170

Tasks

1. Open the Test Case Editor or Test Suite Editor by double-

clicking on the Test Case or Test Suite you want to edit.

2. Select the Test Cases you want to extract by single-clicking

them. Use »CTRL« to select more than one item.

3. Right-click in the editor and select:

Refactor → Extract Test Case .

4. When prompted, enter a name for the new Test Case.

5. The Test Cases you selected will be extracted into this new
Test Case.

6. The extracted Test Case appears as a reused Test Case in

the current editor. It is marked with a small arrow to show
that it is reused, and the Test Case name is in angled brack-
ets (< >) to show that it is the same as the specification
name.

7. The Test Case you just created is also visible in the Test Case
Browser.

Use this feature when you realize that you are planning
on reusing one or more Test Cases for the same or a
similar action again. You will save yourself time in test
creation and maintenance.

3.9.9 Replacing Test Cases in editors: Refac-

toring
You can replace one or more Test Cases in an editor with an-
other Test Case from your library of Test Cases. This is useful if
you have created a module to replace one or more Test Cases
and you want to be guided through the replacement process.

To replace a specific Test Case at all / multiple places

where it has been reused, use the option available in
the Search Result View ( → page 88) .

1. Open the Test Case Editor or Test Suite Editor by double-

clicking on the Test Case or Test Suite you want to edit.

UserManual V8.0.00170 April 15, 2014 73

 Functional Testing User Manual

2. Select the Test Cases you want to replace by single-clicking

them. Use »CTRL« to select more than one item.

3. Right-click in the editor and select:

Refactor → Replace with Test Case .

4. The first page of a wizard appears in which you can replace

selected the Test Cases in a series of steps.

You may only replace single Test Cases which neither

have multiple data sets nor central test data / Excel files
as data.

Page 1: Replacing the Test Cases

1. On the first page of the wizard Figure 3.17 → page 75 ,

you can select a new Test Case to replace the selected Test
Cases.

2. Browse to and select the Test Case you want to add to the
editor.

3. Click ”Next” to match the component names for the old

and new Test Cases, or click ”Finish” to replace the se-
lected Test Cases with the bare new Test Case, without
any component names transferred.

Page 2: Matching component names

1. On the second page of the wizard ( → page 76) , you can

see an overview of component names for the replacement.

• On the left-hand side you can see any component

names that were entered for the Test Cases to be re-
placed. If the component names were propagated ( →
page 119) , you will see a small yellow arrow on the
component name icon.

If the old Test Cases contained no component names,

then you will see the text no component names.

• On the right-hand side, you can see the Component

Names View, which shows any component names that
are required by the new Test Case.

74 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.17: Select Test Case

2. Use this dialog to transfer any component names from

the old Test Cases to the new Test Cases. You can enter
component names, or you can leave the new component
names as they are. You can also set the checkbox in the
Component Names View to propagate the name to the
next Test Case in the hierarchy.

3. Once you have transferred the component names, you can

click ”Next” to add further information or you can click
”Finish” to replace the selected Test Cases with the new
Test Case and the selected component names.

Page 3: Further information

1. On the final page of the wizard, you can enter a Test Case
reference name and a comment for the new Test Case.

2. Once you have entered a name and/or a comment, you

can click ”Finish” to complete the replacement.

Once you have replaced the Test Case, you must manually
adapt the parameters for the new Test Case.

UserManual V8.0.00170 April 15, 2014 75

 Functional Testing User Manual

Figure 3.18: Match component names

3.9.10 Saving Test Cases from an editor as a

new Test Case
You can save selected Test Cases from other Test Cases and
from Test Suites. This lets you create a new keyword that con-
tains the selected modules without having to manually find
them and reuse them.

1. Open the Test Case Editor or Test Suite Editor by double-

clicking on the Test Case or Test Suite you want to edit.

2. Select the Test Cases you want to save into the new Test
Case by single-clicking them. Use »CTRL« to select more
than one item.

3. Right-click in the editor and select:

Refactor → Save as new... .

4. When prompted, enter a name for the new Test Case.

5. A new Test Case will be created containing the Test Cases

you selected, with the data and component names they
used in the current editor.

6. The Test Case you just created is visible in the Test Case
Browser.

76 April 15, 2014 UserManual V8.0.00170

Tasks

Use this feature if you have created reusable Test Cases

that are correctly modularized, but you require them
again (e.g. prerequisites for another Test Case). If the
sequence of actions you require is a recurring logical se-
quence (e.g. enter username, enter password, then click
OK for a login dialog), then we strongly recommend us-
ing the Extract function ( → page 72) instead. This
will give you one reusable module, and therefore one
central place to make any changes should this sequence
change.

3.9.11 Reverting changes in an editor

You can revert an editor you are working in to the state of the
last save.

1. In the editor you are in, right-click and select:

Revert changes
from the context sensitive menu.

2. Confirm that you want to revert the changes when

prompted.

3. The editor will be reverted. Any changes you have made

since the last save will be lost.

3.10 Working with categories in the

browsers and editors
Categories let you group items together to be able to keep an
overview of your data and find things more easily. You can use
categories in the Test Case Browser, in the Test Suite Browser,
in the Central Test Data Editor and in the Object Mapping
Editor (see the section on object mapping for information on
categories in the Object Mapping Editor ( → page 139) ).

3.10.1 Creating a category

1. In the browser or editor, select:
New → Category from the context-sensitive menu.

UserManual V8.0.00170 April 15, 2014 77

 Functional Testing User Manual

2. Name the category when prompted.

3. Once you have a category, you can add items to it by drag

and drop, and also by double-clicking to add new items
(only in the browsers).

4. You can also nest categories in other categories.

5. You can do this either by dragging and dropping a cate-

gory into another category, or by right-clicking in an al-
ready present category and choosing the option to create
a new category.

3.10.2 Creating Test Cases, Test Suites and

Test Jobs in an existing category
Creating Test Cases within an already existing category:

1. To create a Test Case in an already existing category, select

the category in which you want to create the Test Case
with a single-click in the Test Case Browser.

2. Create a Test Case via the context-sensitive menu ( → page

80) .

3. You can also simply double-click on the category in which

you want to create the Test Case.

Creating Test Suites and Test Jobs within an already ex-

isting category:

1. To create a Test Suite or a Test Job in an already existing

category, select the category in which you want to create
the Test Suite or Test Job with a single-click in the Test Suite
Browser.

2. Create a Test Suite or Test Job via the context-sensitive

menu ( → page 125) .

3. To create a Test Suite, you can also simply double-click on

the category in which you want to create the Test Suite.

3.10.3 Adding comments to categories

You can add comments to categories in the Test Suite Browser
and Test Case Browser to add information on the purpose of
the category:

78 April 15, 2014 UserManual V8.0.00170

Tasks

1. In the browser, select the category you want to add a com-

ment to, or edit a comment on.

2. From the context-menu, select:

Edit comment

3. In the dialog that appears, enter the comment for this cat-
egoty and press ”OK”.

4. You will be able to see the comment in the Properties View

for this category, and as a tooltip (as long as the category
has no errors or warnings).

You can also add comments to Test Cases, and Test

Suites ( → page 71) as well as to the Project as a whole
( → page 32) .

UserManual V8.0.00170 April 15, 2014 79

 Functional Testing User Manual

3.11 Working with Test Cases

Test Cases are the ”building blocks” (keywords) for testing.
They can:

• contain other (referenced) Test Cases ( → page 68)

• contain Test Steps ( → page 132)

• be used in Test Suites ( → page 68)

• be used as Event Handlers ( → page 164)

3.11.1 Creating Test Cases

Most of the time spent writing tests will involve creating and
editing Test Cases.
To create a Test Case, you must have created or opened a
Project ( → page 29) .
The Test Case Browser must also be visible. If it is not visible,
change to the Functional Test Specification Perspective per-
spective and select:
Window → Show View → Test Case Browser .

You can also have multiple instances of the Test Case

Browser open ( → page 67) .

1. Create a Test Case by using the context-sensitive menu in

the Test Case Browser:
New → New Test Case .

You can also create Test Cases with a double-click on the

”Test Cases:” root entry or on a category in the Test Case
Browser.

2. A dialog to name the Test Case will appear (Figure 3.19

→ page 81 ). Because the testing approach is keyword-
driven, it is important to name Test Cases meaningfully –
you will be able to read your tests easily and quickly choose
which Test Case you need.

3. Click ”OK”.

80 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.19: New Test Case Dialog

4. This creates a new Test Case with that name in the Test
Case Browser Figure 3.20 → page 81 .

Figure 3.20: Test Case in Test Case Browser

Next steps
The next step is to add Test Cases from the library of Test
Cases to this Test Case ( → page 82) .
You can also:

• Reuse this Test Case to form other Test Cases ( → page

68)

• Edit its content in the Test Case Editor ( → page 68)

• Add this Test Case to a Test Suite to be executed ( → page

68)

UserManual V8.0.00170 April 15, 2014 81

 Functional Testing User Manual

• Use this Test Case as an Event Handler ( → page 164) .

3.11.2 Creating tests from the library of pre-

defined Test Cases
Everything you need to create tests is already available for you
in each Project. The library of Test Cases which appears au-
tomatically in each new Project contains all the actions sup-
ported for testing as well as some examples of more complex
keywords. For general information about the library, read the
section later on ( → page 83) . To learn how to use the library
to create tests, read the next section ( → page 82) .

3.11.2.1 Using the library to create tests

Creating tests with the ITE is really just a matter of:

• Deciding how to structure your tests (i.e. what keywords

to create and how to combine them).

• Choosing the Test Cases from the library (or from your own
set of Test Cases) that you need to create these keywords.

To use the Test Cases from the library, you will first need to
create a Test Case of your own ( → page 80) .

1. Open the Test Case Editor by double-clicking on the Test

Case you want to edit in the Test Case Browser.

2. In the Test Case Browser, browse to a Test Case that you

want to add. For help on finding your way around the
library, see the later section ( → page 84) .

3. You can add the Test Case by dragging and dropping from
the Test Case Browser to the Test Case Editor or you can
right click on the Test Case in the Test Case Editor and
select:
Reference Existing Test Case → to see a list of
all Test Cases that you can add to this Test Case.

You can filter in this dialog using the field at the top.
Use star * as a wild card.

82 April 15, 2014 UserManual V8.0.00170

Tasks

You can open the dialog to reference an existing Test

Case by pressing »ENTER« on a Test Case in the Test Case
Editor.

4. Once you have added the Test Case, you will need to enter
a component name in the Component Names View ( →
page 117) and you will need to enter data for the Test
Case in the Properties View ( → page 91) .

3.11.2.2 Information about the library

1. You can use a highly reusable library of Test Cases to spec-

ify tests.

2. The Projects containing the Test Case libraries are located

under:
examples/testcaseLibrary.

3. The Projects available are:

• unbound_modules_concrete
• unbound_modules_web
• unbound_modules_swt
• unbound_modules_rcp

4. These Projects contain reusable Test Cases which have

been created in advance so you do not have to specify
them yourself.

Refer to the chapter on Components, Actions, and Pa-

rameters ((→Reference Manual p. 21)) for information
on components, the actions they support, and their pa-
rameters.

5. The library is split into categories of actions on compo-

nents. To select something in your AUT, open the select
category and then open the category for the type of com-
ponent you want to select something from.

UserManual V8.0.00170 April 15, 2014 83

 Functional Testing User Manual

The names for these Test Cases all begin with ”ub”. This
means that they are unbound – they are not in any way
dependent on an AUT.

6. Each Test Case in the library contains one Test Step which
corresponds to the action in the Test Case name. The com-
ponent name is a placeholder, and the parameters have
been referenced so that you can enter your own data.

The unbound modules Projects which correspond to

your chosen Project toolkit are automatically imported
into the database and reused in your Project.

We do not recommend making changes to the installed

unbound module Projects, for compatibility reasons. If
you have Test Cases you want to reuse in other Projects,
we advise creating your own library Project.

3.11.2.3 Tips and tricks for using the Test Case library

The Test Cases in the library are organised into actions. In

the basic category, you will find the various actions offered
for testing. The complex category contains some example
keywords which are built up of more than one Test Case.
When specifying your tests, you need to find and choose
which actions you will need. This takes some practice, but
there are some hints which can help you:
High-Level Actions
During a test, high-level actions are executed. This means
that if you want to select something from a menu using the
menupath, for example, you need to look in the category:
Actions (basic)/Select/Menu Bar
and select the Test Case:
ub_mbr_selectEntry_byTextpath
The Test Case finds the menu, opens it, and clicks the item
you specify.

Abstract components
There are some actions which are executable on many differ-

84 April 15, 2014 UserManual V8.0.00170

Tasks

ent components. Clicks, for example can be executed on prat-

ically all components in the interface. You can also check text
on labels, combo boxes and text fields. Obviously, it makes
sense to specify your Test Cases as abstractly as possible so
that they can be reused in more places. This helps keep the
maintenance low later.
You will notice in the library that there is no Button cate-
gory under the Click category. Instead, you will find various
click actions specified for Graphics Component (grc). This is
because all components which support clicks belong to the
Graphics Component group.
In the same way, you will find the category Check/Component
with Text. You can use the check actions from this category
to check text on any component with text – buttons, text
fields, combo boxes, labels.

Parameters
Different actions require different data. Some Test Cases in
the library have been pre-configured with data to make test
specification easier (look in the category Input via Keyboard-
/Application/Key Combination for a long list).
Some actions let you choose whether you want to enter data
using an indexpath or a textpath. We recommend using the
textpath so that you are not dependent on the order of e.g.
menu entries or tabbed panes.
To make text-based parameters more robust, you can of-
ten choose an operator. You can choose between equals,
matches, simple match, not equals. Using matches lets you
use regular expressions so that you don’t have to hard-code
the whole text parameter.

3.11.3 Opening existing Test Cases

You can open an existing Test Case without having to select it
from the Test Case Browser using the Open Test Case dialog.

1. This dialog can be opened using the shortcut

»CTRL+SHIFT+T« or from the menu:
Edit → Open Test Case

2. In the dialog, you can search for a Test Case or Test Cases
in the tree or using the filter ( → page 215) .

3. Select the Test Cases you want to add, and click ”OK”.

UserManual V8.0.00170 April 15, 2014 85

 Functional Testing User Manual

4. The selected Test Cases will be opened in indidivual Test

Case editors.

You can use this option to open a Test Case even if a

filter is active in the Test Case Browser.

3.11.4 Editing Test Cases

From the Test Case Editor, you can edit a Test Case. You can:

• add other Test Cases ( → page 68) .

• add and edit Test Steps ( → page 132) .

• rename the Test Case ( → page 65) or the Test Cases it

contains ( → page 70) .

• add a comment to the Test Case ( → page 71) .

• add, edit or translate data for the Test Case ( → page 112)
.

• extract Test Cases from within this Test Case to make

reusable modules ( → page 72) .

• deactivate specific Test Cases in this Test Case so they are

ignored during execution ( → page 72) .

• replace one or more Test Cases in it with another Test Case

( → page 73) .

3.11.5 Adding and inserting new Test Cases

to a Test Case
1. Open the Test Case Editor by double-clicking on the Test
Case you want to edit in the Test Case Browser.

2. From the context-sensitive menu, select:

Add → New Test Case
(This places the Test Case after any other items in the Test
Case Editor.) or
Insert → New Test Case
(This places the Test Case above the currently selected
item in the Test Case Editor.)

86 April 15, 2014 UserManual V8.0.00170

Tasks

3. In the dialog that appears, enter a meaningful name for

the new Test Case.
4. Click ”OK”.
5. The Test Case appears in the Test Case Editor in the parent
Test Case and also appears in the Test Case Browser. The
Test Case is marked with a small arrow to show that it is
reused here. The name of the Test Case is contained in
angled brackets (< >) to show that it is the same name
that you used when you specified the Test Case.
6. Save the changes in the editor.

3.11.6 Moving Test Cases to external Projects

I
If you are reusing a Project or Projects in your currently opened
Project ( → page 36) , you can move Test Cases you create to
these reused Projects to make them a part of that Project.
This lets you add useful Test Cases to external libraries to be
reused in other Projects.
1. In the Test Case Browser, select the Test Case, Test Cases
or categories you want to move to an external Project that
you are currently reusing in the open Project.
2. Right click on the selected items and select:
Move to external Project
from the context-sensitive menu.
3. From the dialog which appears, select which reused Project
to move them to.
4. The items you selected will appear in the blue colored cat-
egory of the reused Project you selected and will disappear
from their original place.
5. The structure of your Project stays the same – the moved
Test Cases are not deleted from places where you have
reused them, for example.

If you move Test Cases containing referenced Test Cases

from other Projects, make sure that the Project the Test
Cases are dependent on is also reused in your external
Project.

UserManual V8.0.00170 April 15, 2014 87

 Functional Testing User Manual

3.11.7 Replacing a specific Test Case at places

where it has been reused
If you have reused a Test Case at multiple places in your
Project, and later create a new Test Case that should replace
it, then you can perform a mass replace via the Search Re-
sult View. If you just want to replace one single place where a
Test Case has been reused, then you can either select that Test
Case in the Search Result View or use the in-editor replace (
→ page 73) .

In order to perform a mass replace, all Test Cases to be

changed must not be in use by anyone else using the
Project – you should ensure that this is the case before
performing the replace, otherwise the replace cannot be
carried out. You should also be aware before perform-
ing this action that it cannot be undone.

1. Search for all places where the Test Case you want to re-
place is used e.g. Show where used ( → page 208) .

2. In the Search Result View, you will see all places where
the selected Test Case is reused in this Project, including
in other Test Cases, in Test Suites and anywhere you have
used the Test Case as an Event Handler. Select all entries,
or just the Test Case references you want to replace with a
new Test Case reference.

You will only be able to perform the replace if all se-

lected Test Case references use the same original Test
Case. The context-menu entry will be disabled if the
Project is protected, or any of the selected Test Cases
are missing (e.g. from reused Projects)
.

3. From the context menu, select:

Replace with another Test Case

4. The first page of a wizard will appear. Here, you can

choose the Test Case you want to use as a replacement
at the places you selected. It is a good idea to select a Test
Case that ”fits well” (in terms of any component names it

88 April 15, 2014 UserManual V8.0.00170

Tasks

propagates and parameters it references) to the Test Case

you are replacing. You will be able to map any compatible
components and parameter names in the next steps.

5. Press ”Next” to continue to the next page of the wizard.

6. On this page, you can match any component names prop-

agated ( → page 119) from the newly selected Test Case
to already existing propagated component names from the
old Test Case. On the left-hand side, you can see names
that are propagated from the newly chosen Test Case. On
the right-hand side, you can:

• match the new names to existing names if there are

compatible names available in the existing Test Case.
The information for names you match in this way will be
transferred from the existing Test Case to the new Test
Case when the replacement occurs. Any new names
entered, or further propagations at the places of reuse,
will also be transferred. This is the best way of ensuring
that your Project structure is the same after the replace.
• choose to leave any combo boxes empty. In this case,
no match for that component name will take place, and
the new component name will be used.
• see if there are no names available, either because there
is no compatible type for matching in the existing Test
Case, or because the existing Test Case had no propa-
gated component names. In such cases, the new com-
ponent name will be used.

For any non-matched (or non-matchable) component

names, the new names from the new Test Case will be
used. This may result in incomplete object mapping for
your tests.

7. Once you have matched any component names, press

”Next” to continue to the next page of the wizard.

8. On this page, you can match any referenced parameter

names ( → page 92) from the newly selected Test Case to
already existing referenced parameter names from the old
Test Case. On the left-hand side, you can see parameters
that are referenced from the newly chosen Test Case. On
the right-hand side you can:

UserManual V8.0.00170 April 15, 2014 89

 Functional Testing User Manual

• match the new parameter to existing parameters if there

are compatible types available in the existing Test Case.
The data for any parameters you match in this way will
be transferred from the existing Test Case to the new
Test Case when the replacement occurs. Any test data
entered locally, any test data referenced from the origi-
nal specification, and any central test data sets or Excel
tables used, will also be transferred. This is the best way
of ensuring that your Project structure is the same after
the replace.
• choose to leave any combo boxes empty. In this case,
no match for that parameter will take place, and the
new parameter will be used.
• see if there are no names available, either because there
is no compatible type for matching in the existing Test
Case, or because the existing Test Case had no refer-
enced parameters. In such cases, the new parameter
will be used after the replace.

For any non-matched (or non-matchable) parameters,

the new parameters from the new Test Case will be
used. This may result in incomplete test data for your
tests.

9. Once you have finished matching the parameters, press

”Finish” to perform the replace.

The Test Case reference names and any comments that

were used for the original Test Case references, will be
transferred to each new Test Case reference. If the orig-
inal Test Case reference was commented out, the re-
placement Test Case reference will be as well. If you
had used the original Test Case as an Event Handler, the
Event Handler details will also be transferred.

90 April 15, 2014 UserManual V8.0.00170

Tasks

3.12 Working with test data

3.12.1 Data types and entering data for Test

Cases
Most actions in the library require one or more parameters
(e.g. how often to click, what text to enter). Once you have
added Test Cases or Test Steps to a Test Case, you will see
which parameters are required by this action in the Properties
View.

You can also enter data sets in the Data Sets View ( →
page 112) and you can create central data sets to be
reused throughout the Project ( → page 103) .

You can be very flexible with data, so you have a choice about
what to enter in the Properties View:

1. Concrete values ( → page 91) .

2. References ( → page 92) .

3. Variables ( → page 94) .

4. Functions ( → page 97) .

5. A mixture of the above ( → page 101) .

6. An Excel file ( → page 109) .

7. A reference to a central data set ( → page 103) .

3.12.2 Entering concrete values as data in

Test Cases
• In the Properties View for a Test Case, you can enter a
concrete value as a parameter e.g. Hello.

• This means that this particular parameter cannot be

changed when you reuse its parent Test Case.

• Enter concrete values for things that you expect to stay the
same, like your choice of operator (i.e. matches, equals) or
the click count. Deciding which data not to parametrize is
an important decision is test creation.

UserManual V8.0.00170 April 15, 2014 91

 Functional Testing User Manual

Press »CTRL+SPACE« to get content assist in the Proper-

ties View for certain parameters.

• Depending on your test structure, you may want to use

concrete values for all the parameters in a keyword. If,
for example, you have a keyword to open the ”New Cate-
gory” dialog from a menu, you will probably want to write
the menupath as a concrete value. After all, this Test Case
is designed to open this specific dialog, so the menupath
is fixed.

Any concrete values you enter into a Test Case are valid
whenever you reuse this Test Case. If you change the
concrete values in the original Test Case, all of the places
you have reused it will change as well.

3.12.3 Using references for data in Test Cases

• If there are parameters in a Test Case that you want to
change when you reuse it, you can enter a reference
instead of a concrete value. Deciding which data to
parametrize is an important decision in test creation.

Press »CTRL+SPACE« to get content assist in the Proper-

ties View for certain parameters.

• To enter a reference for a parameter, in the Properties

View, enter a reference name, preceded by an equals sign:
=REF_NAME.

Reference names may only consist of letters, numbers

and underscores. You cannot use spaces in reference
names.

• Press »ENTER«. A yellow arrow will appear next to the pa-

reference symbol rameter field in the Properties View.

92 April 15, 2014 UserManual V8.0.00170

Tasks

It helps to choose names that are meaningful so that

you know what sort of data to enter later. Instead of
=TEXT, you could use =CATEGORY_NAME, for example.

• You will see that the reference becomes a parameter of the

parent Test Case. It appears in the Test Case Browser next
to the parent Test Case in square brackets.

• You will be able to enter data for this parameter when you
reuse the Test Case.

You can enter data for it now if you want to – this is

essentially like having default data. They appear when
you reuse the Test Case, but you can overwrite them (
→ page 114) .

For information on editing and deleting referenced parame-

ters from Test Cases, see the following section ( → page 93)
.

3.12.4 Using the edit parameters dialog to

add, edit and delete references
You can use the edit parameters dialog to add, edit and delete
parameters for a Test Case or a central test data set. This sec-
tion is concerned with using the dialog for editing parameters
in a Test Case. For editing parameters for a central test data
set, see the section later ( → page 103) .
To edit the parameters for a Test Case:

1. Open the edit parameters dialog by right-clicking on

the root node in the Test Case Editor and selecting
Edit parameters from the context-sensitive menu.

2. In the dialog, you can see any parameters you have refer-
enced for this Test Case, and what type of parameters they
are.

3. From the dialog, you can add new parameters to the Test
Case, edit existing parameters, and delete parameters. You
can also change the order the parameters appear in.

UserManual V8.0.00170 April 15, 2014 93

 Functional Testing User Manual

4. Use the lock option to lock the parameters for this Test
Case. This means that you cannot delete them, rename
them or remove them in this Test Case.

In the Properties View, you can only add references for

parameters. To edit or delete references, you must use
this dialog.
.

3.12.5 Using variables as data for Test Cases

• You can store values from the AUT during a test to use
later in the test.

• Some actions (e.g. store value) let you save a value as

a variable. You specify the name of the variable, e.g.
USERNAME.

• When you want to use the variable, you can enter it as a

parameter by preceding it with a dollar sign: $USERNAME.

For more information on using variables, see the following

sections:

• Working with variables in tests ( → page 94) .

• Working with system variables ( → page 95) .

• Working with the pre-defined variables ( → page 96) .

3.12.5.1 Reading and using values (variables) from the

AUT

You can store values read from the AUT to use as data in other
Test Cases.

1. Use one of the store value actions on the various compo-

nents to reads a value from a component in the AUT.

You can also use the store value action on the applica-
tion component to store a value you enter.

94 April 15, 2014 UserManual V8.0.00170

Tasks

2. In the parameter field, enter a name for this variable (e.g.

USERNAME).

Variable names may only contain letters, numbers and

underscores

3. When you want to use this value as data for a parameter,

enter the variable name preceded by a dollar sign ($) as the
parameter value (e.g. $USERNAME).
Bear in mind that the variable has to be stored before it
can be used as a parameter value.

Read the following sections for more information on:

• Using system variables in tests ( → page 95) .
• Using the pre-defined variables in tests ( → page 96)

3.12.5.2 Using environment variables in tests

You can add variables to your operating system, which can be

used in your tests.
You will need to set environment variables which have the
form:

TEST_UDV_<variablename>

To use the variable in your tests, enter the variable name (ev-
erything after the underscore) preceded by a dollar sign. Do
not enter the ”TEST_UDV_” part.

After entering or changing an environment variable,

you will need to restart the ITE. Environment variables
for the ITE (i.e. for the test) are only read from the ma-
chine on which the ITE is running, not from the machine
where the AUT Agent is running.

Your system administrator will be able to help you with

operating-system specific ways of setting environment vari-
ables.
Useful variables These variables can be used as environment
variables on your machine or as JVM properties in your AUT
configuration.

UserManual V8.0.00170 April 15, 2014 95

 Functional Testing User Manual

TEST_AUT_KEEP_ALIVE_DELAY This can be useful if you

are using the action to prepare for termination. You can
use this variable to configure (in millseconds) how long the
AUT should be ”kept alive” after the termination com-
mand (e.g. pressing ”Exit” in order for the correct com-
munication between the ITE and the AUT to occur. The
value is set to 2000ms per default.

TEST_AUT_POST_DEREGISTRATION_DELAY This can be

useful if you are using the action synchronize shutdown
and re-start. You can use this variable to configure (in mil-
liseconds) how long your AUT requires after closing to per-
form tasks such as saving resources and settings.

3.12.5.3 Using the pre-defined test execution variables

1. There are pre-defined test execution variables which you

can use in your tests.

2. The following variables are automatically initialized when

executing a Test Suite:

TEST_TESTSUITE: The Test Suite name.

TEST_USERNAME: The account name you are logged
into your computer under.
TEST_DBUSERNAME: The database user.
TEST_AUTAGENT: The hostname for the AUT Agent the
test is running on.
TEST_PORTNUMBER: The port number for the AUT
Agent the test is running on.
TEST_AUT: The AUT name.
TEST_AUTCONFIG: The AUT configuration name.
TEST_CLIENTVERSION: The version of the ITE you are us-
ing.
TEST_LANGUAGE: The language the AUT and the test
are running in, e.g en_US.

3. To use the value of one of these variables in your test, en-

ter:
${VARIABLE_NAME}
as the parameter value.

96 April 15, 2014 UserManual V8.0.00170

Tasks

For a list of language codes, see the section in the refer-

ence manual ((→Reference Manual p. 387)) for details.

3.12.6 Using functions as data for Test Cases

You can calculate specific values without to enter the results
yourself using functions. There are specific functions that
work out-of-the-box, and additional functions can be added
as well.

3.12.6.1 Syntax for functions

The sign used to introduce a function is the question mark: ?

(without quotes).
After the sign, you must enter the name of the function fol-
lowed by the arguments the function requires, e.g.:
?add(arg1,arg2)
The arguments are separated by commas and are placed
within round brackets.

3.12.6.2 Pre-defined functions

The following functions are available directly in the ITE:

Mathematical functions
The following functions give their results as decimal numbers,
e.g. 1.0, 1.2 etc.

add Adds 0 or more numbers to 0, e.g.: ?add(1,2).

sub Subtracts the second number from the first:

?sub(3,2).
This function only accepts two numbers.

mult Multiplies 0 or more numbers by 1 e.g.: ?mult(2,4).

div Divides the first number by the second: ?div(2,1).

This function only accepts two numbers.

trunc Takes two arguments, the decimal to be truncated and

the precision (as an integer) to truncate the decimal to.
Use 0 to cut off the number to no decimal places (i.e. to
receive a plain integer), and use 1 to cut off the decimal to

UserManual V8.0.00170 April 15, 2014 97

 Functional Testing User Manual

one decimal place etc: ?trunc(2.396,0) gives 2 and

?trunc(2.789,1) gives 2.7.

round Takes two arguments, the decimal to be rounded and

the precision (as an integer) to round to. This function
uses half-up rounding to round the number so that if the
final decimal place after rounding is 5 or higher, the final
number will be incremented by 1 e.g.: ?round(2.56,1)
gives 2.6. If the final number after rounding is 4 or less,
there is no incrementation, eg. ?round(2.43,1) gives
2.4.

It is currently only possible to use numbers formatted

with the decimal mark period or fullstop (.). Thousands
separators may not be used. For example, 1.5 is ac-
cepted, but 1,5 is not. 1000 can be entered but 1,000
cannot. Entering 1.000 is equivalent to entering 1.

Use single quotes around negative numbers, e.g. ’-0.5’.

Date functions

now Saves the current date in an internal format that can be

used as a basis for the formatDate and modifyDate func-
tions. This function takes no arguments: ?now().

formatDate Puts a date into a specific format.

The date to be formatted is entered as the first
argument, followed by the format string e.g.
?formatDate(?now(), dd-MM-yyyy). The for-
mats that can used here are the formats from the
SimpleDateFormat class in Java.

parseDate Reads a value that is a date and parses it into

an internal format based on the format string given (i.e.
how the date should be understood). The first argu-
ment is the date, and the second is the format string
?parseDate(2011.06.25,yyyy.MM.dd). This func-
tion should be used when reading and working with dates
shown in the AUT.

modifyDate This function can add days (d), months (M), and
years (y) to a given date. The date must first be parsed (i.e.

98 April 15, 2014 UserManual V8.0.00170

Tasks

using parseDate) so that the correct internal format is used.

This function takes two arguments: the first is the date to
modify, and the second is the modification to perform, e.g.
?modifyDate(?now(),1d). Additions are entered as
positive integers (but without a plus sign, e.g. 1d, 1M, 1y)
and subtractions are entered as negative integers, e.g. -1d,
-1M, -1y.

If you want to use the result of a date function as a part

of your test data (i.e. to enter or check), then you will
most likely need to use formatDate on any date modifi-
cations you have performed.

Test functions

getNodeAttribute Reads the value on the node (e.g. Test

Case, Test Step) on which this function is resolved, and
uses this as the data for the Test Step. It has two possible
arguments, name reads the name of the node, and com-
ment reads the comment on the node. If the comment is
empty, the value used is null. If you have overwritten ei-
ther the name or the comment at this place of reuse, then
these new details are used.

getCentralTestDataSetValue Use this function to access a

value saved in a central data set. This lets you combine
values that you have defined centrally with values that you
use locally, or lets you combine values from different cen-
tral data sets in your test. It locates a single cell in a spe-
cific central data set based on a value in a column that
you define as a key, and a column in which to search for
the required value. It requires four arguments: the name
of the central data set to search in, the name of the col-
umn which you wish to use as a ”key” (you can name the
column KEY if you require), the value in the key column
(to specify the line), and the column in which the required
data cell is located.

Example of the getCentralTestDataSetValue function

The function to retrieve data from a central data set can be ex-
emplified using this example central data set, which is named
Customer:

UserManual V8.0.00170 April 15, 2014 99

 Functional Testing User Manual

CUSTOMER_TYPE CUSTOMER_NAME
NormalUser Bob Normal
SuperUser Alice Super
SupportUser John Support
To select a customer name using the customer type, you
should enter:

?getCentralTestDataSetValue
(Customer,CUSTOMER_TYPE,SuperUser,CUSTOMER_NAME)

This will look in the central data set called Customer, locate
the value SuperUser in the CUSTOMER_TYPE column, and use
that line to choose the cell in the CUSTOMER_NAME column
– Alice Super.
Wrapped functions from other libraries
You can also use the following functions in your tests. For full
documentation on them, please refer to the respective library.

randomInt(exclusive maximum value) Use this function

to generate a random integer up to but not includ-
ing the value you specify. The function is from
org.apache.commons.lang.math.RandomUtils

replaceAll(string,regular expression,replacement) Use

this function to replace all of the parts of a string you
specify with something else. The string to perform the
replacement on is entered as the string, the part(s) of the
string to replace are defined by the regular expression, and
the string to replace it with is given as the replacement.
This function is from java.util.regex.

uuid() This function generates a universal unique identifier.

The function is from java.util.UUID.

base64Encode(string) This function encodes a

string to base 64. The function is from
org.apache.commons.codec.binary.Base64.

base64Decode(string) This function decodes a

string from base 64. The function is from
org.apache.commons.codec.binary.Base64.

3.12.6.3 Embedding functions in other functions

Functions can be added as arguments to other functions. If,

for example, you want to use the result of a subtraction as

100 April 15, 2014 UserManual V8.0.00170

Tasks

the first argument of your addition, you could write it like

this:
?add(?sub(2,1),1)
Results in 1.0 + 1, i.e. 1.0

3.12.6.4 Useful examples for functions

Especially when it comes to the date functions, it is often nec-

essary to use multiple functions embedded within each other.

?formatDate(?now(), dd’ MMMM ’yyyy) e.g. 29 Febru-

ary 2012

?formatDate(?now(), dd’ MMM ’yyyy) e.g. 29 Feb 2012

?formatDate(?now(), dd-MMM-yyyy) e.g. 29-Feb-2012

?formatDate(?now(), dd.MM.yyyy) e.g. 29.02.2012

?formatDate(?now(), dd/MM/yyyy) e.g. 29/02/2012

A more complex example involving embedded functions is

e.g.:

?formatDate(?modifyDate(?parseDate
(22.2.2012, dd.MM.yyyy),-1d),dd.MM.yy)
This function will parse the date 22.2.2012 into an in-
ternal format, subtract one day and then format it as a
dd.MM.yy, in this case: 21.2.12.

3.12.6.5 Adding your own functions

You can also add your own functions using an extension

point. This is described in the Extension Manual.

3.12.7 Concatenating (combining) parame-

ters
The ITE lets you use various different types of parameter:

• Concrete values ( → page 91) .

• Referenced parameters ( → page 92) .

• Variables ( → page 94) .

UserManual V8.0.00170 April 15, 2014 101

 Functional Testing User Manual

• Functions ( → page 97) .

You can use these parameters separately, or you can combine
them to create a parameter value. This is useful if a value you
want to enter or check consists of parts that change and parts
that stay the same.
To combine different types of parameter to make one value,
you must write them in a specific way:
1. Referenced parameters must be written with curly brackets
around the reference name:
={REF_NAME}
2. Variable names must also be written with curly brackets
around them:
${VAR_NAME}
3. Concrete values are written as normal.
4. For example, you can build a data string that contains all
four types of data:
test_={PROJECTNAME}_${CUSTOMERNUMBER}_?now()

3.12.8 Viewing and changing data sources

for Test Cases
The Properties View shows the currently used data source for
each Test Case. The following data sources are available:
Referenced Test Case
The data have come directly from the original specification of
this Test Case. If the data in the referenced Test Case change,
then the changes will also take effect here.
Local Test Case
The data being used were entered for this Test Case. Any
changes made in the original specifiation of the Test Case will
not affect the data here.
You can change from local to referenced test data using the
combo box to reset the default value from the referenced Test
Case.
Central test data set
The data have come from a central test data set ( → page
103) .
Excel data file
An Excel file has been entered as the data source ( → page
109)

102 April 15, 2014 UserManual V8.0.00170

Tasks

3.12.8.1 Changing the data source for a Test Case

• The data source changes automatically to reflect the new

data source when you enter an Excel file, a Central Test
Data Set or when you enter new data in the Test Case.

• To change the data set back to the original specification

data (referenced Test Case), first remove all Excel files or
Central Test Data Sets, then change the data source in the
combo box back to referenced Test Case.

3.12.9 Using central data sets

You can create and manage central test data sets for a Project
which can be reused in Test Cases.

3.12.9.1 Creating and editing central test data sets

To create a central test data set:

1. Open the Central Test Data Editor by clicking the ”Central

Test Data Editor” button on the toolbar or selecting:
Open with → Central Test Data Editor
from the Test Suite Browser.

2. In the Central Test Data Editor, select:

Add new Data Set
from the context-sensitive menu or press »INSERT«.

3. In the dialog that appears, enter a name for the new data
set and click ”OK”.

4. The new data set appears in the Central Test Data Editor.
You can now add parameters to the data set ( → page
104) .

5. You can rename the data set by pressing»F2« or selecting:

Rename
from the context sensitive menu.

6. You can categorize your central data sets using the Add
category function from the context-sensitive menu ( →
page 77) .

UserManual V8.0.00170 April 15, 2014 103

 Functional Testing User Manual

3.12.9.2 Deleting central test data sets

You can delete a central test data set if the data set has not
yet been reused (referenced) in a Test Case ( → page 105) .

1. Select:
Delete
from the context-sensitive menu or press »DELETE«.

2. A dialog will appear if the data set has been reused and
cannot be deleted.

3. You can use the search ( → page 210) to show where the
data set has been used.

3.12.9.3 Adding and modifying parameters for central

test data sets

Once you have created a central test data set ( → page 103) ,
you can add parameters to the data set using the Edit Param-
eters dialog.

1. Open the edit parameters dialog for the central data set
by double-clicking on the data set in the Central Test Data
Editor. You can also select Edit parameters from the
context-sensitive menu.

2. In the Edit Parameters dialog, you can see any parameters

you have already added for this data set, and what type of
parameters they are.

3. Use the ”Add” button to create a new parameter for the

data set.

4. Enter a name for the parameter and select the type of pa-
rameter it should be (e.g. String, Integer, ...). The type of
parameter it should be will depend on which actions are
using it. A list of actions and their parameters (and types)
is available in the reference manual ((→Reference Manual
p. 21)).

Names for referenced parameters may only consist of

letters, numbers and underscores. You cannot use
spaces.

104 April 15, 2014 UserManual V8.0.00170

Tasks

5. You can also change the order the parameters appear in,
edit their types and names, and delete them completely
using this dialog.

3.12.9.4 Entering data for central test data sets

Once you have created a central test data set ( → page 103)
and have added parameters to the central test data set ( →
page 104) then you can enter data for these parameters in
the Data Sets View.
To enter data sets for a central test data set:

1. Open the Central Test Data Editor by clicking the ”Central

Test Data Editor” on the toolbar or selecting:
Open with → Central Test Data Editor
from the Test Suite Browser.

2. In the editor, single-click the central test data set you want
to add data to.

3. In the Data Sets View, make sure the language in the

combo box on the right is the right language for your data.

4. Select ”Add” to add a row.

5. Enter the values for the parameters in the row.

You cannot add referenced parameters (i.e. reference

names preceded by the equals sign) in the Data Sets
View for a central test data set.

6. Use the buttons in the Data Sets View to add more rows,
delete rows and insert rows above the currently selected
row.

3.12.9.5 Reusing central test data sets in Test Cases

You can reuse a central test data set in a Test Case to pro-
vide the concrete data for the parameters required by the Test
Case.

1. In the Properties View for the Test Case, enter the name of
the central test data set you want to use in the Central Test
Data Set field.

UserManual V8.0.00170 April 15, 2014 105

 Functional Testing User Manual

Press »CTRL+SPACE« to see a list of possible data sets for

this Test Case. You will only be shown data sets that
contain the correct parameters with the correct types.

2. When you have entered a central test data set, then the
Properties View shows central test data set as the data
type. You will see the data from the central test data set in
read-only form in the Data Sets View.

If data is missing from the central test data set, you will
receive the error that test data is incomplete for any Test
Suites this Test Case is used in.

3. You can delete the central test data set used by removing
it from the central test data set field. The data type reverts
to local data. For more information on the data sources,
see the earlier section ( → page 102) .

You can use central test data sets that contain

more parameters than your Test Case. For ex-
ample, if your Test Case requires the parameters
NAME, ADDRESS and your central test data set contains
NAME, ADDRESS, POSTCODE, you can still use the cen-
tral test data set.

3.12.9.6 Importing Excel files as central test data

If you have existing Excel files that you want to convert into
central test data, then you can import them via the Central
Test Data Editor:

1. In the Central Test Data Editor, right-click and select

Import from the context-sensitive menu.

2. In the dialog that appears, browse to the directory contain-

ing your Excel file(s).

3. Either select the whole directory (if it contains all Excel files)
on the left, or select the individual Excel files on the right.

106 April 15, 2014 UserManual V8.0.00170

Tasks

4. Click ”Finish” to start the import.

Your Excel files must contain the correct amount and

type of Project languages.

3.12.9.7 Changing the column used in a central test

data set for multiple Test Cases

If you have used a central test data set in multiple Test Cases
and later realize that you have two columns in the central
test data set that contain the same information, then you can
change all Test Cases that use this central test data set to just
use one column. Once you have done this, you can remove
the unnecessary column from the central test data set.

In order to perform this action, all Test Cases to be

changed must not be in use by anyone else using the
Project – you should ensure that this is the case before
performing the action, otherwise the action cannot be
carried out.

1. Search for all places where the central test data set whose
column usage you want to change is used. Use Show
where used on the central test data set to see all places
( → page 210) .

2. In the Search Result View, you will see all places where
the selected central test data set is reused in this Project,
including any original specifications of Test Cases that use
it, and any reused Test Cases that use it (as Test Cases or
as Event Handlers. We recommend selecting all entries to
perform the action, otherwise you may have incomplete
test data after only changing a subset.

3. You will only be able to perform the changes if:

• All the selected Test Cases use the same central test data
set.
• All the selected Test Cases have their original specifica-
tion in this Project, i.e. you do not have a Test Case from
a reused Project that uses the central test data set in this
Project.

UserManual V8.0.00170 April 15, 2014 107

 Functional Testing User Manual

• The Project is not protected.

• The Test Cases you have selected are present (i.e. they
are not missing from e.g. reused Projects.
• None of the selected Test Cases uses two different cen-
tral test data sets (e.g. one central test data set on the
originally specified Test Case, and another one at a place
where it is reused).
• The selected Test Cases have at least one referenced pa-
rameter and at least one of the referenced parameters
has the same type as another parameter in the central
test data set.
4. If the Project is protected, or Test Cases are missing, the
context-menu entry will be disabled. If any of the other
prerequisites are not fulfilled, you will see an information
dialog that lets you automatically deselect any invalid Test
Cases.
5. From the context menu, select:
Change central test data set column usage

6. In the dialog that appears, you can select a parameter to

change on the left-hand side, and the column to change it
to on the right-hand side. You can only change the usage
of columns whose types are the same. If you have e.g.
TEXT1 (string) and TEXT2 (string) in your central test data
set and Test Cases, but you only require TEXT1, then select
TEXT2 on the left-hand side and TEXT1 on the right hand
side.
7. Click ”Finish” to perform the action.
8. All selected Test Cases will be altered to use the newly cho-
sen column in place of the previously used column.
9. If the newly chosen column was already used in one or
more of the selected Test Cases, then all places within the
Test Case that referenced the old column are changed to
reference the newly chosen column. Using the example
from above, all places where TEXT2 was referenced in the
selected Test Case will be changed to TEXT1. The changed
name remains at the interface of the Test Case; TEXT2 is
not deleted from the Test Case, but it is no longer used. If
the newly chosen column was not yet used in one or more
of the selected Test Cases, the old parameter name of the
Test Case is renamed to the newly chosen column.

108 April 15, 2014 UserManual V8.0.00170

Tasks

3.12.10 Using an Excel file as an external data

source
In the Properties View, you can add Excel files as a data source
to Test Cases which contain parameters referenced from the
Test Cases or Test Steps they contain.

The addition of data via Excel is discouraged, because

any problems with the data can only be found once the
test is running. We recommend using the central test
data sets in the ITE to manage data within the Project (
→ page 103) .

1. Navigate to the Properties View for the Test Case you want
to add the Excel file to.
2. Enter the path to the Excel file in the Excel data file field.
The path to the Excel file can be absolute or relative (if you
have specified a data files path ( → page 167) ).

The Excel file must be configured in a specific way in.

order it to be read ( → page 110)

3. If you reuse this Test Case, the Excel file you enter will be
reused along with the Test Case. When you reuse the Test
Case, you can choose whether you leave this file or change
it for another one.

If you store your Excel files in your workspace, you will

be able to open these directly in the ITE from the navi-
gator view using the in-place editor.

4. A Test Case with an Excel file as data is marked with a small

Excel icon in the browsers to help you find it more easily
later.

Please note that the Excel file is read at the start of the
test execution. Any changes to the file after this will
not affect the test data. For information on using the
date function in Excel, see the section later ( → page
111) .

UserManual V8.0.00170 April 15, 2014 109

 Functional Testing User Manual

3.12.10.1 Configuring the Excel file

• The worksheet in Excel must be named with the language

code for the language your data are in. See the Reference
Manual ((→Reference Manual p. 387)) for a list of lan-
guage codes.
For example, if the data of your first sheet are for French,
then name the first sheet: fr_FR (Figure 3.21 → page
110 ).

Figure 3.21: Example Excel Table

You can create sheets for every language you need. Make
sure that each sheet is named with the language code.
The ITE reads the sheet which corresponds to the working
language when the test is being executed.

• Name the top cell of each column with a parameter name

from your Test Case.
For example, if you entered the reference ”=VALUE1”,
then you must enter VALUE1 in the top cell of the column
which will contain data for that parameter.

110 April 15, 2014 UserManual V8.0.00170

Tasks

Values are case sensitive.

• Make sure that all the parameters for your Test Case have
a column.

• Do not leave any gaps in the table.

• You must have an entry for each parameter used in the

Test Case.

• You can then fill in the values or formulae you want to use
for these parameters. Each row in the table represents one
set of data for the parameters used.

We recommend that you format cells as text before

adding the test data. This ensures that Excel’s number
formatting won’t modify the test data in unexpected
and undesirable ways. Especially for the boolean val-
uestrue and false, make sure you format the column as
text.

• If your Excel table contains data which change from day-

to-day, then make sure you open the file before starting
your test. Otherwise, the data from the last-opened state
will be used.

If you store your Excel files in your workspace, you will

be able to open these directly in the ITE from the navi-
gator view using the in-place editor.

• See the section later on using the today function in Excel

to get the current date ( → page 111) .

• Excel files may not contain autofilters in any of the work-

sheets to be used as data sources. Remove any filters from
all your Excel sheets before running a test.

3.12.10.2 Using the =TODAY() function in Excel

1. Because Excel stores the ”=today()” function as a six-digit

number, you must use a particular process to use this func-
tion to check a date as part of a test.

UserManual V8.0.00170 April 15, 2014 111

 Functional Testing User Manual

2. Enter the function =today() in a a different sheet to the

one you are using for your data sets. You can enter it in
the same sheet if you want to, but make sure that it has
its own column. It must not be in one of the columns you
will use as a data set.

3. For example, your =today() function is in sheet one, cell

G4.

4. You want your date to appear as dd.mm.yyyy.

5. In the column for your data set, enter the following for-
mula:

=text(Sheet1!G4, ”dd.mm.yyyy”)

6. This will mean that the date will be treated as it appears

with Excel.

If you are using the =today() function, don’t forget to

open the Excel file before starting your test. Otherwise,
the data from the last-opened state will be used.

If you store your Excel files in your workspace, you will

be able to open these directly in the ITE from the navi-
gator view using the in-place editor.

3.12.11 Using the Data Sets View to enter

data loops and to translate data
The Data Sets View lets you do three things:

• Enter multiple data sets for a parameter from a Test Case

( → page 113) .

• Enter data sets for a central test data set ( → page 105) .

• Translate your parameter values into other languages ( →

page 113) .

You can also create central test data sets for your Project
to reuse in Test Cases ( → page 103) .

112 April 15, 2014 UserManual V8.0.00170

Tasks

3.12.11.1 Data Sets View: adding multiple data sets to

a Test Case

If your Test Case has parameters which have been referenced

from the Test Cases and Test Steps it contains, you can enter
data sets in the Data Sets View.
This means that the Test Case will loop and be executed for
each set of data you enter.
To enter data sets for a Test Case:

1. Open the Test Case Editor or Test Suite Editor by double-

clicking on the Test Case or Test Suite you want to edit in
the browser.

2. In the editor, single-click the Test Case you want to add

data to.

3. In the Data Sets View, make sure the language in the

combo box on the right is the right language for your data.

4. Select ”Add” to add a row.

5. Enter the values for the parameters in the row.

You can also add references in the Data Sets View if you
want to specify the concrete values for your data sets
when you reuse this Test Case.

6. Use the buttons in the Data Sets View to add more rows,
delete rows (if no row is selected, the last row is deleted)
and insert rows above the currently selected row.

3.12.11.2 Data Sets View: translating test data

You can add data for other languages supported by your AUT
by changing the language in the combo box in the Data Sets
View.

You can add supported languages in the Project proper-

ties dialog ( → page 32) .

The other combo boxes are there to help you see the Data
Sets View in different ways. You can see all the data for one
parameter, for one data set or for one language.

UserManual V8.0.00170 April 15, 2014 113

 Functional Testing User Manual

3.12.12 Special parameters: empty strings

and the escape character
Entering empty strings as parameters
If you want the parameter you enter to be an empty string
(i.e. nothing), use two single quote marks: ”

You can use this with the equals, matches or simple match
operators.
You can also use ’^$’ or ’^\s*$’ with the operator matches
to check that a text area is empty.
You can also use ’^$’ with the operator matches to check that
a text area is empty.

If a component looks empty, but entering an empty

string doesn’t work, it may be worth asking a devel-
oper what is actually in the component.

The escape character

Some symbols have a special meaning for test execution. If
you want to use the symbol without the special function, you
have to escape it. The symbol to negate any special function
of the following symbol is a backslash: (\).
See the Reference Manual ((→Reference Manual p. 385)) for
more details on special symbols and escaping them.

When you are using regular expressions, you will also

need to think about which symbols need neutralising.
Sometimes more than one backslash is necessary.

3.12.13 Overwriting data for Test Cases and

Test Suites
When you reuse Test Cases, you reuse them with any concrete
values they contain, and with any default values that you have
entered for their referenced parameters.
Data which has been entered for referenced parameters can
be overwritten when you reuse a Test Case.
Reusing Test Cases happens in two ways:
• by adding the Test Case to another Test Case ( → page 68)
. The Test Case is then nested in the Test Case.

114 April 15, 2014 UserManual V8.0.00170

Tasks

• by adding the Test Case to a Test Suite ( → page 68) . The

Test Case is then nested in the Test Suite.

1. Single-click the reused Test Case in the editor for the Test
Case or Test Suite where you have reused it.

2. In the Properties View, you can see the parameters you ref-
erenced from in this Test Case. The data source for this Test
Case is shown as referenced Test Case to denote that the
data have not been changed after reusing the Test Case.

A grey diamond next to the parameter value field

means that the values in it were entered in the origi-
nal specification of the Test Case.

3. You can enter parameter values here or reference the pa-

rameters again. They would then become parameters of
the parent Test Case.

If you enter values here, you can see a yellow diamond

next to the parameter value field. This means that the
original data have been overwritten. The data source
changes to local Test Case

If you add references here, you will be able to enter or

overwrite data when you reuse the parent Test Case.

Once you change the parameter values of a reused Test

Case, any changes to the parameters in the original
specification of that Test Case will not affect your new
values. You can reset any local changes to the data of
the Test Case by removing all Excel files or Central Test
Data Sets and then selecting Referenced Test Case from
the data source combo box.

UserManual V8.0.00170 April 15, 2014 115

 Functional Testing User Manual

3.13 Working with component

names
Component names are the names you use to refer to the user
interface components you want your actions to be executed
on. These component names are collected and assigned to
real components when you carry out object mapping ( →
page 137) .

A component is an element of the user interface you

can execute an action on, e.g. a button, a text field.

Each component you are planning on testing requires a com-

ponent name. We recommend using well-thought out names
so that object mapping and test creation / maintenance are
easier.

3.13.1 Creating new component names

For information on creating new component names by re-
assigning old component names (in the Component Names
View for example, see the section on reassigning component
names ( → page 117) .
You can create new component names in the Component
Name Browser and in the Object Mapping Editor (tree view)
via the context menu:
New Component Name

You can also use the toolbar button to create a new

component name when you are in the Object Mapping
Editor.

A dialog will appear to allow you to enter a component name.

We recommend having good naming conventions for compo-
nent names, as this will help you when mapping later.
The component name you enter will be created and will ap-
pear in the unassigned component names category in the Ob-
ject Mapping Editor and in the unused component names cat-
egory in the Component Name Browser.

116 April 15, 2014 UserManual V8.0.00170

Tasks

Newly created component names have the type graph-

ics component until they are made more specific, either
by mapping them to a technical name or by entering
this new name in the Component Names View for a
more concrete component type.

3.13.2 Entering and reassigning component

names in the Component Names View

The following section deals with entering component

names in the Component Names View when you have
added Test Cases from the library. For information on
component names in Test Steps, see the Test Steps sec-
tion ( → page 132) .

1. Once you have added a Test Case from the library of Test
Cases ( → page 82) , you will need to enter a component
name for the component you want to test.
2. In the Component Names View, you will see the old name
for this component, which was given in the Test Step con-
tained in the library Test Case. The old name is just a place-
holder and should be reassigned (Figure 3.22 → page 118
).

When you enter a component name in the Component

Names View, you create a new reference to a compo-
nent in the AUT. This component name appears in the
Object Mapping Editor to be mapped to a component
in your AUT. A Test Case containing component names
to be reassigned can therefore be used at a variety of
different places to test different actual components. If
you want to rename a component name, you can do so
in the Component Name Browser ( → page 119) .

3. In the new name field, enter your name for this compo-
nent, e.g. MainWindow_NavigationTree_tre.
We recommend using naming conventions for component
names.

UserManual V8.0.00170 April 15, 2014 117

 Functional Testing User Manual

Figure 3.22: The Component Names View

4. Press »CTRL+SPACE« to see a list of component names you

have already used for this type of component:

Local component names are names you have used in this

Local name Test Case for this component type.
Global component names are names you have used for
Global name this component type, but not in this Test Case.

You can configure how frequently the content assist in

the Component Names View should open in the prefer-
ences ( → page ??) .

5. The component name you enter here will be collected by

the Object Mapping Editor when you carry out object map-
ping so that you can assign it to a component in the AUT.

6. Every time you want to carry out an action on this compo-

nent, use this name.

See the section on the component hierarchy for some

tips on using component names in your tests ( → page
123) .

118 April 15, 2014 UserManual V8.0.00170

Tasks

3.13.3 Renaming component names

Use the rename function to change the name of a component
name in your test specification. Whereas reassigning compo-
nent names results in a new component name being created
( → page 117) , renaming just changes the name at all places
where it is used.
You can rename component names in the Component Name
Browser and in the Object Mapping Editor.

1. Select the component name you want to rename.

2. In the context-menu, select:

Rename

3. In the dialog that appears, enter a new component name

to replace the old name. We recommend using naming
conventions for component names.

4. Press ”OK”. The component name you entered will replace

the old name throughout your test.

You cannot rename a component name with a name

that already exists. To merge two or more component
names to the same name, see the section on merging (
→ page 121) .

3.13.4 Propagating component names

Select the checkbox on the left of the Component Names
View to propagate this component name. This means that
you will be able to see and edit (reassign) this component
name when you reuse the parent of the Test Case you are
editing.
This is useful for creating flexible keywords that can be used
for the same workflow on different components. Depending
on what you want the keyword to do when you reuse it, you
can reassign the name to test different components in the
AUT.
For example, if you create a keyword ”Replace and Check”
which contains an action to replace a text and then check it.
If you want to be able to use this keyword to enter and check
text on any field in your AUT, then you should propagate the

UserManual V8.0.00170 April 15, 2014 119

 Functional Testing User Manual

component names from the actions by checking the checkbox

in the Component Names View. Each time you reuse ”Re-
place and Check”, then you will be able to enter a new name
for the propagated component, allowing you to choose dif-
ferent names that can be mapped to different components.

3.13.5 No component type exists message in

Component Names View
This situation occurs when a component name that has been
propagated and then renamed at the place of reuse is no
longer accessible, either because:

• the name with which the component was propagated has

been changed, or

• the checkbox to propagate the component name has been

deactivated.

In such situations, you will see the message in the Component

Names View :
No Component Type Exists!.

Saving the Test Case will remove the message, however,

you may want to take steps to transfer the component
name before removing the message.

• An example of a situation where this occurs:

1. You have a Test Case TC1 that has a component name

propagated from it: nn_nn_grc.
2. You reused the TC1 Test Case in another Test Case called
TC2, and renamed the component name to LoginDia-
log_OK_btn at the place of reuse.
3. You then either:

– change the component name in the original Test Case

to ”LoginDialog_AnyButton_btn”,
– or you deactivate the checkbox for propagating the
component name from the original Test Case.

120 April 15, 2014 UserManual V8.0.00170

Tasks

• In the Component Names View for the reused Test Case in

TC2, you will see a warning message that the component
name has no type.

The warning field is not editable.

• Depending on whehter you renamed the component name

or removed the checkbox, you can now do one of two
things:

– If you renamed the component name in the original Test

Case (TC1, then you can locate the newly propagated
name in the Component Names View and enter the new
name for the no longer existent component type in the
new name field for the newly propagated name. This
essentially points the previous component name hierar-
chy onto the new one.
– If you deactivated the checkbox, or if you do not want to
transfer the name as mentioned above, you can simply
make any change to the Test Case and then save it. The
message will disappear.

3.13.6 Merging component names

You can merge two or more component names to one uni-
fying name in the Component Name Browser. This makes
sense if you have accidentally created two component names
for the same component.

The component types must be the same to be able

to merge the component names, and the component
names must not have already been mapped to different
technical names from the AUT. The component names
must all come from the current Project, not from any of
the reused Projects.

To merge component names:

1. Select the component names you want to merge. Use

»CTRL« to select multiple names.

2. From the context-menu, select:

Merge Component Names

UserManual V8.0.00170 April 15, 2014 121

 Functional Testing User Manual

3. A dialog will appear in which you can choose which of the

selected names you want to merge all the names to. Select
the name you want and click ”OK”.

4. The component names you selected will be merged to the

name you specified throughout your test.

3.13.7 Deleting unused component names

When you reassign component names in the Component
Names View, you automatically create new component
names if the name you enter did not previously exist in the
Project.
Larger Projects can often end up with a number of component
names that are no longer used. You can see and delete these
names in the Component Name Browser. The names in the
Unused Component Names category (Figure 3.23 → page
122 ) are not used anywhere in this Project – they are not
present in any Test Cases and they have not been mapped
to any technical names from the AUT in the Object Mapping
Editor.

Figure 3.23: The Component Name Browser

To delete unused component names, select the name you

want to delete and select:
Delete
from the context-menu.

122 April 15, 2014 UserManual V8.0.00170

Tasks

To cleanup component names that are only used in map-

pings, or that are no longer used for a specific AUT, use
the function Cleanup unused component names in the
Object Mapping Editor ( → page 144) .

3.13.8 Understanding the component hierar-

chy
The component hierarchy is designed to allow flexible test
specification and robust tests. For a graphical overview of the
component hierarchy, see the reference manual (→Reference
Manual p. 381).

Abstract components

You can write tests very abstractly at the beginning, only

adding detail later. You will notice that the library contains
categories such as Component with Text Input and Graphics
Component.
These are abstract components – actions in these categories
can be used on a wide range of actual components in the
AUT. You can use a Click action on the Graphics Component
to click any component in the AUT. You just need to enter
different component names for it in the Component Names
View. Using the same component name for different

component types

What happens if you want to specify a test that clicks in a

table and then selects a cell in the table?
The click action is on the Graphics Component and the select
cell action is on the Table component – but you don’t want to
have two different component names.
This isn’t a problem. You can use the same component
name for different components as long as these are compat-
ible. So, in this case, the Graphics Component and the Table
component can both use the component name e.g. Table-
View_MainTable_tbl.

UserManual V8.0.00170 April 15, 2014 123

 Functional Testing User Manual

You cannot use the same component name for incom-

patible types, for example, trees and tables.

An overview of the component hierarchy can be seen in:

(→Reference Manual p. 381).

124 April 15, 2014 UserManual V8.0.00170

Tasks

3.14 Working with Test Suites

3.14.1 Creating a Test Suite

Test Suites are used to organize and prepare Test Cases to be
executed.
To create a Test Suite, the Test Suite Browser must be visible.
If it is not visible, change to the Functional Test Specification
Perspective and select:
Window → Show View → Test Suite Browser .

1. Select:
New → New Test Suite
from the context-sensitive menu in the Test Suite Browser.

2. Name the new Test Suite when prompted with a meaning-

ful name. It is a good idea to have naming conventions for
Test Suites.

3. Click ”OK”.

4. The Test Suite you created will appear in the Test Suite
Browser under the category Test Suites.

5. Once you have created a Test Suite, you can:

• Add Test Cases to it to be executed ( → page 68) .

• Configure the Test Suite in the Properties View ( → page
126) .
• Rename the Test Suite ( → page 65) .
• Delete Test Cases from it ( → page 69) .
• Add the Test Suite to a Test Job to be executed along
with other Test Suites ( → page 128) .

You can filter in the Test Suite Browser using the field at
the top. Use star * as a wild card.

You can combine multiple Test Suites to create a Test Job

( → page 128) . This is useful for testing multiple AUT’s
(or instances of the same AUT in one test.

UserManual V8.0.00170 April 15, 2014 125

 Functional Testing User Manual

3.14.2 Configuring Test Suites in the Proper-

ties View
To configure a Test Suite, you must first create one ( → page
125) .

If you are editing the Test Suite, the working language

(which is specified via the globe button on the toolbar)
must be set to a language supported by the chosen AUT
for the Test Suite. Otherwise the Test Suite will be uned-
itable.

1. Open the Test Suite Editor by double-clicking on the Test

Suite you want to configure.

2. In the Properties View, you can:

A Change the Test Suite name by entering a new name in

the Test Suite name field.
B Add a comment to the Test Suite ( → page 71) .
C Enter a value in the step delay field.

The step delay is the time left between each Test Step
during test execution. The default is 0 milliseconds ( →
page 158) .

D Select the AUT for this Test Suite. To be able to select an

AUT (and object map, and execute your test) you must
have added at least one AUT to the Project ( → page
47) .

You don’t have to choose an AUT for a Test Suite as soon

as you have created it, but you will have to choose one
before object mapping, for example.

E Choose a default reentry type for each of the four error

types from the combo-boxes.
Event Handlers are Test Cases used to deal with errors
during test execution. When an error occurs, the current
Test Case is searched for an Event Handler for that error
type. If none is found, the parent Test Case is searched,
and so on. If no Event Handler for the test is found,

126 April 15, 2014 UserManual V8.0.00170

Tasks

then a default Event Handler (specified in the Test Suite

properties)is activated.
As a general rule, you should avoid default Event Han-
dlers being executed. See the sections on Event Han-
dlers for information on the event types ( → page 165)
, reentry types ( → page 165) and creating your own
Event Handlers.
F Save the changes in the Test Suite Editor.

UserManual V8.0.00170 April 15, 2014 127

 Functional Testing User Manual

3.15 Working with Test Jobs to test

multiple AUT’s

3.15.1 Combining Test Suites into a Test Job

You can create a Test Job when you want to execute a collec-
tion of Test Suites after each other.
The Test Suites can test different instances of the same AUT,
or different AUT’s entirely.
You do not have to create a Test Job if you only want to run
tests on one instance of one AUT. To do this, you can use a
Test Suite ( → page 125) . A Test Job is most useful when you
want to switch between two AUT’s (either the same AUT or a
different one) in one test run.

3.15.2 Testing different AUT’s in one test run

You can test multiple AUT’s in one test run.
The AUT’s can be the same actual AUT which has been started
multiple times (to test refresh aspects, for example).
You can test AUT’s that were started independently, or AUT’s
that are launched by other AUT’s.

3.15.2.1 Testing independently started AUT’s

To be able to test multiple AUT’s that are not started by each

other, the following criteria must be met:

• The AUT’s are either written with the same toolkit (e.g.
Swing) or,

• you have specified your Project at the concrete level, and

will only be testing areas of the AUT’s that can be tested
with the actions that are valid for all AUT types (i.e. no
RCP-specific components are involved in the test) ( → page
29) .

• The AUT’s are all defined in the same Project.

• The first AUT can either be started using the autrun com-
mand ( → page 55) or via an AUT configuration ( → page
50) . Any other AUT’s required for the Test Job must have
been started with the autrun command.

128 April 15, 2014 UserManual V8.0.00170

Tasks

To run Test Jobs from the test executor, all AUT’s for the
test run must already be started when the test execu-
tion begins. For unattended build and test processes,
this will mean that the AUT’s must be started with the
autrun command.

3.15.2.2 Testing AUT’s that are launched by other

AUT’s

If your AUT starts other AUT’s which you also want to test,
then the following criteria must be met:

• The AUT Agent must be running in lenient or non-strict

mode ( → page 22) .
• The AUT’s must be written with the same toolkit (e.g.
Swing) ( → page 29) .
• The AUT’s have all been defined for this Project ( → page
47) .
• The order in which the launched AUT’s will appear and be
tested must be known.

When an AUT is launched by another AUT, the AUT ID

for the new AUT is formed as AUT ID + 1. The next
AUT to be started receives the ID AUT ID + 2, and so
on. You can enter these AUT IDs in the Test Suites in the
Test Job.

Behavior of AUT’s when being started by other AUT’s

RCP starting RCP:[The newly started RCP AUT receives the ID

ID+1.]
Swing Jar or main class starting Swing Jar or main class:[This
is currently not possible.]
Swing Jar or main class starting Swing executable:[This is cur-
rently not possible.]
Swing executable starting Swing Jar or main class:[The newly
started Swing AUT receives the ID ID+1.]

UserManual V8.0.00170 April 15, 2014 129

 Functional Testing User Manual

Swing executable starting Swing executable:[The newly

started Swing AUT receives the ID ID+1.]

If the AUT Agent is not running in lenient mode, then

the newly started AUT will shut down.

3.15.3 Creating a new Test Job

To create a Test Job, the Test Suite Browser must be visible.
If it is not visible, change to the Functional Test Specification
Perspective and select:
Window → Show View → Test Suite Browser .

1. Select:
New → New Test Job
from the context-sensitive menu in the Test Suite Browser.

2. Name the new Test Job when prompted with a meaningful

name. It is a good idea to have naming conventions for
Test Jobs.

3. Click ”OK”.

4. The Test Job you created will appear in the Test Suite
Browser under the category Test Jobs.

5. Once you have created a Test Job, you can:

• Add Test Suites to it ( → page 68) .

• Specify which AUT the Test Suites should test ( → page
130) .
• Rename the Test Job ( → page 65) .
• Delete Test Suites from it ( → page 69) .

3.15.4 Specifying which AUT to test in a Test

Job
Once you have added a Test Suite to a Test Job ( → page 68)
, you must select the AUT ID that you wish to run this Test
Suite on from the Properties View.
This enables you to differentiate between multiple AUT’s (or
instances of the same AUT in your tests).

130 April 15, 2014 UserManual V8.0.00170

Tasks

You must have defined all AUT’s to be tested during a

Test Job in the AUT definition dialog ( → page 47) .

UserManual V8.0.00170 April 15, 2014 131

 Functional Testing User Manual

3.16 Information on Test Steps

Test Steps are the smallest unit in a test. They correspond to
one action on one component.

Instead of creating Test Steps, we recommend using the

library of Test Cases ( → page 82) . Each Test Case in
the library contains one Test Step, with all the param-
eters already referenced. Using the library makes test
creation much easier!

3.16.1 Specifying Test Steps

You must have created a Test Case ( → page 80) in order

to create Test Steps.

1. Open the Test Case Editor by double-clicking on the Test

Case you want to edit in the Test Case Browser.

2. Create a Test Step from the context-sensitive menu in the

Test Case Editor:
Add → New Test Step .
(This adds the Test Step after any other items in the Test
Case Editor.)

3. Alternatively, use the option in the context-sensitive menu

to insert a Test Step. This inserts the new Test Step above
the currently selected item.

4. The New Test Step (Figure 3.24 → page 133 ) dialog will
appear.

Filling in the Test Step dialog

Test Step name

1. In the Test Step Name field, enter a name for the Test Step.
This name is just for recognition purposes, but should be
easily identifiable at a later point.
Component type

2. Select the component you want to test from the combo

box.

132 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.24: New Test Step Dialog

A component is an element of the user interface you

can execute an action on, e.g. a button, a text field.

Component name

3. Enter a component name. This is your user-defined name

that you will use to refer to this particular component. It
will later be mapped to the real component in the AUT.
Again, we suggest using conventions to name compo-
nents.

4. When you are entering component names, a combo box

appears with a list of names you have already used.
If any of the names are grayed out, this means they have
been used for other component types and cannot be used
for the currently selected component type.
You can change, or reassign component names later when
you reuse this Test Case. Doing this means that you can
execute the same actions on different components in the
interface. The section on the Component Names View (
→ page 117) contains information on reassigning compo-
nent names.
Action

5. From the combo box, choose the action you want to exe-
cute on this component.

UserManual V8.0.00170 April 15, 2014 133

 Functional Testing User Manual

Refer to the chapter on Components, Actions, and Pa-

rameters ((→Reference Manual p. 21)) for information
on components, the actions they support, and their pa-
rameters.

6. Click ”OK”.

7. The Test Step will appear as nested in the Test Case.

You can change the position of Test Steps using drag-

and-drop.

You can see and edit the details of any selected Test Step
in the Properties View.
The next step is to add parameter values (data) for Test
Steps in the Properties View ( → page 91) .

3.16.2 Editing Test Steps

1. Open the Test Case Editor by double-clicking the Test Case
you want to edit in the Test Case Browser.

2. Single-click the Test Step you want to edit.

3. In the Properties View, you can:

• edit the Test Step name

• add a comment
• edit the component, component name and action for
the Test Step
• edit the parameter values for the Test Step ( → page
91)

4. You can also move the Test Step within the Test Case using
drag-and-drop.

5. To delete the Test Step, select:

Delete
from the context-sensitive menu.

134 April 15, 2014 UserManual V8.0.00170

Tasks

Select the component or action in the Properties View

and press »F1« to see context-sensitive help about this
component or action from the reference manual.

3.17 Working with manual Test Cases

3.17.1 Creating manual tests

You can create manual tests to be executed and analyzed.
A Test Case containing manual Test Steps is the same as an
automated Test Case for all intents and purposes. You can add
data, reuse it in other Test Cases, and add it to Test Suites to
be executed. The only difference is during execution: manual
tests are executed in an interactive mode ( → page 136) .
To create a manual test:

1. Create a Test Case ( → page 80)

2. Add the module for manual Test Case from the library of
Test Cases (category: Manual Test Step).

3. In the Properties View, you can enter three pieces of data:

The action(s) to perform: Enter a short description

which should appear when the test is being executed.
You can also enter referenced parameters ( → page
92) or variables ( → page 94) here to specify different
data for the test.
The expected behaviour: Enter the description (any any
data) of the expected outcome of the Test Step.
Timeout: Enter how long the test execution should wait
before receiving the information that the Test Step
passed or failed. We recommend setting this timeout
value high enough for a manual tester to be able to
complete the Test Step and enter any comments.

4. Once your manual Test Case is finished, then you can add
it to a Test Suite ( → page 68) to be executed ( → page
136) .

UserManual V8.0.00170 April 15, 2014 135

 Functional Testing User Manual

We recommend keeping manual Test Cases in a separate

category to automated Test Cases. Although it is possi-
ble to combine manual and automated Test Cases in one
test, make sure you know which Test Suites can be run
completely automatically for your unattended tests!

3.17.2 Executing and analyzing manual tests

Once you have created a manual Test Case ( → page 135) ,
you can execute it.

1. Start the AUT ( → page 154) .

2. Start the Test Suite containing the manual Test Steps ( →

page 155) .

3. For each manual Test Step in the test, a dialog will appear
with the descriptions and data you entered for the action
to perform and the expected behavior.

4. Execute the Test Step as described, enter a comment if nec-

essary, then click either ”passed” or ”failed” in the dialog
to move to the next Test Step.

If the Test Step fails, then an automatic screenshot will

be taken ( → page 171) , and any Event Handlers Chap-
ter ”Dealing with errors in tests: Event Handlers” ( →
page 164) for this Test Case will be activated.

5. Once the dialog has been closed, the next Test Step dialog
will appear.

6. At the end of the test, you can see the test result report
like any other automated test ( → page 160) .

136 April 15, 2014 UserManual V8.0.00170

Tasks

3.18 Object mapping

3.18.1 Object mapping

Object mapping is the joining of the component names you
have specified in Test Steps to the real components in the
AUT. Each component name you have specified in your Test
Cases and used in a Test Suite will be shown in the Object
Mapping Editor to be mapped.

New component names you have created in the Object

Mapping Editor but have not yet used in Test Cases will
also be shown in the Object Mapping Editor.

To be able to carry out object mapping, you must have:

• started and connected to the AUT Agent ( → page 21)

• created a Test Case containing Test Steps ( → page 80)

• added Test Cases to a Test Suite ( → page 125)

• specified an AUT ( → page 47)

• configured an AUT if you want to start the AUT from the

ITE ( → page 50)

• chosen an AUT for the Test Suite ( → page 126)

• checked that your current working language is supported

by the chosen AUT.

• connected to the AUT Agent ( → page 23)

• started the AUT to be mapped ( → page 154)

• opened the Object Mapping Editor ( → page 138)

3.18.2 Working with the Object Mapping Ed-

itor
3.18.2.1 Opening the Object Mapping Editor

1. Open the Object Mapping Editor by selecting the Test Suite

whose components you want to map and selecting:
Open with → Object Mapping Editor .

UserManual V8.0.00170 April 15, 2014 137

 Functional Testing User Manual

The Object Mapping Editor also opens automatically

when you start the Object Mapping Mode via the tool-
bar.

The Object Mapping Editor for the AUT used by this Test
Suite will appear (see Figure 3.26 → page 151 ).

You can see the name of the AUT you are mapping in.
the tab of the editor

3.18.2.2 The different views in the Object Mapping Ed-

itor

You have two options to view the Object Mapping Editor -

a split view and a tree view. Each view displays the same
information, but in a different format. Depending on the view
you choose, you can carry out different actions.
The split view
This view is automatically shown when the Object Mapping
Editor is opened. It contains three panels for the three main
categories. In the split view, you can:

• Assign (map) technical names to component names ( →

page 150) by dragging component names onto technical
names (either assigned or unassigned).

The split view is especially useful if you have many map-

pings – it lets you find component names and technical
names separately to map them, without having to scroll
through the whole tree.

• Create new component names for your tests ( → page

116) .

• Rename component names ( → page 119) .

• Create categories and map into them ( → page 139) .

The tree view

In the tree view, you can:

138 April 15, 2014 UserManual V8.0.00170

Tasks

• Assign (map) technical names to component names ( →

page 150) by dragging component names onto technical
names (either assigned or unassigned).

• Create new component names for your tests ( → page

116) .

• Rename component names ( → page 119) .

• Create categories and map into them ( → page 139) .

3.18.2.3 Working with categories in the Object Map-

ping Editor

Default categories in the Object Mapping Editor

The Object Mapping Editor tree view displays the following
categories by default:

Unassigned component names: these are the names you

have used in your Test Cases or component names that you
have created ( → page 116) . They are unassigned because
they have not yet been mapped to a technical name.

Unassigned technical names: these are the names that

you have collected from the AUT ( → page 146) , but
not yet assigned to component names.

Assigned names: there are pairs of names that have been

mapped to each other. Each technical name can be
mapped to one or more component names. This mapping
tells the ITE which actual components you are referring to
in your Test Cases.

Creating categories in the Object Mapping Editor

We recommend creating categories in the Object Mapping
Editor to make your mapping work easier.

• You can create categories and subcategories in the Object

Mapping Editor (tree view) by:

1. Selecting the category you want your new category to

appear in (e.g. in ”assigned names”).
2. Selecting ”create category” from the context-sensitive
menu.
3. Entering a name for the category

UserManual V8.0.00170 April 15, 2014 139

 Functional Testing User Manual

You can’t have two categories with the same name at

the same level.

• When you are mapping, you can choose which category to

map into. See the next section ( → page 140) for details.

It is a good idea to create categories in the Object Map-

ping Editor.

Mapping into categories in the Object Mapping Editor

Once you have created categories in the Object Mapping Ed-
itor, you can choose to map technical names collected from
the AUT directly into a category. This can help if you have
created a category for each dialog/window, and you want to
map all of the components from it into one category.

1. When you are in the Object Mapping Mode, right-click on-

the category you want to map into and select:
Map components into this category
to make the technical names you collect from the AUT ap-
pear in this subcategory.

If you have already mapped the technical name, the

name will be shown in the Object Mapping Editor, but
not moved into the category.

The status bar displays which category you are mapping

into.

3.18.2.4 The configuration view in the Object Mapping

Editor

In the configuration view in the Object Mapping Editor you

can alter the object recognition for the test execution.
Understanding object recognition
Object recognition during test execution is based on a calcu-
lation which takes various factors into account. For some ap-
plications, some factors may be more important than others,
and you can change their weighting accordingly.

140 April 15, 2014 UserManual V8.0.00170

Tasks

The object location is a heuristic process. During test execu-

tion, a calculation is made for each component in the AUT to
see how similar it is to the originally mapped component. This
calculation is based primarily on the component type – if you
mapped a combo box, only combo boxes will considered. For
each component of the same type, the similarity to the origi-
nal is calculated using weighted properties. The factors used
in the calculation are:

Name: The name of the object within the AUT code, as given
by the developer (if a name was given).

Path: The route through the AUT hierarchy to get to this

component.

Context: The components in the vicinity of this component.

Threshold: This determines what percentage value a com-

ponent in the AUT must have in order to be considered
as the originally mapped component. Components with a
value under the threshold are not considered. The compo-
nent with the highest value above the threshold is chosen
during execution.

Options for object recognition You can change the profile

used during test execution using the combo box:

Standard: This is the default profile. It has a high value for

name weight and lower values for context and path. The
threshold is 85%.

Strict: In this profile, the values for name, path and context
are the same as in the standard profile. The threshold is at
100%. This means that a component must exactly corre-
spond to the originally mapped component.

Given names: In this profile, only the component name is

considered. A component will only be selected if it has
the same name as the originally mapped component. This
profile can be used when you are sure that all of the com-
ponents in the AUT have unique names.

Custom: This profile lets you move the sliders yourself. You
can lock sliders to stop them being affected by other slid-
ers.

UserManual V8.0.00170 April 15, 2014 141

 Functional Testing User Manual

Figure 3.25: Object Mapping Configuration

142 April 15, 2014 UserManual V8.0.00170

Tasks

Take care when manually customizing the object map-

ping settings. You may have test execution problems
if you have set the values too strictly, or not strictly
enough.

3.18.2.5 Refreshing the Object Mapping Editor

1. Select refresh from the context-sensitive menu in the Ob-

ject Mapping Editor or press »F5« to refresh the Object
Mapping Editor.

2. Confirm that you want to want to refresh the editor.

When you refresh the Object Mapping Editor, any new com-
ponent names which have been added to Test Suites for this
AUT are collected.

3.18.2.6 Finding components in the AUT via the Object

Mapping Editor: highlight in AUT

In the Object Mapping Editor, you can search for:

• All the places where a component name has been used in

the test ( → page 209)

• The specific place where a particular component name

comes from in the test ( → page 209)

• The technical component in the AUT (see below).

Highlighting a component in the AUT

To search for components in the AUT, the Object Mapping

Editor must be open ( → page 138) , and the AUT must be
running ( → page 154) in the Object Mapping Mode ( →
page 146) .

1. In the Object Mapping Editor, right-click on the technical

name whose component you want to find in the AUT and
select:
Highlight in AUT
from the context-sensitive menu.

UserManual V8.0.00170 April 15, 2014 143

 Functional Testing User Manual

2. The component whose technical name you selected will be

highlighted with a green border in the AUT.

You can only highlight components that are currently

visible in the AUT.

3.18.3 Deleting from the Object Mapping Ed-

itor
1. You can delete items from the Object Mapping Editor using
the ”delete” option from the context-sensitive menu.

2. You can also select the item you want to delete and press
»DELETE«.

3. If you delete a component name that is still used in a Test

Case for this Test Suite it will reappear when you select
”refresh” from the context-sensitive menu.

If you want to remove all unused mappings from the

Object Mapping Editor, then use the Cleanup option (
→ page 144) .

3.18.3.1 Removing unused component names from the

Object Mapping Editor

Over time, your Project will change, and these changes may
mean that component names you had previously used in Test
Suites, then mapped to technical names via the Object Map-
ping, are no longer used. This results in object mappings in
which the component name is no longer used in the test for
this AUT. Such component names can be recognized by the
fact that Show corresponding specification in the Object Map-
ping Editor ( → page 210) returns no search results in the
search result view (i.e. the component name is no longer used
in the test), or if the search result view shows only Test Cases
that are used in other AUT’s. If you perform Show where used
in the Component Name Browser ( → page 209) and the
only search result is a mapping, then this is also a component
name that is no longer used in the test.

144 April 15, 2014 UserManual V8.0.00170

Tasks

You can delete any component names from the Object Map-
ping Editor that are unused in the Project for this AUT:

1. In the Object Mapping Editor, select:

Cleanup → unused component names
from the context-sensitive menu.

2. The cleanup operation starts, and a progress dialog is

shown while unused names are being searched for. De-
pending on the size of your Project, this search may take
some time.

3. If the Object Mapping Editor contains component names

that are not used in any of the Test Suites for this AUT
(either component names that are already mapped, or are
still unassigned), then they are shown in a Delete unused
component names dialog.

If no component names are found, then you will see a

message informing you of this.

4. In the dialog to delete unused component names, you can

see which component names have been identified for dele-
tion. You can deselect individual component names to opt
not to delete them. Once you have specified which com-
ponent names should be deleted, click ”OK”.

5. The component names you specify will be deleted from

the Object Mapping Editor. Save the editor to save the
changes.

Removing component names from the Object Mapping

Editor does not mean that the component names are
deleted from the Project. However, if the deletion from
the object map means that the component name is now
used nowhere in the Project, then it will appear under
the Unused Component Names category in the Compo-
nent Name Browser and can be deleted from the whole
Project ( → page 122)
.

UserManual V8.0.00170 April 15, 2014 145

 Functional Testing User Manual

3.18.4 Collecting components (technical

names) from the AUT
Once your test specification is ready, you can collect compo-
nents (technical names) from the AUT to map (assign) to the
component names you used in your tests.
To collect components from the AUT, you must have:

• started and connected to the AUT Agent ( → page 21)

• created a Test Case containing Test Steps ( → page 80)

• added Test Cases to a Test Suite ( → page 125)

• specified an AUT ( → page 47)

• configured an AUT ( → page 50) if you want to start the

AUT from the ITE

• chosen an AUT for the Test Suite ( → page 126)

• checked that your current working language is supported

by the chosen AUT.

• started the AUT to be mapped ( → page 154)

• opened the object mapping editor ( → page 138)

1. Start the Object Mapping Mode by clicking the arrow next

to theStart Object Mapping Mode on the toolbar and se-
lecting which AUT (based on the AUT ID) you want to map.
start Object Mapping
Mode
If you have the same AUT running more than once, you
will only be able to collect components from the AUT
whose ID you chose. The object map for AUT’s that are
the same is, however, identical.

The status bar will show that the Object Mapping Mode is
active.

2. Bring the AUT into focus by clicking on its titlebar.

3. Collect the component as described in the sections below

for the specific toolkits.

146 April 15, 2014 UserManual V8.0.00170

Tasks

4. In the Object Mapping Editor, the technical name for this

component will appear in the unassigned technical names
category.

If you have already mapped this component, it will be

highlighted in the Object Mapping Editor.

5. When you collect a technical name, it is displayed with a

colored dot in the Object Mapping Editor. The color of the
dot indicates the strength of the component recognition
for this component, in the current state of the AUT ( →
page 149) .

6. Collect all the names you need from the AUT and then click
the Stop Object Mapping Mode button on the toolbar. stop Object Mapping
Mode
7. You can now map (assign) the component names you used
in your Test Cases to the technical names you have col-
lected from the AUT ( → page 150) .

3.18.4.1 For Java and Win (.NET) AUT’s:

• In the AUT for which the Object Mapping Mode was

started, move the cursor over components. They will be
highlighted with a green border (see Figure 3.27 → page
152 ).

• To collect a technical name for a component, hover the

cursor over the component whose name you want to col-
lect.

• Press »CTRL+SHIFT+Q«.

You can change the key combination for the object map-
ping in the object mapping preferences ( → page 170) .
This is a good idea if the current key combination has a
specific meaning in your AUT. You can also set the ob-
ject mapping combination to a mouse click if your AUT
does not accept key combinations.

• If no component is collected, then you may need to write

an extension to recognize and test the component. More
information on this is available in the Extension Manual.

UserManual V8.0.00170 April 15, 2014 147

 Functional Testing User Manual

3.18.4.2 For HTML AUT’s:

• While the Object Mapping Mode is active, the AUT cannot

be used.

• To collect a technical name for a component, click the com-

ponent whose name you want to collect.

• If the AUT you are mapping has been specified as a multi-

window AUT in the AUT configuration ( → page 59) ,
then you will see an extra button in the Object Mapping
Editor. When multiple windows are open, then you can
choose between the windows – the window you choose
is the window in which the mapping will take place. You
should open the new window before starting the Object
Mapping Mode. You can switch back and forth between
windows by selecting them in the Object Mapping Editor.

• You will also need to use the HTML actions to switch be-
tween windows in your test.

3.18.4.3 For iOS AUT’s:

Object mapping for iOS AUT’s is done by tapping the compo-

nent or clicking it if you are working on a simulator.
There are three types of tap you can use, with different ef-
fects. We recommend reading the information on address-
ing the correct component in your iOS tests in the section on
Toolkits ( → page 280) .

Single tap: This collects the component directly underneath

your finger or the mouse cursor.

Double tap: This collects the component directly under-

neath your finger or the mouse cursor, plus its direct par-
ent. For example, if you want to collect a OK button, but
you click on the ”OK” label, then a double tap will collect
both the label and the button. Double taps are recom-
mended for collecting any components that have text on
them – a single tap may only collect the label, whereas a
double-tap will collect the label and the component it is in.

Long tap: This collects the component directly underneath

your finger or the mouse cursor, plus all of its parents. This
is useful if you want to collect disabled components (which
cannot be collected with a single tap), or if you want to

148 April 15, 2014 UserManual V8.0.00170

Tasks

address components that are ”hard to reach” with a single

or double tap.

The AUT functionality is deactivated during object map-

ping – clicks on buttons won’t close popovers, for ex-
ample. To move to another screen, you must stop the
Object Mapping Mode, switch, and then restart the Ob-
ject Mapping Mode to continue mapping.

3.18.4.4 Understanding the colored dots when collect-

ing component names in the Object Mapping
Editor

When technical names are collected from the AUT, they ap-
pear in the Object Mapping Editor with a colored dot. The
color of the dot corresponds to the strength of the compo-
nent recognition for this component at the time of collecting.
A green dot signifies that the component can be found as
an exact match, and that only this component was above
the threshold ( → page 140) (i.e. only this component
was considered as possible.
A yellow dot means that the component can be found as an
exact match, but that other components were also above
the threshold, i.e. this was not the only component con-
sidered possible.
A red dot means that the component can not currently be
found if a test is executed. The recognition value for the
component is below the current threshold.
You can use this information to identify components that will
not be recognized in the current state of the AUT before run-
ning the test.

The colored dot disappears after saving. It is not a mea-

surement of the component state over time, but only at
the moment when the component was collected. You
can see how well each component was actually located
during a test by looking in the test result reports. Each
Test Step provides information on the match heuristic
for each component.

UserManual V8.0.00170 April 15, 2014 149

 Functional Testing User Manual

3.18.5 Mapping (assigning) collected techni-

cal names to component names
Once you have collected the components from the AUT that
you will use during the test ( → page 146) , you can then map
them to the component names you used in your Test Cases.

1. In the Object Mapping Editor, in the split view or the tree

view ( → page 138) , you will see the component names
you have created ( → page 116) and/or used in your Test
Cases, as well as the names you have collected from the
AUT. The names are grouped into categories of unassigned
and assigned names ( → page 139) .

2. To map a component name to a technical name, you must

drag the unassigned component name onto the corre-
sponding unassigned technical name that you want this
component name to refer to.

3. When a component name has been assigned to a techi-

cal name, the joined names appear in the assigned names
category. The component type for the component name is
adjusted so that it reflects the type of component it has-
been mapped to ( → page 123) .

You can also ”unassign” component names from techni-

cal names by dragging the component name back into
the unassigned component names category

4. Save the changes in the editor.

You will only be able to map component names to tech-

nical names if their types are compatible ( → page 123)
.

3.18.6 Object mapping and AUT changes

If your AUT has changed from one version to the next, your
tests may still run, depending on the nature and extent of the
changes.

150 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.26: Object Mapping Editor

Please bear in mind that changing the look and feel of

your AUT may lead to different technical names for the
components in your AUT if you have not named the
components.

If your test does not run, a few simple steps will update it.
If you get a component not found error, or the wrong com-
ponent is selected during the test, remap the new component
from the AUT and assign it to your component name.
This updates this component for the whole test.

UserManual V8.0.00170 April 15, 2014 151

 Functional Testing User Manual

Figure 3.27: Green Border around Supported Component

152 April 15, 2014 UserManual V8.0.00170

Tasks

3.18.7 Viewing properties for a component in

the Object Mapping Mode
When you collect a component from a Swing, SWT/RCP or
JavaFX AUT in the Object Mapping Mode ( → page 146) ,
you can see additional information on the properties for that
component in the Properties View.
The property information shows you which properties the
component has, and their values. If a property is not accessi-
ble, you will see a notice informing you of this.
You can use this information to help you write tests that use
the actions check property and store property.
The property information is not saved when the Object Map-
ping Editor is saved: to view property information again, you
must collect the component in the Object Mapping Mode
again.

Property information can be transient, i.e. it can change

as the component or AUT changes. To make sure that
you collect the right property, collect the component
when it is in the state that you want it to have. A sim-
ple example is the color of a component: if you have a
component can be green or red and you want to check
that it is red, then you should collect it while it is red to
see the correct property.

UserManual V8.0.00170 April 15, 2014 153

 Functional Testing User Manual

3.19 Test execution

3.19.1 Prerequisites for test execution

To be able to start a test you must:

1. Create a Test Suite ( → page 125) .

2. Add Test Cases to be executed to the Test Suite ( → page

68)

3. Define an AUT ( → page 47) .

4. Configure an AUT ( → page 50) if you want to start the

AUT from the ITE.

5. Choose an AUT for the Test Suite ( → page 126) .

6. Set the working language to the language you want to

execute the test in.

7. Connect to the AUT Agent ( → page 23) .

8. Start the AUT ( → page 154) (either from the ITE or using
the autrun command).

9. Complete object mapping ( → page 137) .

10. Make sure that your test data is complete in your Test
Cases.

It is a good idea to set your preferences for test results

in the preferences dialog ( → page 167) before test
execution.

3.19.2 Starting the AUT

To start the AUT, you must:

• have defined an AUT ( → page 47)

• have connected to the AUT Agent ( → page 23)

• if you want to start your AUT from the ITE, and not using
the autrun option, then you must have configured an AUT
( → page 50)

154 April 15, 2014 UserManual V8.0.00170

Tasks

You can only start AUT’s from the ITE which support
the current working language. Change the working lan-
guage if necessary by selecting a language from the list
next to the language button on the toolbar.

1. On the toolbar, click on the arrow next to the ”Start AUT”

button. start AUT

2. Select an AUT and the configuration to start it with from

the list.

3. The AUT will be started in the current working language.

4. Clicking directly on the ”Start AUT” button will start the

most recently started AUT (marked with a tick in the list of
AUT’s and configurations).

Once the AUT has been started, it will appear in the running
AUT’s view.

Further information on starting specific types of AUT is

available in the toolkit-specific details ( → page 259) .

3.19.3 Starting, stopping and pausing Test

Suites and Test Jobs
3.19.3.1 Starting a Test Suite or a Test Job

To start a Test Suite or a Test Job, you must:

• have started the AUT ( → page 154)

• have completed object mapping for the Test Suite or Test

Suites ( → page 137)

• have entered complete test data for your Test Suites, for
the language you want the test to run in.

Before starting a Test Suite or a Test Job, it is a good

idea to review your preferences for the test results ( →
page 171) .

UserManual V8.0.00170 April 15, 2014 155

 Functional Testing User Manual

Starting a Test Suite: You can start a Test Suite from the
Test Suite Browser or from the Running AUT’s View. Click
on the arrow next to the ”Start test execution” button and
select a Test Suite to start from the list.

Starting a Test Job: You can start a Test Job from the Test
Suite Browser. Click on the arrow next to the ”start test
execution” button and select a Test Job to start from the
list.
start test

The amount of Test Suites or Test Jobs in the list for the
”start test” button depends on your selection. In the
Running AUT’s View, only Test Suites for the currently
selected AUT will be shown. In the Test Suite Browser,
if you have selected a Test Suite or a Test Job, only the
selected item will be startable.

When a test is running, you can view the progress of the test
in the Progress View. This is especially useful if the ITE and
the AUT are running on different machines: you can see how
much longer the test will run without having to switch to the
machine the AUT is running on.

3.19.3.2 Stopping a Test Suite or Test Job

To stop the test at any point, click on the ”stop test execution”
stop test button on the toolbar. The test stops automatically when it
finishes or when an error occurs whose Event Handler has
exit as a reentry type.

3.19.3.3 Pausing a Test Suite or Test Job

1. To pause a test, click on the ”pause test execution” button

pause test on the main toolbar.

2. To continue with the test, press the ”Pause test execution”

button again.

You can opt to automatically pause the test execution

when an error occurs via the toolbar ( → page 157) .

156 April 15, 2014 UserManual V8.0.00170

Tasks

If the client and AUT Agent are installed on the same

machine, moving the mouse will disrupt the test.

3.19.4 Interactive test analysis

If you are executing tests interactively, you can use the ITE to
help you analyze any errors that occur.

3.19.4.1 Pause on Error

On the toolbar in the ITE, click the ”Pause on Test Execution

Errors” button or press »F9« to cause the test to pause when
it encounters an error.

Failed Test Steps that have a retry Event Handler will

not be paused unless the final retry fails.

3.19.4.2 Continuing after an error

Once you have analyzed the error in the AUT or in the test
specification, you have two options:
Continue with the Event Handler: Press the ”Pause test
execution” button on the toolbar ( → page 156) to con-
tinue with the test. This will result in a Event Handler (ei-
ther a default Event Handler or one of your own) being
activated.
Continue without Event Handler: Press the ”Continue
without Event Handler” button or »F8« to continue with
the test as if the failed Test Step had been successful. No
Event Handler is activated. This option is useful if the Event
Handler that would be activated would restart the AUT or
exit the test, but you are either able to ignore the error for
the moment or make changes in the AUT to ensure that
the test will be able to continue.

Any changes you make to the test specification while

the test is paused will not become valid until the next
test execution start.

UserManual V8.0.00170 April 15, 2014 157

 Functional Testing User Manual

3.19.5 Altering the speed of test execution

You can slow down the speed of test execution to be able
to watch your tests by entering a step delay in the Properties
View for the Test Suite ( → page 126) .

158 April 15, 2014 UserManual V8.0.00170

Tasks

3.20 Working with test results

3.20.1 The Test Result View

The Test Result View Figure 3.28 → page 160 tracks the
test progress for each Test Suite, marking each Test Step as
successful or unsuccessful.
When the test begins, the Test Steps to be executed appear
in the Test Result View. As each Test Step is executed, it is
marked with a question mark. If the Test Step is successful,
it is marked with a green tick. Failed Test Steps are marked
with red crosses. Test Steps which succeeded after retrying (
→ page 164) are marked differently to show that they were
successful after retrying.
Navigating in the Test Result View

• Single click on an item in the Test Result View to see details

for that item in the Properties View.

• Double-click on an item in the Test Result View to be taken

to this item in the Test Suite.

• You can clear the Test Result View by clicking the ”clear”
button in the tab of the view.

• Use the arrows on the toolbar to spring to the next or pre-

vious error in the Test Result View (you can also use the
combinations »ALT+UP« and »ALT+DOWN«).

• Each node in the Test Result View shows the amount of

time taken to execute this node. You can turn this option
off in the preferences ( → page 173) .

You can also see screenshots of errors that were taken

by selecting the screenshot from the tree in the test re-
sult tree. You will need to have the Image View open to
see the screenshot. From the Image View, you can also
save the image to your file system.

For preferences about the Test Result View, see the section on
the preference pages ( → page 171) .

UserManual V8.0.00170 April 15, 2014 159

 Functional Testing User Manual

Figure 3.28: Test Result View

3.20.2 XML and HTML reports

You can create XML and HTML reports for your tests in one of
two ways:

1. In the Test Result Summary View ( → page 163) .

2. You can specify that XML and HTML reports should be cre-
ated when a test runs in the preferences ( → page 171)
.
• We recommend using the option to export test results
from the Test Result Summary View, as this does not
involve defining any external files for your test environ-
ment.

3.20.3 Working with the Test Result Sum-

mary View
A test result summary and full details about the whole test
are stored for each test run. Individual Test Suites within a
Test Job are counted as one test run each.

160 April 15, 2014 UserManual V8.0.00170

Tasks

You can see the test result summaries in the Functional Test
Reporting Perspective, in the Test Result Summary View.

3.20.3.1 Re-opening the test result view for a test run

1. If the full details for a test run are still available (the column
Details shows true), you can re-open the full test result by
double-clicking on the entry in the Test Result Summary
View or by clicking the button to open the report in the
top right-hand corner of the view.

2. In the test result, you can navigate through the test results
using the mouse or using the toolbar buttons to spring to
the next or previous error. In this way, you can view any
screenshots in the Image View and details about errors in
the Properties View.

3. Each node in the Test Result View shows the amount of

time taken to execute this node and any parameter values
that were used at this node. You can turn these options
off in the preferences ( → page 173) .

In the Project properties, you can specify how often the

full reports should be automatically deleted from the
database ( → page 33) .

3.20.3.2 Filtering and sorting in the Test Result Sum-

mary View

The Test Result Summary View shows a summary of each Test

Suite that has run.
Sorting entries in the Test Result Summary View

Click on a column header to sort the table according to the

values in this column.
Showing and hiding columns in the Test Result Sum-
mary View

In the context-menu on the column headers in the Test Result

Summary View, you can select which columns you want to
show in the view. Your settings for this view are saved in your
workspace.

UserManual V8.0.00170 April 15, 2014 161

 Functional Testing User Manual

Filtering in the Test Result Summary View

At the top of the Test Result Summary View there is a filter.

Choose which column you want to filter, and enter the value
you want to filter by (use * as a wildcard).

3.20.3.3 Changing the amount of result summaries

shown in the Test Result Summary View

In the test result preferences ( → page 171) you can alter the
amount of days that a test result summary is shown. The top
of the Test Result Summary View shows the amount of days
that test result summaries are being shown for. Any unshown
summaries are still present in the database and can be shown
by increasing the amount of days.

3.20.3.4 Changing the relevance of a test run

You can change the relevance of a test run (i.e. whether it is

exported with the Project or not) in the Test Result Summary
View.

1. Select the test run whose relevance you want to change.

2. Select:
Toggle relevance
from the context-sensitive menu.

3.20.3.5 Refreshing the Test Result Summary View

refresh view Use the ”Refresh” button at the top right hand corner of the
Test Result Summary View to refresh the view after tests have
been run.

3.20.3.6 Deleting test runs from the Test Result Sum-

mary View

Select one or more rows in the Test Result Summary View and
delete test runs use the ”Delete” button in the top right hand corner of the
view to delete these test runs.

162 April 15, 2014 UserManual V8.0.00170

Tasks

3.20.3.7 Exporting test results from the Test Result

Summary View as HTML and XML reports

• Select one or more test reports and select Export from

the context-sensitive menu or click the ”Export” button on
the toolbar of the Test Result Summary View.

• In the dialog that opens, enter or browse to a directory

where the test results should be saved.

• When you click ”Finish”, the result reports for the selected
test runs will be exported to the directory you entered.

• For each test run, an XML and an HTML file are created.

In order to export test results from the Test Result Sum-

mary View, details for these reports must still be in the
database. This will be shown as true in the Details col-
umn in the Test Result Summary View.

3.20.3.8 Entering comments for test runs in the Test

Result Summary View

You can add a comment to a test run in the Test Result Sum-
mary View by:

• Selecting a test run in the Test Result Summary View

and then selecting Edit comment from the context-
sensitive menu.

• In the dialog that opens, enter a title for the comment and
a longer description in the details area.

• When you click ”OK”, the title of the comment is shown

in the Comment column.

• You can view the details for a comment by reselecting

Edit comment from the context-sensitive menu.

UserManual V8.0.00170 April 15, 2014 163

 Functional Testing User Manual

3.21 Dealing with errors in tests:

Event Handlers
Event Handlers are Test Cases used to deal with deviations
during test execution. When an error occurs, the current Test
Case is searched for an Event Handler for that error type. If
none is found, the parent Test Case is searched, and so on. If
no Event Handler for the test is found, then a default Event
Handler is activated. Default Event Handlers are specified in
the Test Suite properties ( → page 126) .
The advantage of adding your own Event Handlers is that you
can define specific behavior for certain errors in each Test
Case. An Event Handler can be an empty Test Case, or can
contain Test Cases to be executed when the error occurs.
For each Event Handler, you must specify:

an event type to define what sort of error should activate

this Test Case ( → page 165) .
a reentry type to define how the test should continue once
the Event Handler has been executed ( → page 165) .

3.21.1 Adding Event Handlers to a Test Case

This section deals with adding Event Handlers to Test Cases.

1. Open the Test Case Editor by double-clicking on the Test

Case you want to edit in the Test Case Browser.
2. Select
Add → Test Case as Event Handler
from the context-sensitive menu in the editor or use
»CTRL+ENTER«.
3. Choose a Test Case to add from the dialog that appears.

You can also drag the Test Case you want to use straight
into the Event Handlers area of at the bottom of th the
Test Case Editor.

You can’t add a Test Case to itself as an Event Handler,

because this would create an infinite loop.

164 April 15, 2014 UserManual V8.0.00170

Tasks

4. You can optionally add a name for the Event Handler that
will be used as the referenced name for this Event Handler.

5. Select an event type from the combo box ( → page 165) .

6. Select a reentry type from the combo box ( → page 165) .

For each Test Case you can only add one Event Handler
for each event type.

7. Click ”OK”.

8. The Event Handler appears in the lower half of the Test

Case Editor. Event Handler

9. Save the changes in the editor.

3.21.2 Event types

The event type is the type of error the Event Handler will react
to. There are four event types. They correspond to common
errors which happen during test execution.

Component not found If a component in the AUT cannot

be found, an error occurs. The component might not be
found if it has been changed, is not (yet) visible or has been
deleted.

Check failed For some actions, you can specify an expected

value to check. If the value you specify is not true, then a
check failed error occurs.

Action error Action errors occur when an action cannot be

carried out on a component, when the data is invalid (e.g.
an invalid menu path) or when an action takes too long
and there is a timeout.

Configuration error Configuration errors occur when there

is an internal problem, for example a changed implemen-
tation class in the XML file.

3.21.3 Reentry types

The reentry type specifies how the test should continue once
the Event Handler Test Case has been executed.

UserManual V8.0.00170 April 15, 2014 165

 Functional Testing User Manual

Break The test execution leaves the Test Case in which the
error occurred and continues at the next Test Case or Test
Step.

Continue The test execution carries on at the next Test Case

or Test Step. This is a good option when the error is rela-
tively unimportant and does not affect the following Test
Steps.

Exit The test execution is stopped. Use this when the error is
so severe that the test cannot be continued.

Return The test execution leaves the Test Case in which the
activated Event Handler is nested. This could be the current
Test Case or one higher up in the hierarchy. This option is
useful if you have a use case, which contains Test Cases to
test a particular area or function. You can decide to leave
this part of the test, and carry on at the next use case.
Return will continue at the next Test Suite in a Test Job if
it is activated as a default Event Handler or if there are no
further steps in the current Test Suite.

Pause The test execution is paused. To restart the test, click

the pause button in the toolbar in the ITE.

Retry The failed Test Step is repeated as many times as you

specify in the Properties View. If the Test Step is successful
on repeating, it is marked as successful after retrying. If the
Test Step fails on all retries, the error type is passed on to
the next parent Test Case and this Test Step (and therefore
the test) is marked as failed.

166 April 15, 2014 UserManual V8.0.00170

Tasks

3.22 Preferences
Open the preferences dialog (Figure 3.29 → page 167 ) by
selecting:
Window → Preferences .

3.22.1 Test preferences

Figure 3.29: Preference Dialog

In the preferences dialog, select Test from the tree on the left
hand side.
From this page, you can configure your preferences for:

Auto-scrolling and -expanding: When the checkbox is

marked, the views and browsers automatically scroll in the
direction you move the mouse when you are dragging and
dropping. Trees will also be automatically expanded when
you hover over them while dragging items.

Minimizing the ITE: When the checkbox is marked, the ITE

is automatically minimized when test execution begins.
This is useful if you are letting tests run on the same ma-
chine you are specifying on.

AUT confirmation dialog: When the checkbox is marked, a

dialog appears to check if you are sure when you click the
”stop AUT” button.

Original Test Case name: When the checkbox is activated,

you can see the original name of a referenced Test Case in
brackets behind a new name you enter for the Test Case.

UserManual V8.0.00170 April 15, 2014 167

 Functional Testing User Manual

This can help you to see and search for Test Cases you have
reused.
Test Step information: When this checkbox is activated,
you see the details about the Test Step (the component
name and type, and the action) in square brackets behind
the Test Step name. If you do not want to see these details,
you can deactivate this checkbox.
Show referenced children: When this option is not active,
you can only see referenced parent Test Cases in the Test
Case Browser. The referenced Test Cases contained in
these Test Cases are not displayed. This action can be use-
ful if you want to improve the speed of working with the
ITE.
Project auto load: If you have selected a Project to be au-
tomatically loaded ( → page 38) , then you can stop the
auto-loading by deactivating the checkbox.
Delay for content assist in the Component Names View:
Enter the amount of time in milliseconds you want to wait
after each character entry before displaying content assist
in the Component Names View. Increase the delay to see
the content assist less frequently. You can see the content
assist at any time by pressing »CTRL+SPACE«.
Switching to the Functional Test Execution Perspective:
When the test begins, the ITE can automatically change to
the Functional Test Execution Perspective. You can choose
to always be asked, to always change, or to never change.
Data files location: You can specify a location where ex-
ternal data files (e.g. Excel files) are held, or use the
workspace directory as the base location.

The advantage of using the workspace as a location for

your data files is that you can view these in the navi-
gator view directly in the ITE. Windows users can even
open Excel files from the ITE using the In-Place editor.

3.22.2 AUT Agent preferences

You can find the AUT Agent preference page under:
Test-AUT Agent
in the preferences dialog.

168 April 15, 2014 UserManual V8.0.00170

Tasks

1. In the AUT Agent preference page, you can add, edit and
delete AUT Agents and port numbers.

2. The hostnames and port numbers you enter here are dis-
played in the drop-down list for the ”Connect to AUT
Agent” button on the toolbar. You will be able to con-
nect to these hostnames on these port numbers when you
have started an AUT Agent on them ( → page 21) .

The AUT Agent preference page can also be accessed

from the AUT configuration dialog which you can open
from the Project properties.

3.22.3 Embedded AUT Agent preferences

You can find the preference page for the embedded AUT
Agent under:
Test-AUT Agent-Embedded AUT Agent
in the preferences dialog.
On this page, you can enter the port number that the embed-
ded AUT Agent ( → page 23) should use when you connect
to it ( → page 23) . The default is 60001.

3.22.4 database preferences

You can find the database connection preference page under:
Test-database Connections
in the preferences dialog.
When you start the ITE for the first time, it is automatically
configured to use an embedded database. If this is the only
database configured, then the database login is performed
automatically.
In this preference page, you can configure other database
connections for your productive database.

We do not recommend using the embedded database

for productive use.

UserManual V8.0.00170 April 15, 2014 169

 Functional Testing User Manual

3.22.4.1 Adding, editing and removing database con-

figurations

To add a new database:

1. In the database Connections preference page, click ”Add”.

2. In the dialog that appears, enter a meaningful configura-

tion name.

3. Select the type of database that this configuration is for.

The ITE is thoroughly tested with Oracle. PostGreSQL

and MySQL have been successfully tried out, but we
cannot guarantee their usage in productive environ-
ments.

4. Based on the database type you choose, you must enter

more details about the database connection. Speak to your
database administrator if you are unsure of the connection
details.

You can edit and delete database configurations using the

buttons in the database Connections preference page.

3.22.5 Editor preferences

In the Test - Editors preferences, you can choose whether you
want items (Test Cases and Test Steps) to be placed at the
bottom of the tree or after the selected item when you use
the add option.

3.22.6 Object mapping preferences

You can access the object mapping preferences from Test -
Object Mapping in the preferences dialog.

1. Select whether you want the ITE to display how many

nodes are contained in each category in the Object Map-
ping Editor.

2. Choose which keystrokes or mouse buttons you want to

use to collect components in the Object Mapping Mode.

170 April 15, 2014 UserManual V8.0.00170

Tasks

If your AUT does not accept keystrokes, set the object

collection preference to a mouse button combined with
a modifier key.

3.22.7 Observation mode preferences

The observation mode can only be used for Java AUT’s.

Start/stop check mode: Choose which keystroke you want

to use to start and stop the check mode when you are
observing Test Cases in Java AUT’s.

Check component: Choose which keystroke you want to

use to show the check dialog when you are in check mode.
The check dialog lets you choose what property of the se-
lected component you want to check.

Show console: The console provides information on the ac-

tions that have been observed. This is especially useful if
your AUT is running on a different machine to your client.

Trigger for replace text: Replace text actions are observed

when the focus moves from the text component to an-
other component. Depending on your application, this
may not happen automatically in some situations. Enter
triggers here which you can use to signify that you wish to
observe a replace text action, even if the focus does not
move from the text component.

3.22.8 Test result preferences

You can open the test result preference page by selecting Test
- Test Results from the preference dialog.

1. Choose whether you want the Test Result View to open

when testing begins.
The Test Result View follows the test execution and shows
which Test Steps were successful and which failed.

UserManual V8.0.00170 April 15, 2014 171

 Functional Testing User Manual

2. Choose whether you want to track the test execution

progress in the Test Result View. When this option is
activated, the Test Result View scrolls to follow the test
progress.

3. Choose whether you want to automatically create a

screenshot when a test encounters an error. Screenshots
are automatically saved in the database and can be viewed
using the Image View when you select the failed Test Step
in the Test Result View.

Screenshots are only taken of the primary monitor. Mul-

tiple monitors are not supported for screenshots.

4. Choose whether you want to create HTML and XML re-

ports for each execution. When you activate this choice,
decide whether you want full reports or just the errors to
be shown. Enter a directory for the reports.

5. Decide whether you want all test runs or no test runs to be

marked as relevant, or whether you want to be prompted
each time. Non-relevant test results are not exported with
the Project, are not considered for any BIRT reports ( →
page 247) and do not save details to be reported to exter-
nal ALM repositories ( → page 200) .

6. Enter the amount of days that test result summaries should

be displayed for. This gives you a better overview of the
most recent results in the Test Result Summary View.

3.22.9 Importing and exporting database

preferences
You can export and import your database preferences for the
ITE. This makes migrating to new versions easier, as you do
not have to reenter any database preferences.
To export your database preferences:

1. Select:
File → Export
from the main menu in the ITE.

2. In the dialog that appears, select: General/Preferences and

click ”Next”.

172 April 15, 2014 UserManual V8.0.00170

Tasks

3. Select the Database Connections option and browse to a

place in the file system where you want the preferences to
be saved.

4. Click ”Finish”.

To import your database preferences:

1. Select:
File → Import
from the main menu in the ITE.

2. In the dialog that appears, select: General/Preferences and

click ”Next”.

3. Browse to the preference file you wish to import.

4. Select the Database Connections option and click ”Finish”.

3.22.10 Label decoration preferences

You can open the label decoration preferences by selecting
General - Appearance - Label Decorations from the preference
dialog.
From this preference page, you can alter your preferences for:

Completeness Check Decorator: We recommend leaving

this decorator active, as it shows you red crosses and
tooltips in the Test Suite Browser when Test Suites and Test
Jobs are incomplete.

Test Result Duration Decorator: Deactivate this option to

not see the execution time required for each node in the
Test Result View. The times shown are for the execution
of each node, including its children. You can use this infor-
mation to see whether specific Test Cases are taking longer
than you expect them to.

Test Result Parameter Decorator: Deactivate this option to

not see the parameter values used at this node (i.e. either
entered at this level, or actually used at this place) in the
Test Result View. You can use this information to easily see
which data were used for your Test Cases, without hav-
ing to click through each individual node in the Test Result
View. This can be especially useful if you have one Test
Case that runs multiple times with different datasets.

UserManual V8.0.00170 April 15, 2014 173

 Functional Testing User Manual

3.22.11 Workspace preferences

You can find the workspace preferences under:
General/Startup and Shutdown/Workspaces
in the preferences dialog (Figure 3.34 → page 176 ).
Here, you can specify whether or not to see the workspace
prompt when starting the ITE.
You can also configure how many workspaces to see in your
recent workspaces list, and remove any you no longer wish to
see.

3.22.12 General/Keys preferences

In the General preferences, you can select the Keys option
to be able to edit the key binding for shortcuts in the ITE.
Here, you can create your own shortcuts or alter the current
shortcuts.

3.22.13 Help preferences

1. Choose whether you want to have help displayed in an
external browser. This lets you see more information at
once.

2. For context-sensitive help for windows and dialogs, choose

how you want the help to appear.

3. Choose how many search results should be shown when

searching through the help system.

174 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.30: AUT Agent Configuration Dialog

Figure 3.31: Object Mapping Preference Dialog

Figure 3.32: Observation Mode Preference Dialog

UserManual V8.0.00170 April 15, 2014 175

 Functional Testing User Manual

Figure 3.33: Test Result Preference Dialog

Figure 3.34: Workspace Preferences

176 April 15, 2014 UserManual V8.0.00170

Tasks

3.23 Observing Test Cases

The ITE offers an Observation Mode to help you get started
with your tests. For more information on using the Observa-
tion Mode and best practices for writing tests, please read the
following sections.

The Observation Mode only supports Java (Swing,

SWT/RCP) AUT’s. GEF components in RCP AUT’s cannot
be observed.

3.23.1 Tips and tricks for using the observa-

tion mode
We have designed the observation mode to help you get
started with your tests and to help you understand what sort
of user actions correspond to actions in the library.
The ITE is first and foremost a keyword-driven tool, and the
library of Test Cases installed means that you have various
benefits over simple recording:

• You can create tests without needing the AUT - you don’t
have to wait for each version of the AUT to begin test spec-
ification.

• Your tests aren’t so dependent on the actual implementa-

tion of the AUT, so they can be a lot more general in terms
of data, component implementations etc. and therefore a
lot more robust and maintainable.

• Using keywords encourages you to think about your test

structure a lot more, which also helps maintenance later.

Nevertheless, we understand that you may want to observe

some Test Cases. Here are some tips that might help you:

• Think about your test structure at the beginning: what

modules will you want to reuse? Start by observing small
Test Cases, e.g. a Test Case to login, a Test Case to open a
dialog etc.

• Check while you are observing that the actions you carry
out are observed in the way you meant.

UserManual V8.0.00170 April 15, 2014 177

 Functional Testing User Manual

• Supplement your observed Test Cases with other Test Cases

from the library of Test Cases installed.

• Refactor as you go! If you have recorded a Test Case with

specific data, but you will want to use it for any type of
data, then add a reference for the data.

3.23.2 Starting observing

To be able to observe Test Steps, you must:

• define an AUT ( → page 47)

Only Java AUT’s can use the observation mode.

• configure an AUT ( → page 50) if you want to start it

from the ITE.

• set the working language to the language you want to

observe in.

• start the AUT you want to observe from ( → page 154) (ei-
ther via a configuration ( → page 50) or using the autrun
command ( → page 55) ).

Once you have completed these steps, you can select the ”ob-
start observation serve Test Case” button on the main toolbar.

1. When asked, enter a name for the observed Test Case.

2. The status bar will show that you are in the observation
mode.

3. A Test Case Editor for the observed Test Case will appear.

4. Switch to the AUT and activate it by clicking once in the

title bar.

5. You can now observe Test Steps.

If you have a Test Case open in the Test Case Editor, the
Test Steps will be observed into this open Test Case.

178 April 15, 2014 UserManual V8.0.00170

Tasks

3.23.3 Observing tests in Java AUT’s

If you have not already done so, we recommend reading

the tips section for the observation mode before begin-
ning observing ( → page 177) .

1. In Java AUT’s (Swing and SWT/RCP, but not GEF com-

ponents in RCP) the observation mode will automatically
record your actions in the user interface. Each action is
created as a Test Step in the Test Case Editor for this ob-
served Test Case.

See the section later on performing check actions in the

observation mode ( → page 181) .

2. You can also see which actions have been recorded in the
console (Figure 3.35 → page 179 ).

Figure 3.35: The observation console

If you are creating tests for SWT and RCP AUT’s, check
that you have set the keyboard layout correctly in the
Project properties ( → page 58) and that you have de-
fined the right toolkit for the Project ( → page 33) .

3. Component names for your components are automatically

generated and assigned to the technical names from the

UserManual V8.0.00170 April 15, 2014 179

 Functional Testing User Manual

AUT when you observe Test Steps. If you have already cre-
ated and mapped a component name for a technical com-
ponent, this name will be used instead of creating a new
one.

4. Once you have recorded the actions you need, stop the
observation mode by clicking on the ”stop observing Test
stop observation Case” button on the main toolbar.

5. Save the Test Case editor containing the Test Steps you
have just observed.

6. Check the Test Steps and their parameter values which

have been recorded. You will notice that any text that
contains non-alphanumeric characters is enclosed in sin-
gle quotes. Single quotes are used to cancel any meaning
of the characters within the quotes.

Run the test that you have just recorded to see if it

works as you intended. If not, you may need to make
some changes to the parameter values, or you may have
to supplement the Test Case with Test Cases from the li-
brary ( → page 82) .

3.23.3.1 Actions that cannot be recorded

A few actions cannot be recorded in the current version.

These include:

• Key combinations that are used as shortcuts in SWT appli-

cations.

• Click counts on trees. The select actions are correctly

recorded, but the click count is set to 0 and must be man-
ually adjusted.

• Components that contain texts that are too long (more

than 3999 characters).

• Actions on native dialogs e.g. file choosers.

• Actions in the figure canvas for GEF components.

180 April 15, 2014 UserManual V8.0.00170

Tasks

3.23.3.2 Performing checks in the Java observation

mode

You can perform checks in the observation mode by taking

the following steps:

1. Start the check mode by pressing »CTRL+SHIFT+F11«. This

key combination can be changed in the preferences ( →
page 171) .

2. In the observation console, the check mode will be marked

as on.

3. In the AUT, components will be highlighted with a red bor-

der (Figure 3.36 → page 181 ).

Figure 3.36: Red borders in the check mode

While the check mode is active, no other actions will be

recorded.

4. Hover over the component you want to execute a check on

and press »CTRL+SHIFT+F12«. This key combination can be
changed in the preferences ( → page 171) .

5. A dialog will appear showing the type of component you

are performing the check on.

6. From the dialog, select the check action you want to per-
form and enter any parameters the check action needs.
Many check actions have predefined parameters based on
the state of the AUT.

7. When you have specified your check action, choose

whether you want to close the dialog and continue in the

UserManual V8.0.00170 April 15, 2014 181

 Functional Testing User Manual

check mode (check on) or whether you want to stop the

check mode when the dialog closes (stop checking).

You can manually stop the check mode using the same
key combination as you used to start the check mode
(»CTRL+SHIFT+F11« by default).

8. The check action you specify will be added to the Test Case
Editor.

182 April 15, 2014 UserManual V8.0.00170

Tasks

3.24 Working with the Problem View

3.24.1 The Problem View

The Problem View (Figure 3.37 → page 183 ) is in the middle
of the specification perspective, at the bottom, by default.
It shows three types of message:

• Information information

• Errors error

• Warnings warning

Right-clicking on a message and selecting Quick Fix will either

solve the problem or take you to the place where you can
solve the problem, if this is possible.

Figure 3.37: Problem View

UserManual V8.0.00170 April 15, 2014 183

 Functional Testing User Manual

3.25 Working with the Teststyle

guidelines
Teststyle lets you perform static analysis of your tests to make
sure they conform to conventions and best practices. For any
guidelines you have set in the Project, Teststyle will inform
you if they are not being upheld by displaying information,
warnings and errors in the Problem View. Elements in the
Project where warnings and errors are present are decorated
with the yellow warning symbol and the red error cross.
The Teststyle guidelines available reflect best practices and
conventions from working in a variety of Projects. They in-
clude guidelines on naming conventions to make tests easy to
read, easy to incorporate into build processes, structural con-
ventions for your Projects and test design guidelines to make
tests maintainable and understandable.

3.25.1 Activating Teststyle for a Project

You can activate Teststyle for a Project in the Project proper-
ties:
1. Open the Project properties via:
Test → Properties
2. Select Teststyle from the left.
3. Using the checkbox at the top of the dialog (Figure 3.38
→ page 188 ), you can centrally activate or deactivate Test-
style for the whole Project.

By default, Teststyle is activated for all Projects.

4. Click ”OK” in the Project properties to save the changes.

5. If your current Project flouts any of the guidelines that are
set, then you will see entries in the Problem View notifying
you of the places where guidelines are being flouted. For
more information on working with the Problem View to fix
tests, see the section later ( → page 187) .

The Teststyle settings are central for the whole Project

and will be seen by all users of the Project.

184 April 15, 2014 UserManual V8.0.00170

Tasks

3.25.2 Configuring Teststyle for a Project

When Teststyle has been activated for a Project ( → page 184)
, you can configure:

• which guidelines should be used ( → page 185)

• what kind of a message a flouted guideline should show

(information, warning or error) ( → page 186)

• the attributes for a guideline ( → page 186)

• the contexts a guideline should be active for ( → page

187)

3.25.2.1 Activating and deactivating individual guide-

lines

In the Project properties, under the Teststyle section, you can

activate and deactivate guidelines for use in the Project:

1. When Teststyle is enabled for the Project ( → page 184) ,

select the checkbox for an individual guideline to activate
it for the Project.

2. Deselect a checkbox to deactivate the guideline.

When you select a guideline, the description text gives

you more information on what the guideline is for.

3. You can (de)select all the guidelines in a category by acti-

vating or deactivating the checkbox for the category name.

4. You can also use the buttons ”Select All” and ”Deselect
All” to (de)select all the guidelines.

5. Click ”OK” in the Project properties to save the changes.

6. If your current Project flouts any of the guidelines that are

set, then you will see entries in the Problem View notifying
you of the places where guidelines are being flouted. For
more information on working with the Problem View to fix
tests, see the section later ( → page 187) .

UserManual V8.0.00170 April 15, 2014 185

 Functional Testing User Manual

3.25.2.2 Setting the message level for guidelines

For each guideline in the Project properties, you can decide

how you want to be notified that the guideline is not being
upheld.
The choices available are:

Information: Information is shown in the Problem View us-

ing a blue icon. Elements in the test are not decorated with
information messages.

Warning: Warnings are shown in the Problem View using a

yellow icon. Warnings are also shown on elements in the
test (e.g. Test Cases.

Errors: Errors are shown in the Problem View using a red

icon. Warnings are also shown on elements in the test (e.g.
Test Cases, Test Suites. If a Test Suite contains a Teststyle
error, it will not be executable via the ITE.

To set the message level for a guideline:

1. In the Project properties, under the section Teststyle, select

the guideline you want to configure.

2. In the combo-box on the right-hand side, select the level of

message you want to receive if this guideline is not upheld.

3. Click ”OK” in the Project properties to save the changes.

3.25.2.3 Configuring the attributes for guidelines

For many of the guidelines in the Project properties, you

can define the values or quantities for the aspects it checks.
For example, you can edit the attribute Maximum number
of parameters for the guideline that specifies the maximum
amount of parameters on a Test Case.
To edit the attributes for a guideline:

1. In the Project properties, under the section Teststyle, select

the guideline you want to configure.

2. Click ”Edit attributes” to open the attributes dialog.

3. In the dialog (Figure 3.39 → page 188 ), you can see and
edit the values for any editable attributes for this guideline.

4. Confirm your changes in this dialog using ”OK”.

186 April 15, 2014 UserManual V8.0.00170

Tasks

5. Click ”OK” in the Project properties to save the changes.

If you enter an invalid value, the default value will be

used in its place.

3.25.2.4 Configuring the contexts for guidelines

For many of the guidelines in the Project properties, you can

set the contexts they should be valid for. Some of the available
contexts include Test Cases, Test Suites, or the whole Project.
To edit the context for a guideline:

1. In the Project properties, under the section Teststyle, select

the guideline you want to configure.

2. Click ”Edit context” to open the context dialog.

3. In the dialog (Figure 3.40 → page 191 ), you can see and
edit any available contexts for this guideline.

4. To activate a context, select the checkbox next to it. To

deactivate a context, deselect its checkbox.

5. Confirm your changes in this dialog using ”OK”.

6. Click ”OK” in the Project properties to save the changes.

If you enter an invalid value, the default value will be

used in its place.

3.25.3 Working with the Problem View to

view and fix Teststyle problems
Once you have activated ( → page 184) and configured (
→ page 185) Teststyle for a Project, you will be informed
when your chosen guidelines are not being upheld. The cen-
tral place for viewing your Teststyle information, warnings and
errors is the Problem View.
For each Teststyle message, you will see an entry in the Prob-
lem View, with the information on where the guideline is not

UserManual V8.0.00170 April 15, 2014 187

 Functional Testing User Manual

Figure 3.38: Teststyle

Figure 3.39: Edit Attributes

188 April 15, 2014 UserManual V8.0.00170

Tasks

being upheld. You can use the Problem View to view the rule
that has been flouted and also to fix the problem using the
Quick Fix option.

3.25.3.1 Viewing the broken Teststyle rule from the

Problem View

1. Select the entry in the Problem View whose rule you want
to view.

2. Right-click in the Problem View and select:

Show Teststyle Rule
from the context-sensitive menu.

3. The Project properties dialog appears, opened at the Test-

style page. The guideline that resulted in the entry in the
Problem View is selected.

4. From here you can adapt the guideline if required ( →

page 185) .

3.25.3.2 Using Quick Fix to fix the problem

1. Select the entry or entries you want to work on from the

Problem View.

2. Right-click in the Problem View and select:

Quick Fix
from the context-sensitive menu.

3. The Quick Fix dialog Figure 3.41 → page 192 will appear
with the options available to fix the problem. The options
may range from opening an editor to automatically fixing
the problem.

4. Select the option(s) you want to carry out and click ”OK”.

5. The option(s) you chose will be executed.

3.25.4 Working with the Teststyle rules

The Teststyle rules are categorized according to the area of
test specification they deal with.

Naming: The guidelines in this category deal with naming

conventions for items you use in your tests.

UserManual V8.0.00170 April 15, 2014 189

 Functional Testing User Manual

Specification: These guidelines give you assistance with best

practices for writing your tests.

Structure: In this category, advice is given on categories and

Test Suite types that are helpful.

You can see a description of each category and guideline by

selecting it from the dialog.

190 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.40: Edit Contexts

UserManual V8.0.00170 April 15, 2014 191

 Functional Testing User Manual

Figure 3.41: Quick Fix

192 April 15, 2014 UserManual V8.0.00170

Tasks

3.26 Working with Metrics

The Analysis framework lets you run metrics on your Project.
In the current version, three example metrics are included
which can be run on the whole Project or on parts of it.
The analyses and metrics can either be run for the whole
Project, or for specific contexts within the Project.
To run a metric or analysis for the whole Project, select the
metric or analysis you want to perform from the toolbar but-
ton.
To run a metric or analysis for a specific context, select the
context you require (e.g. the top node in the Test Case
Browser to perform the metric or analysis just for items within
this browser) and then select:
Analyze
from the context menu, selecting the required option to run.
Once a metric or analysis has run, the results are shown in the
Search Result View.
The following metrics and analyses are available:

3.26.0.1 Numeric Project Element Counter

This metric is in the category Numerical Metrics.

This metric counts the amount of items in a Project according
to the following rules:

Test Cases: How many individual Test Cases have been cre-
ated.

Test Suites: How many individual Test Suites have been cre-
ated.

Test Jobs: How many individual Test Jobs have been created.

Test Steps: How many individual Test Steps have been cre-
ated, plus how many Test Steps have been used from any
reused Projects. Test Steps are only counted once for the
place they are specified (or, in the case of Test Steps from
reused Projects, reused). They are not counted transitively
(i.e. if a Project contains a Test Case with one Test Step,
and this Test Case is reused four times, there is still only
one Test Step.

Referenced Test Cases: How many separate (not transitive)

Test Case references there are in the current scope. If a

UserManual V8.0.00170 April 15, 2014 193

 Functional Testing User Manual

Test Case TC1 is reused twice in a Test Case TC2, then the
number of reuses for TC1 is two, regardless of how many
times TC2 is reused.

Event Handlers: How many Event Handlers are used in the

current scope. The same rules for non-transitivity apply -
if TC1 contains an Event Handler, then this Event Handler
is only counted once, regardless how many times TC1 is
reused.

Categories: How many categories are created in the current

scope. Only categories in the Test Case Browser and Test
Suite Browser are currently counted.

The results are shown in the Search Result View.

3.26.0.2 Ratio general : specific

This metric is in the category Numerical Metrics.

This metric calculates the amount of Test Cases or Test Steps
used that are generally available for all toolkits (the ”con-
crete” actions). It then counts the amount of actions used
that are specific to one or more particular toolkits (e.g. spe-
cific to the RCP toolkit or the HTML toolkit). The results are
presented as percentages in the Search Result View.
Wherever possible, it is preferable to work with more general
actions than specific. This metric may help you to gauge how
well you are keeping to this guideline.

3.26.0.3 Empty chains analysis

This analysis is in the category Analysis.

This analysis examines the current scope for test hierarchies
wherein a Test Case is reused in one place – alone in another
Test Case. This Test Case is then also reused in one place –
again alone which is then reused in one place alone in another
Test Case and so on. Such hierarchies can often be redundant:
the Test Case at the bottom of the hierarchy could just as well
have been reused directly in the Test Case at the top of the
hierarchy.
Such empty chains are collected during the analysis (which
may take longer on larger Projects) and displayed in the Search
Result View. They are shown in order of their length, starting
with the longest chains.

194 April 15, 2014 UserManual V8.0.00170

Tasks

3.26.0.4 Waits and delays

This analysis can be performed on Test Result Reports in the

Functional Test Execution Perspective and in the Functional
Test Reporting Perspective. Select a node you want to analyze
and select:
Analyze → Waits and delays
from the context-sensitive menu.
The analysis examines the selected node and the nodes below
it in the Test Result Report for all instances where a wait is
performed. This can be the action ”Wait” or it could also be
the parameters ”Delay after...” or ”Delay before...”. Basically,
any time a static wait (i.e. not a timeout) is performed, then
this is analyzed.
You can define a parameter for the analysis which specifies
the minimum value of waits to be analyzed (in milliseconds).
If you enter e.g. 5000, then only waits above 5000ms will be
shown in the results.
Once the results have been calculated, they are shown in the
Search Result View. They are organized according to the ac-
tion that the wait is contained in. The amount of waits cor-
responding to each action is shown in brackets behind the
action name. On the right hand side of the Search Result
View, the cumulative values for the amount of waits for each
action are shown. The number on the left is the total amount
of waits that correspond to the parameter value entered. The
number on the right shows the total amount of waits for this
action, regardless of the parameter. In this way, it is easier to
see whether your tests have a few very large waits, or many
smaller waits.

Double click on one of the wait actions to jump to this

place in the test Result View.

UserManual V8.0.00170 April 15, 2014 195

 Functional Testing User Manual

3.27 Working with external task

repositories (ALM Integration)
The ITE is integrated with the Eclipse Mylyn Project to allow
you to:

• Connect your ITE (via the workspace) to external task

repositories.
• View, work on and edit tasks directly in the ITE.
• Create tasks directly in the ITE.
• Integrate your tests with application lifecycle management
(ALM) tools to provide information on the automated tests
performed for specfic features or releases. We have tested
the integration with Jira, Bugzilla and HP ALM.

The Mylyn online help is included in the installation.

Select:
Help → Help Contents
in the ITE to see the Mylyn help.

3.27.1 Configuring task repositories in your

workspace
Each repository you want to work with in your ITE must be
configured in the workspace you are using.

1. Select:
Window → Show View → Other
from the menu.
2. In the Mylyn section, select Task Repositories and click
”OK”. The Task Repositories View will appear. The Bugzilla
Repositories for GUIdancer and Jubula are pre-configured.
3. In the Task Repositories View, right click and select Add
Task Repository from the context menu.
4. In the dialog that appears, you will see the pre-defined
task repositories for the ITE. You can select one of these
or choose to install a different connector. Depending on
the connector you want to use, you may require additional
software from Tasktop, or the connector may incur license
fees. If you want to connect to a HP ALM repository, please
follow the instructions below ( → page 197) .

196 April 15, 2014 UserManual V8.0.00170

Tasks

5. Once you have selected your connector, click ”Next”.

6. On the following page, you will need to configure the task

repository. Please refer to the Mylyn documentation for
information on repository configuration.

7. Click ”Finish” once the repository is configured.

8. To be able to see tasks in this repository, select:

Window → Show View → Other
from the menu.

9. In the Mylyn section, select Task List and click ”OK”. The
Task List View will appear.

You will now be able to see items in this repository, open

them in the ITE, add queries for your workspace and work on
tasks from this repository. You will also be able to select this
repository in the Project properties as the repository for your
Project ( → page 200) .

3.27.1.1 Adding a HP ALM repository to your

workspace

1. To add the connector for a HP ALM repository, you will

have to install and license software from Tasktop.

2. Once you have a Tasktop account and a license for HP

ALM, you can install and use the HP ALM connector.

3. On the www.tasktop.com website, select Downloads and

locate the Tasktop Dev product.

4. Select the option to download the plugin.

5. Follow the instructions on the Tasktop website to install the

the plugin into your ITE. You will require the Tasktop Dev
Enterprise for the HP ALM connector.

6. When prompted to restart the ITE automatically, say No

and then restart the ITE manually via the menu.

7. When the ITE is restarted, you will be prompted to enter

your account details for Tasktop.

8. Once you have entered your information, you will be able

to configure the repository via the Task Repositories view.

UserManual V8.0.00170 April 15, 2014 197

 Functional Testing User Manual

3.27.2 Working on tasks in the ITE: contexts

Once you have configured a task repository for your
workspace ( → page 196) , you can work on tasks from that
repository.

3.27.2.1 Opening and editing tasks in the ITE

• To be able to see tasks in a repository, select:

Window → Show View → Other
from the menu.

• In the Mylyn section, select Task List and click ”OK”. The
Task List View will appear.

• Double-click on a task to open this task in the editor area.

• Once a task is open, you can work on it as you would in

an external system – add comments, change status etc.

3.27.2.2 Working on tasks in the ITE

Mylyn supports context- or task-based working. When you

work on a task, you only see items relevant to that task,
so that coming back to the task later involves less context-
switching.

• Mylyn supports context-based working. You can work on

existing tasks in a configured repository, or you can create
tasks to work on.

• To work on a task, you must activate it. To activate a task,

select the task in the Task List and select:
Activate
from the context-sensitive menu.

• When you activate a task for the first time, the browsers
and editors will seem very empty. This is because nothing
is yet a part of the context for this task.

• You can navigate through the browsers by pressing

»ALT+CLICK« to expand each level, or you can press the
Focus on task button in the browsers to show the whole
tree (not focusing on the task), or just the items in the cur-
rent context (focusing on the task).

198 April 15, 2014 UserManual V8.0.00170

Tasks

• Items are automatically added to your context when you

select them in a browser, when you open them in an edi-
tor, or when you perform other actions that cause them to
be made relevant (e.g. Test Case creation, showing a Test
Case specification etc.). Items that are used particularly
frequently are marked as landmarks and shown in bold.
• You can manually alter which items are in your context
using the context-sensitive menu for a specific item. You
can manually make items landmarks, or remove them from
the context.
• The context that is created for you will be re-created when
you reactivate the task at a later point.

3.27.3 Creating tasks in external repositories

from test result reports
You can create a new task with pre-filled information directly
from an open test result report in the Test Result View. This is
useful if a test has failed and you want to create e.g. an issue
in your bug-tracking system for the failure.
1. In an open test result report, select the node that best de-
scribes the test failure (e.g. a Test Case or Test Step that
has failed, or the whole Test Suite, then right-click and se-
lect:
Create a Mylyn Task
from the context-sensitive menu.
2. In the dialog that appears, select a repository in which
to create the task. A local repository is available by de-
fault, but you can also add connections to Bugzilla and
Trac repositories by clicking ”Add Task Repository” in the
New Task Dialog. Connectors to other repositories can also
be added. See the Mylyn documentation for more details
on adding repositories.
3. Click ”Finish” once you have selected your repository.
4. The editor for a new task will appear. It is pre-filled with
information relevant to the node that you selected. Edit
the task to make it descriptive enough for a bug report
and save the editor.
5. Once you have created a task, you can activate it to start
saving your context for this task. See the later section ( →
page 198) for details.

UserManual V8.0.00170 April 15, 2014 199

 Functional Testing User Manual

3.27.4 Automatically reporting to external

repositories after test runs
You can automatically report the status of an automated test
to an external system. The reporting is achieved by writing a
comment on a task in the external repository. The comment
includes a link to the test result in the dasboard.

3.27.4.1 Configuring a task repository for your Project

Once you have configured one or more repositories for your

workspace ( → page 196) , you can select one of these to be
the test-relevant repository for your Project.
This will let you:

• Add a task ID from this repository to Test Cases and Test

Suites in the Project to signify that this item is the test for
this task ( → page 201) .

• Automatically report test results to the task defined when

a test runs.

• View the test results for the relevant item in the dashboard
as a link from the task repository.

To configure a task repository for your Project:

1. In the Project Properties, select Mylyn ALM from the tree

on the left Figure 3.42 → page 201 .

2. In the page that appears, you can select a repository from

the combo-box. You can validate the repository settings
using the button.

3. You can then choose whether to only report failed tests,

only report successful tests, or both.

4. Enter the URL of the Dashboard that is configured to use

the correct database for your test results. This is the Dash-
board that will be opened when you click on a test result
link from the task repository. For more information on con-
figuring and starting the Dashboard, see the documenta-
tion ( → page 227) .

200 April 15, 2014 UserManual V8.0.00170

Tasks

Figure 3.42: ALM Settings

3.27.4.2 Adding task IDs to Test Suites and Test Cases

You can add a task ID to Test Cases and Test Suites in your
Project.
The task ID should be a valid ID in the repository that you
have specified as the repository for this Project ( → page 200)
. Adding the task ID to an item in your Project means that this
item is the relevant test for that task in your repository. You
will be able to report test results for this item as a comment to
the task in the repository. The comment will include a link to
the dashboard, in which the test result report can be viewed.
To add a task ID to a Test Case or Test Suite:

1. Open the item in the editor by double-clicking it.

2. In the Properties View, in the cell for Task ID, enter the task
ID from the external repository. You can only enter task IDs
at the place of specification – you cannot overwrite them
when you reuse the item.

3. Save the editor.

4. When you have added a task ID to a node, you can open

the task for this node from the browser by selecting:
Open with → Mylyn Task Editor

UserManual V8.0.00170 April 15, 2014 201

 Functional Testing User Manual

You should ensure that you add task IDs to the right
node-level to provide you with the relevant amount of
information for the tasks in your repository. This will
usually be at the level of Use Cases within a Test Suite.

3.27.4.3 Test execution with reporting to external

repositories

If your Project is joined to an external repository ( → page

200) , and you have added task IDs to one or more items in
your Project ( → page 201) , then you will be able to report
the test results to the repository after the test has run. The
test run can be either via the ITE or via the command line
testexec.

If you run a test via the ITE which should report to ALM
systems, the reporting is triggered automatically once
the test has run. If the reporting for the test run encoun-
ters an error, then you will be able to manually trigger
the reporting later ( → page 203) . To report to ALM
systems after running a test via testexec, you must also
manually trigger the recording ( → page 203) .

When reporting is triggered, the following happens:

• A connection is made to ALM system configured in the

Project properties.
• The test results are then analyzed to see if any comments
need to be added in the external repository (commenting
can be (de)activated for failed nodes or successful nodes in
the Project properties, for example).
• If there are comments to be added, the ITE writes one com-
ment per task, as defined in the Project properties. If multi-
ple items in one test run reference the same task ID, or if an
item with a task ID is executed multiple times in the same
test run, then each test status and result link is written, but
all in one comment.

Tests that have a status other than passed (e.g. failed,

stopped, still testing) are considered as failed.

202 April 15, 2014 UserManual V8.0.00170

Tasks

• You can see the status of the ALM reporting in the console
view.

• Once a comment has been written, you can see the com-
ment in the external repository. From there, you can click
on the link provided to open the test result report in the
Dashboard that you specified for your Project. The Dash-
board must be already running for this action to succeed.
The test results must also still be present in the database (
→ page 161) .

• The test result report is opened at the node which refer-

enced the current task ID.

• You can see the status of the reporting in the Test Result
Summary View ( → page 203) .

The integration for writing to external repositories can

be used with Bugzilla 3.6+, JIRA 5.0+ and HP ALM 11+.
Other repositories for which there are Mylyn connectors
may also work, but these have not been tested.

Reporting to ALM repositories after a test started via

testexec For tests started via testexec, the reporting does not
happen automatically. Instead, you must choose to report to
ALM from the Test Result Summary View.

1. In a Project that is configured to report to an ALM repos-

itory, when a test has run via testexec, you can open the
Reporting Perspective and locate the test run in the Test
Result Summary View.

2. In the ALM Report Status column, you will see whether

there are any reports pending. You can see various statuses
in this column:

Not configured: if you have not configured ALM report-

ing for the Project, or if the relevance of the test run was
set to false when the test was started.
Not yet reported: if reporting was configured for the
Project, and there is information available to be reported
that has not yet been reported, e.g. from a test run via
testexec. You will also see this status if you have run
a test via the ITE that could not report to the ALM sys-
tem due to e.g. a connection problem. This allows you

UserManual V8.0.00170 April 15, 2014 203

 Functional Testing User Manual

to report test results later, once the problem has been

resolved.
Reported: this status will be shown if you have run a test
with reporting configured via the ITE, which reports au-
tomatically. It will also be shown if you have chosen to
report to the ALM system after running a test via tes-
texec. This status will also be shown even if the test run
was not linked to any tasks, but reporting is configured
for the Project. It can be understood as any reporting
that was necessary has been carried out.
Report discarded: if reporting information was available,
but the information was discarded and therefore not re-
ported. You can do this by selecting the option to dis-
card a pending report from the context menu. This sta-
tus will also be shown for any test runs in a Project that
you import that had the status Not yet reported when
the Project was exported.
Marked as non-relevant: you will see this status for any
test runs that were marked as relevant when the test
was started and which have information to report (sta-
tus: Not yet reported),but which you then mark as non-
relevant by toggling the relevance in the Test Result
Summary View. This status means that you could report
or discard the information, but only if you re-toggle the
test run to be relevant.

3. Select any test runs whose results you want to report to

ALM, and click on the ”Report to ALM” button on the
toolbar. You can also select this option from the context-
sensitive menu. If you select multiple test runs, the report-
ing will take place sequentially for each test run.

4. When you select this option, the reporting will be triggered

as described above. If the reporting is successful, the status
in the ALM Report Status column changes from Not yet
reported to Reported. If an error occurs, then the status
remains as Not yet reported.

5. If you do not want to report the test results to an ALM tool,

you can discard the reporting information by selecting the
option to discard a pending report from the context menu.
This changes the status in the ALM Report Status column
from Not yet reported to Report discarded.

204 April 15, 2014 UserManual V8.0.00170

Tasks

3.27.4.4 Specific information for HP ALM users

• To use the HP ALM integration, you must use a sepa-

rate connector for HP ALM which may incur license costs.
Visit the Tasktop website for more details http://www.
tasktop.com.

• If you have changed the attribute IDs in your HP

ALM installation for defects and / or requirements
from their relative defaults (BG_DEV_COMMENTS and
REQ_DEV_COMMENTS), or if you have changed the ID for
the connector, then you must modify these properties in
the almAccess.properties file contained in the jar:
org.eclipse.jubula.client.alm.mylyn.core

• Since tasks in HP ALM only have one comment field, the re-
sult information is appended to the comment field instead
of being added as a new comment each time.

• To write to requirements in a default HP ALM installation,

you must use the prefix REQ, e.g. REQ100. To write to
defects in a default HP ALM installation, you must use the
prefix DEF, e.g. DEF42.

UserManual V8.0.00170 April 15, 2014 205

 Functional Testing User Manual

3.28 Adapting the user interface

You can individualize the user interface in various ways.

3.28.1 Moving Browsers, Views and Editors

You can move items in the user interface in two ways:

• Drag-and-drop views or browsers. While the mouse button

is held, the target location is marked by a gray rectangle.
• Right mouse-click on the tab area and select ”Move” and
then either ”View” or ”Tab Group”. Single-click to drop
the item.

3.28.2 Resizing in the user interface

To change the size of the views and browsers:

• Double-click on the tab of a view, browser or editor to

maximize it. Double-click again to minimize it.
• Use the buttons in the top right-hand corner of the view
or browser to minimize, maximize or restore it.
• Drag the borders of the view or browser to enlarge or re-
duce it.
• Right mouse-click on the name of the view or browser and
select ”Size” and then the side to be adjusted. The cho-
sen side appears as a blue line which can be dragged and
dropped.
• To turn the view or browser into a separate window, select
”Detached” from the context-sensitive menu of the tab
area.

3.28.3 Restoring user interface defaults

1. You can restore the default perspective at any time:
Window → Reset Perspective .
2. To show or restore individual views or browsers, choose
either the ”restore” icon in the tab for the view or select:
Window → Show View
and then choose which view to display.

206 April 15, 2014 UserManual V8.0.00170

Tasks

3.28.4 Changing perspectives

1. To change between perspectives, select:
Window → Open Perspective .

2. Select which perspective to open.

3. Alternatively, you can use the icons in the top left-hand

corner of the current perspective to toggle between per-
spectives.

3.28.4.1 Automatically changing perspective

By selecting:
Window → Preferences ,
you can choose to automatically change to the Functional
Test Execution Perspective when test execution starts, or to
be asked each time a Test Suite is started.

UserManual V8.0.00170 April 15, 2014 207

 Functional Testing User Manual

3.29 Searching

3.29.1 Searching for and opening the origi-

nal specification of a Test Case or Test
Suite
To find the the original specification of any reused Test Case
or Test Suite:

1. Single-click the Test Case or Test Suite whose specification

you want to find.

2. Right-click on the Test Case or Test Suite and select ”Show

specification” from the context-sensitive menu. You can
also press »F6« to show the specification.

3. The originally specified Test Case or Test Suite will be high-

lighted in the Test Case Browser or Test Suite Browser.

4. You can open the specified Test Case or Test Suite auto-
matically by selecting ”Open specification” or by pressing
»F3«. This also works on the original specification of Test
Cases, Test Suites and Test Jobs in the brosers.

5. If you double-click the Test Case or Test Suite while it is in

an editor, then this will also open the original specification
(as if you had pressed »F3«).

Test Cases and Test Suites that are not visible due to ac-
tive filters in the browser are not displayed when show
specification is used. You can, however, use open speci-
fication to directly open a filtered Test Case or Test Suite.

3.29.2 Searching for places where a Test Case

or Test Suite has been used
To find the places where you have reused a Test Case or a Test
Suite:

1. In a browser or an editor, right-click on the Test Case or

Test Suite whose places of reuse you want to find. You
must have selected the parent (original specification) for
the action to be enabled.

208 April 15, 2014 UserManual V8.0.00170

Tasks

2. Select ”show where reused” from the context sensitive

menu. You can also press »F7« to show the places where
a Test Case or Test Suite has been reused.

3. In the ”Search Result View” ( → page 213) , a list of places

will appear. These are the places where the Test Case or
Test Suite has been reused.

4. Double-click on an icon in the view to highlight and open

the place of reuse.

5. If you are using this option on a Test Case and want to

replace the Test Case you searched for with another Test
Case at some or all of the places where it is reused, you
can start this action from the Search Result View ( → page
88) .

If you select this option on a nested Test Case, you

will be shown the other places where the Test Case is
nested. To see where its parent Test Case is used, you
must then carry out the same steps on the parent.

3.29.3 Searching for places where a compo-

nent name has been used
You can find the places where you have used a component
name from within the Object Mapping Editor and the Com-
ponent Name Browser.
In the Component Name Browser:

1. Select the component name you want to search for and

select:
Show where used
from the context-sensitive menu. You can also press »F7«
to show the places where the name has been used.

2. All the places where you have used this component name
in this Project will be shown in the Search Result View ( →
page 213) . Both Test Cases and object mappings where
the component name was used will be shown.

In the Object Mapping Editor: Show where used:

UserManual V8.0.00170 April 15, 2014 209

 Functional Testing User Manual

1. Select the component name you want to search for and

select:
Show where used
from the context-sensitive menu. You can also press »F7«
to show the places where the name has been used.

2. All the places where you have used this component name
in this Project will be shown in the Search Result View ( →
page 213) .

In the Object Mapping Editor: Show corresponding

specification:
Use this option when a component name appears in the Ob-
ject Mapping Editor that should have been overwritten, but
hasn’t been.

1. Select the component name you want to search for and

select:
Show corresponding specification
from the context-sensitive menu.

2. The Search Result View only shows places which could

have lead to this component name appearing in the Ob-
ject Mapping Editor, not all places in the test where it has
been used.

3.29.4 Searching for places where a central

test data set has been used
You can find the places where you have used a central test
data set from within the Central Test Data Editor:

1. Select the central data set you want to search for and se-
lect:
Show where used
from the context-sensitive menu. You can also press »F7«
to show the places where the data set has been used.

2. All the places where you have used this data set in this
Project will be shown in the ”Search Result View” ( →
page 213) .

3. If you want to change the Test Cases that use this central
test data set so that they use a different column from the
data set, then you can start this action from the Search
Result View ( → page 107) .

210 April 15, 2014 UserManual V8.0.00170

Tasks

3.29.5 Using the search dialog

You can open the search dialog (Figure 3.43 → page 211 )
from the toolbar, by pressing »CTRL+H« or via the menu:
Search → Search

Figure 3.43: Search Dialog

The search dialog allows you to search the current Project in

the current working language for:

• Keywords ( → page 211) (Test Cases, Test Steps, Test

Suites, Test Jobs and categories).

• Test data used in Test Cases or central test data sets ( →

page 212) .

• Files in the workspace ( → page 213) .

3.29.5.1 Searching for keywords (Test Cases, Test

Steps, Test Suites, Test Jobs and categories)
throughout the Project

On the first tab of the search dialog, you can search for the
following based on their name:

• Test Steps

• Test Cases – either the original specification or places

where a Test Case has been reused (referenced)

• Test Suites – either the original specification or places

where a Test Suite has been reused (referenced)

• Test Jobs

• Categories

UserManual V8.0.00170 April 15, 2014 211

 Functional Testing User Manual

Enter the term you wish to search for and select whether you
want the search term to be case sensitive or whether you will
be using regular expressions. You can also specify whether
you want to search in the whole Project, or just for the se-
lected nodes ( → page 213) .
Click ”Search” to start the search. The results are shown in
the Search Result View ( → page 213) .

Only names from within the current Project and in the

current working language are displayed. Names from
reused Projects are not found.

3.29.5.2 Searching for test data

On the second tab of the search dialog, you can search for
test data in the following:

• Central test data sets

• Test Cases – either either the original specification or places

where a Test Case has been reused (referenced)

• Test Steps

The search does not consider the name of the central

test data set, for example, only the data contained in it.

Enter the term you wish to search for and select whether you
want the search term to be case sensitive or whether you will
be using regular expressions. You can also specify whether
you want to search in the whole Project, or just for the se-
lected nodes ( → page 213) .
Click ”Search” to start the search. The results are shown in
the Search Result View ( → page 213) .

Only test data from within the current Project and in

the current working language is displayed. Data from
reused Projects is not found.

212 April 15, 2014 UserManual V8.0.00170

Tasks

3.29.5.3 Searching for files in the workspace

On the third tab of the search dialog, you can search for and
in files contained in your workspace.
Enter the term you wish to search for and click ”Search” to
start the search. The results are shown in the Search Result
View ( → page 213) .

3.29.5.4 Limiting the search to the selected node

In the search dialog, you can specify whether the search you
define should be performed on the whole Project, or just on
the node you have selected in a browser. If you select to just
search within the selected node, then you can define which
browser or browsers to search in (you may have more than
one active selection in your browsers):

Test Suite Browser This search will be limited to the se-

lected item (Test Suite, Test Job, category) in the Test
Suite Browser. If you select the root node in the Test
Suite Browser, then the whole Test Suite Browser will be
searched.

Main Test Case Browser This search will be limited to the

selected item (Test Case, category) in the Test Case
Browser. If you have more than one Test Case Browser
open ( → page 67) , then the one marked as Main will be
used. If you select the root node in the Test Case Browser,
then the whole Test Case Browser will be searched.

All Test Case Browsers If you have more than one Test Case
Browser open ( → page 67) , then the selected nodes in
all of them will be searched.If you select the root node in
the Test Case Browser, then the whole Test Case Browser
will be searched.

You can select one or more of these options to perform the

search.

3.29.6 Using the search result view

The Search Result View shows any items found during a
search – either via the search dialog or the ”Show where
used” action.
From the Search Result View, you can:

UserManual V8.0.00170 April 15, 2014 213

 Functional Testing User Manual

• Double-click on an item to open its editor.

• Re-run the search using the button in the top right-hand

corner of the view.

• Perform various actions on your search results ( → page

214)

3.29.6.1 Using search results to make wide-reaching

changes to your Project

Once you have performed a search, you can perform specific

actions on the results:

• You can replace a Test Case at multiple places where it has

been reused with another Test Case ( → page 88) .

• You can change the column of a central test data set used
by any Test Cases that use this central test data set ( →
page 107) .

3.29.7 Searching for items in editors and

browsers
The ITE offers a search function in most editors and views.

1. Start the search function either via:

Edit → Find
or using the context-sensitive menu in the editors and
browsers.

2. In the find dialog, you can enter the following criteria:

• The text you are searching for.

• The direction you want to search in.
• Whether the search is case sensitive or not.
• Whether you are using regular expressions (→Reference
Manual p. 15).

Regular expression searches are case-sensitive.

• Whether the search should be wrapped. This will carry

on the search from the top of the browser once you
reach the bottom of the browser.

214 April 15, 2014 UserManual V8.0.00170

Tasks

3. Items which correspond to the search terms are highlighted

in gray.

3.29.8 Using filters in the ITE

3.29.8.1 Text filters

The Test Case Browser, the Test Suite Browser, the Compo-
nent Name Browser and the Object Mapping Editor (in the
tree view) all contain a filter area at the top. You can enter
a filter text into this area to show matches to the text in the
browser or editor. Use star (*) as a wildcard.
In the Test Case Browser, the Component Name Browser and
the Test Suite Browser, the names of the items in the browser
are considered for the filter.
In the Object Mapping Editor, the names and types of the
components are considered for the filter.

3.29.9 Other filter options

Some browsers offer pre-defined filters in the top right-hand
corner.
In the Component Name Browser, you have the following op-
tions:

• Sort by name or by type

• Hide component names from reused Projects.

In the Test Case Browser, you can also show any unused Test
Cases.

We recommend using this filter to refactor or clear up

your test.

UserManual V8.0.00170 April 15, 2014 215

 Functional Testing User Manual

3.30 Using the test executor for test-

ing from the command line
You can also run tests using the test executor. From the com-
mand line interface, you can select and start tests.

It is especially important to ensure that your test con-

tains a suitable startup module to wait for the AUT,
perform the login if necessary and reset the AUT to a
defined state when you are running tests from the com-
mand line.

3.30.1 Starting the test executor

1. In a command line interface, locate the installation direc-
tory and open the ITE directory within it.

2. Enter testexec.exe.
This will run the executable testexec.exe.

3. Do not press »ENTER« until you have entered the neces-

sary parameters. See the next section for details on the
parameters.

3.30.2 Parameters for the test executor

• Once you have browsed to the correct directory and en-
tered testexec.exe, you can enter the parameters for
the test execution.

• The test executor has various parameters Figure 3.30.2 →

page 217 :

216 April 15, 2014 UserManual V8.0.00170

Tasks

Detail Parameter
Help -h
Gives parameter help
Project name -project <project name>
e.g. -project ”ExampleProject”
Project version -version <project version>
e.g. -version ”1.3”
Configuration -c <path to configuration file>
file
e.g. -c ”<pathToQADocs>/config.xml”
Use this instead of entering arguments
via the command line ( → page 222) .
Database URL -dburl <URL>
(optional)
e.g. -dburl ”db.example.de”
If you enter this parameter, you do not
need to enter the -data or -dbscheme param-
eter ( → page 220)
You can find the dburl in the database pref-
erences
If no URL is given, the default will be used.
Database user- -dbuser <username>
name
e.g. -dbuser ”username”
Database pass- -dbpw <password>
word
e.g. -dbpw ”password”
Server (optional) -server <AUT Agent hostname>
e.g. -server ”localhost”
This is optional if you want to use the
embedded AUT Agent ( → page 219) .
Port number -port <port number>
(optional)
e.g. -port ”60000”
This is optional if you are using the
embedded AUT Agent and want to use a dy-
namically
chosen port. If you are using the embedded
AUT Agent and want to specify the port
then you should still enter a port number.
If you are working with a separately started

UserManual V8.0.00170 April 15, 2014 217

 Functional Testing User Manual

Detail Parameter
AUT Agent, this argument is required ( →
page 219) .
Language -language <language code>
e.g. -language ”en_US”
A list of language codes is available in the
reference manual (→Reference Manual p.
387).
Test Suite -testsuite <testsuite name>
e.g. -testsuite ”suite1”
Use to start a Test Suite ( → page 220)
Only one Test Suite or Test Job can be started
Test Job -testjob <testjob name>
e.g. -testjob ”job1”
Use to start a Test Job ( → page 220)
Only one Test Suite or Test Job can be started
AUT configura- -autconfig <configuration name>
tion name
e.g. -autconfig ”localconfiguration”
Use when starting an AUT via a configuration
( → page 220) .
AUT ID -autid <ID>
e.g. -autid ”SimpleAdder1”
Use when AUT was started via autrun ( →
page 220) .
Data directory -datadir <path to external
test data directory>
e.g. -datadir ”<pathToQADocs>/data”
Result directory -resultdir <path to directory>
e.g. -resultdir ”<pathToQADocs>/results”
No run option -n
(optional)
e.g. -n
Checks if the Test Suite is startable.
Quiet option -q
(optional)
e.g. -q
Does not give out test information.
Timeout (op- -timeout <timeout in seconds>
tional)
e.g. -timeout ”3600”

218 April 15, 2014 UserManual V8.0.00170

Tasks

Detail Parameter
Enter an optional timeout for testexec.
No screenshot -s
(optional)
no screenshots will be taken on errors.
No screenshots -sx
in HTML and
XML (optional)
screenshots will be taken on errors
and written to the database
but they will not appear in the
XML and HTML reports.
Test results -r
not relevant
(optional)

Flags the test results as not relevant

in the test result summary ( → page 171) .
Workspace -data <path to workspace>
e.g. -data ”<pathToQADocs>/workspace”
The ITE workspace with the preference
settings for the database connection
This is optional if you enter the -dburl
parameter ( → page 220)
Database -dbscheme <scheme>
scheme
e.g. -dbscheme ”embedded”
This is optional if you enter the -dburl
parameter ( → page 220)

3.30.2.1 Using a separate AUT Agent or the embedded

AUT Agent

• When using testexec, you have the choice between work-

ing with an AUT Agent that you start separately, or using
an embedded AUT Agent that is started automatically by
testexec.

• If you want to use a separately started AUT Agent, then

the AUT Agent must be started on the machine you are
testing on. Enter the parameters for the server and port
number to connect to this AUT Agent.

UserManual V8.0.00170 April 15, 2014 219

 Functional Testing User Manual

If you are working with Test Jobs, you must use a sepa-
rately started AUT Agent, because you will require the
AUT Agent to start the AUT via autrun.

• If you want to have testexec start and connect to an em-

bedded AUT Agent automatically, then you have two op-
tions:

– You can leave out both the parameters for the server
and the port number. This will result in an embedded
AUT Agent being started on a dynamically chosen port.
– You can leave out the server parameter, but still enter a
port number. This will result in an embedded AUT Agent
being started on the port you define.

3.30.2.2 Test Suites and Test Jobs

• You can either enter a Test Suite to be executed or a Test

Job. Only one of these two commands is accepted for the
test executor.

• If you are starting a Test Suite, your AUT will be started

from its configuration. You must enter the configuration
name using the correct parameter for the testexec.

• If you are starting a Test Job, you must make sure that
the first AUT you require is already started with the autrun
command. You must then enter the AUT ID as a parameter
for the testexec. Any other AUT’s required during the test
must either also be started already, or started as a part of
the test itself. When working with Test Jobs, you must
use a separately started AUT Agent. You cannot use the
embedded AUT Agent with testexec when you are starting
a Test Job.

3.30.2.3 Using the dburl instead of workspace and db-

scheme

You can use the dburl parameter to specify which database

should be used instead of entering the dbscheme and
workspace parameters. This has the advantage that you do
not need to create a workspace on the test machine that is
configured for the correct database.

220 April 15, 2014 UserManual V8.0.00170

Tasks

3.30.2.4 Starting the test execution via testexec

1. Once you have entered all the necessary parameters, press

»ENTER«.

2. The client will connect to the AUT Agent (either the de-
fined separate AUT Agent or it will start an embedded AUT
Agent then connect to it), connect to the database, open
the Project, start the AUT (for a Test Suite) or connect to it
(for Test Jobs) and then execute the Test Suite or Test Job
you specified.

3. Once the test has finished, the client will show an exit
code.

• ”Exit code: 0” indicates that the test was successful.

• ”Exit code: 1” indicates that the test contained an error.

To stop the test execution, use »CTRL+C«

3.30.2.5 The no-run option

Using the no run option will check the completeness of the

Project, test data and the validity of the database connection.
The AUT Agent connection is not checked.

3.30.2.6 Passing on arguments to the JVM

The test executor also accepts arguments to pass on to the

Java Virtual Machine. This means that you can, for ex-
ample, increase the initial and maximum amount of sys-
tem memory allocated to the JVM with the parameters
-Xms<memory_size> and -Xmx<memory_size>, respec-
tively. For example, the parameter -Xmx128M would make a
maximum of 128 MB of system memory available to the test
executor. When entering the standard parameters for the test
executor, you may add -J<JVM_parameter> for each JVM
parameter you wish to set. For example, -J-Xmx128M. Mul-
tiple parameters, like standard parameters, are separated by
spaces.
Here is an example of defining mutliple JVM parameters:
-J-Xmx128M -JXms128M.

UserManual V8.0.00170 April 15, 2014 221

 Functional Testing User Manual

3.30.3 Using the test executor with the em-

bedded database
If you are using the default embedded database, you will need
to enter the following information as parameters:

-dbscheme Default Embedded (H2)

-dbuser sa

-dbpw <empty> (””)

If you have changed the name of the default database scheme

in the database preferences ( → page 169) , you should alter
the parameter for the -dbscheme accordingly.

3.30.4 Using a configuration file

1. You can also enter test executor parameters in an XML con-
figuration file.

The workspace parameter (-data) cannot currently be

entered in the configuration file for the test executor,
it must be entered directly into the command line inter-
face.

2. This saves you typing in the same details each time you
start a test.

3. To enter the configuration file path, enter the following

command:
-c <path to file>
For example: -c ”<pathToQADocs>/config1.xml”

4. You can also overwrite parameters contained in the con-

figuration file by entering another parameter directly into
the interface.

5. For example, if your configuration file contains the Test

Suite ”Suite1”, but you enter -testsuite ”Suite2”
in the command line interface, the Test Suite called
”Suite2” will be started, not ”Suite1”.

6. To create an XML file:

A Open a text editor of your choice.

222 April 15, 2014 UserManual V8.0.00170

Tasks

B Enter the desired parameters as shown in the example

in the installation. It can be found under:
InstallationDirectory/examples/scripts
C Save the file as an XML file.
D This file will be used when you enter the ”-c <path to
file>” parameter.

The no-run, quiet mode, no screenshot, no screenshots

in reports, no relevance and -data (for the workspace)
parameters can only be entered in the command line
interface. They cannot be entered in the configuration
file.

Java Virtual Machine parameters can only be entered in

the command line interface. They cannot be entered in
the configuration file.

3.31 Using the dbtool client to im-

port, delete and export from the
command line
You can use the dbtool to import, export and delete Projects
from the database in without using the ITE. You can also use
it to create a new version of a Project in the database.
This is particularly useful for automated build and test pro-
cesses, where you may want to automatically export and im-
port Projects out of and into version control to run your tests.

3.31.1 Starting the dbtool

1. In a command line interface, locate the installation direc-
tory and open the ITE directory within it.

2. Enter dbtool.exe.
This will run the executable dbtool.exe.

3. Do not press »ENTER« until you have entered the neces-

sary parameters. See the next section for details on the
parameters.

UserManual V8.0.00170 April 15, 2014 223

 Functional Testing User Manual

3.31.2 Parameters for the dbtool

1. Once you have browsed to the installation directory and
entered dbtool, you can enter the parameters for the
database actions.

2. The dbtool uses the parameters described in the table Fig-

ure 3.31.2 → page 224 :

Detail Parameter
Help -h
Gives parameter help
Delete Project -delete <project-name
project-version>
e.g. -delete ”ExampleProject” 1.0 ( → page 225)
Delete All -deleteall
e.g. -deleteall ( → page 225)
Keep test result -keepsummary (optional)
summaries
e.g. -keepsummary ( → page 225)
Directory -directory <directory path>
e.g. -directory ”<pathToQADocs>/projects/”
The directory for imports and/or exports
The directory must already exist
Export Project -export <project-name
project-version>
e.g. -export ”ExampleProject” ”1.0”
Existing files with the same name will be overwrit-
ten
Export All -exportall
e.g. -exportall
The directory for the export all must be empty
The directory must already exist
Import Project -import <import-file>
e.g. -import <ExampleProject.xml>
Create Version -createVersion <project-name>
<old-version> <new-version>
e.g. -createVersion ”MyProject” ”1.0” ”1.1” ( →
page 225)
Workspace -data <path to workspace>
e.g. -data ”<pathToQADocs>/workspace”
The ITE workspace with the preference
settings for the database connection

224 April 15, 2014 UserManual V8.0.00170

Tasks

Detail Parameter
This is optional if you enter the -dburl
parameter
Database -dbscheme <scheme>
scheme
e.g. -dbscheme ”Oracle”
This is optional if you enter the -dburl
parameter
Database user- -dbuser <username>
name
e.g. -dbuser ”username”
Use sa (without quotes) for
the embedded database.
Database pass- -dbpw <password>
word
e.g. -dbpw ”password”
Use <empty> (””
for the embedded database)
Database URL -dburl <URL>
(optional)
e.g. -dburl ”db.example.de”
If no URL is given, the default will be used.
If you enter this, you do not
need to enter the -data or -dbscheme parameter
You can find the dburl in the database preferences

3.31.2.1 Deleting Projects but keeping test result sum-

maries

You can use the parameter -keepsummary to specify that

the test result summaries should not be deleted when the
Project or Projects are deleted. This is useful for continuous
integration processes, where the test results over time should
be kept, but the Projects are reimported into the database (for
example from the version control system) each night. If you
do not enter this parameter, the summaries will be deleted
with the Projects.

3.31.2.2 Creating new versions of Projects

You can use the dbtool to create a new version of a Project

that already exists in the database. You enter the Project
name, the version you want to create a copy of, and the new
version number that the Project should be created under. The

UserManual V8.0.00170 April 15, 2014 225

 Functional Testing User Manual

create new version command functions in the same way as

the create new version option in the ITE ( → page 43) . If the
Project is not in the database in the specified version, or if the
new version already exists, then the action will fail. We rec-
ommend using this when you are sure that no-one is working
on the Project.

If you are using the embedded database, see the section

on using the embedded database with the Test Executor.
for information on which username and password to
use ( → page 222)

Once you have entered all the necessary parameters, press

»ENTER«.

226 April 15, 2014 UserManual V8.0.00170

Tasks

3.32 Working with the dashboard

3.32.1 The Dashboard application

The Dashboard is a web application that allows you to view
test results from within a browser. You can only see test results
which are still in the database ( → page 161) . If you still wish
to see test results after a database migration, then you should
ensure that the old database instance and a Dashboard in the
correct version remain installed so that older test results can
be read.

3.32.1.1 The Dashboard server

In the installation directory, in the folder dashboard, you will

find the dashboardserver.
When this server is started, it receives configuration informa-
tion for the database you will be connected to via the browser.
For information on starting the server, refer to the later sec-
tion ( → page 228) . The Dashboard can also be started with
default parameters and with automatic browser opening. See
the section on using the Dashboard locally for more informa-
tion ( → page 227) .
The workspace directory for the Dashboard is in your home
directory under:
.guidancer/dashboardWorkspace

3.32.2 Starting the Dashboard application in

the browser
Once the Dashboard server has been started, you can start
the Dashboard application in the browser. This happens auto-
matically if you are using the dashboard application ( → page
227) , or you can enter a URL to start the web application and
connect to the server you started ( → page 229) .

3.32.3 Using the Dashboard locally: Starting

the Dashboard with default parame-
ters and automatic browser opening
Although the Dashboard is primarily intended to be started on
a central machine with access to a central database in which

UserManual V8.0.00170 April 15, 2014 227

 Functional Testing User Manual

the test results reside, it is also possible to start the Dashboard

in a default configuration to allow access to the embedded
database. This option is useful if you are evaluating the func-
tion and want to use the Dashboard on your local machine
without having to enter any configuration information.

1. In the installation directory, open the dashboard folder.

2. In this folder, start the dashboard application (Windows

users use dashboard.exe, Unix users use dashboard.sh.

3. Starting this application starts the dashboardserver with

default parameters for the embedded database. You can
see which parameters are used by looking in the dash-
boardserver.properties file which is in the same folder as
the Dashboard application.

4. While the server is starting, you will see a progress window.

A system tray icon for the Dashboard server will appear on
your screen.

5. Once the server is started, a browser opens containing

the Functional Test Reporting Perspective in which you can
view and open Test Result Reports from the database ( →
page 230) .

Bear in mind that if you are not using the embed-

ded database, then you will have to start the Dash-
board server with other parameters to connect to the
database you are using ( → page 228) .

3.32.4 Using the Dashboard over the net-

work: Starting the Dashboard server
with custom parameters
You can start the Dashboard server with default parameters
or with custom parameters.

1. In the installation directory, open the dashboard folder.

2. In this folder, start the dashboardserver.

3. If you start the server without any arguments, it will use

the properties file dashboardserver.properties from its cur-
rent working directory. You can see this properties file in

228 April 15, 2014 UserManual V8.0.00170

Tasks

the same folder as the dashboardserver on Windows and

Linux, and in the folder:
dashboard/dashboardserver.app/Contents/MacOS
on Mac systems.
4. You can, alternatively, specify a different properties file us-
ing -c <PROPERTIES_FILE>.
Keep in mind that on Mac systems you cannot use a vari-
able (e. g. $HOME) after - - args in the path of the prop-
erties file when you try to start the dashboardserver from
the command line via the "open" command.
5. The properties file must contain the following properties
with the values you require for them (do not use line breaks
within the properties in the properties file):

org.eclipse.jubula.dashboard.
port=<PORTNUMBER>

org.eclipse.jubula.dashboard.
jdbc_driver=<JDBC_DRIVER>

org.eclipse.jubula.dashboard.
jdbc_url=<JDBC_URL>

org.eclipse.jubula.dashboard.
database_username=<DB_USERNAME>

org.eclipse.jubula.dashboard.
database_password=<DB_PASSWORD>

6. Once the Dashboard server has started, users will be able

to connect to it via the web application ( → page 229) .

3.32.5 Connecting to the Dashboard in the

browser
Once a Dashboard server has been started ( → page 228) ,
then you can start the web application in the browser.
Enter the following URL:

http://HOSTNAME:PORTNUMBER/dashboard
Once the application has loaded, you will see the Functional
Test Reporting Perspective and can use it to view and analyze
test results ( → page 230) .

UserManual V8.0.00170 April 15, 2014 229

 Functional Testing User Manual

3.32.6 Using the Dashboard

Once you have started the Dashboard application in your
browser ( → page 228) , you will see the Functional Test
Reporting Perspective you are familiar with from the ITE ( →
page 160) .

3.32.6.1 Features available in the Dashboard

Many of the features available for viewing test results in the

ITE are also available here:

• You can reopen the Test Result View for a test run whose
details are still in the database ( → page 161) .

• You can refresh the Test Result Summary View ( → page

162) .

• You can filter and sort in the Test Result Summary View (
→ page 161) .

• When a test result is open, you can jump to the next or

previous error ( → page 160) and view properties details
/ any screenshots taken for a selected node.

• You can export test results as HTML and XML reports from
the Dashboard.

3.32.6.2 Features unavailable in the Dashboard

database changes: You cannot perform any actions in the

Dashboard that alter the data in the database, e.g. delet-
ing test result summaries, entering comments, toggling rel-
evance or reporting to ALM.

Preferences You also cannot change the preferences via the

workspace, so the default period of time for which you
see test result summaries is 30 days, and the label decora-
tion for execution duration time and parameter values are
displayed ( → page 173) .

Code coverage Code coverage reports cannot be opened in

the Dashboard. You can, however, see the code coverage
values in the Test Result Summary View.

BIRT reports are not available in the Dashboard.

230 April 15, 2014 UserManual V8.0.00170

Tasks

3.32.7 Stopping the Dashboard

You can close the browser to stop viewing the Dashboard at
any time. This does not, however, stop the Dashboard server.
If you are using the Dashboard application ( → page 227)
you can stop the Dashboard server by right-clicking on the
system tray icon and selecting ”Exit”.
If you started the Dashboard server ( → page 228) , then you
can stop the Dashboard server by killing the process.

UserManual V8.0.00170 April 15, 2014 231

 Functional Testing User Manual

3.33 Using Chronon

Chronon (3.0) is supported as a monitoring agent to record
information about the behavior of your AUT during a test.
The information gathered by Chronon can be used to help
analyze any errors found in the program.

Jubula Feature users: the Chronon plugins are only

available in the standalone version.

3.33.1 Using Chronon when testing your AUT

You can configure your AUT to run with Chronon recording
so that you can analyze any errors that occur during your au-
tomated test runs. See the section later ( → page 234) on
analysing the reports for information on the tooling required
to do this.

Jubula Feature users: The support for Chronon record-

ing in AUT’s is currently only available in the standalone
software.

3.33.1.1 Adding Chronon information in the AUT con-

figuration

You can select Chronon as a monitoring agent and configure

it in the Expert Settings in the AUT configuration.

1. Open the AUT configuration dialog from the Project prop-

erties ( → page 32) .

2. Select the Expert configuration.

3. Select Chronon (separate installation) as a monitoring

agent ( → page 233) .

4. You can then enter the configuration details for the moni-
toring.

232 April 15, 2014 UserManual V8.0.00170

Tasks

3.33.1.2 Configuring the separate Chronon installation

for use with your AUT

Enter the following configuration details:

Java Agent JAR: Enter the path to the Chronon recorder

JAR you have installed.

Native Agent File: The path to the platform-specific native

recorder agent library.

Config file: Enter the absolute path to the configuration file

for the recorder. The configuration file has the same setup
as a Java properties file. It must contain the following prop-
erties:
servermode (set to true)
name (the AUT name as it will be displayed in the Chronon
Recording Server UI)
autostartwithconfig (if you want the recording to
start automatically (recommended) then the recording pa-
rameters need to be set in the Chronon application.)
port (optional – if none is entered, 8042 is used.).
The documentation for the configuration file is available
on the Chronon site:
http://chronon.onconfluence.com/
display/DOC/Recorder+Configuration+File

You can also refer to the Chronon documentation for

information on the required parameters to run your
tests with the Recording Server. :
http://chronon.onconfluence.com
/display/DOC/Recording+outside+Eclipse

3.33.1.3 Adapting tests to improve data collection

You should bear the following in mind when using Chronon

for recording information in automated tests.

Performance in the AUT may be affected

• The recordings that Chronon performs are very memory-

intensive. For this reason, you may notice performance

UserManual V8.0.00170 April 15, 2014 233

 Functional Testing User Manual

differences in your AUT. It may also be necessary to in-

crease the step delay for your tests, and / or add extra
synchronization to compensate for the performance dif-
ferences when Chronon is running.

• For these reasons, we do not recommend having Chronon

configured as a part of your standard AUT configuration.
Instead, we suggest running tests with Chronon monitor-
ing when needed.

• We also strongly suggest ensuring that your AUT and the

machine it is running on have sufficient memory to cope
with the increased monitoring activity.

Stopping or restarting the AUT will cause the previously

recorded information to be lost

• The recording files are written when the AUT is stopped.

This means either stopping the AUT by hand, using the
”Stop AUT” button in on the toolbar in the ITE or when
you use the restart action.

• Because of this, we recommend executing individual Test

Cases (use cases) in Test Suites that you want to analyze
with Chronon. You should ensure that any Event Handlers
in the Test Suite will not cause the AUT to restart.

3.33.1.4 Analyzing the generated reports

To analyze the reports generated, you will require the

Chronon Time Travelling Debugger from Chronon Systems.
You can download a trial version of this tool. The link to the
trial version is provided in the expert AUT configuration.
Open source projects may contact Chronon Systems for free
licenses.

3.34 Launch Configurations

3.34.1 Intro
If you are using the the Eclipse Jubula Feature in your Eclipse
installation, you can start AUT’s from within Eclipse, similar
to the way in which you would debug an application using
Eclipse. This section describes how to start your AUT directly
from the IDE.

234 April 15, 2014 UserManual V8.0.00170

Tasks

3.34.2 Requirements
The following Features need to be installed in order to start
Swing AUT’s:

• Jubula Launch Support for Java / Swing

• Java Developer Tools (JDT)

The following Features need to be installed in order to start

RCP AUT’s:

• Jubula Launch Support for Eclipse RCP

• Java Developer Tools (JDT)

• Eclipse Plug-in Development Environment (PDE)

You can find an update site containing the Jubula Fea-

ture and the Launch Integration in the correct version
for each standalone version in the installation directory
in the development folder.

3.34.3 Customizing the Perspective

In most cases, the button to start AUT’s is not included in the
main toolbar. The following steps describe how to add this
button to a Perspective’s toolbar:

1. Select:
Window → Customize Perspective...
from the main menu.

2. In the dialog that appears, select the Command Groups

Availability tab.

3. Ensure that the entry Start AUT in the section Available

command groups: is checked.

4. Close the dialog by pressing the OK button.

Once you have completed the steps listed above, the Start
AUT button should be visible in the main toolbar of the active
Perspective. Start AUT

UserManual V8.0.00170 April 15, 2014 235

 Functional Testing User Manual

3.34.4 Starting the AUT

The Start AUT button can be used, just like the Run or De-
bug buttons, to launch an application or configure application
launches. Applications started in this way are always started
in debug mode. Furthermore, Start AUT adds additional infor-
mation to the launch process, allowing the started application
Start AUT to be tested.
Some of the additional information that makes the started
application testable can be configured from the Test tab of
the Start AUT Configurations dialog.
The AUT ID can be assigned or left blank. If left blank, the
configuration name (ex. New_configuration) will be used.

3.34.5 AUT Agent

Although the automatic AUT Agent selection generally selects
the correct AUT Agent, it can be useful to know what criteria
go into the selection process. These rules are followed when
deciding with which AUT Agent the starting AUT should be
registered:

1. If the ITE is currently connected to an AUT Agent, then that

AUT Agent will be used.

2. If an embedded AUT Agent is running, the ITE will con-

nect to the embedded AUT Agent and use that for AUT
registration.

3. An embedded AUT Agent will be started, and the connec-

tion will be made and used for AUT registration.

3.34.6 Additional information for RCP AUT’s

3.34.6.1 Keyboard Layout

The Keyboard Layout for the AUT can be defined in the Start
AUT Configurations dialog. The entered value must represent
a locale and must represent a defined keyboard layout.

3.34.6.2 RCP Remote Control Plug-in

In order to start an RCP AUT, the RCP Remote Control plug-

in (org.eclipse.jubula.rc.rcp) must be included in the launch

236 April 15, 2014 UserManual V8.0.00170

Tasks

configuration. The list of plug-ins for the launch configura-

tion can be viewed and modified from the Plug-ins tab of the
Start AUT Configurations dialog when an Eclipse Application
launch configuration is selected.

3.34.7 Common Pitfalls

• Breakpoints may alter the timing of tests. This can have
consequences such as timeouts, tests failing when they
should succeed, and tests succeeding when they should
fail.

UserManual V8.0.00170 April 15, 2014 237

 Functional Testing User Manual

3.35 Troubleshooting

3.35.1 General help

Always check in the Problem View first for any help with your
tests. The messages there should help you with most of the
problems. The ITE also highlights problems in the browsers
and views with red crosses. Hover the mouse over the item to
see a tool tip with more information.
In some text fields you can only enter certain characters. A
red background in a text field means that you have entered
something incorrect in that field. A yellow background means
that the information entered is incomplete.
Looking in the log files may help to resolve some problems.
Logs for the client (ITE) and AUT Agent can be found via:
Help → Show Client/AUT Agent Log

The ITE can only access an AUT Agent log file if it is

currently connected to a AUT Agent.

This section contains information on some of the more com-

mon problems:

• Starting the AUT Agent ( → page 238) .

• Connecting to the AUT Agent ( → page 239) .

• Starting the AUT ( → page 239) .

• Mapping components from the AUT ( → page 240) .

• Executing Test Suites ( → page 241) .

• Failed Test Suites ( → page 242) .

• Locked Test Cases ( → page 243) .

For other problems, look in the relevant section of the user

manual or the reference manual. There are also FAQs on the
BREDEX website.

3.35.2 I can’t start the AUT Agent

Check:

238 April 15, 2014 UserManual V8.0.00170

Tasks

• That you have used the right port number and that it is not
being used by any other program.
• Whether the computer on which the AUT Agent is installed
is switched on.
• That there are no network problems, and that all necessary
hardware is connected.

For information on starting the AUT Agent, refer to the sec-

tion earlier in this chapter ( → page 21) .

3.35.3 I can’t connect to the AUT Agent

Check:

• That the AUT Agent you want to connect to has been

started and is running ( → page 21) .

If you have not started an AUT Agent, you can work

with the embedded AUT Agent ( → page 23) .

• That you are connecting the AUT Agent to the right port
number and AUT Agent hostname.
• That you are connecting to the right version of the AUT
Agent.

For more information on connecting to the AUT Agent, see

the section earlier in this chapter ( → page 23) .

3.35.4 I can’t start the AUT

If the start AUT button is disabled
If you cannot start a particular AUT, this could be because:

• You have not connected to the AUT Agent ( → page 23) .

• You have not defined an AUT ( → page 47) .
• You have not configured an AUT ( → page 50) .
• The AUT does not support the current working language.

Errors starting the AUT

If there is an error starting the AUT, this could be because:

UserManual V8.0.00170 April 15, 2014 239

 Functional Testing User Manual

The AUT cannot be found: Make sure that the JAR or ex-
ecutable file for the AUT is correct, or that the classpaths
are correct ( → page 50) .

The main class has not been found: Make sure that the
JAR file or the classpaths you have entered contain the
main class ( → page 50) .

The JAR given as a classpath is not valid: Check that you

have entered the right JAR file, and that the path to it is
correct from this computer. If you have entered a relative
path, make sure that it is relative to the AUT working di-
rectory, if there is one, or to the AUT Agent directory if you
have not specified a AUT working directory.

The JAR given as a classpath does not contain a distinct main class:
Check that you have entered a JAR which contains a main
class.

If the AUT does not appear in the Running AUT’s View

If the AUT does not appear in the Running AUT’s View and
you are testing an RCP application, make sure that the RCP
Remote Control plugin has been installed ( → page 260) .
Otherwise, check that the toolkit you specified in the AUT
configuration ( → page 50) is the right toolkit for this AUT.

3.35.5 I can’t map components in the Object

Mapping Mode
Green border does not appear in Java AUT’s
If you are in the Object Mapping Mode and cannot see a
green border around components, then this could mean the
following:

• The border cannot be drawn – try collecting the compo-

nent anyway and see if the technical name appears in the
Object Mapping Editor.

• The component is not supported – find out whether the

component in your AUT is a standard component or a cus-
tom component. If it is a custom component, you may
need to write an extension to be able to test it.

Green border is shown but component cannot be

mapped
If you can see the green border in the Object Mapping Mode

240 April 15, 2014 UserManual V8.0.00170

Tasks

but cannot collect the component, this could mean the fol-
lowing:

• The key combination you are using is being blocked by the

AUT – try changing the combination ( → page 170) .
• The component is already mapped. Check whether a tech-
nical name in the unassigned technical names or assigned
names category is being highlighted.
• The component is not supported – find out whether the
component in your AUT is a standard component or a cus-
tom component. If it is a custom component, you may
need to write an extension to be able to test it.

Problems with GTK

The GTK graphics toolkit (often used with Linux) can make
object mapping with the default settings impossible for
certain components. If the AUT that you are mapping
is running under Linux, please change the object map-
ping shortcut key combination to anything other than
»CTRL+SHIFT+[0-9 OR A-F]«.

3.35.6 I can’t execute my Test Suite

If you cannot start a Test Suite, check that:

• The Test Suite has complete data for the current language.

No parameter values can be empty in a Test Suite. If you

no longer need the parameter, delete it.

• The object mapping is complete ( → page 137) .

• The Object Mapping Mode and the observation mode have
been switched off.
• You have connected to the AUT Agent ( → page 23) .
• You have started the AUT ( → page 154) .

You can use the Test Suite Browser to click through the
Test Suite to see the exact places where data and object
maps are missing.

UserManual V8.0.00170 April 15, 2014 241

 Functional Testing User Manual

3.35.7 My Test Suite failed

If your test fails, you can find exact details about the problem
by looking at the Test Result View ( → page 160) . A screen-
shot of the AUT is automatically taken when an error occurs
and can be seen in the Image View.
For other problems with test execution, check:

• That the AUT is in focus and is visible. You can automat-

ically activate the AUT in the AUT properties ( → page
50) or you can use a Test Case to activate the AUT. You
can also set your preferences to minimize the ITE when test
execution begins ( → page 167) .

Bear in mind that different platforms have different fo-

cus behavior. You may need to specifically bring the
AUT into focus by clicking into it as a part of the test.

• That the AUT is ready when the test begins. To ensure

this, you can insert a Test Case at the beginning of each
test which waits for the window or for the first compo-
nent you want to test. This is especially important when
you are running tests from the command line with the Test
Executor.

Waiting for a window to appear is generally a good idea

whenever a new window or dialog is opened during the
test. Waiting for the window or the component you
want to test will make sure that your tests run even
under different timing conditions.

• Make sure that the Test Cases and Test Steps are in the
right order.

• Ensure that the data you have entered is correct.

• Check your object mapping configuration ( → page 140)

. We recommend that you set the recognition to ”stan-
dard”.

• If the AUT is an RCP application, make sure that the key-

board layout is correct ( → page 50) . Otherwise, make
sure you have the current version of the RCP Remote Con-
trol plugin (start your application with -clean to be sure).

242 April 15, 2014 UserManual V8.0.00170

Tasks

• Check that the Test Steps preceding the failed Test Step
were successful by looking at the state of the application.

To help you analyze the reasons for Test Suite failure,

you can use the pause on error option ( → page 157) .

3.35.8 My Test Suite failed when using rdesk-

top
• Under a very specific configuration involving rdesktop 1.5,
tests are known to frequently fail with an action error:
’Timeout received before confirming the posted event’.

• This occurs when rdesktop 1.5 is used to log into a user

account used for the ITE as well as a separate account for
the AUT Agent.

• The problem does not occur under rdesktop 1.4.1.

3.35.9 I can’t save my editor

If you are working in a multi-user environment, or if you
are working on multiple editors at once, the editors may be
locked. This is to secure the editors so that conflicting changes
do not take place. You will be able to save changes in your
editor once the changes by the other tester or in the other
editor have been saved.
After an irregular shutdown, you may find that some editors
may still be locked. This is temporary and will pass.

3.35.10 Creating a support information pack-

age
If you have found a problem with the ITE itself, you can create
a support information package from within the ITE. You can
choose which information to include in the package, which
can be uploaded to a bug-tracking system as a .zip file.

1. Select:
Help → Create Support Information Package

UserManual V8.0.00170 April 15, 2014 243

 Functional Testing User Manual

2. In the dialog which appears, select what to add to the

package:

Configuration information: This includes information

about how you have configured the ITE, which other
plugins you are using, and information about your envi-
ronment.
The AUT Agent log This lets us see the messages from
the AUT Agent. If you are not connected to the AUT
Agent, this option will be grayed out.
The client log This lets us see the messages from the ITE.
The Project and depending Projects The currently
open Project and any Projects it reuses.

3. Browse to the destination to save the .zip file.

4. Click ”OK”.

5. The prepared package will be saved to the destination you

specified.

3.35.11 Log file locations

The logs for the ITE and the AUT Agent can be found in your
home directory under:
.jubula/logs

244 April 15, 2014 UserManual V8.0.00170

Tasks

3.36 Finishing up

3.36.1 Stopping the AUT

1. When you stop the AUT Agent, any AUT’s that were con-
nected to this AUT Agent are closed.

2. AUT’s which were started from a configuration are auto-

matically closed when the test execution via the test ex-
ecutor stops.

3. To stop the AUT manually, select the AUT you want to stop
from the Running AUT’s View and then click the Stop AUT
button. stop AUT

4. A dialog will appear to ask you if you are sure you want to
stop the AUT. Click ”yes”.

5. You can opt to not see this dialog in the preferences ( →

page 167) .

Stopping an AUT in a test

Stopping an AUT as part of a test is generally not possible.
The AUT will be stopped automatically at the end of testing
according to the points mentioned above.
You can use the restart action to restart the AUT during the
test. You may be able to use the action External Key Com-
bination to send an unconfirmed keystroke to the AUT (i.e.
»ENTER« on a prompt dialog for closing the AUT) to close the
AUT at the end of your test, however, the success of this is de-
pendent on the AUT and environment as well as timing and
synchronization issues.

3.36.2 Disconnecting from the AUT Agent

To disconnect from the AUT Agent, select the ”Disconnect
from AUT Agent ” button on the toolbar. disconnect AUT
Agent

3.36.3 Closing the ITE and stopping the AUT

Agent
Once the Test Suite, AUT and AUT Agent have been stopped
or disconnected, make sure any changes are saved and select:
File → Exit .

UserManual V8.0.00170 April 15, 2014 245

 Functional Testing User Manual

3.36.4 Stopping the AUT Agent

• Stop the AUT Agent by selecting:
Start → Programs → GUIdancer or Jubula
and then ”Stop AUT Agent” from the Windows Menu.

• Under Linux, use the script:

stopautagent.

You can also stop the AUT Agent from the system tray.

• You can use the parameter -p <port number> to spec-

ify which port number should be stopped.

• You can also enter the hostname directly after the

stopautagent command to specify which hostname
should be stopped.

Stopping the AUT Agent will stop any AUT’s that are
connected to this AUT Agent.

246 April 15, 2014 UserManual V8.0.00170

Tasks

3.37 Producing long-term reports of

test runs with BIRT

3.37.1 Generating BIRT reports

From the Test Result Summary View ( → page 160) , you can
generate reports of your test runs over time using the BIRT
reporting engine.

Only test runs that have been marked as relevant are

included in the generated BIRT reports. You can change
the relevance from the Test Result Summary View ( →
page 162) .

• The ITE offers a selection of example reports:

Test Comments: This report shows a table of all failed

tests for the time chosen, whose relevance is set to true
and whose name does not include BROKEN. The com-
ment title that can be entered in the Test Result Sum-
mary View ( → page 163) is also shown. This report is
useful for delivering daily status reports of the tests.
Test Execution Overview: This report shows a list of ex-
ecuted, relevant Test Suites over the time period se-
lected. For each day in the time period, there is a col-
ored block for the Test Suite to display its status. Green
means that the test ran without any errors. Red means
that the test ran, but with errors. Yellow means that
the test ran more than once on that day. White means
that the Test Suite did not run on this day. This report is
useful for teams with large amounts of Test Suites who
need to ensure on a daily basis that all Test Suites were
started. Test Suites that were not run at all during the
selected time period are not displayed.
Test Duration: This report shows the duration of the cho-
sen tests.
Test Execution Histogram: This report shows the pro-
portion of executed, failed and non-executed Test Steps
for a test. This report is most useful when one specific
Test Suite is compared to see its progress over time.
Test History: This report shows a graph of the percent-
age completion for the selected Test Suites for the dates

UserManual V8.0.00170 April 15, 2014 247

 Functional Testing User Manual

given. There is also a list of the AUT’s, Test Suites and

test runs.
Test History Absolute: This report shows the same de-
tails as the Test History report, but instead of showing
the test results in percentages, shows the actual amount
of Test Steps executed. It also shows the difference be-
tween expected and executed Test Steps.
Test History Absolute and Coverage: This report
shows the same details as the Test History Absolute
report with any code coverage information that is
available for the chosen test runs.
Testresult: This report gives out the full test details up to
the given nesting level.
Testresult Summary: This report shows a table of the
Test Result Summary View for the dates and tests cho-
sen.

• To start a report, click the arrow next to the ”Create Re-

port” button and select the report you want to generate.
create BIRT report

If you are not already connected to the database, then

a dialog will appear to create the connection ( → page
27) .

• The BIRT report viewer starts (the first time it starts it may
take some time).

• The parameters for the report are displayed:

Selection: In this section, specify which time frame the

report should be generated for (either from a specific
date, or using the options yesterday, now, last week
etc.) as well as for which Project, Test Suite, Test Job and
the operating system. The details in the selection section
are combined using and. SQL syntax can be used (e.g. %
is used as a wildcard for any number of any characters,
_ is used as a wildcard for one character).
Test run ID: Some reports are generated for a specific test
run. The test run ID of the currently selected test sum-
mary is entered by default, but you can enter a different
run.

248 April 15, 2014 UserManual V8.0.00170

Tasks

Detail Selection: For the Testresult and TestresultError re-

ports, you must also specify the nesting level (how many
levels in the hierarchy should be shown) and the ID of
the test run you want to generate the report for. The
test run ID for each run can be seen in the Test Result
Summary View.

• Click ”OK” to start the report generation.

• Once the report is ready, it will be shown in the BIRT viewer.

• Hover over the points on the graph in a report to see any

additional information about the point (comment, data
value etc.).

• You can click through the report’s pages in the viewer and
also export the report as a PDF.

The option Auto when exporting a report leads to the

right-hand side of the report being cut off.

You can also create your own reports to execute ( →

page 249) .

3.37.2 Writing your own BIRT reports

The BIRT reports are examples of how you could document
your quality over time. You can also create other reports to
generate depending on which details you want to see in the
reports. To create reports, you will need to use the BIRT de-
signer from Actuate. There is an open source version and a
commerical version of the designer.
The following information describes what information from
the database can be used to generate BIRT reports. For help
using BIRT, please see the BIRT documentation.
There are four database tables that contain relevant data for
test results:

testresult_summary This table contains one row per exe-

cuted Test Suite and corresponds to the Test Result Sum-
mary View in the ITE.

UserManual V8.0.00170 April 15, 2014 249

 Functional Testing User Manual

testresult This table contains further information about each

test run (each row in the testresult_summary table), includ-
ing all executed nodes.

parameter_details This table contains the name, type and

value for all parameters (data) in the executed test.

parameter_list This table gives a parent-child relation be-

tween the executed nodes from the testresult table and
the parameters in the parameter_details table.

3.37.2.1 Creating a BIRT report

Using the BIRT report designer, you can create your own re-
ports which will display specific information from these tables.
In the installation directory, in:
plugins/com.bredexsw.guidancer.reporting.birt.viewer
there is the directory reports.
In this directory, the templates for the reports available in the
ITE are stored. There is also a library which uses the database
as a data source and contains data sets (SQL queries) to this
database. The following information is contained in the li-
brary:

Datasets: there are views to show details from the four ta-
bles for reporting in the database.

Report parameters: These are parameters for the database

queries that can be used to limit the scope of a report.

Report items: These are examples of pre-defined tables and

graphs which can be used in other reports.

Master pages: These define the layout of the reports

Themes: The themes contain information about colors, fonts

etc. The themes are in the ite.css file.

Be careful when working with the reports and themes

that you do not break the existing reports!

250 April 15, 2014 UserManual V8.0.00170

Tasks

3.37.3 Showing BIRT reports in an external

viewer
The BIRT reports are shown in an integrated BIRT report
viewer.
If you have a BIRT report viewer elsewhere (e.g. in a Tomcat
server), then you can put the templates and the library into
the external BIRT viewer on the server and view them without
starting the ITE.
For information on viewing BIRT reports in external viewers,
please consult the BIRT documentation.

UserManual V8.0.00170 April 15, 2014 251

 Functional Testing User Manual

3.38 Working with code coverage

with Java tests
The ITE is integrated with the JaCoCo code coverage tool for
Java applications to let you run and analyze code coverage for
your tests.

Code coverage is only available for AUT’s started via an

AUT configuration ( → page 50) (i.e. not using the
autrun command), and which use Java 1.5 or higher.

3.38.1 Configuring code coverage for an AUT

You can activate code coverage for an AUT configuration with
the following steps:

1. Open the AUT configuration dialog from the Project prop-

erties ( → page 32) .

2. Select the Expert configuration.

3. Select the code coverage agent you wish to use (JaCoCo is

available out-of-the-box).

4. You can then enter the AUT installation directory and the
AUT source directory for the code coverage:

The AUT installation directory is the directory contain-

ing the class files (compiled Java files) for your AUT. You
must enter this directory to make code coverage possi-
ble for your test run.
The AUT source directory is the directory where the
source files (i.e. the program code) for your AUT are
kept. Entering a directory for the source files is optional,
however, if you do not enter one, then you will not be
able to view your code coverage results at the source file
level. The AUT source directory must contain the source
files in their Java package structure. The class files must
have been compiled with debug information to make
the lines of code executed visible in the code coverage
report.

252 April 15, 2014 UserManual V8.0.00170

Tasks

You can enter relative paths for the AUT installation and
AUT source directories. The paths are relative to the
working directory.

5. To make sure you only monitor your own code, enter

a package pattern to specify which packages should be
monitored. The pattern must be a valid regular expression.
If you do not enter a package pattern, all classes in the
virtual machine will be considered for the code coverage
value.

Not entering a package pattern can result in extremely

large messages being sent from the AUT Agent, which
may cause memory problems ( → page 253) .

6. Select whether you want the code coverage value to be

reset when a new Test Suite starts ( → page 253) .

3.38.1.1 Increasing the Java Heap Space for code cov-

erage

Running a test with a code coverage profiler leads to an in-

creased memory requirement for the ITE. You can increase the
heap space for the ITE and also enter a package pattern ( →
page 252) to reduce the amount of files considered for code
coverage.

Users working with a MySQL database should also fol-

low the steps from the Installation Manual to increase
the maximum allowed packet for the database.

3.38.2 Resetting and accumulating code cov-

erage
To make sure you get the correct results for your code cover-
age, it is important to be aware of which actions will accumu-
late the recorded code coverage and which actions will reset
the value back to zero.

UserManual V8.0.00170 April 15, 2014 253

 Functional Testing User Manual

Code coverage reset

The following result in the code coverage value being reset:

• Stopping the AUT. When the AUT is started again, the

code coverage value is reset to zero. The test executor
ensures that all monitoring information is collected before
stopping the AUT.

If you stop the AUT while code coverage is being calcu-

lated, then the value will also be set to zero!

Code coverage accumulation

The following result in code coverage information being ac-
cumulated:

• Any actions you perform manually in an AUT that has been

started with code coverage will contribute to the code cov-
erage result.

• Code coverage is accumulated across Test Suites by de-

fault. If you want to reset the code coverage at the begin-
ning of each Test Suite, then select this option in the AUT
configuration ( → page 252) .

If you are working with Test Jobs, then do not opt to

reset the code coverage at the beginning of a Test Suite.

• If you use the restart action during a test, this does not
result in the code coverage value being reset.

3.38.3 Viewing the code coverage for a test

run
Once a test with code coverage has run, the code coverage
information must first be processed in order to show it in the
Test Result Summary View.
The following columns are available in the Test Result Sum-
mary View to show you code coverage information:

254 April 15, 2014 UserManual V8.0.00170

Tasks

If a column is not visible, you can show it by selecting it

from the context-sensitive menu on the header row for
the Test Result Summary View.

• The Profiling Agent column displays which code coverage

agent was selected for the test run.

• The Measured Value column shows the Instruction Cover-

age for the test run. You can see the values for other types
of coverage in the Properties View when you select the test
run. An overview of the meanings of the coverage types is
available on the JaCoCo website:
http://www.eclemma.org/jacoco/trunk/doc/counters.html.

The measured value will become visible once the code

coverage information has been processed. You may
need to refresh the Test Result Summary View.

• The Profiling Details column indicates whether the full de-

tails for the code coverage report are still in the database.
Full profiling details are removed from the database at the
same time as test run details ( → page 161) . The period
of time that details remain in the database can be specified
in the Project properties ( → page 33) .

Opening and viewing the code coverage report

1. In the Test Result Summary View, select the test run whose
code coverage you want to see and click the ”Open Profil-
ing Report” button at the top of the view.

The details about code coverage are available in the

database for the same amount of time as the test re-
sult details ( → page 161) . After this time, the code
coverage details are deleted along with the test run de-
tails.

2. In the editor that opens, you can see the details for the
code coverage for the test run.

UserManual V8.0.00170 April 15, 2014 255

 Functional Testing User Manual

3. If you specified a source file directory for your AUT ( →

page 252) and compiled your AUT classes with debug
information, you will be able to navigate through your
classes to see more detailed information about the code
coverage through the whole AUT.

4. Once you have opened a code coverage report, it is saved

into your workspace. You can reopen it from the Navigator
View.

You should regularly remove old code coverage reports

from your workspace to avoid overfilling it.

3.38.4 Troubleshooting code coverage

When using code coverage, please bear the following in
mind:

• Code Coverage is only possible with AUT’s started via an

AUT configuration ( → page 50) (i.e. not using the autrun
command), and which use Java 1.5 or higher.

• JaCoCo manipulates the byte code of your AUT at runtime

to be able to measure code coverage. It is therefore highly
sensitive to other byte code manipulations that take place
at the same time (e.g. cglib).

• If you wish to analyze the Code Coverage at the source

code level, as well as entering the Source Directory in the
AUT configuration, you must also ensure that your class
files have been compiled with debug information.

• Running Code Coverage analyses can become memory-

intensive for larger AUT’s. A pattern can be used to reduce
the code analyzed. You can also increase the heap space
for the ITE to ensure that enough memory is available. We
have successfully performed code coverage analysis with
JaCoCo on an AUT with 72,000 classes.

• Users working with the embedded database may run into

memory problems sooner than users working with an Ora-
cle database. Please remember that we do not recommend
working with the embedded database for productive use.

256 April 15, 2014 UserManual V8.0.00170

Tasks

The AUT does not start when Code Coverage is enabled

If the AUT starts normally without Code Coverage but does
not when Code Coverage is activated, ensure that you are not
using the embedded AUT Agent.
The Test Result Summary View displays the monitoring
agent as JaCoCo, but the coverage value is 0
If you can open the HTML report for the Code Coverage, but it
shows ”NaN”, then this could mean that the class files for the
analysis were not found. Check the path to the Installation
Directory in the AUT configuration. It could also be the case
that other byte code manipulations were running at the same
time as JaCoCo.

UserManual V8.0.00170 April 15, 2014 257

 Functional Testing User Manual

258 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

Chapter 4

Toolkit-specific
information

This chapter contains information testing AUT’s written in the

various supported toolkits.

4.1 Testing Swing AUT’s

You can write tests for Swing AUT’s when you select the
toolkit concrete or Swing in the Project properties. The Swing
and concrete toolkits actually contain the same actions as
each other.
When you select Swing as the Project toolkit, the library
Project unbound_modules_concrete is automatically reused in
your Project. The actions in this library are described in the ref-
erence manual (→Reference Manual p. 21).

4.1.1 Supported Swing AUT’s

AUT’s written with the Swing GUI toolkit are supported ac-
cording to the following points:

• The AUT is written using Java 1.5 or higher.

• It uses a Java SE (Standard Edition) JRE.

AUT’s based on the NetBeans framework, and NetBeans

itself, are currently not supported.

UserManual V8.0.00170 April 15, 2014 259

 Functional Testing User Manual

4.1.2 Design for testability in Swing

4.1.2.1 Naming components

Although components in the AUT can be recognized even

when they are not named by the developers, using the set-
Name method for the current Swing component class cer-
tainly makes it easier to test AUT’s. Even if a whole area of the
AUT has changed, the component will still be found based on
this unique name.

4.1.2.2 Adding support for text retrieval

You can add support for renderers for Swing components

without the getText() method in order to access text that is
otherwise non-readable during test execution.
• An example of the adapter mechanism can be found here:
http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/
tree/org.eclipse.jubula.examples.extension.swing.rc.renderer
• This does not replace the support for custom Swing ren-
derers that can be changed directly by your developers.
• If you are able to change the renderers yourself, you can
still implement one of the following in your renderer:
public String getTestableText(); public String getText();

4.2 Testing RCP AUT’s

You can write tests for RCP AUT’s by selecting the toolkit con-
crete or RCP from the Project properties. If you will need
to test RCP-specific components (such as toolbars with drop-
down menus, or tree-tables), you will need to select RCP as
the toolkit for the Project.
When you select RCP as the Project toolkit, the library Projects
unbound_modules_concrete, unbound_modules_swt and
unbound_modules_rcp are automatically reused in your
Project. The actions in these libraries are described in the ref-
erence manual (→Reference Manual p. 21).

The GEF toolkit is a subset of the RCP toolkit and is de-

scribed in a later section ( → page 265) .

260 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

4.2.1 Supported RCP AUT’s

AUT’s written with the RCP GUI toolkit are supported accord-
ing to the following points:

• The AUT is written using Java 1.5 or higher.

• It uses a Java SE (Standard Edition) JRE.

• The AUT must use SWT version 3.1 or higher. For Mac
systems, the version of SWT used must be 3.6 or higher.

• Eclipse versions 3.1-3.x and 4.x (with and without the com-
patibility layer) are currently testable.

4.2.2 Setting up an RCP AUT for testing

If you want to test a Rich Client Platform application,
you must ensure that our ”RCP Remote Control” plugin
(org.eclipse.jubula.rc.rcp) is added to your AUT and that it will
be started when the AUT starts. If you are working in a con-
tinuous build and test process, then we highly recommend
doing this as a part of the product build, or just afterwards
( → page 262) . For testing purposes, and to get started
quicker, the steps can also be done manually as follows:

Please ensure that you follow all these steps!

1. Locate the installation directory, and open the develop-

ment folder.

2. Extract the content of the rcp-support.zip folder into the

plugins directory for your RCP AUT.

3. RCP applications generally have a configuration/config.ini

file which contains the parameter osgi.bundles. This pa-
rameter needs to be modified to allow the RCP remote
control plugin to load on AUT startup. You must add
,org.eclipse.jubula.rc.rcp@start (the comma is important to
delimit this argument from the others) to the end of the
osgi.bundles parameter.

4. Start your AUT normally (i.e. not as an AUT. Close it, and
then start it again.

5. In your AUT, open Help → About .

UserManual V8.0.00170 April 15, 2014 261

 Functional Testing User Manual

6. In the plugin details for your AUT, you should be able to

see that the following plugins are started:

• org.eclipse.jubula.rc.rcp
• org.eclipse.jubula.rc.rcp.common

7. If you can see these plugins, then you can continue and
start your AUT via e.g. an AUT configuration ( → page 52)
or via autrun ( → page 55) .

8. If you cannot see these plugins, then you should speak

to a member of the development team to implement the
suggestions described in the section below ( → page 262)
.

When you install a new version of the ITE, you must

repeat these steps with the new RCP remote control
plugin. We recommend starting your AUT once with
-clean to ensure that the new remote control plugin is
used.

If you do not follow these steps, the AUT Agent will not be
able to communicate with your AUT!

4.2.2.1 Setting up an RCP AUT for testing as a part of

the build process

We recommend adding the RCP accessor to your AUT auto-

matically in one of the following ways. Which way you choose
will depend on your AUT, build process and Eclipse version,
and you should check with the development team which ap-
proach is best:

During the product build: Adding the RCP Accessor as a

plugin to your AUT as it is being built is one way to en-
sure that it is present and started when the AUT starts.

Via the OSGI console: If adding the Accessor during the

build is not an option, then you can add it after the build
via the OSGI console. The availability of this option is de-
pendent on the version of Eclipse you use, and your AUT:
It must allow this type of post-hoc inclusion of plugins for
this to work.

262 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

Via the P2 director: Alternatively, you can add it after the

product build using the P2 director. The availability of this
option is dependent on the version of Eclipse you use, and
your AUT: It must allow this type of post-hoc inclusion of
plugins for this to work.

4.2.3 Keyboard Layouts

For RCP AUT’s, a keyboard layout must be entered in the AUT
configuration ( → page 58) . German (DE) and English (US)
are provided as standard keyboard layouts.
If you require a different keyboard layout, you must create a
mapping file for the new language (→Reference Manual p.
391) and place it in the server/resources directory. You also
have to put this mapping file into the RCP Remote Control
plug-in of your AUT:

<RCPAUT>/plugins/org.eclipse.jubula.rc.rcp_<Version>/resources

4.2.4 Design for testability in RCP

4.2.4.1 Naming components

Although components can be located in the AUT even when

they are not named by the developers, naming components
is nevertheless a good idea. In SWT and RCP there is no
method like the Swing setName method to name compo-
nents in the program code. However, you can improve the
testability of your application by using the following method
in your SWT or RCP code for the current component class:
setData(String key, String ComponentName). For the key, use
TEST_COMP_NAME.
Even if you do not name components, you can choose to have
unique names generated for your components in the AUT in
the AUT dialog ( → page 47) .

4.2.4.2 Adding support for text retrieval

You can add support for renderers for SWT components or

items without the getText() method in order to access text
that is otherwise non-readable during test execution.

UserManual V8.0.00170 April 15, 2014 263

 Functional Testing User Manual

Use the method setData(String key, Object value)

on the instance of the component or item whose text you
want to access. The key is TEST_TESTABLE_TEXT
For example, to access an otherwise unreachable text on a
label:
myLabel.setData("TEST_TESTABLE_TEXT", label);
If you are making text in e.g. a table accessible, then you will
need to add a dynamic part for the column, e.g.:

myTableItemInstance.setData
("TEST_TESTABLE_TEXT_" + colIdx, text);

4.2.5 Component name generation in RCP

RCP AUT’s often use wizards and standard dialogs. The com-
ponents in these dialogs are not often named by developers,
and are in different places on Windows, Linux and Mac sys-
tems.
You can decide if unique names should be generated for these
components in your AUT, if no name has been given. You
can configure this in the AUT settings ( → page 47) . We
recommend selecting this option, as it makes your tests more
robust to any changes and also makes platform-independent
testing possible in RCP AUT’s.

4.2.6 Best practices for testing RCP AUT’s

Perspective layout reset
One of the features of RCP AUT’s is that they generally re-
member the state of the AUT (position of views, which per-
spective was open) when the AUT is closed. In order to make
tests as robust as possible, we recommend starting each use
case with a module to reset the perspective to its defaults,
and testing with this default perspective.
Workspace choice
RCP AUT’s use a workspace to save user-specific preferences.
The choice of workspace is usually offered before the AUT
starts. This dialog is not currently testable, so we recommend
adding the desired workspace as an AUT argument in the AUT
configuration ( → page 50) . The parameter used to specify
the workspace is -data ”WORKSPACE”.

264 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

4.3 Testing GEF AUT’s

The GEF toolkit is a sub-toolkit of RCP. To be able to test AUT’s
that contain GEF components, you must select RCP as the
toolkit in the Project properties.
The same points about the RCP Remote Control plugin and
the keyboard files mentioned in the section on RCP AUT’s (
→ page 260) are also valid for testing AUT’s with GEF com-
ponents.
Testing GEF components is a little different to testing other
components, because we highly recommend that the soft-
ware developers use our accessibility plug-in in the AUT to
make the testing of GEF components more robust.

GEF testing is supported from GEF version 3.0 up to but

not including 4.0. We test our GEF support on GEF ver-
sion 3.7.2.

4.3.1 Testing GEF components

Like other tests, tests for GEF components are based on the
component, action, parameter principle. However, it is im-
portant to note that individual figures are not addressed us-
ing component names. The only component that is mapped
in GEF is the figure canvas. The figures on the canvas are
tested by referring to their textpath. See the Reference Man-
ual (→Reference Manual p. 295) for more details on the GEF
actions.

The observation mode cannot be used to record actions

in the canvas.

4.3.2 Using the GEF inspector

The GEF Inspector View in the ITE allows you to collect infor-
mation about the textpath to an item from within your RCP
AUT. For many of the actions on GEF figures, you will need to
know the textpath. Using the accessibility plug-in will mean
that the textpaths will be easier to determine without the in-

UserManual V8.0.00170 April 15, 2014 265

 Functional Testing User Manual

spector. See the extension manual for further information on

creating your own accessibility plug-in.
To use the inspector, you must have started the AUT ( → page
154) .

1. Open the GEF Inspector View if it is not already open via:

Window → Show View → Other

2. In the Inspector View, select the AUT you want to inspect

in from the drop-down menu next to the activate inspector
button.

3. Click on an item to inspect it.

Make sure that the AUT is in focus before inspecting the

figure. You may need to click in the title bar once to do
this.

4. In the GEF Inspector View, the path to the item will be

shown. If the code for your AUT uses the accessibility code,
then the textpath will be less complex and more readable.

5. You can copy the textpath from the Inspector View via
the context-menu and paste it as a parameter in your Test
Cases.

You will need to activate the inspector for each item you
want to inspect

4.4 Testing JavaFX AUT’s

You can write tests for JavaFX AUT’s when you select the
toolkit concrete or JavaFX in the Project properties. The
JavaFX and concrete toolkits actually contain the same actions
as each other.
When you select JavaFX as the Project toolkit, the library
Project unbound_modules_concrete is automatically reused in
your Project. The actions in this library are described in the ref-
erence manual (→Reference Manual p. 21).

266 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

4.4.1 Design for testability in JavaFX

4.4.1.1 Naming components

Although components can be located in the AUT even when

they are not named by the developers, naming components
is nevertheless a good idea. You can improve the testability of
your application by using the following method in your JavaFX
code for the current component class: setId();.

4.4.2 Information on the support for JavaFX

AUT’s
AUT modifications
No modifications are necessary to ensure that the AUT can be
tested. The AUT can be deployed normally: no extra steps are
needed for a test deployment. Information on AUT types
AUT’s that are created with FXML seem to display long delays
when showing screens. Object recognition and test execu-
tion are possible, but you will need to use longer waits when
opening new screens in tests for these AUT’s.
Supported components
Below is an overview of the supported components. You
can also see individual tickets for component support via the
Eclipse bugzilla:
http://eclip.se/421595

Buttons are supported

Toggle buttons, radio buttons and checkboxes: are sup-

ported

Text components such as labels and text are supported

Text input components such as text fields and password

fields are supported

Combo boxes: are supported. You can select from combo

boxes and check items in them, but we have not yet im-
plemented support for text input on editable combo boxes.

Choice boxes are supported. To be able to map a choice

box, you must ensure that the choice box has a padding
(e.g. of 5px) between the choice box itself and its compos-
ite components. This allows you to collect the choice box

UserManual V8.0.00170 April 15, 2014 267

 Functional Testing User Manual

itself in the Object Mapping Mode instead of the compo-

nents within it. You may, in some cases, be able to col-
lect the choice box even without padding by hovering the
mouse just outside of its bounds at e.g. the bottom right.

Tables: TableView tables are supported

Trees: TreeView trees are supported

Lists: ListView lists are supported. Drag and drop of list items
is not supported.

Tabbed components: Tab Panes are supported

Context menus: are supported

Menu bars: are supported. Only single menu bars are cur-
rently supported. If your AUT has multiple menu bars, an
error will be thrown.

Accordeons are supported. To be able to map an accordeon,

you must ensure that the accordeon has a padding (e.g. of
5px) between the accordeon itself and its composite com-
ponents. This allows you to collect the accordeon itself
in the Object Mapping Mode instead of the components
within it. You may, in some cases, be able to collect the
accordeon even without padding by hovering the mouse
just outside of its bounds at e.g. the bottom right.

Image views are supported. You can perform graphics com-

ponent actions on them (check, click, wait for, ...)

Dialogs from ControlsFX Lightweight and heavyweight di-

alogs from the ControlsFX library are supported

Application actions are supported. Synchronized termina-

tion and restart is not implemented. The simple restart
does work, however.

Other information The observation mode, autrun and code

coverage do not work for JavaFX AUT’s.

4.5 Testing HTML AUT’s

HTML AUT’s are supported for testing. To be able to test
HTML applications, select the HTML toolkit in the Project
properties.

268 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

When you select HTML as the Project toolkit, the li-

brary Projects unbound_modules_concrete and un-
bound_modules_html are automatically reused in your
Project. The actions in these libraries are described in the
reference manual (→Reference Manual p. 21).

4.5.1 Supported HTML AUT’s

AUT’s written with the HTML GUI toolkit are supported ac-
cording to the following points:

• The HTML tests are driven by Selenium. We document

which version of Selenium we are currently using as a driver
in the release notes. Check the release notes for the cur-
rent Selenium version and check the Selenium documenta-
tion for supported browsers.
• We strongly recommend writing HTML AUT’s so that they
are conform to the W3C standard. You can check whether
your AUT is W3C conform using an online validator:
http://validator.w3.org
• We recommend disabling the protected mode in Internet
Explorer when testing HTML AUT’s. This may be required in
Windows 8+ when performing key combinations as a part
of the test, but may also be required for other versions and
other actions.
• Some of the actions in the concrete toolkit (i.e. which
are theoretically valid for all AUT types) may not (yet) be
supported. In some cases, this is because the component
doesn’t exist as such in HTML AUT’s (menu bars for exam-
ple). In other cases, text components such as tables or lists
do not have a concept for dealing with selection as they
do in e.g. Swing.
• The autrun option to start AUT’s ( → page 55) cannot be
used for HTML AUT’s.
• There is a minor difference in the way that clicks are per-
formed in HTML compared to other supported toolkits. In
other toolkits such as Swing, an API is used to simulate ac-
tions at the OS level so that the the computer itself can’t
distinguish whether it came from a tool or a keyboard. A
normal click by a user in a browser would go via the mouse
through various layers to the webserver, resulting in a re-
quest to that webserver. The clicks in the HTML toolkit are

UserManual V8.0.00170 April 15, 2014 269

 Functional Testing User Manual

performed by firing DOM events using Javascript therefore

bypassing the mouse level. So, although the computer can
tell the difference, the webserver can’t.

• HTML AUT’s can be tested in single-window or multi-

window mode. If your AUT has functions that cause new
windows to open, then you should specify this in the AUT
configuration. You can then map components from dif-
ferent windows, and also use specific actions to switch
windows during your test. Multi-window mode on Inter-
net Explorer is considerably slower than on Firefox – this
is a known issue registered at Selenium. There are known
issues with AUT starting in multi-window mode on OSX
systems for Firefox and on Safari – we do not test these
combinations.

Closing HTML AUT’s via the close button

• If you close a HTML AUT by closing the browser, the ITE will
correctly notice the closure after 5 seconds (configurable)
and will remove the AUT from the running AUT’s view.

• The mechanism works by polling the AUT, and if it is no

longer there after the configured time, the AUT is consid-
ered to be stopped.

• If your AUT may sometimes be unreachable for longer than

the default 5 seconds, you can change this time by using a
process or system property:
TEST_MAX_AUT_RESPONSE_TIME=<timeInMs>.

• Further information on this is available in this issue:

http://bugzilla.bredex.de/1391.

Overwriting launcher options now possible

• You can now manually overwrite launcher options for the

launchers for autrun, testexec, dbtool and dashboard.

4.5.2 Design for testability in HTML AUT’s

Although it is not obligatory to name components in your
AUT, you neverthless make your AUT more testable by doing
so.

• Each supported component in HTML AUT’s can have its

own attribute used to identify it during test execution.

270 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

• In your AUT configuration ( → page 53) , you can define

an attribute name which should be used as an identifier
for components.

• For example if your attribute name is testid (e.g.

<div testid=”Username”></div>) then you would
enter testid in the AUT configuration.

4.6 Testing Windows (.NET) AUT’s

You can write tests for Windows AUT’s that use the .NET
framework when you select the toolkit concrete or win in the
Project properties. The win and concrete toolkits actually con-
tain the same actions as each other.
When you select win as the Project toolkit, the library Project
unbound_modules_concrete is automatically reused in your
Project. The actions in this library are described in the refer-
ence manual (→Reference Manual p. 21).

4.6.1 Supported Windows AUT’s

The following AUT’s written with the .NET framework are sup-
ported:

• You must be using Windows XP or higher.

• We have performed our WinForms and WPF tests with an

AUT in .NET version 4.0. Although tests may be also be
executable with .NET 3.5 (or even lower), the minimum
supported version is .NET 4.0.

The support for WPF AUT’s is currently experimental.

We encourage you to test the support with your own
AUT’s and welcome feedback about the current support.

• AUT’s that are not written with WinForms or WPF (e.g.

Win32, etc.) are not supported in the current version.

UserManual V8.0.00170 April 15, 2014 271

 Functional Testing User Manual

4.6.2 Information on the support for Win-

dows AUT’s
4.6.2.1 The UI Automation Framework and clicking

The Windows support is realized using the Microsoft UI Au-

tomation Framework. This framework is used to access com-
ponents and to perform many of the supported actions. The
Automation Framework is the recommended approach to
controlling .NET AUT’s, and it does not perform clicks or text
inputs at the Operating System level; rather it invokes func-
tions on the components.
For the majority of the click actions, however, we have imple-
mented real clicks that are performed at the Operating Sys-
tem level in order to allow e.g. opening of context-menus
via right click, clicks at specific positions and position-based
access (e.g. for context-menus, move actions and check at
mouse position).

4.6.2.2 Supported AUT’s

We currently only support WinForms and WPF AUT’s. It may

be possible to map components from e.g. Win32 AUT’s, but
the tests on such components may fail. It is therefore worth
checking with your development team what components the
AUT you are testing is using.

4.6.3 Information on WinForms AUT’s

4.6.3.1 Supported and unsupported components

Our regression tests are performed on a variety of compo-

nents, including (but not limited to): buttons (push, check-
box, radio), textfields, trees, tables, menus, context menus,
lists, combo boxes and tabbed panes.
Possible component restrictions

Tables: Our actions have been written for and tested on ta-
bles of type System.Windows.Forms.DataGridView. Since
the introduction of this component in .NET 2.0, the
older System.Windows.Forms.DataGrid is no longer rec-
ommended. System.Windows.Forms.DataGrid tables are
not supported.

272 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

4.6.3.2 Supported and unsupported actions

Most of the actions that are available in the concrete toolkit

have been implemented for Windows AUT’s. These include,
but are not limited to: clicking, checking, entering text and
selecting.
Actions not (yet) implemented

Drag and Drop

Using row headers for table selection: Unlike other sup-

ported toolkits, Windows AUT’s have integrated row head-
ers in tables. These are not yet supported. When using the
actions Select Value from Row and Select Cell, the row can
therefore only be selected using its index. It is not possible
to enter the value in the first column to identify the row as
is the case in other toolkits.

Combo box: Check selection of entry by index: This ac-

tion will not be implemented for Windows AUT’s, as the
dropdown list needs to be opened to access the list items.
If text is already in the text field of the combo box when
it is opened, then the first item that matches the entered
text is selected – this may change the selected item and
therefore the index.

Combo box: Relative selection: For the same reason as

above, only the value absolute is supported for selections
by value from the combo box.

Trees: Multiselection: As WinForms does not support true

multiselection for Trees, any actions used to test the multi-
selection of a Tree will fail.

Deprecated actions: Any actions marked as deprecated

have not been implemented.

Show Text

Editability checks for tables: The actions for check ed-

itability on a whole table, or on individual cells within it,
are not supported in the current version.

Checking the text of password fields: The contents of

password fields cannot be checked in tests for Windows
AUT’s, as the Windows RC does not run in the same pro-
cess as the AUT itself. Such checks on password fields will
always fail with a Check Failed error.

UserManual V8.0.00170 April 15, 2014 273

 Functional Testing User Manual

4.6.4 Information on WPF AUT’s

The support for WPF AUT’s is currently experimental. We en-
courage you to test the support with your own AUT’s and
welcome feedback about the current support.

4.6.5 Operating system language, compo-

nent recognition and extensibility
The UI automation framework does not provide language-
independent component types for component recognition.
As this would have otherwise lead to language-dependent
mapping, we have implemented an internal map from the
component type ID to our own designation of the component
type. This makes object mapping language-independent, but
means that the Windows toolkit cannot currently be extended
to add support for new components.

4.6.6 UI automation and screen scaling

We recommend against changing the DPI settings on your
test machines to make components and text appear larger.
Such modifications may lead to unpredictable problems for
test execution. The resolution of the screen, however, has no
bearing on object recognition.

4.6.7 Windows AUT’s and the observation

mode
The observation mode cannot be used for Windows (.NET)
AUT’s.

4.6.8 Mapping components in WinForm-

sAUT’s
Composite components may be mappable as separate
parts
For some components that consist of other components (e.g.
combo boxes that consist of a textfield and a button), it may
be possible to collect the individual components (textfield,
button) as well as the whole composite (the combo box).
When performing mapping, you should make sure that you

274 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

are collecting the component that it makes sense to perform

your chosen action on. For example, you can only perform
a Select from Combo Box on a combo box. While it may be
possible to perform a Replace Text on the textfield included in
the combo box, it will almost always make more sense to deal
with the logical component as opposed to its parts.
Mapping of dynamic content items in components
It may be possible to map individual items within components
that are addressed as a whole component in the test speci-
fication. For example, it may be possible to map individual
list entries. Even when this is the case, we recommend map-
ping the list component and performing actions on the whole
component that deal with its content (e.g. Select entry from
list, Check existence of entry in list). This makes tests more
robust and able to deal with dynamic data.
Mapping components in tabbed panes
When mapping a component that is contained in a tabbed
pane, it is important to move the mouse cursor quickly and
directly to the component you want to map, to avoid collect-
ing the tabbed pane itself.

4.6.9 Nested scrolling

AUT’s in which scrollable components are nested (e.g. a scrol-
lable component within a scrollable component and so on)
may not be supported in the current version.

4.6.10 autrun not supported

Starting WinForms AUT’s with autrun is not yet supported.

4.7 Testing iOS AUT’s

You can write tests for iOS AUT’s when you select the toolkit
concrete, mobile or iOS in the Project properties.
When you select iOS as the Project toolkit, the library Projects
unbound_modules_concrete, unbound_modules_mobile and
unbound_modules_iOS are automatically reused in your
Project.
The actions in the concrete library are described in the refer-
ence manual (→Reference Manual p. 21).

UserManual V8.0.00170 April 15, 2014 275

 Functional Testing User Manual

4.7.1 Supported iOS AUT’s

The following AUT’s written for iOS are supported:

• You must be using iOS SDK 5.0 or higher. iOS AUT’s on

version 6.1 and 7.0 of iOS are supported.
• You can run tests either on a simulator (i386) or on a real
device (armv7 and armv7s).

4.7.2 Setting up an iOS AUT for testing

If you want to test an iOS application, you have to prepare
the AUT in order to make it testable.

This preparation is designed to be undertaken by a de-

veloper who has access to the AUT’s source code as well
as knowledge of developing for iOS using Objective-C
and Xcode. These instructions assume you are using
Xcode 4. For Xcode 3 please adapt the instructions ac-
cordingly.

4.7.2.1 Add the library to your project files

The first step is to link the librc.mobile.ios.nativ static library

and its header file directly into your iOS application. This lets
your project and thereby your iOS application be run as a
testable AUT.

1. Locate the development/iOS-support.zip file in the installa-

tion directory in Finder.
2. Unzip it and drag all of its content into the Project Naviga-
tor.

4.7.2.2 Create a Testing Target

We strongly recommend that you create a separate target

which contains and uses all the necessary modifications for
your AUT to be testable. Once you have created a second
target for the testing-enabled version of your AUT to test,
you can begin testing simply by running this second target.
Having a separate target also ensures that no testing code
will be released into the productive version of your app.

276 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

The new target will start as a duplicate of your old target. To

create the duplicated target:

1. Select the project file for your app in the Project Navigator.

2. From there, CTRL+click the target for your app and select
the ”Duplicate” option. Xcode may ask you if you want
your copy to be for a different iOS device, which you don’t,
so choose ”Duplicate Only”.

3. The new target will be created. We suggest renaming it,

e.g. to GUIdancer or Jubula Tests.

4. You can also (optionally) rename the new target from the
default MyApp copy to something more meaningful e.g.
MyApp (GUIdancer or Jubula Tests) by selecting the ”Build
Settings” tab and searching for ”Product Name”, then
changing the value to a new name.

4.7.2.3 Configure the Testing Target

Now that you have a target for your tests, add the tests to
that target.

1. With the project settings still selected in the Project Navi-

gator, and the new integration tests target selected in the
project settings, select the ”Build Phases” tab.

2. Under the ”Link Binary With Libraries” section, press the

”+” button.

3. In the sheet that appears, select CFNetwork.framework

and SenTestingKit.framework and click ”Add”.

4. Then click ”Add other...” in the lower left corner and lo-
cate and select the library librc.mobile.ios.nativ.a and click
”Open”.

5. Next, make sure that the UIRemoteControl.h header file

can be accessed. To do this, add the UIRemoteControl.h
to the ”Header Search Paths” build setting. Start by se-
lecting the ”Build Settings” tab of the project settings, and
from there, use the filter control to find the ”Header Search
Paths” setting.

6. Double click the value, and add the file UIRemoteControl.h

to the list. If it’s not there already, you should add the
$(inherited) entry as the first entry in this list.

UserManual V8.0.00170 April 15, 2014 277

 Functional Testing User Manual

7. The iOS support takes advantage of Objective C’s ability to

add categories to an object, but this isn’t enabled for static
libraries by default. To enable this, add the -ObjC and -
all_load flags to the ”Other Linker Flags” build settings.

8. Finally, add a preprocessor flag to the testing target so that

you can conditionally include code. This will help to make
sure that none of the testing code makes it into the pro-
duction app. Call the flag RUN_FUNCTIONAL_TESTS and
add it under the ”Preprocessor Macros”. Again, make sure
the $(inherited) entry is first in the list.

4.7.2.4 Add hook into the AUT

Finally, the app needs a hook so that it actually al-

lows the attachment and running of the tests when ex-
ecuting the Tests target. This is achieved by using the
RUN_FUNCTIONAL_TESTS macro that was defined in the pre-
ceding section. This ”preprocessor macro” is only defined in
the testing target, so the remote controlling won’t be pos-
sible in the regular target. To allow your AUT to be remote
controlled, add the following code to your application dele-
gate:

...
#if RUN_FUNCTIONAL_TESTS
#import "UIRemoteControl.h"
#endif
...

and the following code to the end of its -

(void)applicationDidFinishLaunching[withOptions]: method

...
#if RUN_FUNCTIONAL_TESTS
[UIRemoteControl attach];
// alternatively you can
// allow the UIRemoteControl
// to use a specific port number
// on the iOS device
// by using:
//
// [UIRemoteControl attach:<portNo>];
//
// this is necessary

278 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

// e.g. when you’re running

// different AUTs in parallel on
// the same iOS device
#endif
...

You also have to make sure that your application delegate

provides a UIWindow property called window which contains
the window used to present the app’s visual content on the
device’s main screen.

...
#if RUN_FUNCTIONAL_TESTS
@property(nonatomic, retain)
UIWindow *window
#endif
...

Everything should now be configured. When you run the AUT

tests target it will launch your app and allow the ITE to re-
motely attach (on the port specified, or on 11022 if none is
entered) and execute tests.

If you do not follow the above steps, the AUT Agent

will not be able to communicate with your AUT!

This documentation is derived from the KIF installation docu-

mentation (http://github.com/square/KIF) as we make use of
KIF internally.

4.7.3 Design for testability in iOS AUT’s

4.7.3.1 Naming components

To be able to robustly test iOS AUT’s, we highly recommend

naming the components in your AUT. The name that is used
as a part of the object recognition is the accessibility identifier.
This is a variable that can be specified for each UI component
in an iOS AUT. It is language-independent and is designed for
use in automated tests. We recommend using unique names
throughout the AUT.

UserManual V8.0.00170 April 15, 2014 279

 Functional Testing User Manual

4.7.3.2 Adding support for text retrieval

If you use custom UI views and cannot access the text con-
tained in them during a test, then you can implement the
UITestable protocol, which provides a method allowing the
remote control to read the text from such controls.

4.7.4 Addressing the correct component in

your iOS tests
One of the specifics of iOS AUT’s is that individual components
such as labels on buttons are separately collectible. You can
specify tests that will tap e.g. the label on a button, but this
may not necessarily result in the button itself being tapped.
In order to tap the button, it may be necessary to ensure that
the action you perform is actually sent to the button, and not
the label.
Another example of this is when dealing with components
such as lists and tabbed controls. You can map the individual
items within the list or the tabbed control in order to check
them or tap them, but it is also possible to map the whole
tabbed control or list in order to address the items within the
component based on their content or index. Depending on
what you want to test, you may want one option or the other.
As a general rule, aiming to address the higher-level compo-
nent (the list instead of the button, for example), is usually
preferable.
The different types of object mapping gestures (see ( → page
148) ) ensure that you can always see which components are
available. Part of your test design will involve identifying the
component you want to test and choosing the correct techni-
cal name to map to your component name.

4.7.5 Working with iOS components and ac-

tions
When testing iOS AUT’s, many of the components will be sim-
ilar to those found in desktop AUT’s. You can use the actions
from the unbound_modules_concrete library to perform ac-
tions such as:

• Click (tap) items.

• Check existence and various properties of components.

280 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

• Synchronize based on component availability.

• Replace text on text components.

The following sections deal with how to use actions to address

specific components in iOS.

4.7.5.1 Working with iOS switches

Switches in iOS AUT’s (Figure 4.1 → page 281 ) can be ad-

dressed using the actions:

• Click (to tap the switch). Depending on the AUT, this will
toggle the state of the switch.

• Other actions on the Graphics Component such as check

existence, wait for component etc.

• Swipe. By entering a direction, you can specify whether to

activate or deactivate the switch.

• Check selection (Button Component) - use this to check

whether the switch is activated or not.

Figure 4.1: Switch

4.7.5.2 Working with iOS Table Views (lists)

• Table Views in iOS are used to organize information on the

screen. They may just consist of items (and therefore look
like a simple list (Figure 4.2 → page 282 )), or they may
contain various sections – each section can contain other
components (Figure 4.3 → page 283 ).

• Both types of Table View are testable using the actions

available on the List component.

• You can, e.g. select items from the list, check their exis-
tence etc.

• In the Table Views that contain other components, you

can also address the individual components (labels, but-
tons etc.) in the list using the actions such as check exis-
tence, check text, click etc.

UserManual V8.0.00170 April 15, 2014 281

 Functional Testing User Manual

• When writing a test on these components, it is important

to decide which component you want to test ( → page
280) .

• If you need to scroll to a certain section of a list that is

currently not visible, you can use the select action on the
list component to make the correct portion of the screen
visible. You can also use 0 clicks to simply hover over the
item instead of tapping it.

Bear in mind that many apps remember where you were

on a screen. You may need to add explicit scrolling (via
selection) to your tests in order to ensure that the com-
ponents you require are on screen.

Figure 4.2: Simple Table View (list component)

4.7.5.3 Working with iOS tabbed controls

• Many components in iOS AUT’s can be addressed as

tabbed controls – in a similar way to tabbed panes in a
Swing AUT for example.

• The components tabbed bar and segmented control (Fig-

ure 4.4 → page 283 ) are examples of two components
that can be addressed with the actions on the tabbed con-
trol component. You can select a tab based on its content
or its index, check the selection of a specific tab, check the
existence etc.

282 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

Figure 4.3: Grouped Table View (list component)

• In many cases, you will also be able to map the individ-

ual tabs as e.g. buttons or labels. As described earlier (
→ page 280) , we highly recommend ensuring that you
are addressing the most relevant and high-level control for
your test.

Figure 4.4: Segmented controls (tabbed controls)

4.7.5.4 Working with iOS pickers

• The iOS components pickers can be addressed using ac-

tions for combo components.

• You can select items from pickers that have only one col-
umn (Figure 4.5 → page 284 ) using the actions for
combo component in the concrete toolkit. You can also
check the existence of items in the picker, check their se-
lection etc.

UserManual V8.0.00170 April 15, 2014 283

 Functional Testing User Manual

• To work with pickers that have multiple columns, you

should use the actions in the iOS toolkit to select from the
picker based on the column value. In this way, you can
specify which column the selection should take place in.

Figure 4.5: Single picker (combo component)

Figure 4.6: Picker with multiple columns

Hints for working with pickers

Check text on multi-column pickers: If you use the action

check text on pickers with multiple columns, the result will
be a concatenated value of all columns.
Grey items not addressable: Items that are grey in the
picker cannot be checked or selected.
Index-based selection on infinite pickers: Some pickers
do not have a finite amount of items – they scroll infinitely.
We strongly advise against usin index-based selection or
checking on such pickers.

4.7.5.5 Working with gestures

• In the iOS toolkit, you will find swipe actions for many com-
ponents. You can use these actions to perform swipes in a
specific direction.

284 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

4.7.5.6 Working with the keyboard

• To use actions such as replace text, you do not need to

worry about using the keyboard – the test execution com-
ponent does this for you.

• However, if you would like to press specific buttons on the

keyboard such as »DONE«, »DELETE« and so on, then you
should use the action in the unbound_modules_ios called
Tap View with Accessibility Label.

• This allows you to press any item on the screen (on the
keyboard or elsewhere) based on its accessibility label:

– The accessibility label is an internal attribute for a com-

ponent that is designed to be used by screen readers
etc.
– You can find out the accessibility label for an item by us-
ing the Accessibility Inspector on e.g. an iOS simulator.
You can activate the Inspector via the General Settings.
– Once you know the label, you can enter it as a parame-
ter (exactly as it is written).
– Bear in mind that accessibility labels are language-
dependent (i.e. you will need to translate the test data),
and also sometimes orientation-dependent. It is also
not necessarily the case that the accessibility label is the
same as the text on the item that is visible in the AUT.

Many iOS devices have a setting activated to start each

text with a capital letter. We recommend deactivating
this setting for your tests, as attempts to enter lower-
case text at the beginning of a textfield will otherwise
fail.

4.7.5.7 Working with unmappable (unsupported) com-

ponents

If there is a component that is unsupported, then you may be

able to tap it using the action in the unbound_modules_ios
called Tap View with Accessibility Label. For more information
on this action, see the section on working with the keyboard
( → page 285) .

UserManual V8.0.00170 April 15, 2014 285

 Functional Testing User Manual

4.7.5.8 Other important information for testing iOS

AUT’s

Non-supported components
The following components are not a part of the iOS toolkit,
and their actions from the concrete toolkit cannot be used in
iOS tests:

• Menus

• Tables

• Trees

• Context menus

Non-supported actions
The following actions are currently not supported:

Take screenshot: It is currently not possible to take screen-

shots as a part of the test. Automatic screenshots on errors
are, however, produced.

Restart: The restart action restarts the internal connection to

the AUT, not the AUT itself. This means that you should
consider how to reset your AUT to a known starting point
as part of your Event Handlers (to ensure that the test can
continue despite an error). How to do this will be depen-
dent on your AUT.

Check text on secure textfields: The text on a secure

textfield cannot be accessed, e.g. to perform check text.

Check / store property actions are not supported in the

current version.

Application input text is not supported. Use input text or

replace text on Component with Text Input instead.

Copy to clipboard is currently not supported.

Other information

No detailed information on test failure: When a Test

Step fails, there is currently no detailed information about
the reason for the error.

286 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

Support characters for text input: Any keys on the key-

board that are only accessible by a long press, and not by
switching the whole keyboard (e.g. characters with um-
lauts) cannot currently be entered.

Disabled components cannot be mapped directly using

e.g. tap. Instead, to collect the technical name for a dis-
abled component, you should use the long tap gesture to
collect all of the visible components. This includes the dis-
abled components.

4.7.6 Testing AUT’s written with Monotouch

4.7.6.1 Create a binding project

First you have to create a MonoTouch Binding Project.

The project template can be found in the category
C#/MonoTouch. A binding project contains a reference to the
MonoTouch library as well as two C# files called ApiDefini-
tion.cs and StructsAndEnums.cs.

4.7.6.2 Add the library to the binding project

Add the library file librc.mobile.ios.nativ.a to the new bind-

ing project. The file is part of the archive development/iOS-
support.zip in the installation directory.
MonoDevelop will ask either to copy, move or link the file
in the binding project. We recommend choosing copy be-
cause MonoDevelop will place a generated C# file called li-
brc.mobile.ios.nativ.linkwith.cs next to the library file.

4.7.6.3 Setting up linker options

The file librc.mobile.ios.nativ.linkwith.cs specifies the linker

options. It contains a single annotation named LinkWith.
Change the annotation to:

[assembly: LinkWith
("librc.mobile.ios.nativ.a",
LinkTarget.Simulator | LinkTarget.ArmV6
| LinkTarget.ArmV7,
"-ObjC -all_load", ForceLoad = true,
Frameworks="CFNetwork")

UserManual V8.0.00170 April 15, 2014 287

 Functional Testing User Manual

Doing this allows your AUT to be tested on the simulator as

well as on iOS devices. The framework CFNetwork is needed
to communicate with the ITE.

4.7.6.4 Defining the API contract

An Objective-C header file is provided. To use the library from

within a .NET project, you have to link the library’s interface
parts to .NET structures.
Linking is done in the file ApiDefinition.cs. You have to trans-
late the header file contents into some C# interfaces. Finally
you have to annotate the interfaces/methods/parameters that
name the library’s objects.
Detailed information about translation and annota-
tion may be found on Xamarins web site: http:
//docs.xamarin.com/ios/Guides/Advanced_
Topics/Binding_Objective-C_Libraries.
To use the library, adapt the following:
Library’s header file content Linking in ApiDefiniton.cs
@interface ObjCClass
... [BaseType (typeof (NSObject))]
interface ObjCClass {
@end ...
}
+(void)method1:(int)parameter; [Static, Export(”method1:”)]
void method1(int parameter);
-(NSString∗)method2; [Export”method2”)]
NSString method2();
@protocol MyDelegate
-(int)method3;
@end [BaseType (typeof(NSObject))]
[Model]
interface MyDelegate {
[Export(”method3”)]
[Abstract]
int method3();
}

4.7.6.5 Building a .NET library

When linking is done, build the binding project in Release

mode. When it is done, you will find a DLL in the bin/Release
directory of the binding project.

288 April 15, 2014 UserManual V8.0.00170

Toolkit-specific information

Copy this DLL to your project for your AUT and add it as a
reference to a .NET Assembly.
When the library changes, we recommend to remove this ref-
erence and repeat the entire process.

4.7.6.6 Add hook into AUT

When the binding DLL is referenced by your project, you can

use the namespace and all interfaces defined in ApiDefini-
tion.cs. Adding the hook is the same as described for native
iOS Apps but using C# syntax. You should omit the preproces-
sor macros mentioned there or implement your own switch
for enabling the test hook.
Native iOS Apps are required to provide a ”window” property
in the AppDelegate. Your C# AppDelegate has to provide and
use this property too:

[Export("window")]
UIWindow window { get; set; }

UserManual V8.0.00170 April 15, 2014 289

 Functional Testing User Manual

290 April 15, 2014 UserManual V8.0.00170

User interface

Chapter 5

User interface

There are four types of area in the user interface:

Perspectives
A perspective is a collection of views, editors and browsers on
the screen.
Browsers
Browsers let you see the Test Cases and Test Suites you have
created in their hierarchical structures. There is also a browser
for component names.
Editors
Editors let you modify, add and delete items. You can open
editors by double-clicking on a node (e.g. Test Suite or Test
Case) in a browser.
Views
Views show details about the currently selected item. If you
single-click an item in a browser, the details in the views are
read-only. If you select an item from within an editor, you can
edit some of the values in the views.

You can change the way your user interface looks by moving
areas, changing the colors, and hiding/showing views ( →
page 206) .
To reset the default layout at any time, select:
Window → Reset Perspective .

UserManual V8.0.00170 April 15, 2014 291

 Functional Testing User Manual

5.1 Perspectives

5.1.1 The Functional Test Specification Per-

spective
The Functional Test Specification Perspective (Figure 5.1 →
page 293 ) provides browsers, editors and views to let you
create and edit tests.
It contains:

• The Test Suite Browser

• The Test Case Browser

• The Component Name Browser

• The editor area

• The Properties View

• The Data Sets View

• The Component Names View

• The Problem View

• The search result view (behind the Problem View)

• The Running AUT’s View

The Component Names View, Data Sets View and Properties

View show you details about the currently selected item in the
browser or editor.

292 April 15, 2014 UserManual V8.0.00170

User interface

Figure 5.1: Specification Perspective

UserManual V8.0.00170 April 15, 2014 293

 Functional Testing User Manual

5.1.2 The Functional Test Execution Perspec-

tive
In the Functional Test Execution Perspective, you can see the
following (Figure 5.2 → page 294 ):

• The Test Suite Browser

• The Test Result View

• The Properties View

• The Image View

Figure 5.2: Functional Test Execution Perspective

You cannot edit in the Functional Test Execution Perspective,

but you can see the results of tests that have been started
interactively..

294 April 15, 2014 UserManual V8.0.00170

User interface

5.1.3 The Functional Test Reporting Perspec-

tive
In the Functional Test Reporting Perspective, you can see an
overview of all the test runs in the current database, for all
Projects it contains. You can reopen test runs if the details for
the report are still in the database ( → page 161) and analyze
the test using the Properties View and the Image View.
The Functional Test Reporting Perspective (Figure 5.3 → page
296 ) contains the following views:

• The Test Result View

• The Properties View

• The Image View

• The Test Result Summary View

UserManual V8.0.00170 April 15, 2014 295

 Functional Testing User Manual

Figure 5.3: Reporting Perspective

296 April 15, 2014 UserManual V8.0.00170
User interface

5.1.4 The workspace perspective

In the workspace perspective (Figure 5.4 → page 298 ),
you can view the Projects and files in your workspace. The
workspace perspective contains the following:

• Navigator View

• An editor area to view e.g. Excel and HTML files.

UserManual V8.0.00170 April 15, 2014 297

 Functional Testing User Manual

Figure 5.4: Workspace Perspective

298 April 15, 2014 UserManual V8.0.00170

User interface

5.2 Browsers
There are three browsers in the ITE:

The Test Case Browser lets you create and manage your
Test Cases.

The Test Suite Browser lets you create and manage your
Test Suites.

The Component Name Browser lets you see, merge add

and delete component names.

5.2.1 The Test Suite Browser

The Test Suite Browser is by default in the upper left-hand
corner of the Functional Test Specification Perspective. In this
browser, you can create Test Suites and Test Jobs for executing
tests.
More information on working with browsers is available in the
Tasks chapter ( → page 65) .

You can filter in the Test Suite Browser using the field at
the top. Use star * as a wild card.

5.2.2 The Test Case Browser

The Test Case Browser is by default in the lower left-hand
corner of the Functional Test Specification Perspective. In this
browser, you can create Test Cases, which are the ”building
blocks” for your tests. They are used to group Test Steps and
other Test Cases.
More information on working with browsers is available in the
Tasks chapter ( → page 65) . To make working with larger
Projects easier, you can also have the Test Case Browser open
more than once ( → page 67) .

You can filter in the Test Case Browser using the field at
the top. Use star * as a wild card.

UserManual V8.0.00170 April 15, 2014 299

 Functional Testing User Manual

5.2.3 The Component Name Browser

The Component Name Browser (Figure 5.5 → page 300 )
is by default in the lower left-hand corner of the Functional
Test Specification Perspective, behind the Test Case Browser.
In this browser, you can see component names used in this
Project and in other Projects. You can rename, add, delete
and merge component names and can also find where you
have used component names in your test.

You can filter in the Component Name Browser using

the field at the top. Use star * as a wild card.

Figure 5.5: Component Name Browser

5.3 Editors
Editors appear in the editor area in the middle of the perspec-
tive when you double-click an item in one of the browsers or
in the Navigator View.
You can tell what sort of editor it is in two ways:

1. The tab for each editor shows an ID-code for what type of
editor it is:

• ”TC” for the Test Case Editor

300 April 15, 2014 UserManual V8.0.00170

User interface

• ”TS” for the Test Suite Editor

• ”OM” for the Object Mapping Editor
• ”TD” for the Central Test Data Editor

The tab also shows the name of the item the editor is for.

5.3.1 Test Case Editor

You can open the Test Case Editor by double-clicking a Test
Case in the Test Case Browser.
In the Test Case Editor:

• You can create, modify and delete Test Steps.

• You can add and delete other Test Cases.

• You can add Event Handlers. They appear in the Event

Handler area below the Test Case Editor.

• You can alter test data and component names for the Test
Case.

When you single-click items (Test Cases, Test Steps) in the Test
Case Editor, the support views (Properties View, Component
Names View and Data Sets View) show details about this item.
Using these views, you can edit the properties, test data and
component names for this item.

5.3.2 Test Suite Editor

You can open the Test Suite Editor by double-clicking a Test
Suite in the Test Suite Browser.
In the Test Suite Editor:

• You can add Test Cases to Test Suites.

• You can alter the Test Suite properties (e.g. the AUT it uses,
the default Event Handlers).

• You can alter test data for the Test Cases shown.

In the Test Suite Editor, you can only alter details for the
top-level Test Cases for each subtree.

UserManual V8.0.00170 April 15, 2014 301

 Functional Testing User Manual

When you single-click Test Cases in the Test Suite Editor, the
support views (Properties View, Component Names View and
Data Sets View) show details about this Test Case. Using these
views, you can edit the properties, test data and component
names for this item.

5.3.3 Object Mapping Editor

Each AUT in a Project has an Object Mapping Editor. You
can open the Object Mapping Editor by right-clicking on a
Test Suite in the Test Suite Browser and selecting ”open with
Object Mapping Editor”.
You can also open the Object Mapping Editor by single-
clicking the chosen Test Suite and clicking on the ”start Object
Mapping Mode” button on the toolbar. This also starts the
Object Mapping Mode.
The Object Mapping Editor has four tabs, a split view, a tree
view, a table view and configuration tab. In the Object Map-
ping Editor:

• You can see all the component names you have used in the
Test Suite you selected, and any other Test Suites which use
the same AUT.

• You can see any technical names you have collected from
the AUT.

• You can see the component and technical names you have
assigned to each other to complete mapping.

5.3.4 Central Test Data Editor

You can open the Central Test Data Editor via the button on
the toolbar.
In the Central Test Data Editor:

• You can create, modify and delete central test data sets.

• You can search for places where central test data sets have
been used.

5.4 Views
The ITE has the following views:

302 April 15, 2014 UserManual V8.0.00170

User interface

• Properties View

• Data Sets View

• Component Names View

• Test Result View

• Problem View

• Search result view

• Navigator View

• Console

• Inspector View

• Test Result Summary View

• Running AUT’s View

• Image View

• Progress View

The first three views are support views. Their content changes
depending on the current selection – they show details corre-
sponding to the currently selected item.
Use Window → Show View → Other to see a full list of
views that can be opened in the ITE.

5.4.1 The Properties View

The Properties View is in the upper right-hand corner of each
perspective. The Properties View shows details about the se-
lected item in a browser or editor.
If you select something from a browser, you can see its de-
tails in the Properties View, but you can’t edit them. You can
only edit details from within an editor. Read-only fields in the
Properties View have a lock icon at their left-hand side. read only
Test Suite details
If you select a Test Suite, you will see the following:

• The Test Suite name.

• Any comments for the Test Suite.

• The step delay for this Test Suite.

UserManual V8.0.00170 April 15, 2014 303

 Functional Testing User Manual

• The name of the AUT this Test Suite uses.

• The reentry properties for the default Event Handlers.

Test Case details

If you select a Test Case, the Properties View shows the fol-
lowing:

• The Test Case name.

• Any comments for the Test Case.

• The data source details for this Test Case

• Any parameters/parameter values if references have been

used in the Test Case.

Test Step details

If you select a Test Step, you will see the following:

• The Test Step name.

• Any comments for this Test Step.

• Details about the component in the Test Step:

– The component type.

– The component name (given by you).

• Details about the action in the Test Step.

• Details about the parameters in the Test Step. For each

parameter you will see:

– The parameter name.

– The parameter type (e.g. if it is an integer, a string etc).
– The parameter value (either a concrete value or a refer-
ence).

Test result details

If you select an item from the Test Result View, you will see
the following:

• The result details:

– The name of the item.

– What type of item it is.

304 April 15, 2014 UserManual V8.0.00170

User interface

– Any comments for the item.

• The test result – if it passed or failed.
• For Test Steps, you can also see the component, action and
parameter details. If the Test Step failed, you can also see
the error details.
• For Event Handlers, you can see the type of Event Handler
it was, and what the reentry property was.

Icons in the Properties View

When the Properties View contains data (i.e. a filled-in pa-
rameter value field), there are certain icons to help you under-
stand the data.

• Values which are the same as in the original specification

display a small gray diamond to the left of the field. original data
• Values which have been overwritten at a place of reuse
show a small yellow diamond. overwritten data

5.4.2 The Data Sets View

The Data Sets View is in the lower right-hand corner of the
Functional Test Specification Perspective by default. It lets you
add, modify, delete and see any data for Test Cases. For each
Test Case containing references or for each central test data
set, you can add data sets in this view. This is also the view
where you can translate your data and overwrite data when
you reuse a Test Case. When data in the Data Sets View are
uneditable, they are shown in gray. Values in black may be
edited.
To make entering data easier, pressing »ENTER« will spring
to the next cell or row, or to the ”Add” button if no more
rows have been added. The »TAB« key springs to the ”Add”
button.

5.4.3 The Component Names View

The Component Names View is in the lower right-hand corner
of the Functional Test Specification Perspective by default, just
behind the Data Sets View. It lets you see the component
names used in a reused Test Case, and add more component
names. This means that you can use a Test Case to execute
the same actions on different components.

UserManual V8.0.00170 April 15, 2014 305

 Functional Testing User Manual

5.4.4 The Test Result View

The Test Result View is in the middle of the Functional Test
Execution Perspective by default. It can also be displayed in
the bottom right-hand corner of the Functional Test Specifi-
cation Perspective via the preferences. It follows and displays
the results of the test execution. Each Test Step and Test Case
is marked with a green tick or a red cross depending on if it
passed or failed.
If you select an item in the Test Result View, you can see its
details in the Properties View. If the Project is open and the
item is still available, you can double-click on a Test Step or
Test Case in the Test Result View, to highlight it in the Test
Suite Browser. Double-clicking on this item in the Test Suite
Browser will open the editor for this item in the Functional
Test Specification Perspective.

5.4.5 The Problem View

The Problem View is by default at the bottom of the Func-
tional Test Specification Perspective, under the editor area.
The Properties View helps you to work with the ITE by giv-
ing you information, warnings and errors. Double-clicking on
a message will either carry out the necessary action or open a
dialog/editor to sort out the problem, if this is possible.

5.4.6 The search result view

The search result view (Figure 5.6 → page 307 ) is at the
bottom of the Functional Test Specification Perspective, under
the editor area, and just behind the Problem View by default.
If you perform searches, the results are shown here. For most
searches, if you double-click on an item in the search result
view, the corresponding item is highlighted in the Test Case
Browser or Test Suite Browser. You can see a history of previ-
ous searches, and re-run them directly from within the view.
You can also refresh the current search.

5.4.7 The Navigator View

The Navigator View is at the top right-hand corner of the
workspace perspective by default. The Navigator View gives
you a view of your workspace and the files in it.

306 April 15, 2014 UserManual V8.0.00170

User interface

Figure 5.6: Search Result View

5.4.8 The console

The console is shown in the bottom right-hand corner of the
Functional Test Specification Perspective. It lets you follow
certain processes, for example, the import of Projects.

5.4.9 The Inspector View

The Inspector View can be used to help you test RCP AUT’s
which use the GEF framework. When the inspector is ac-
tivated, figures can be clicked in the GEF canvas, and their
textpath (used to identify them in the test) is shown. The In-
spector View is shown by default in the bottom right-hand
corner of the Functional Test Specification Perspective.

5.4.10 The Test Result Summary View

The Test Result Summary View offers an overview of all tests
that have run in this database. It can be filtered and sorted.
The Test Result Summary View is displayed in the Functional
Test Reporting Perspective.

5.4.11 The Running AUT’s View

The Running AUT’s View is above the Test Suite Browser in the
Functional Test Specification Perspective. It shows an overview
of all running AUT’s and can be used to stop AUT’s and to start
Test Suites.

UserManual V8.0.00170 April 15, 2014 307

 Functional Testing User Manual

5.4.12 The Image View

The Image View is used to see automatically generated
screenshots of errors that have occurred in tests.

5.4.13 The Progress View

The progress view shows which longer-running actions are
currently being executed. These can include starting AUT’s,
connecting to the AUT Agent, and executing tests.

5.5 The status bar

The status bar in the lower right-hand corner of the perspec-
tive gives important information about the AUT Agent status,
working language, AUT and the observation mode and Object
Mapping Mode.

308 April 15, 2014 UserManual V8.0.00170

Concepts

Chapter 6

Concepts

The following sections introduce the concepts and capabilities

of the tool.

6.1 Overview
The ITE is based on the Eclipse development platform, a
platform-independent, open-source framework for develop-
ing applications.
With the ITE, you can specify, modify, execute and analyse
tests. The user interface offers various ways of working, so
that you can choose the way that suits you best. You can
alter the way the client looks, and the way it behaves. You
can work using the menu bar, the tool bar, context-sensitive
menus and shortcuts.

6.2 Testing
The information in this section help you to understand how
your application is tested, and how you can write tests for the
actions you want to test.

6.2.1 Understanding how the ITE and test ex-

ecution work
6.2.1.1 Actions

For test execution, we support ”high-level” actions. By this

we mean that some of the actions which can be chosen for a
component actually carry out a number of actions. This makes

UserManual V8.0.00170 April 15, 2014 309

 Functional Testing User Manual

the creation of Test Cases easier and quicker, and makes them
more understandable.
For example, there are two actions to enter text into a text
field. The action Replace Text selects the whole text in the
component and then enters the text input. This effectively
overwrites any text which was already in the component. The
Input Text action clicks once in the component and then en-
ters the text, which means that any text previously in the com-
ponent remains.
Another example is the selection and navigation through trees
and menus. Like a human tester, the test execution works
using the path to the item to select, and doesn’t first have to
select the individual sub-items in the path.
High-level actions can be used on all standard components
without problems. However, if the behaviour or look-and-feel
or a component has been changed (e.g. double-click in a text
field brings up a dialog instead of selecting the word) then
some high-level actions may not work. In this case you will
have to combine the low-level actions. Often, there are many
ways of achieving the same effect in your test, and it may
just be a case of trying out a few different ones to see which
works for you and your AUT.
When writing tests, it helps to be aware of things that a hu-
man tester does implicitly. Often, these are things that have
to be explicitly stated in an automated test, like waiting for
the application to be ready, or selecting an item before open-
ing the context menu, or even pressing enter to close a cell
editor in a table.

6.2.1.2 Test execution

Tests are generally execute by sending real clicks and key

presses, in the same way that a manual tester would. This
means that a test will give you the same results as a manual
test – if a menu is disabled, an item can’t be selected and so
on.
Once clicks and key presses have been sent, we wait for con-
firmation from the AUT that they have arrived (manual testers
use their eyes, we use confirmers).
If the AUT or the components in it need to be scrolled to ac-
cess the area being tested, scrolling happens automatically. In
the same way, if a tree is collapsed, you do not need to specify
an expand action before selecting a node. The expansion is
done as part of the selection.

310 April 15, 2014 UserManual V8.0.00170

Concepts

6.2.2 Standards conformance

If components have been derived and altered such that they
no longer respond to actions in the same way (i.e. rewriting
the single-click event for a textbox, non-standard responses
to certain key combinations, etc.), they may no longer be
testable out of the box.
It is therefore recommended for the purposes of testing – and
also for the sake of conformance to usability standards – that
the toolkit conventions are held to.
There may, of course, be situations where exceptions are nec-
essary. For this reason, there is an API via which testing classes
can be implemented so that even changed components can
be tested. See the Extension Manual for more information.

6.3 Architecture
This is a client-server application. We refer to the client part
as the Integrated Test Environment or ITE, and the server com-
ponent as the AUT Agent.:

The ITE is where tests are specified and evaluated.

The AUT Agent controls the application under test (AUT)

and executes the specified tests.

You can install the ITE and AUT Agent on different machines;
even on different platforms. This lets you specify and run your
tests on different machines, and means that you can run the
same test on different platforms.

6.3.1 ITE
The ITE is the interface between you and the AUT. It provides
you with browsers to see Test Cases and Test Suites, and edi-
tors to modify them.
In the client, you specify your tests without any program-
ming. You can write tests modularly, structure them to fit
your needs, and easily change them to follow developments
in the AUT.

UserManual V8.0.00170 April 15, 2014 311

 Functional Testing User Manual

6.3.2 AUT Agent

The AUT Agent is the link between your specified tests and
the AUT. Once the AUT Agent has started the AUT, object
mapping can take place, and tests can be observed and exe-
cuted.
You can install the AUT Agent on the same machine as the
client or on any other machine in the network, as long as the
AUT can also run on the machine. The AUT Agent can even
run on a different platform than the client.
This separation of the client and AUT Agent means that you
don’t have to sacrifice control of your machine during test ex-
ecution. It also means that you can test your AUT on different
systems using the same test, and from the same client.

6.3.3 Working with the ITE and AUT Agent

on different machines
You can install the ITE on any machine in the network, and
then install the AUT Agent on various other machines in the
network.
Within the ITE, you can define configurations for your AUT.
The configurations specify where the AUT jar or exe file is, the
JRE binary etc., and on which machine it should look.
You can specify different AUT Agent hosts and port numbers
to connect to.

6.4 Database structure

You can store your Projects in a single-user database or in a
multi-user database (recommended).

6.4.1 Supported systems

The ITE uses Eclipse Link as an object relational mapping layer.
The ITE is tested with Oracle. Other database solutions sup-
ported by Eclipse Link may also be used as a database, though
these have not been tested by our team.

312 April 15, 2014 UserManual V8.0.00170

Concepts

6.4.2 Single-user
If you work on a single-user database, only one tester can
work on a specific Project at a time. This also applies to the
test executor – the ITE and the test executor cannot access a
single-user database at the same time.
This method reduces the complexity of the system and its con-
figuration, and should really only be used for demo purposes.
Project sharing remains possible, however, through import/ex-
port.

6.4.3 Multi-user
When using a multi-user database, multiple testers can work
on a single Project concurrently.
Within such a scenario, all testers currently working on a
Project may view and execute all parts of it. As soon as one
tester alters a part of the Project, a lock is placed on that unit
to disallow other users from making changes of their own.
They are, however, still able to view and execute a locked test
unit. Once the user with the lock has saved all changes, the
lock is removed, and the test unit is once again available for
editing.
This database scenario is well-suited for larger testing oper-
ations, allowing for tight collaboration among testers and
reducing the overall time needed to specify complex testing
projects.

6.5 Approaches to testing

Modular testing is supported by the ITE. You can either create
modules in advance and combine them to make larger Test
Cases, or you can create modules from existing Test Cases
when you realize you need them.

6.5.1 Writing modules in advance

If you can identify which reusable modules a test will require
in advance, then you can specify them in a general or abstract
way, making them easy to adapt and reuse.

UserManual V8.0.00170 April 15, 2014 313

 Functional Testing User Manual

These small units are used to construct other modules or

building blocks, which are more adapted to the task at hand.
Concrete details can be added as needed.
One of the advantages of this approach is that tests are flex-
ible and easy to maintain, since a change made at a central
point can update many places where that Test Case has been
reused. Tests are also generally more efficient, because time is
not wasted specifying what is essentially the same Test Case
over and over again.
The difficulty with this approach testing is that it requires a
good knowledge of the structure of the test – you have to
know which Test Cases are going to be required multiple
times, and this is often not easy to recognize at the begin-
ning of testing.

6.5.2 Creating modules from existing Test

Cases
It is often initially more intuitive to start writing a test in a lin-
ear fashion, adding steps as necessary. Each step is specified
for the current purpose, and contains all the necessary details
(e.g. data).
The possible problem with this method is that similar or iden-
tical parts are often separately and multiply specified, which
means that making changes at a later point can be difficult
and time-consuming.
To avoid this, you can extract Test Cases from other Test Cases
to combine them into reusable modules ( → page 72) .

6.5.3 Choosing a method

Obviously, these two approaches lie on a continuum. You can
”mix-and-match” so that you can choose the approach that
works best for you – a combination of the two or one method
for one Test Case and the other for another Test Case.
For example, if you know that a certain test procedure (e.g.
logging in) has to be executed frequently, you can specify a
Test Case to do this, and specfiy it to be easily reusable (using
references as data-placeholders, and using general compo-
nent names to be reassigned). For parts of the test which are
not likely to be carried out more than once, you can specify
them with data and definite component names.

314 April 15, 2014 UserManual V8.0.00170

Concepts

6.6 Test hierarchy

The following sections describe the test hierarchy in the ITE.
Basically, you can think of the test hierarchy as a tree structure
which can be of any size, complexity and depth (Figure 6.1 →
page 315 ).

Figure 6.1: Test Hierarchy

The hierarchical structure gives you flexibility in your tests to

make changes and keep the test in touch with current soft-
ware development.

6.6.1 Test Steps

A Test Step is the smallest unit in the test hierarchy. Each
Test Step represents one action on one component (or user-
interface element) in the AUT.
The interaction is composed of three details, which we refer
to as ”CAP” (component, action, parameter):

UserManual V8.0.00170 April 15, 2014 315

 Functional Testing User Manual

Component: a component is a user-interface object (e.g. a

button, a combo box).

Action: the action is the operation to be executed on the

selected component. Each component has a number of
actions which can be executed on it, for example, buttons
can be clicked, an input can be made into a text field.

Parameter: the parameter(s) are the data or variables asso-

ciated with an action. When a button is clicked, the pa-
rameter is the amount of clicks. When you are entering
text into a text field, the parameter is the text you want to
enter. The amount and type of parameters depends on the
action.

The only detail which needs to be fixed at this point in the

specification is the action. The actual component to be tested
and the parameters can be added or changed later on.
The specification is also separate from the AUT. You give the
component you specify a component name, which you use to
identify the component in your test. This component name is
assigned to the actual component in the AUT at a later point.
In this way, specification can begin before the AUT is available.
An example if a Test Step could be entering text (e.g. hello)
into a text field:

Component Text field/text area/text

pane/...
Action Enter text
Parameter hello

We recommend using the Test Cases in the library

Projects installed with instead of writing Test Steps. Us-
ing the Test Cases from the library Projects saves time
and improves the flexibility of your tests.

6.6.2 Test Cases

Test Cases are a level up from Test Steps in the test hierarchy.
They are the building blocks or keywords from which other
Test Cases and Test Suites are made. They are the reusable
elements of your tests.

316 April 15, 2014 UserManual V8.0.00170

Concepts

A Test Case can contain any number of Test Steps and other
Test Cases nested to any depth. Test Cases are given user-
defined names.
Test Cases can be reused – in other Test Cases and in Test
Suites. There are no limits on how often a Test Case can be
reused, as long as no circular dependencies (infinite loops) are
created.

6.6.3 Test Suites

Test Suites are the containers for Test Cases to be executed
and can contain as many Test Cases as necessary. Each Test
Suite must be bound to one AUT which it will test. An AUT
can be bound to more than one Test Suite.
An important concept for testing is the ability to test a pro-
gram modularly. Program parts can be tested as and when
they are delivered using the specific Test Suites for each part.
Only the chosen Test Suite in a project will be executed, which
means that testing can begin whether all program compo-
nents are available/functional or not.

6.6.4 Test Jobs

Test Jobs are the containers for Test Suites which are to be
executed in a sequence. A Test Job can contain Test Suites
which test different AUT’s or different instances of the same
AUT (with some restrictions, see the previous section ( →
page 128) for details). Each Test Suite in a Test Job is bound
to an AUT and specifies which AUT it will test based on the
AUT ID.

6.6.5 Projects
Tests are organized into Projects. A Project is the top-level con-
tainer. Projects contain runnable tests and the details about
the AUT’s to be tested (how to start them, in which language
etc.).
You can work jointly on Projects using the multi-user
database, and you can also share Projects using the import
and export functions.

UserManual V8.0.00170 April 15, 2014 317

 Functional Testing User Manual

6.7 Reusability
Test Cases are the reusable units. Test Cases can be referenced
in other Test Cases to create modularly built tests.
Being able to reuse Test Cases means that you should put
some thought into how to design them so that they are as
specific as they need to be while also being generic enough
to reuse in different situations.
You can improve the flexibility of a Test Case by:

• Using references ( → page 92) instead of concrete data if

the data can change. References allow you to feed a Test
Case with different data each time you reuse it.

• Using the abstract components (e.g. component with text,

component with text input, graphics component) ( →
page 318) to specify your tests wherever possible.

• Allowing the component it tests to be defined when you

reuse it ( → page 117) .

6.7.0.1 Abstract, concrete and toolkit specific compo-

nents

There are three levels of components:

Abstract components are general, high-level components

from which other components are derived. They are de-
scribed in terms of what features a component has, e.g.
graphics component, component with text. They group
actions together which can all be executed on components
of this type.

Concrete components are components which are available

to all graphical toolkits, but which are restricted to a certain
component type, e.g. combo box, list.

Toolkit specific components are the most specific compo-

nents. They are only available for certain toolkits. For ex-
ample, a HTML link is a component which is only available
in Web applications.

We recommend that you specify your tests as abstractly as

possible, and as concretely as necessary. If you want to create
a Test Case to click a button, it is better to use the abstract
component graphics component. The graphics component

318 April 15, 2014 UserManual V8.0.00170

Concepts

also contains the click action, and has the advantage that the
Test Case can then be used on other components than but-
tons. If you want to select a cell from a table, however, you
will have to use the concrete component table, because this
is the highest level which offers this action.
The more abstract your specification, the more flexible your
Test Cases are.

6.8 Multi-lingual testing

6.8.1 Project and AUT languages

You can test different language versions of your AUT with the
same test. All you have to do is translate the data for the test.
To make multilingual testing possible, you have specify which
languages you are using:

Project language(s): These languages are specified during

Project creation and are valid for all AUT’s in this Project.
You will be able to have AUT’s which support one or more
of these languages.

Default language: One of the Project languages is the de-

fault language. This is the language which will automati-
cally be set as the working language when you open the
Project.

AUT language(s): When you are defining an AUT, you

choose one or more AUT languages from the selection of
Project languages. These languages are the languages the
AUT supports. You can start the AUT in these languages
and write test data for these languages.

The working language: In the toolbar in the ITE, you can

change the working language to any of the Project lan-
guages. The working language determines which Test
Suites you can edit (only those whose AUT supports this
language) and the language the AUT is started in.

6.9 Object mapping

Object mapping is the process which joins your component
names from your Test Steps to the actual technical names for

UserManual V8.0.00170 April 15, 2014 319

 Functional Testing User Manual

the components in the AUT. Because object mapping can be

the last step before execution, you can start specifying tests
before the software is even available.
Object mapping consists of two steps:

1. Collecting the technical names for the components from

the AUT.

2. Assigning these technical names to the component names

you used in your Test Steps.

Object mapping is bound to the AUT, not to a Test Suite.

All Test Suites which use the same AUT share an object
map.

6.9.1 Component names

When you specify Test Steps, you specify component names
for the components you want to test. When you add Test
Cases to a Test Suite, all component names used in the Test
Cases are collected by the Object Mapping Editor. You can
then collect the technical names from the AUT.

6.9.2 Technical names

You do not need to consult the developers to collect technical
names; you use the running AUT to collect the names. If the
developers have named the components, this name will be
collected. If the developers have not named the component,
a name is generated.

In the mapping mode, high-level components are usu-

ally addressed. You will not be able to map individual
menu entries or tree nodes on desktop applications, for
example. Instead, you map the tree component, and
specify which entry/node to select/check as a parame-
ter for the action.

320 April 15, 2014 UserManual V8.0.00170

Concepts

6.9.3 Assigning technical names to compo-

nent names
Once you have collected the technical names from the AUT,
you can ”assign” them to the component names using drag-
and-drop. In this way, you are telling your test which real
component you are referring to in each Test Step.
The fact that the object map is separate from the specification
means that any changes that need to be made to update a
test only need to be made once.

6.9.4 Locating components during test exe-

cution
The component recognition system uses various details about
mapped components to find the right component during the
test. The location of the component in the AUT hierarchy, the
components near to it and the name of the component all
play a role in component recognition. For each possible com-
ponent, the similarity to the originally mapped component is
calculated. The component with the highest result is selected.
This method makes object mapping generally resilient to
changes in the AUT.

6.10 Test execution

The prerequisites for test execution are covered in the previous
chapter ( → page 154) .

6.10.1 Test Step execution

Tests are executed tests on the following basis:

• A user-defined component is located in the user interface

of the AUT.

• The specified action is executed on this component, with

the parameters you gave for the action.

The success of an action is based on whether it was carried

out or not. There are no implicit checks which verify the state
of the application to check if the execution of an action actu-
ally had an effect. For example, if an action is carried out to

UserManual V8.0.00170 April 15, 2014 321

 Functional Testing User Manual

click a button, this Test Step will be marked as successful even

if the button is disabled. From the remote control perspective,
a click was executed on the button component.
It is worth bearing this in mind if a test has failed, especially
because of a ”component not found” error. What may have
happened is that a further component was not found due to
a dialog still being in focus, because the ”close” button was
disabled, for example. Although a click was executed on this
button, it did not have the desired effect. The test continued,
but ran into problems.

6.11 Observing user actions

As explained in the introduction ( → page 8) and in the
section on how to record ( → page 177) , we believe that
recording tests has various disadvantages in any tool.
However, you can observe Test Cases in a running Java AUT.
You can record actions and checks in your AUT, and the out-
put for these actions is Test Steps.
You can create the same tests with observing as you can with
specification. The real differences are:

• object mapping is carried out automatically in observing

mode. Because of this, you do not provide a component
name, but one is created automatically.
• you must use concrete values for parameters in the ob-
servation mode. You can (and should), however, change
these to references in the specification perspective later so
that your tests are more reusable.

You can reuse observed Test Cases in the same ways as you
can reuse specified Test Cases.

The observation mode supports high level actions. To

find out exactly how an action works, look up the com-.
ponent and its action in (→Reference Manual p. 21)

6.12 Event Handlers

Event Handlers are a way of reacting to errors during test ex-
ecution and to continue the test in a way you define.

322 April 15, 2014 UserManual V8.0.00170

Concepts

An Event Handler is a Test Case used with a special function. It Event Handler
is only executed when a certain type of error occurs. There are
four different types of error, and each Test Case can have an
Event Handler for each error type. You can specify different
reactions to each different error type, so that serious errors
can stop the test, but unimportant errors will not affect the
execution.
Because Event Handlers are normal Test Cases, they can also
contain Event Handlers, can do any of the things that a normal
Test Case can do. The only restriction is that you cannot add
a Test Case to itself as an Event Handler.

6.12.1 How Event Handlers work

When an error occurs in a Test Step, its parent Test Case is
searched for an Event Handler for this type of error. If no
Event Handler is found, the parent Test Case of this Test Case
is searched and so on. Once a corresponding Event Handler is
found, it is activated.
If no Event Handler is found in the highest Test Case in this
part of the tree, a default Event Handler (set in the Test Suite
properties) is activated.
Each Event Handler requires an ”Event Type” and a ”Reentry
Type”. For information on these terms, see the section in the
Tasks chapter ( → page 164) .

6.12.2 Default Event Handlers

Default Event Handlers are a part of the Test Suite and can
be considered as being present at the Test Suite level. They
are activated when no Event Handler has been found for the
event type in the part of the tree where the error occurred.
The default reentry type for each event type can be specified
in the Properties View for the Test Suite Editor.
The reentry types for the default Event Handlers are the same
throughout the tree. Everywhere a certain type of error oc-
curs, the same action will be taken, unless the part of the tree
where the error occurred has its own Event Handler for that
event type.

UserManual V8.0.00170 April 15, 2014 323

 Functional Testing User Manual

6.12.3 Customized Event Handlers

Customized Event Handlers are essentially Test Cases, and can
be empty or contain other Test Steps/Test Cases. They can be
used to specify particular behavior in case of an error in one
part of the test tree, or they can be placed so as to affect how
the test continues. If an Event Handler contains Test Step-
s/Test Cases, the specified reentry will happen when the Event
Handler has been executed.
Customized Event Handlers are valid for all Test Cases under
the Test Case where the Event Handler is nested, unless one
of these child Test Cases has an Event Handler of its own for
this error type.

6.13 Extensibility
You can write extensions for various parts of the tool. This
requires somebody to implement the extension.
For information on how to do this, see the Extension Manual.

6.14 Summary
After reading this chapter, the structure and concepts of the
tool should be clear. You can specify reusable Test Cases to
make Test Suites in a Project. To enhance the reusability and
structure of test elements and the ease of use, there are var-
ious features supported by the program. To look at these
features in more detail and find out how to use them, see the
”Tasks” chapter ( → page 21) .

324 April 15, 2014 UserManual V8.0.00170

Glossary

Chapter 7

Glossary

Action A method which is carried out on a Component. An

Action is part of a Test Step, and serves to either execute a
command (e.g. click, enter text), or verify property or state
information about a Component (e.g. check Component
name, check visibility).

AUT The Application Under Test. The AUT is the entire pro-
gram that you wish to test.

AUT Configuration The information required in order to lo-

cate and start an AUT in the configuration desired by the
user. An AUT Configuration includes program information
such as JRE location and class path, and AUT configuration
information such as command-line parameters and envi-
ronment variables. Details about the AUT are given when
a project is created, and are entered into the relevant fields
in the Test Suite Editor.

CAP The three parts of a Test Step : Component, Action,

Parameter.

Classname for AUT The fully qualified classname which

contains the main method of the AUT.

Classpath for AUT An environment variable that informs

Java where to look for the class files which are needed
to run the AUT.

Component A user interface object. Each component has a

set of actions that can be carried out upon it.

Component Name The symbolic name you choose for a

component in the AUT and use in a Test Step or Test Case.

UserManual V8.0.00170 April 15, 2014 325

 Functional Testing User Manual

Component Names View In this view, component names

in reused Test Cases can be reassigned to create multiple
component names for one Test Step. This allows many
components of the same type or within the same group or
family to be mapped to the same Test Step. The default
position of the Component Names View is in the lower
right-hand corner of the perspective.

Component Type The type of graphical user interface object

which will be acted upon in a Test Step, e.g. ”Menu Bar”
or ”Combo Box”.

Data Sets View The view in which multiple parameter val-

ues for a Test Case can be defined and edited. The default
position of the Data Sets View is the right-hand side of the
perspective, in the middle.

Empty string To enter an empty string as a parameter (i.e.

nothing at all), use backslash \.
To actually write a backslash, you must enter two back-
slashes.

Escape character The character used to cancel any special

function that the following symbol may have. The default
escape character is \.

Event Handling The process by which errors are dealt with

during the execution of a test. If no user-defined Event
Handler has been specified, a default Event Handler is ac-
tivated.

Graphical User Interface A means of interacting with a

computer by the use of a graphically oriented (as opposed
to text-oriented) display. Modern graphical user interfaces
(GUI’s) are controlled by a mouse as well as a keyboard, and
consist of windows, buttons, text areas, and other manip-
ulable objects which are designed to make computer op-
eration simpler and more intuitive.

ITE Short for Integrated Test Environment. By this we mean

the application where tests are written.

JAR The Java™Archive file format. It allows multiple classes

and other program files and data to be combined into one
compressed file, which often represents a complete pro-
gram. In this context, a JAR describes the Java™Archive of
the AUT.

326 April 15, 2014 UserManual V8.0.00170

Glossary

Object mapping The process by which component names

you created in your test are attached to the technical
names used in the AUT.

Parameters The information that is given to an action to per-

form a Test Step, such as name, value, etc. A parameter
consists of:

• a name
• a type
• a value

Most actions require one or more parameters.

Parameter Name A name which describes a parameter

which is sent to an action.

Parameter Type The type of value which is sent as a param-

eter to an action. The following parameter types are sup-
ported:

• String
• Integer
• Boolean

Parameter Value The contents of the parameter which is

sent to an action. A parameter value can either be a static
value (e.g. Hello, 123), a reference (e.g. =REFERENCE)
or a variable.

Port Number A software address used to identify and com-

municate between individual programs or services on a
single computer or between multiple computers on a net-
work. A hostname and port number must be given in order
to connect to an AUT Agent.

Project A Project contains all the information for the test, in-
cluding Test Suites and Test Cases, AUT’s and data. Projects
are stored in the database.

Project Properties Information pertaining to the active

project, including the name (all projects in the database
must have unique names), the Project language(s), and the
data language for the Project.

Propagation When references are entered, the parameter

they replace is carried up into the next Test Case in the
hierarchy. This is propagation.

UserManual V8.0.00170 April 15, 2014 327

 Functional Testing User Manual

Properties View The view for displaying and editing the

properties of selected Test Steps or Test Cases, located by
default in the top right-hand corner of the perspective. Test
Steps and Test Cases can be edited in the Properties View
by clicking on their icon in their respective editor. The Prop-
erties View is also used to display detailed results of a Test
Suite once it has been executed.

Reference Symbol The character used to denote a reference

within a parameter. The default reference symbol is =.

Specification The method by which test details and instruc-

tions are entered by the user in the ITE. Tests are not
programmed, but rather specified in plain language, then
object-mapped to the program’s technical names.

Step Delay The time to wait between Test Steps, given in

milliseconds. A step delay causes a slower test execution.

Technical Name A name given to a graphical user interface

object of an AUT by a software developer. Technical names
are used to uniquely identify an object within an applica-
tion and are mapped to a component name as defined by
the user in a Test Step.

Test Case A reusable test object which contains Test Steps

or other Test Cases.

Test Case Browser A view which shows the hierarchy of

Test Cases as entered and defined by the user. The Test
Case Browser is by default in the bottom left-hand corner
of the perspective.

Test Case Editor An editor area used to create and alter Test
Cases and Test Steps. The Test Case Editor is located by
default in the center of the perspective.

Test Data Values which are entered into parameters for an

action in Test Steps. Test data may be entered directly into
a parameter or referenced.

Test Job A Test Job is a collection of Test Suites which are

designed to be executed after each other. The Test Suites
can test the samme AUT, different instances of the same
AUT, or different AUT’s entirely.

Test Result View The view which displays the results of an

executed Test Suite.

328 April 15, 2014 UserManual V8.0.00170

Glossary

Test Step The smallest test object. A Test Step belongs to a

Test Case. A Test Step consists of

• a Component
• an Action
• a Parameter

Test Suite A Test Suite uses an AUT configuration and con-

tains all Test Cases and their respective Test Steps, in the
order in which they are to be tested.

Test Suite Browser The view containing the Test Suite tree,
where the Test Cases in a Test Suite can be seen. The Test
Suite Browser is situated by default in the top left-hand
corner of the perspective.

Test Suite Editor An editor pane used to view the proper-

ties of the Test Suite and the Test Cases used in it, and
to edit their parameter values and names. The Test Suite
Editor is located by default in the center of the perspective.

Workspace Personal preferences relating to the client layout

and actions are saved in a Workspace. All changes made
in the ”Preferences” dialog are stored here.

UserManual V8.0.00170 April 15, 2014 329

 Functional Testing User Manual

330 April 15, 2014 UserManual V8.0.00170

Index

Chapter 8

Index

Abstract components, 123

Action, 132, 315
Specify, 132
Action Error, 126, 164, 165
Activation, 26, 50, 52, 57, 58, 60
Add
AUT Agent, 168
AUT Configuration, 50, 52, 57, 58, 60
Comments, 71
Component Name, 116
Event Handler, 164
Task ID, 72
Test Cases, 68
Test Suite, 68
Application activation, 26, 50, 52, 57, 58, 60
Assigned names, 139
AUT
Configuration, 50, 52, 57, 58, 60
Errors, 239
iOS, 276
Languages, 319
RCP, 261
Start, 154
Stop, 245
AUT Agent, 21, 312
Add, 168
Connect, 23
Disconnect, 245
Embedded, 21, 23
Preferences, 169
Errors, 238
iOS, 60

UserManual V8.0.00170 April 15, 2014 331

 Functional Testing User Manual

Parameters, 22
Preferences, 168
Quiet Mode, 22
Starting, 21
Stop, 245
AUT Configuration
Add, 50, 52, 57, 58, 60
Edit, 50, 52, 57, 58, 60
iOS, 60
AUT ID, 52, 57, 58, 60, 126, 236
autrun command
Define AUT, 55

Best Practices
RCP, 264
Break, 126, 165
Browser, 291
Component Name, 292
Test Case, 292, 299
Test Suite, 292, 299

CAP, 132, 315

Categories
Comments, 78
Object Mapping, 139
Test Cases, 77
Test Jobs, 77
Test Suites, 77
Central test data
Editor, 302
Central Test Data Set
Search, 210
Change
Database, 28
Changes in the AUT, 150
Check failed, 126, 165
Chronon
Support for AUTs, 232
Classname, 52
Classpath, 52
Cleanup
Object Mapping Editor, 144
Client, 311
CmdLineParameter, 52, 57
Comment
Add, 71

332 April 15, 2014 UserManual V8.0.00170

Index

Comments
Categories, 78
Component, 117, 132, 315
Names, 319
Delete, 122
Global, 117
Hierarchy, 123
Local, 117
Merge, 121
New, 116
Reassigning, 117
Rename, 119
View, 117, 292, 302
Type, 132
Component Name
Delete, 65
Renaming, 65
Component name
Show where used, 209
Component Name Browser, 292
Component not found, 126, 164, 165
Concatenation, 101
Concrete Value, 91
Configuration
AUT, 50, 52, 57, 58, 60
Test Suite, 126
Configuration error, 126, 164, 165
Connect
AUT Agent, 23
Console
View, 302
Continue, 126, 165
Continue without Event Handler, 157
Create
Project, 29
Data Sets View, 112, 292, 302
Database, 312
Change, 28
Log-in, 27
Preferences, 169
Select, 28
dbtool, 223, 224
Default
Language, 29
Default Event Handler, 126

UserManual V8.0.00170 April 15, 2014 333

 Functional Testing User Manual

Default Language, 319

Define AUT
autrun command, 55
Delete
Component Name, 65
Component Names, 122
Test Case, 65
Test Job, 65
Test Steps, 69
Test Suite, 65
Delete Project, 39
Design For Testability
Web, 270
Design for Testability
iOS, 279
JavaFX, 267
RCP, 263
Swing, 260
Disconnect AUT Agent, 245
Edit
AUT Configuration, 50, 52, 57, 58, 60
Project Properties, 32
Test Case, 69, 86
Test Job, 69
Test Steps, 134
Test Suite, 69
Editor, 291
Central test data, 302
Object Mapping, 302
Preferences, 170
Test Case, 301
Test Suite, 125, 130, 301
View, 292, 302
Embedded AUT Agent, 23
Preferences, 169
Empty String, 114
Environment, 52, 57
Environment variables, 95
Error Messages, 183
Error Types, 126, 164, 165
Errors
AUT, 239
AUT Agent, 238
Test Suite not executable, 241
Escape Character, 114

334 April 15, 2014 UserManual V8.0.00170

Index

Event Handler, 159, 322

Add, 164
Default, 126
Error Types, 126, 164, 165
Reentry Properties, 126, 165
Excel data, 109
Excel File Configuration, 110
Excel TODAY function, 111
Execution
Perspective, 206, 294
Test
Pause, 156
Prepare, 154
Start, 155
Stop, 156
Exit, 126, 165
Export
All, 41
Project, 41
Extensibility, 324
Extracting
Test Case, 72
Find, 214
Finding Places of Reuse, 208, 210
Functions, 97
Syntax, 97
GEF, 265
Inspector, 265
Global Component Names, 117
Heuristic, 140
Hierarchy of Component Names, 123
Highlight in AUT, 143
ID attribute name, 58, 270
Image
View, 302
Import
Project, 41
Information Messages, 183
Inspector
GEF, 265
Inspector View, 302
Integrated Test Environment, 311
iOS, 276

UserManual V8.0.00170 April 15, 2014 335

 Functional Testing User Manual

Accessibility ID, 279

AUT Agent, 60
AUT Configuration, 60
Design For Testability, 279
Naming components, 279
Remote Control, 276
Start AUT, 60
Text retrieval support, 279
iOS AUT’s, 276
ITE, 311
Starting, 25

JavaFX
Design For Testability, 267
Set ID, 267
JRE parameters, 95

Keyboard Layout, 263

Language
Default, 29
Languages
AUT, 319
Project, 29, 319
Working, 319
Launch Configurations, 234
Library of Test Cases, 82
Local Component Names, 117
Locked
Test Case, 243, 313
Log-in
Database, 27

Maintainability, 319
Merge Component Names, 121
Messages
Error, 183
Information, 183
Warning, 183

Names
Component, 319
Reassigning, 117
Technical, 319
Navigator View, 297, 302
New
Component Name, 116

336 April 15, 2014 UserManual V8.0.00170

Index

Project, 29
Test Case, 80
Test Job, 130
Test Step, 132
Test Suite, 125

Object Mapping, 137, 319

Assigned names, 139
Categories, 139
Collect components, 146
Editor, 302
Cleanup, 144
Refresh, 143
Highlight in AUT, 143
in categories, 140
Map components, 150
Preferences, 140, 170
Property Information, 153
Unassigned component names, 139
Unassigned technical names, 139
objectmapping, 240
Observation, 322
Observation Mode, 177
Preferences, 171
Start, 178
Tips, 177
Observing
Test Steps, 179
Open Project, 37
Overwrite data, 114

Parameter, 91, 132, 315

Concatenation, 101
Concrete Value, 91
Data Set, 112
Empty String, 114
Escape Character, 114
Excel file, 109
Function, 97
JRE, 95
Overwrite, 114
Reference, 92
Variable, 94
Parameters
Delete, 93
Edit, 93

UserManual V8.0.00170 April 15, 2014 337

 Functional Testing User Manual

Pause, 126, 165

Test Job, 156
Test Suite, 156
Pause on Error, 157
Pause Test Execution, 156
Perspective, 291
Execution, 206, 294
Reporting, 295
Specification, 206, 292
Workspace, 297
Predefined Variables, 96
Preferences
AUT Agent, 168
Database connection, 169
Editor, 170
Embedded AUT Agent, 169
Object Mapping, 140, 170
Observation Mode, 171
Reset, 206
Test, 167
Test Result, 171
Problem View, 183, 292, 302
Progress
View, 302
Project, 317
Create, 29
Delete, 39
Export, 41
Import, 41
Languages, 29, 319
New, 29
Open, 37
Properties, 32
Refresh, 39
Save As, 40
Version, 43
Properties View, 292, 302
Property Information
Object Mapping, 153
RCP, 261
Best Practices, 264
Design For Testability, 263
Generate Technical Names, 264
Remote Control, 261
Set Data, 263

338 April 15, 2014 UserManual V8.0.00170

Index

RCP AUT’s, 261

rdesktop, 243
Reassigning
Component Names, 117
Reentry Properties, 126, 165
References, 92
Refresh
Object Mapping, 143
Refresh Project, 39
Rename
Component Name, 119
Referenced Test Case, 70
Referenced Test Suite, 70
Renaming
Component Names, 65
Test Cases, 65
Test Jobs, 65
Test Suites, 65
Replace
Test Case, 73
Reporting
Perspective, 295
Results
View, 159
XML and HTML Reports, 160, 171
Retry, 165
Return, 126, 165
Revert changes, 77
Running AUT’s View, 302
Save As
New Test Case, 76
Save Project As, 40
Search, 214
Central Test Data Set, 210
Component in AUT, 143
Components in Test Cases, 143
Search Result View, 302
Select
Database, 28
Server, 311
Set Data, 263
Set ID, 267
Set Name, 260
Show specification
Test Cases, 208

UserManual V8.0.00170 April 15, 2014 339

 Functional Testing User Manual

Test Suites, 208

Show where used
Component name, 209
Test Cases, 208
Test Suites, 208
Specification
Perspective, 206, 292
Speed of test execution, 158
Start
AUT, 154
AUT Agent, 21
iOS, 60
ITE, 25
Observation Mode, 178
Test Execution, 155
Test Job, 155
Test Suite, 155
Status Bar, 308
Stop
AUT, 245
AUT Agent, 245
Test Execution, 156
Test Job, 156
Test Suite, 156
Storing Variables, 94
Support Package, 243
Swing
Design For Testability, 260
Set Name, 260
System variables, 95
Task ID
Add, 72
Technical Names, 319
Test
Execution
Prepare, 154
Pause, 156
Preferences, 167
Result View, 302
Results, 159
Start, 155
Stop, 156
Test Case, 316
Add, 68
Browser, 292

340 April 15, 2014 UserManual V8.0.00170

Index

Categories, 77
Delete, 65
Edit, 69, 86
Editor, 301
Extracting, 72
Library, 82
Locked, 243, 313
New, 80
Renaming, 65
Replace, 73
Save As, 76
Show specification, 208
Show where used, 208
Test Case Browser
Opening multiple times, 67
Test data, 91
Editor, 302
Test execution
Speed, 158
Test Executor, 216, 222
Test Job, 128–130, 317
Categories, 77
Delete, 65
Edit, 69
Pause, 156
Renaming, 65
Start, 155
Stop, 156
Test Result
Preferences, 171
View, 294
Test Result Summary
View, 295
Test Result Summary View, 302
Test Step, 315
Delete, 69
Edit, 134
New, 132
Observe, 179
Test Suite, 125, 317
Add, 68
Browser, 292
Categories, 77
Configuration, 126
Delete, 65

UserManual V8.0.00170 April 15, 2014 341

 Functional Testing User Manual

Edit, 69
Editor, 125, 130, 301
Failed, 242
New, 125
not executable, 241
Pause, 156
Renaming, 65
Show specification, 208
Show where used, 208
Start, 155
Stop, 156
Translating data, 112
Troubleshooting, 238
Typesetting Conventions, 12

Unassigned names
Component, 139
Technical, 139
User Interface
Adapting, 206

Variables, 94
Environment, 95
Pre-defined, 96
Storing, 94
System, 95
Verify failed, 164
Versioning Projects, 43
View, 291, 302
Component Names, 117, 292, 302
Console, 302
Data Sets, 292, 302
Editor, 292, 302
Image, 302
Inspector, 302
Navigator, 302
Problem, 183, 292, 302
Progress, 302
Properties, 292, 302
Results, 159
Running AUT’s, 302
Search Result, 302
Show, 206
Test Result, 302
Test Result Summary, 302
Views

342 April 15, 2014 UserManual V8.0.00170

Index

Navigator, 297
Test Result, 294
Test Result Summary, 295

Warning Messages, 183

Web
Design For Testability, 270
Working Directory, 51, 52, 57
Working language, 319
Workspace
Perspective, 297

XML and HTML Result Reports, 160, 171

UserManual V8.0.00170 April 15, 2014 343