About Criterion State Machines

A criterion has two separate state machines. One that controls when the Condition is checked (Test Session>Pass/Fail>View/Edit Criterion window) and another that deals with it’s status. The criterion status (or states) are NA, PENDING, PASSED, FAILED, and OCCURRED.

When a Test Case or Session is started, each criterion begins with a PENDING state ( Pass/Fail History sub tab). The condition is checked while the criterion is Started and not Stopped, that is, when the start-criterion condition is true and the stop-criterion condition is false.

NOTE: Some Test Cases can skip states. For example, the Network Host Test Case, does not do anything in the start function and goes directly from INITIALIZED to STARTED.

Criterion can be reset, so they can be used multiple times, as in multiple iteration tests, or within one test iteration if an automation loop is occurring. To keep track of the multiple uses, each Criterion has a Failure Count, which increments each time a Criterion fails. In addition, the Pass/Fail History sub tab in the Reports tab, monitors the criteria like measurements.

This topic includes the following state machines diagrams:

Learn more about:

Result Type State Diagram

A Criterion state/status is managed in two separate ways:

On the main Pass/Fail tab, you will see the top level status, once a Criterion FAILS, it stays FAILED on this tab, and a Failure Count is shown.
In the Reports, the Pass/Fail History tab shows historical values for the Criterion Status. On this tab, you can see some of transitions for a Criterion, down to a granularity of a standard interval.

Below are Criterion state diagrams for each Result type.

^ Back to Top

Test Case States

Test Cases have simple state machine (see the State Machine illustrated below). The Criterion Operators will work for the Test Case states based on the Test Case state machine.

Test Cases have simple state machine (see the State Machine illustrated below). The Criterion Operators will work for the Test Case states based on the Test Case state machine. The state RUNNING is < STOPPING and CLEANUP is > STOPPED. When working with automation control tests and loops, keep in mind that when a test case loops and the state goes to INITIALIZING or STARTING, the Test Case State will be at a lower value. To handle the loop around properly, you can set the Start, Stop, Expire and/or Reset appropriately. You should RESET on the INITIALIZED.

For example, if you setup a criterion as Test Case State is > INITIALIZED, then any of the Test Case States, STARTING, STOPPED, RUNNING, STOPPING, STOPPED CLEANUP, will evaluate true.

NOTE: See Test Automation Control Steps to learn more about setting up and avoiding loop around issues.

^ Back to Top

Test Session States

Test Sessions state represents the overall state or step for the test. There are two basic state machines for a test session, one for parallel execution and one for automation controlled tests. The Operators will work for test states based on these state machines.

For example, if you setup Criterion for Test State > RUNNING, then any of STOPPING, CLEANUP, WAIT_FOR_TRANSFERS, FINAL, or COMPLETE will return true.

NOTE: When working with multi-iteration tests, note that when the test loops and the state goes to INITIALIZING or STARTING, the Test Session State will be < RUNNING. To avoid the loop around issues, make sure you set the Start, Stop, Expire and/or Reset appropriately. See Test Automation Control Steps to learn more about setting up and avoiding loop around issues.

^ Back to Top