Parameter Files
The parameter files are stored in the following folder:
...\MyITest4U\AUTReleases\<AUTRelease>\ParameterFiles
The parameter files contain all test parameters and check points. Each line in the parameter file represents one loop.
An empty line will stop test execution.
$$$$ should not be used as parameter as it has a special meaning. There is no escape possibility provided.
Comments can be added below the parameter lines. Make sure there is at least one empty line between the last parameter line and the comment.
The parameter file has the following basic structure:
Step 1;Step 2;.…;Step N
Each parameter has a section for values, index, Find, NotToFind and AP (additional parameters).
Step 1;Index;Find;NotToFind;AP;Step 2;Index;Find;NotToFind;AP;....
The Step i column contains the parameter values.
Index is the index of the GUI element. The default is 0 (counting starts at 0).
Find is a string which needs to be found on the current window. NotToFind should not be found on the current window. Both Find and NotToFind can contain more than one string. They need to be separated by "|". Escaping of "|" can be done as shown in the following example:
aaa|fff\|bb\\||b
results in
aaa
fff|bb\|
b
Additional Parameters (AP)
Addition parameters can be set in the AP field by the use of a string containing the letters i, x, c, t, s, y, z and a positive integer. The integer stands for StepsToGoBack. Its default value is 0. StepsToGoBack is mandatory. The letters are optional. The order of the integer and the letters does not matter e.g. st1 or s1t have the same meaning. Each additional parameter is described below.
StepsToGoBack
StepsToGoBack has to be a positive integer between 0 and the total number of test steps.
StepsToGoBack can be used for a retrial of a test part like the filling of a form. The test needs at least two loops. The test will run in the first loop till StepsToGoBack is > 0. Than will go back the given number of steps and continue with the second loop.
In the last loop StepsToGoBack has to be 0 for all steps.
StepsToGoBack can not be set for an ignored step.
An example where StepsToGoBack is useful, is the checking of a parameter validation as shown in the following example:
The AUT has an address form. Step 1 - 10 are needed to get to the address form. Step 11 - 15 will fill in the address data. Step 16 will submit the address form only if all fields are filled in correctly. Step 17 - 24 will do something with the address data.
In loop 1 the test runs till step 16. In the step 11 - 15 invalid address data was added.
Loop 2 will start at step 11 fill in the correct address data and run till step 24.
Further Additional Parameters
The further additional parameters can be inserted after StepsToGoBack. They are:
| i | i indicates that this test step should fail and the error will be ignored. A working test step which is marked with an i will result in an error with the text ShouldNotWork. The use of the i allows doing negative tests which will not show up in the test result as error. Further it allows to mark test steps which should work but do not because of a bug in the AUT. Once the bug is fixed the test result will indicate the change and the i can be removed. |
| x |
Steps marked with a x are ignored. The x is useful in combination with test block templates e.g.
For all parameter validation the same test template can be used. Parameters which are absent can be marked with x and so the same template can be used for all parameter validation. Doing a parameter validation in this way leads to less tests. StepsToGoBack for steps which are ignored (marked with x) has no effect. |
| c | c stands for CloseOpenedWindows. If a step is marked with a c all windows opened by this step are closed. Further all open modal windows of the AUT are closed as well. |
| t | A screen shot is taken after a step which is marked with a t. |
| s | All GUI elements of the current window are collected if a step is marked with s. |
| y | GlobalFind can be ignored with a y. |
| z | GlobalNotToFind can be ignored with a z. |
y and z can only be set in the parameter file. They never show up in the editor.
The use of Global Find and Global NotToFind is described under Universal Check Points.
Variable Identifier Parts
Sometimes it happens that the properties identifying a GUI element change because of the application design.
For example the window title can be dependent on the person who is logged in.
These cases can be handled in the following way:
In front of the value the changing property and its value can be set using the following format:
NewWindowTitle<newWindowTilte>$$$$value
This can be done for the following properties:
- NewWindowTitle
- NewClassName
- NewAutomationId
- NewFrameworkId
- NewName
- NewHelpText
Context Menus
Context Menu and normal Menus can not be distinguished by UI Automation. They need to be searched in a different way.
Therefore Context Menus have to be marked with CM| in the parameter file. The parameter for a Context Menu has always to start with CM|.
Context Menu clicks need to start at the Root Context Menu and all Sub Menus on the way to the desired Sub Menu need to be clicked.
The Context Menu has to be visible to be clicked.
Context Menu can be inserted into the database by making a test block showing the Context Menu and setting CollectAfterStep for the step showing the Context Menu.
Window Handling
In case the AUT window gets closed and reopened (e.g. after login the login window closes and the application window opens) the action FindAppWindow can be used to find the new application window. This action takes the name of the new application window as parameter.
Checks which are done after an action can not be done if the proceeding action is FindAppWindow.
Best Practice
The Parameter File is written after saving a test / test block. The "old" content is moved to the comment section of the Parameter File. Therefore it is best to finish a test / test block and then edit the Parameter File.
Configuration
Under Config some general configuration can be done.
GUI elements which should not be clicked in a Spider run can be set under the menu Global and Locale Excludes. The identifier of these GUI elements should contain the given string e.g. should GUI elements be excluded with the text "Logout" "Logout" has to be given as the exclude. Only "Log" will not work.
Test Migration
The test generation configuration are migrated in the following way:
Exclude from test generation is migrated every time the migration editor is opened. The value set in the new release will be overwritten if a GUI element was excluded in the old release.
The default value will be set if it is not null in the new release. Already set default values will not be overwritten.