TestStepValues can either be created manually (see chapter "Working with manual TestCases") or by dragging and dropping Modules (see chapter "Create 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.
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.
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.
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 (see chapter "ActionModes").
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 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.
|
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. |
|
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. |
|
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. |
The DataType determines the type of entry made in the Value field. The following types are available:
|
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. |
|
Password |
Values in the Value field are displayed with wildcards * in Test Automation for SAP Commander.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 "Specify values"), 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.
If a dynamic expression is used for specifying values, this can be translated indirectly via the context menu option Translate Value (see chapter "Specify values"). 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").