Skip to content

Validation Rules

A response with status 200 means the server didn't crash. It doesn't mean the response is right. Applications fail in subtler ways than HTTP status codes can express:

  • They return 200 with an error page in the body ("Sorry, something went wrong. Please try again.")
  • They return 200 with a logged-out page after the session quietly expired
  • They return 200 with a partial response: headers and footers present, but the critical data missing
  • They return 200 with a CAPTCHA challenge instead of the requested content

If your replay or load test treats every 200 as success, all of these slip through. You finish a load test that thinks it succeeded and the numbers tell you nothing, because half the virtual users were actually looking at error pages the whole time. Validation rules are how you tell Load Tester what a correct response actually looks like, so it can flag the ones that aren't.

This is configuration, not replay-time behavior. You define validation rules once, on the test case, and every replay and every load test then checks them automatically.

From the Blog

"The conclusions derived from your load testing efforts can only be as good as the data. If the data is bad, the conclusions likely will be as well. So always validate your pages to ensure valid test results." Chris Merrill, Chief Engineer

The Three Validation Types

Load Tester supports three kinds of validation rule:

  • Content Contains. The response body must contain a specific string. Use this to assert that a page rendered the content that proves the workflow is on track: the user's name on the dashboard, "Order confirmed" on the checkout page, an expected product SKU in a search result.
  • Content Does Not Contain. The response body must not contain a specific string. Use this to assert that the response isn't a failure page in disguise: "Session expired," "Please log in," "Sorry, something went wrong," "Verify you are human."
  • Response Code. The response must return a specific HTTP status. Useful when the page legitimately returns something other than 200 (a redirect chain that should end in a 302, an API endpoint that returns 201 on creation), or when you want to fail on the specific code that the application uses to signal a problem.

You can layer multiple rules on a single transaction. A login response might have a Content Contains rule for the username, a Content Does Not Contain rule for "Invalid credentials," and a Response Code rule for 200. Any rule that fails fails the transaction.

Adding a Validation Rule

  1. Select a transaction in the Test Case Editor (the page-tree view of your recorded test case)
  2. Right-click the transaction → Add Validation Rule
  3. Choose the validation type (Content Contains, Content Does Not Contain, or Response Code)
  4. Enter the value to check:
    • For content rules: the exact string the response must (or must not) contain. Case-sensitive.
    • For response-code rules: the numeric status code (200, 302, 201, etc.)
  5. Click OK

The rule is now part of the test case. It will fire on every subsequent replay and every virtual user during a load test.

Useful Patterns

Assert That the User Is Logged In

The single most useful validation rule on most test cases. After the login transaction, add a Content Contains rule that checks for something only a logged-in user would see: their username, an account-specific link ("My Orders"), a session-specific greeting ("Welcome, Alice"). If login silently fails (wrong credentials, expired account, MFA challenge), the rest of the test case will run unauthenticated and silently fail too, with every page returning 200-OK login screens. The validation rule catches that on transaction one, before the failure cascades.

Assert That an Error Page Isn't Present

For workflows where a known failure page exists ("Something went wrong," "We're experiencing high traffic, please try later," "Session expired"), add a Content Does Not Contain rule for the failure text on each major page. This catches the case where the page returns 200 but the body is an apology.

Assert API Response Shape

For REST/JSON API transactions, the response body should contain specific JSON keys or values. A Content Contains rule for "order_id" or "status":"created" will catch responses where the API returned an error envelope instead of the expected payload, even when the HTTP status is 200.

Assert Redirect Chains Resolve Correctly

If your login flow ends with a 302 redirect to a dashboard URL, add a Response Code rule for 302 on the redirect-source transaction and a Content Contains rule on the final destination. This catches the case where the redirect now lands somewhere unexpected (a different dashboard, a TOS page, a region-specific landing) without your test case noticing.

What Happens When a Validation Rule Fails

A failed validation rule fails the transaction, exactly as if the HTTP request itself had errored. The transaction shows up red in the Test Case Editor after replay, the Errors View lists it with the validation rule that failed and the actual response body for inspection, and during a load test the failure counts toward the test's error rate.

The failure is per-virtual-user, not per-test. If one virtual user out of a thousand hits a momentary error page, only that user's transaction fails. This is what you want. The aggregate error rate over a load test is a real signal: it tells you what fraction of users are seeing broken responses, even when every single one of them came back with status 200.

Validation Under Load

Validation rules run on every virtual user on every page. They are cheap, so don't worry about the performance impact. What you do need to think about is whether the rule is correct under load, not just under replay.

A rule like Content Contains "Welcome, Alice" works fine on a single-user replay because the dataset returns Alice's row. Under load, with a dataset rotating across thousands of users, that rule will fail on every user who isn't Alice. The right rule for a multi-user test is Content Contains "Welcome," (no username) or Content Contains "My Account" (a constant element of the logged-in page).

The same principle applies to any rule that incidentally captures session-specific or user-specific text. Generalize the rule to assert the kind of content you expect, not the specific values from your recording.

For most test cases, three rules are enough to catch nearly all silent failures:

  • One Content Contains rule on the post-login page that proves authentication worked
  • One Content Does Not Contain rule on the same page that asserts the known failure-page text is absent
  • One Content Does Not Contain rule for "Verify you are human" or your CAPTCHA text on every page that might trigger bot detection

Add more rules as you learn how your application fails. Each rule you add is a category of silent failure that future load tests will catch automatically.

Related Topics: