We recommend using Visual Studio 2017
This documentation is archived and is not being maintained.

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


This is not a complete list of properties.

  • 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.

  • 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.


    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.


    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.

  • 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.