Define performance requirements in schedules

Define performance requirements in schedules

+
Search Tips | Advanced Search

Overview
Performance requirements for a schedule...

Specify acceptable thresholds of performance
Validate service level agreements

Define a performance requirement in a schedule

In the Test Navigator, browse to the schedule and double-click it.
In the Schedule Element Details area, click...
Performance Requirements tab | Enable Performance Requirements

The page contains a table of performance requirements that apply to the schedule. Within the table, the requirements are organized into common requirements, which pertain to all protocols, protocol-specific requirements, and requirements that pertain to resource data being collected.
Expand the requirements tree, click the requirement to define, and define the requirement as follows:

Option Description
Name You can change the name of a performance requirement to improve readability.
Changing a requirement name causes a mismatch between the Performance Requirements report, which uses the changed name, and the other reports, which use the default name. Therefore, when you change a requirement name, be sure to keep track of the original name.
Operator Select an operator.
Value Type a value.
Standard Click to make the requirement standard.
If a standard requirement is not met, the schedule run will have a verdict of fail. Clear to make the requirement supplemental. In general, supplemental requirements are used for requirements that are tracked internally. A supplemental requirement cannot cause a run to fail, and supplemental results are restricted to two pages of the Performance Requirements report.

To hide the shaded rows, select...
Hide Undefined Requirements

Shading indicates that a requirement is not defined,
Select a requirement and click Clear to remove its definition. The requirement is still available and can be redefined.

Example

You can define performance requirements in a test, if protocol supports it, or in a schedule.

When you define a requirement in a test, the requirement is defined individually for each test element—even if you select multiple test elements.
When you define a requirement in a schedule, the requirement is applied to the aggregate of test elements.

For example, assume that you select each page in a test and define this requirement:
Average response time for page [ms] [For Run] must be less than 5 seconds

This means that if one page in the test has a response time of 6 seconds, the requirement on that page fails. The other pages, which have a response time of less than 5 seconds, pass.
Assume that you open a schedule and define this requirement:
Average response time for all pages [ms] [For Run] must be less than 5 seconds

This measures the average response time for all of the pages. One page can have a response time of 30 seconds, but if enough pages have sufficiently low response times to counter the negative effect of that one page, the requirement passes.
For information on defining requirements in HTTP tests, see Define performance requirements in tests.

Related

Schedule overview
User group overview
Create a schedule
Set the user load
Add a test to a schedule
Repeat tests in a schedule
Delay virtual users or actions
Run tests at a set rate
Run tests in random order
Add a transaction to a schedule
Synchronize users
Emulate network traffic from multiple hosts

Option	Description
Name	You can change the name of a performance requirement to improve readability. Changing a requirement name causes a mismatch between the Performance Requirements report, which uses the changed name, and the other reports, which use the default name. Therefore, when you change a requirement name, be sure to keep track of the original name.
Operator	Select an operator.
Value	Type a value.
Standard	Click to make the requirement standard. If a standard requirement is not met, the schedule run will have a verdict of fail. Clear to make the requirement supplemental. In general, supplemental requirements are used for requirements that are tracked internally. A supplemental requirement cannot cause a run to fail, and supplemental results are restricted to two pages of the Performance Requirements report.