Setting Web Performance Test Properties Using the Web Performance Test Editor

You can set properties on Web performance tests and on parts of Web performance tests to control the way the test runs and verifies aspects of the site that you are testing. You can set these properties at the following levels:

• On a Web performance test

• On a Web performance test request

• On form post parameters and query string parameters

Note

This is not a complete list of properties.

Properties on Web Performance Tests

• StopOnError property. When you run a Web performance test, an error on an HTTP request can cause the test to fail. Despite the failed result, the test will not automatically stop running. To make the test stop running when such an error occurs, set the test's Stop On Error property to True.

• InheritFromWebTest property on child Web performance tests. If the Web performance test is included in another Web performance test and inherits properties from that parent Web performance test, this property returns a WebTest object of the parent Web performance test.

• Both WebTest and WebTestRequest objects now have an Outcome property, which gets a Pass or Fail outcome. For more information, see Outcome and Outcome.

Properties on Web Performance Test Requests

• ExpectedHttpStatusCode. This property specifies the HTTP status code that indicates success for the request. The Web performance test Recorder initially sets this value to blank. A return code in the 200- or 300-level range is a success.

  You can add a dependent request to a request. If the dependent request fails and its HTTP status code matches the Expected Http Status Code on the request definition, the dependent request will be marked as pass.

  If you add a dependent request and set its Parse Dependent Requests property to True, and a matching request is parsed, the definition of the dependent request overrides the parsed request. This lets you ignore failures from a dependent request that are not in the 200- or 300-level range by explicitly adding the dependent request and setting its return code appropriately. The dependent-request URL in the Web performance test can contain a context parameter as part of the path.

• FollowRedirects. If you set the Follow Redirects property to True, the Expected HTTP Code property applies to the Recorded Response URL.

  For example, you could set Expected HTTP Status Code to 401 and Follow Redirects to True. When you run the test, this verifies whether an HTTP status code of 401 (Unauthorized) is returned when the user specified in the credentials for the Web performance test is not authorized to access the page.

• Expected Response URL   The Expected Response URL property captures the expected final URL for a request after following all redirects. The Web Performance Test Recorder automatically populates this field with the appropriate value.

  Note

  Query string parameters are not included in the URL in the Expected Response URL property.

  If you set the Follow Redirects property on a request to False, the Response URL validation rule matches the URL property of the request.

  Note

  The Expected Response URL property is typically checked by a validation rule, for example the Response URL rule. The Response URL rule has no properties, but validates during runtime that the final URL, after all redirects, matches the value that was recorded. In other words, the final URL is the URL that appears in the address bar of a Web browser after a request is complete. This rule is intended to detect redirects to an error page. The Response URL validation rule is automatically added to a recorded Web performance test.

Properties on Parameters

• Recorded Value   You might want to unbind a bound field on a page and then restore its value to the original static value. To restore the original recorded value for the property, use the Recorded Value property on a FormPost or QueryString parameter. When one of these parameters is unbound, the value of the parameter is automatically set to the recorded value.

See Also

Tasks

How to: Use Reporting Names to Easily Identify Requests in a Web Performance Test

How to: Create a Coded Web Performance Test

How to: Edit an Existing Web Performance Test Using the Web Performance Test Editor

Concepts

Binding a Data Source to a Web Performance Test

Using Validation and Extraction Rules in Web Performance Tests

Other Resources

Customizing Web Performance Test Recordings Using Web Performance Test Editor