TestStep Values, Using XTestStep Values

Upon manual test execution, TestStepValues can either be created manually (see chapter "Working with manual TestCases") or by dragging and dropping Modules (see chapter "Creating TestSteps from Modules").

TestStepValues

TestStepValues are the actual steering parameters which can fulfill various tasks:

  • Value inputs into the test object (Input)

  • Verification of values or control properties (Verify)

  • Reading out values of the test object (Output)

  • Buffering of values (Buffer)

The following TestStepValues correspond to the linked ModuleAttributes and thus the controls to be steered in the test object.

Icon

Description

Manual TestStepValue

Table

Input, simple control item

Select, ComboBox

Button

RadioButton

A (Label), HTML link

Customized control item

Tree icon

This chapter contains a description of the characteristics and options of TestStepValues. For a more detailed documentation on how to use and steer them, please refer to chapter "Steering Test Objects"

XTestStepValues

XTestStepValues are used along with Tosca TBox. The basic options and properties are similar to the classic TestStepValues. Please see also the Tosca TBox Manual for further information on XTestStepValues.

An XTestStepValue may contain additional XTestStepValues, depending on the structure of the corresponding ModuleAttribute.

When a TestStep is created by dragging & dropping an XModule to a TestCase, XTestStepValues are either created initially as wildcards or as generated XTestStepValues. XTestStepValue names can be edited if specified in the XModuleAttribute. The specification is automatically made when an XModule is created.

The property Cardinality defines how many XTestStepValues can be created for a ModuleAttribute (see chapter "Default properties for Modules"). If an ActionMode is assigned to an initially created XTestStepValue, it will turn into a generated XTestStepValue.

Icon

Description

Initially created XTestStepValue

Generated XTestStepValue

If the hierarchy of XModuleAttributes is modified, the corresponding XTestStepValues are marked with a warning symbol. The synchronization is described in chapter "Synchronize (XTestStep)".

Parameter values

Specific criteria are decisive when parameters (see chapter "Properties for XModules") should be used in a TestStepValue. At first the ModuleAttribute to be used for specifying the parameters is determined:

  • If the XModuleAttribute, which has been assigned to the XTestStepValue, is a reference, it is verified whether the XTestStepValue implements a specialization.

  • If the XTestStepValue implements a specialization, the XModuleAttribute of the specialization is used as a basis for determining the parameters.

  • If the XTestStepValue does not implement any specializations, the referenced XModuleAttribute is used.

Parameters are determined on the basis of the specified XModuleAttribute:

  • The parameters of the XModuleAttribute are transferred.

  • If the XModuleAttribute is a specialization or a reference to another XModule, its parameter is also transferred. This applies to several generalization levels.

  • If a parameter value is overwritten within a specialization or a reference, the value of the recently used specialization or reference is used.

Parameters of an XTestStepValue can be shown by selecting Search all->Relevant XParams from the context menu.

An XModuleAttribute is assigned to an XTestStepValue. This XModuleAttribute points to the XModule Person with the following parameters:

First name = John

Last name = Doe

The XTestStepValue implements the specialization Legal person (i.e. the specialization of Person) with the following parameters:

Last name = Smith

Commercial register no. = 001234A

On the basis of this information, the XTestStepValue now contains the following parameters along with the following values:

First name = John

Last name = Smith

Commercial register no. = 0011234A

The parameters of the XModule Legal person are transferred. Since the XModule Legal person is a specialization of the XModule Person, the parameters of the XModule Person, which have not been specified in the XModule Legal person, are additionally transferred.

Properties

The following section describes the properties of (X)TestStepValues. Their use within the TestStep is described in chapter "ActionMode DoNothing".

Name

The name of the TestStep. Corresponds to the name of the control from the module definition.

Value

The action is performed using this value depending on the selected ActionMode.

ActionMode

ActionModes are used for steering the test object and they define how the value in the Value field has to be used in order to steer the control.

In order to improve visibility, you can display the ActionModes with various background colors which can be enabled via the Options dialog (see chapter "Options - TestCase (Options)").

Possible ActionModes for common TestStepValues:

The table below lists all possible ActionModes for common TestStepValues. Examples on how they are used can be obtained from chapter "Steering Test Objects".

ActionMode

Color

Description

DoNothing

white

With the ActionMode DoNothing no action is performed. The content of the field Value has no influence. The test object specified by the Module is steered, but not the control.

Input

white

Input is used for steering individual controls. This includes the input of a value, the operation of a control panel or a ComboBox, etc. The specific input mode is determined by the field Value.

Verify

