You can specify how error conditions are handled when running a test or schedule. Error
conditions include verification point failures, connection failures, server timeouts, custom code
alerts, and problems with data correlation.
You can specify error-handling behavior for the workbench, schedules, tests, and test
elements/steps. The Errors report displays the error conditions and error behavior that
occurred in a test or schedule. When you set the error-handling behavior for the workbench, it
is applied to all the tests in the workbench. To apply it for the workbench, click .For example, to stop running a test when a Mobile or Web UI
action fails, select the UI Action Failed check box. Click
Exit Test, and then click OK. The
error-handling behavior that is specified closest to where an error occurs takes precedence.
If a specific action is set to continue when a step fails, and the test is set to stop if a
step fails, then the test will continue running if the step fails.
-
Double-click the test to open it from the Test Navigator view.
The test opens.
- In the Test editor, complete one of the following steps:
-
To specify error-handling behavior for a request/step or other elements in the test hierarchy,
in the Test Contents section, select the element and in the Test Details section,
click the Advanced tab.
-
To specify error-handling behavior for an element such as a connection, substitution, or reference, select the element, and then click
Change. Skip to step 5.
-
To specify error-handling behavior for a dataset that is associated with a test, on the
Common Options page, select the dataset and click Dataset
Properties, and then click Change. Skip to step 5.
-
Under Error Handling, expand Click to show conditions.
The error condition table is displayed. The error condition table shows all possible
conditions that can be handled in the test.
| Error condition |
Description |
| Test Verdict Failed |
The error condition Test verdict failed is met if the test
verdict is set to fail. |
| UI Action Failed |
This option is to stop running a test when a Mobile or Web UI
action fails. |
| UI Fatal Error |
This option is to allow test execution for a compound test to
continue even after a fatal exception in one of the tests in a
compound test. |
- Select the check box next to the condition for which to
specify behavior.
A window opens where you can specify
the action to take and the message to log when the condition occurs.
-
To apply an action when the specified condition occurs, select the Override
action upon error check box .
| Option | Description |
|---|
| Continue |
Click to continue running the test. |
| Exit transaction |
Click to exit a transaction when the specified condition occurs. Select the
Innermost or Outermost transaction, or type
the name of a transaction. |
| Exit loop |
Click to exit a loop when the specified condition occurs. Select the
Innermost or Outermost loop, or type the name
of a loop. |
| Continue to next iteration of loop |
Click to continue to the next iteration of a loop when the specified condition occurs.
Select the Innermost or Outermost loop, or type
the name of a loop. |
| Exit test |
Click to exit the test when the specified condition occurs. |
| Exit user |
Click to stop the virtual user that encounters the specified condition. For a Web UI
test, this action will stop the test execution. |
| Terminate run |
Click to stop the run when the specified condition occurs. |
-
To contribute to the health of the page, transaction, or loop, select the Override
contribution to health status check box and select Yes. The
respective reports display the health of the page, transaction, or loop.
- Optional:
To write a message to the test log when the specified condition occurs, select the
Override log message upon error check box and type a message.
- Click OK.