| | | | | | | |
| Version 3.4.7 |
| Recording options |
The following options determine which kinds of events are recorded and which filters are applied, how components are recorded and arranged, and how sub-items are handled.
|
|  |
||
|
| Figure 29.9: Recording options | ||
This option is very useful if the client name assigned to your
SUT contains variables (e.g. $(client)), which
generally makes sense when creating procedures. If this option
is set, the client attribute of all recorded nodes is set to the
unexpanded 'Client' value of the
'Start SUT client' node through which the SUT was started.
Depending on what you are currently working on, it may or may not make sense to add newly recorded sequences directly at the current insertion mark. If you deactivate this option, new recordings are placed in a new 'Sequence' under 'Extras'.
To simplify recording a sequence of events with interspersed checks, you can switch between plain recording and recording checks by pressing a key in the SUT. The key that triggers this switch is set through this option. The default key is [F12].
When QF-Test is recording checks, it can give visual feedback on the component the mouse is currently over by inverting its foreground and background colors. Rarely this may have unwanted visual side effects, so you can turn that feature off with this option.
When recording images for 'Check image' nodes, non-opaque components used to be recorded with a black background. Thus, the image could deviate from what the user was seeing. This error has been corrected and normally the background is now recorded correctly. If this option is activated, the old, broken mechanism is used instead which may be useful if many checks for non-opaque components have already been recorded using that method.
| Events to record |
These options specify which kinds of events are recorded and which aren't. You should not tinker with these unless you know what you are doing.
|
|  |
||
|
| Figure 29.10: Options for events to record | ||
Activating this option causes a sequence of MOUSE_MOVED,
MOUSE_PRESSED, MOUSE_RELEASED and MOUSE_CLICKED events to be
recorded as a single 'Mouse click' pseudo event (see subsection 30.8.1).
This option lets you record a sequence of KEY_PRESSED,
KEY_TYPED and KEY_RELEASED events (or just KEY_PRESSED and
KEY_RELEASED for function keys) as a single 'Keystroke' pseudo
event (see subsection 30.8.2).
For many types of components and sub-items it doesn't matter where exactly a MouseEvent occurs. However, if large values are recorded for the X or Y coordinate of a 'Mouse event', there's the danger that the event might miss its target upon replay if the component has shrunk a little due to font changes or because the window has been resized. This is also a possible source for problems when converting a recorded sequence to a 'Procedure' with variable target components.
If this option is activated, QF-Test ignores the coordinates of recorded MouseEvents if it thinks that the coordinates don't matter for the target component, e.g. for all kinds of buttons, for menu items, table cells, list items and tree nodes. For the latter QF-Test distinguishes between clicks on the node itself and on the expand/collapse toggle. When MouseEvents without coordinates are played back, QF-Test targets the center of the respective component or item except that the X coordinate for items is limited to 5 because item bounds cannot always be calculated correctly.
When replaying a sequence during which a new window is opened,
it may be useful to allow for a longer than usual delay until
the window is opened. By activating this option, a recorded
WINDOW_OPENED event will be turned into a 'Wait for component to appear'
node automatically.
Web For web clients this option causes a 'Wait for document to load' node to be inserted whenever loading of a document completes. This is important for proper synchronization when navigating to another page.
| Events to pack |
In order to keep the amount of raw event data generated during normal use of a Java GUI manageable, QF-Test employs a set of recording filters and packers. These do their best to keep everything needed for successful replay and throw away the rest. To get an impression of the actual data behind a recorded sequence, try recording a short sequence with all of these turned off, and with 'Mouse click' and 'Keystroke' pseudo events disabled.
|
|  |
||
|
| Figure 29.11: Options for events to pack | ||
MOUSE_MOVED events (System)
MOUSE_MOVED events are especially frequent. Every mouse cursor
motion generates a handful of these. Under most circumstances,
only the last of a consecutive series of MOUSE_MOVED events is
actually useful, so all events except the last one are
dropped, if this option is activated. An example where this is
not advisable is recording some freehand drawing in a graphics
application.
Note One might think that MOUSE_MOVED events
are completely useless, since MOUSE_PRESSED or MOUSE_RELEASED
events have their own set of coordinates, but this is not the
case. Some Java components require a MOUSE_MOVED event before
a MOUSE_PRESSED event is recognized.
MOUSE_DRAGGED events (System)
MOUSE_DRAGGED events are like MOUSE_MOVED events, but with one
mouse button held down. Similarly, only the last of a series
of MOUSE_DRAGGED events is recorded unless you turn off this
option, except for special cases (see next option).
There are situations where not only the final target of a mouse drag is of interest, but intermediate points as well. The most common is invoking a menu item in a sub-menu.
Note As of QF-Test 1.05.2, the following no longer applies because
MOUSE_MOVED or MOUSE_DRAGGED events that are required
for opening sub-menus are not "optimized away" anymore. However, there may be
other situations where intermediate stops are useful when recording drags.
|
|  |
||
|
| Figure 29.12: Dragging to a sub-menu | ||
As illustrated above, creating a new 'Test' node for a suite could be done by clicking on the »Insert« menu button, dragging the mouse to the »Test and Sequence nodes« item for the sub-menu, so the sub-menu pops up, then dragging on to the »Test« menu item and releasing the mouse button. Normally such a sequence would be reduced to a press, a drag to the final »Test« item and a release. It would fail to replay, since the sub-menu would never be popped up. To work correctly, an additional drag to the »Test and Sequence nodes« item must be recorded.
For that reason QF-Test recognizes a MOUSE_DRAGGED event as
important if you hover over an intermediate component for a
while during the drag. The delay (in milliseconds) needed to
recognize such an event is set through this option.
To record the above example correctly with this option set to 1000, you'd have to click on the »Insert« menu button, drag to the »Sequences« item and keep the mouse pointer stationary for one second, then move on to the »Test« sub-menu item and release the mouse button.
It sometimes happens unintentionally that the mouse cursor is
moved between pressing the mouse button and releasing it. This
movement may be registered as a MOUSE_DRAGGED event, depending
on the JDK version and the distance of the move. QF-Test is
able to compensate for small movements and still convert the click
into an abstract 'Mouse click' event. This option defines the maximum
distance between pressing and releasing the mouse button that
QF-Test will ignore. Every MOUSE_DRAGGED event above that
distance will be left unchanged.
Another example where a lot of events are generated is
entering a short string of text into a text field. Each
character typed leads to at least one KEY_PRESSED, one
KEY_TYPED and one KEY_RELEASED event. For additional fun,
the KEY_RELEASED events may arrive out of order or not at
all, depending on operating system and JDK version.
If this option is activated, sequences of KeyEvents on a text
component (to be exact: a component whose class is derived
from java.awt.TextField or
javax.swing.text.JTextField) are converted into a
'Text input' node. Only true character input is packed,
function or control keys or key combinations with
[Control] or [Alt]
are left unchanged.
When the packed sequence is replayed, only KEY_TYPED events
are generated. KEY_PRESSED and KEY_RELEASED events cannot be
generated, since the required key code is system dependent and
cannot be determined from the character alone. This is not a
problem however, since text components usually handle only
KEY_TYPED events and some special keys.
This option determines the value of the 'Clear target component first' attribute of a recorded 'Text input' node. If the option is not set, the attribute will not be set either. Otherwise, the 'Clear target component first' attribute is set if and only if the text field or text area was empty before the input started.
This option determines the value of the 'Replay single events' attribute of a recorded 'Text input' node. If the option is set, the attribute will be set and vice versa. The conservative way is to keep the option set, but for a typical application that does not add its own KeyListeners to text fields it should be safe to turn it off so as to speed up replay of 'Text input' nodes.
| Components |
|
|  |
||
|
| Figure 29.13: Options for recording components | ||
This option defines the key for a very useful functionality: recording components directly from the SUT. Pressing this key in the SUT will switch it to "component recording" mode, regardless of whether event recording is currently activated or not. In this mode, clicking on a component with the mouse will cause the component to be recorded and added to the test-suite if it was unknown before. If more than one test-suite is currently opened, the menu item »Record«-»Receive components« determines the suite that will receive the components. The 'Id' of the 'Component' is put on the clipboard so it can be pasted into any text field with [Control-V]. This latter feature is very handy when creating an event or a check from scratch.
|
|  |
||
|
| Figure 29.14: Popup menu for recording components | ||
You can also record a whole component hierarchy at once by clicking with the right mouse button instead. This will bring up a popup menu with the following four options:
setName(). All
components in the whole window are recorded and put into a
test-suite of their own. Each unnamed component for which a
name will improve testability is marked with a name of the
form "SUGGESTED NAME (n): suggestion". The running count in
braces is just used to avoid duplicates. The suggested name
is built from the component's class and other available
information. It should be taken with a grain of salt.
Normally "component recording" mode is turned off by either pressing the hotkey again or by selecting a component. If you want to record multiple single components, hold down an additional modifier key when switching to "component recording" mode (e.g. [Shift-F11]). That way selecting a component will not turn off the mode, only pressing the hotkey again will.
If this option is set, QF-Test does not record any custom classes for 'Components'. Instead it moves up the class hierarchy until it encounters a system class and records that. Set this option if the class names of your custom GUI classes tend to differ between releases.
Note You must activate this option if you intend to obfuscate the jar files of your application or if you are using a custom class loader to load your application's GUI classes.
Swing support HTML markup in various kinds of labels, buttons and sub-elements of complex components. For component identification and validation, the HTML markup is often not useful and will clutter up things. If this option is set, QF-Test converts HTML to normal text by removing all HTML markup so only the actual text content is left.
Note There are two versions of this option which are closely related. This one is effective during recording, the other one during replay. Obviously, both options should always have the same value. There's one exception though: When migrating from one setting to another, QF-Test's components have to be updated. During that process, keep the replay option at the old setting and change this option to the new one. Be sure to update the replay setting after updating the components.
This option determines the weight given to the names of components for recording. Possible choices are:
Override everything
This is the most effective and adaptable way of searching components, but it
requires that the names of the components are unique, at least within the same
window. If that uniqueness is given, use this choice.
WebDon't use this value for a web page with frames. Use "Hierarchical
resolution" instead.
Hierarchical resolution
This choice should be used if component names are not unique on a per-window
basis, but naming is still used consistently so that two components with identical
names have at least parent components or ancestors with distinct names.
That way, component recognition is still tolerant to a lot of change, but if
a named component is moved to a different named parent in the SUT, the test-suite
will have to be updated to reflect the change.
Plain attribute
If there are components with identical names in the SUT within the same parent
component you must use this setting. The name will still play an important role in
component recognition, but not much more than the 'Feature'
attribute.
Eclipse and applications based on the Rich Client Platform (RCP) have a complex
GUI with support for changing perspectives. Such a change causes components to be
rearranged which can make it hard for QF-Test to recognize them unless names are set
at least on the major components. This is further complicated by the fact that the
structure of the components is not what it appears to be - the main components are
all arranged in a relatively flat hierarchy within the workbench. On the upside,
RCP based applications have a uniform inner structure based on Views
and Editors, many of which are named.
If this option is turned on, QF-Test will do its best to automatically associate GUI
elements with their RCP counterparts and assign names based on that association.
This can drastically improve component recognition for such applications. However,
if some names thus assigned turn out not to be reliable over time, they can also
interfere. In such a case, names can be assigned to the affected components either
using setData as described in chapter 6 or
with the help of a NameResolver as described in section 39.1. Both will override automatically generated names.
QF-Test supports three different kinds of views for the components of the SUT. For more information about their effect on component recognition, see section 36.2.
The flat view collects all components of a window as direct
child nodes of the respective 'Window' node. The
advantage of this view is that structural changes of the
component hierarchy have little effect on component
recognition. This is also its greatest disadvantage: since
structural information is not available, this view gives
reasonable recognition quality only if setName()
is used ubiquitously. Another drawback is the lack of
clearness.
The complement to the flat view is the full hierarchy. It
includes every single component of the SUT's GUI, emulating
all parent/child relationships. This view can be a useful tool
for developers or testers that want to gain insights into the
SUT's structure, but is not very applicable for testing,
since structural changes affect it too much. As long as you
don't change the GUI however, it will give you excellent
recognition without the help of setName().
A compromise between flat and full hierarchy is available through the choice "Intelligent". For this view only the "interesting" components of the SUT are recorded. "Interesting" in this case means that either the user can interact with the component, or it is located at some important point in the hierarchy, like the children of a split pane or a tabbed pane. In some later version of QF-Test this decision may be made configurable as well.
If selected, QF-Test prepends the 'Id' of the 'Window' parent of a 'Component' to its 'Id' during recording. This is useful to disambiguate ids of components with identical names in different windows.
When a 'Component' is recorded for the first time, QF-Test assigns an automatically generated 'Id'. The id of a direct or indirect parent node may be prepended to this id. This is useful to distinguish between similar components that don't have a name of their own.
Example: Imagine two JScrollPanes, one named
"TreeScrollPane" and the other named
"DetailScrollPane". Without this functionality, their vertical
scrollbars would get the ids "scrollbarVertical" and
"scrollbarVertical2". With this function turned on, the ids
would be "TreeScrollPane.scrollbarVertical" and
"DetailScrollPane".scrollbarVertical". That way it is
immediately obvious which component is the target of an event.
There are four possible settings:
setName. A component that
doesn't have a name of its own, gets the id of its
nearest named ancestor node prepended.
setName is used sparingly or not at all, it
is better to set this option to "Nearest ancestor with name
or feature". That way either the name or a distinctive
feature of an ancestor node will be applicable.
If set, this option limits the length of automatically generated ids. This can improve clearness since ids can get very long, e.g. when generated from a component's feature.
| Recording sub-items |
Events on complex components like tables or trees can be recorded relative to a sub-item of the component. For further information about sub-items see the 'Item' node or section 7.3.
|
|  |
||
|
| Figure 29.15: Options for recording sub-items | ||
This option activates recording sub-items. When turned off, events on complex components are no different from events on simple components.
When recording an event for a sub-item, the 'Item's' index can be defined 'As string' or 'As number'.
The third choice, "Intelligent", causes QF-Test to record the index in the format most appropriate for the item. If the name of the item is unique within the complex component, a string index is recorded, a numeric index otherwise.
As explained in section 7.3, there are two ways to address a sub-item: either through a special syntax or by creating an 'Item' node. This option determines the method to use in recorded events.
Choosing "Intelligent" will cause an 'Item' node to be created if the index of the sub-item is a string and if the sub-item itself is not editable. Otherwise the special syntax is used.
It is not uncommon that trees have identically named nodes
under different parent nodes, e.g. a file system with the
directories /tmp and /usr/tmp. By
using a path format in the 'Items' for tree nodes
QF-Test can make full use of the hierarchical structure to
distinguish between these nodes. The slash character
'/' is used as separator.
If this option is deactivated, trees will be treated as flat lists.
| Recording procedures |
The following options determine the configuration of the Procedure Builder which is described in detail in Automated Creation of Basic Procedures.
|
|  |
||
|
| Figure 29.16: Procedure Builder options | ||
This option defines a key for turning on automatic procedure recording directly in the SUT.
Here you can specify your own template file for the Procedure Builder. If a relative path is given, QF-Test looks for the definition file in the directory that QF-Test was started from and in the default include directory.
| | | | | | | Last update: 04/23/2012 Copyright © 1999-2012 Quality First Software GmbH |