green

Allows the value of a control provided by the application to be verified as specified in the field Value. Control properties can also be verified.

Buffer

yellow

If input values are repeatedly needed they can be saved with the ActionMode Buffer.

Output

blue

The value provided by the application to the control of the TestStep is read and stored in the XML ResultSet.
These values are available in Tosca Commander

  • if the TestCase was executed in an ExecutionList.

  • in the column Used Value in the details view of the ExecutionList.

WaitOn

orange

The ActionMode WaitOn interrupts the execution of the TestCase until the respective control has the value or property that has been specified in the Value field.

Possible ActionModes for XTestStepValues:

If no explicit ActionMode has been selected, the ActionMode of the parent node is used for determining the ActionMode and it is marked implicit (I) with a grey background color. The parent element is set to Select by default.

ActionModes for Tosca XEngines

ActionMode

Description

<implicit>

The ActionMode <implicit> is only available if the InterfaceType is NonGUI. The ActionMode is automatically determined on the basis of the selected ActionMode <implicit>. All child elements are assigned the ActionMode Select. Leave elements receive the ActionMode Input.

The implicitly determined ActionMode is displayed and greyed out.

Insert

An object is created.
The value is {NULL} by default.

Select

The specified node is selected. The name of the node must be unique. The value is {NULL} by default.

Constraint

This ActionMode limits the search for a superordinate node. Examples of its usage include business-based table steering or the selection of a certain XML node.

Verify

Serves to verify the value provided by the application for the control of the TestStep as specified in the Value field. The target node must be specified uniquely for this ActionMode to be performed.

Buffer

If input values are repeatedly needed they can be buffered by using the ActionMode Buffer.

Input

The value that has been specified in the Value column is entered.

WaitOn

The ActionMode WaitOn interrupts the execution of the TestCase until the respective control has the value or property that has been specified in the Value field.

DataType

The DataType determines the type of entry made in the Value field. The following types are available:

DataTypes

DataType

Description

String

Any characters that are not commented will be processed according to the ActionMode (default setting).

Numeric

The value in the Value field is regarded as a number. Therefore, the various notations do not affect the test.
Example: 10.500,90 equals 10500.90

Password

Values in the Value field are displayed with wildcards * in Tosca Commander. For classic TestStep Values the actual values remain unchanged and are stored unencrypted. With XTestStep Values the values are saved encrypted.

Date

The value in the Value field is interpreted as date. Therefore, the various notations do not affect the test.

Boolean

The value in the Value field is interpreted as a boolean value, which can be either true or false.

Options

Reset Value

This option deletes the value entered in the Value field and sets the ActionMode to DoNothing.

Set ActionMode

The ActionMode can be changed to the following values:

  • DoNothing

  • Input

  • Verify

  • WaitOn

  • Buffer

  • Output

Translate Value

If a dynamic expression is used (see chapter "Dynamic expressions"), it can be translated indirectly prior to verification. In the subsequent dialog the translated value is either shown or the user is informed on the fact that the expression can not be translated.

Verifying dynamic values

If a dynamic expression is used for specifying values, this can be translated indirectly via the context menu option Translate Value (see chapter "Dynamic expressions"). You can also left-click on the TestStepValue and select Translate Value from the dynamic menu TestCases. The subsequent dialog box shows either the translated value or a note on the fact that the expression cannot be translated:

Translating value

Implement specialization (XTestStepValue)

This option is available if several Specialization Modules are generated for one TestStepValue. The type of specialization can be selected from the subsequent dialog (see chapter "Select specialization (XTestStepValue)").

Create XTestStepValue (XTestStepValue)

This option generates all initially created XTestStepValues of a tree, starting from the selected XTestStepValue. All required XTestStepValues are generated until the XTestStepValue from which the option has been started.

The wildcards remain available for further generation processes, depending on the value assigned to the property Cardinality (see chapter "Default properties for Modules").

Create XTestStepValue tree (XTestStepValue)

This option is similar to "Create XTestStepValue (XTestStepValue)". Additionally all subsequent XTestStepValues (child elements) are generated.

The wildcards remain available for further generation processes, depending on the value assigned to the property Cardinality (see chapter "Default properties for Modules").

TestStepSubValue

TestStepSubValues are hierarchically located beneath the TestStepValue. They are used if one Input field is not sufficient for the execution of the test.

An example is "Steering tables". The TestStepValue represents the table. Additional information such as row, column etc. is defined in the TestStepSubValues.

Options

Reset Value

This operation deletes the value entered in the Value field and sets the ActionMode to DoNothing.