Defining requirements in schedules

You can define performance requirements for a schedule to specify acceptable thresholds of performance and to validate service level agreements. Starting from version 9.2.0.1, you can define both performance and functional requirements in the schedules. The verdict of the schedule is computed based on the requirements defined in the schedule. You can view the verdict in the Requirements report.

Procedure

  1. In the Test Navigator, browse to the schedule and double-click it. The schedule opens.
  2. In the Schedule Element Details area, select the Requirements category, and select Enable Requirements. The page contains a table of performance requirements that apply to the schedule. From 9.2.0.1, you can view both performance and functional requirements. 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. From 9.2.0.1, you can also view functional requirements and testing infrastructure (agents) requirements.
  3. 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 requirement to improve readability. However, changing a requirement name causes a mismatch between the 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 Requirements report.
  4. Optionally, select Hide Undefined Requirements to hide the shaded rows. Shading indicates that a requirement is not defined.
  5. 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 your 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 every 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 Defining requirements in tests.

Feedback