This documentation is archived and is not being maintained.

Techniques for Verifying and Debugging Web Tests with Team System 2008

Visual Studio 2008

After you create a Web test, you should run the Web test to determine whether the Web test performs as designed. This article is the second in a series of three articles related to creating and debugging Web tests in Team System 2008. This article highlights how to determine whether a Web test works as intended and provides techniques for resolving common Web test issues. For more information, see Techniques for Testing Web Site Performance with Team System 2008.

Web tests contain a list of HTTP requests; each of these requests consists primarily of query string parameters, form parameters, and a URL that targets a Web server. The Web test engine executes these HTTP requests, retrieves the responses from the servers, and collects timing data.

Because the Web test engine works at the HTTP layer, it does not directly simulate client-side scripting like JavaScript or ActiveX controls. Generating load on a server is fundamental to Web tests. As a result, client-side scripting that only affects the appearance of a Web page is not significant to the Web test. Client-side scripting that sets parameter values or causes additional HTTP requests, such as AJAX, does affect the load on the server and might require you to manually modify the Web test to simulate the scripting.

Web tests are not executed by using Internet Explorer. All requests are executed directly, by using the Web test engine; no interaction with Internet Explorer or any other browser occurs. The Web test engine communicates directly with the target Web server by using standard HTTP request and response messages.

Similarly, the embedded Internet Explorer control on the Web Browser tab in the Web Test Viewer only displays response pages received by the Web test engine. The Web test engine writes the responses to a temporary location on disk and then loads the temporary files in the Internet Explorer control in the Web Test Viewer. Pages that are designed for other browsers can be verified by using the Response tab if they do not appear correctly on the Web Browser tab.

Another source of confusion is that different browser templates can be selected when you are running Web load tests. These browser templates only affect the default set of HTTP headers sent with each request. The key header that Web servers use to determine the browser type is the UserAgent header. The Web test engine issues requests directly by using standard HTTP protocol, regardless of which browser template is selected.

Using the Web Test Viewer to Verify a Web Test

Before you add a Web test to a load test and run it for a long time, you should make sure that the test works exactly as intended. To do this, you use the Web Test Viewer. The Web Test Viewer allows you to watch a Web test as it runs, and to view all aspects of a previous test run. For more information, see Running and Viewing a Web Test.

Verifying a newly created Web test goes beyond just looking at the outcome of the test run and seeing whether it passed. For example, for a Web test without validation rules, passed only means that no exceptions were thrown, no rules failed, and no HTTP errors occurred. Verification includes making sure the Web test exhibits the correct behavior on the target Web application, in addition to executing without any errors. It is important to review the response for each request to make sure that it is correct.

The following table lists items to examine when verifying a Web test, and some additional information about each type of problem.

Problems to check for Additional Information

HTTP request error

HTTP errors are signified by a response status code in the 400-599 range. Typically, an HTTP error contains a response body that indicates what caused the problem.

For example, a 401 Unauthorized error might indicate that a user name and password must be configured on the root node of the Web test. A 404 Not Found error might indicate that the Web application has changed since recording occurred. A 500 Internal Server Error generally indicates a bug in the Web application.

If you want to verify that a specific error is generated during a Web test, use the new ExpectedHttpStatusCode property. For more information, see Setting Web Test Properties.

Dependent requests that are not found

A top-level request can appear to have failed because one of its dependent requests could not be found. This error might indicate a problem with the HTML of the Web application. These errors can be suppressed by disabling the ParseDependentRequests property on the request. This prevents dependent requests such as images, CSS, and JavaScript from being automatically parsed out of the HTML and requested.

Extraction and validation rule failures

Extraction and validation rule failures are shown on the Details tab of the Web Test Viewer. These failures usually occur because the Web server returned a page that contained unexpected content, such as by redirecting to a log on or an error page.

Extraction rule failures frequently cause errors on subsequent requests such as, "X was not found in the Web test context."

Test-level exception

A test level exception is shown in the Web Test Viewer as a node after the last successful request. Test level exceptions include exceptions in WebTestPlugins, PreWebTest and PostWebTest event handlers, and exceptions that are not specific to a particular request in a coded Web test.

Request-level exception

Request level exceptions cause an individual request to fail, but let the Web test continue. These exceptions include those thrown from WebTestRequestPlugins, PreRequest, and PostRequest event handlers, and extraction and validation rules. The exception message and a stack trace (if available), are shown at the bottom of the Details tab in the Web Test Viewer.

Incorrect page content returned by server

Verifying that the Web server returns the correct content is frequently done by visually inspecting each page in the Web Browser and Response tabs of the Web Test Viewer.

Validation rules can be used to automate this process when the Web test is verified to work correctly.

Common Problems

Web Server Responds Differently During Execution than Recording

Web applications sometimes behave differently during Web test execution than they do during recording.

This type of problem can occur for many different reasons and frequently gives you an error message such as the following:

Request failed: $HIDDEN1.__VIEWSTATE not found in test context.

This error occurs when the Web test tries to use a hidden field in the Web test context that it was unable to locate and extract from a previous response page it received.

For example, if a server error caused hidden fields, and the next request depends on those fields not existing on the page, you would see the following error message:

Request failed: Context parameter '$HIDDEN1._VIEWSTATE' not found in test context.

There are many reasons why a server might respond differently during execution than it did during recording. Some common reasons are summarized in the following sections. In every case, validation rules can be added to requests to automatically verify that the server responds with the correct content.

One-Time-Use Data

One common reason why the Web server would respond differently during execution than recording is one-time-use data, such as when a Web application creates a unique user name. Playing back this kind of Web test without adding data binding or a random value can result in the Web application displaying an error when the test tries to create a duplicate username.

JavaScript Redirects

A Web application that uses JavaScript redirects, for example setting window.location, might respond differently during execution than during recording because the Web test engine does not run script code. This type of problem can be easily corrected by inserting the URL the script redirects to and moving necessary extraction rules to the new request from the page that performs the redirect. Because this problem occurs in the Web test immediately after recording, the only extraction rule likely to be present is ExtractHiddenFields.

Using the Recorder Log

The Web test recorder can generate a recording log for each recording. You can turn on this log to see what Internet Explorer is sending over HTTP.

To turn on the recorder log, set these registry entries:

Windows Registry Editor

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\EnterpriseTools\QualityTools\WebLoadTest]
"CreateLog"=dword:00000001
"RecorderLogFolder"="c:\\RecorderLogs\"

This registry setting gives you a log file for each recording session. Open the log file and find the failing request. Then, carefully compare all parts of the request in the request log to the request in Web Test Viewer, paying additional attention to the following:

  • URI
  • Query string parameters and values
  • HTTP headers, including custom headers and cookies
  • Post body

When you identify the difference, you can go back to the Web test to fix the problem. Some areas to look for are:

  • Missing custom HTTP headers in the Web test
  • Incorrectly handled dynamic parameters:
    • Parameters marked as dynamic that are not intended to be dynamic.
    • Incorrect extraction rules

Handling View State and Other Dynamic Parameters

Even before ASP.NET 1.0 introduced the __VIEWSTATE hidden form field, Web applications used dynamically generated form and query string parameters to pass information between pages. These dynamic parameters require special consideration in a Web test because they can change every time that the Web test runs. A Web test with hard-coded parameter values might not work for very long after recording, or even at all.

Web tests enable testing with dynamic parameters by using extraction rules and context binding. Extraction rules are included on requests for pages that will contain a dynamic value. When the extraction rule runs, it extracts the dynamic value into the Web test context by using a configurable name such as "myparam". A subsequent request then contains a query string or form parameter with a value of {{myparam}}. When the Web test runs, the value in the Web test context is substituted for {{myparam}}.

The sequence of events for an extraction rule is as follows:

  1. The Web test engine starts executing Request1.
  2. Request1 is sent to the target server.
  3. A response is received from the target server.
  4. The extraction rule on Request1 runs on the response page.
  5. The extraction rule adds an entry in the Web test context.
  6. The Web test engine starts executing Request2.
  7. Query string parameters, form parameters, and any other context-bound values on Request2 are substituted from the Web test context.
  8. Request2 is sent to the target server.

Automatic Hidden Field Tracking

Web tests contain special support for handling dynamic hidden fields, such as __VIEWSTATE. When a Web test is recorded, hidden fields are automatically matched with form and query string parameters. When a match is found, the ExtractHiddenFields rule is applied to the request. This generates the source of the hidden field. At this time, context bindings are applied to parameters on the request, making use of the hidden fields.

ExtractHiddenFields is a special extraction rule because, unlike rules that extract one value into the context, it extracts every hidden field value on the page into the Web test context. Normal extraction rules use the ContextParameter property to determine the name to use for the context parameter, but ExtractHiddenFields uses that property only to differentiate from multiple groups of hidden fields that might be in the context at the same time. For example, an ExtractHiddenFields rule with ContextParameter set to 1 will extract __VIEWSTATE as "$Hidden1.__VIEWSTATE".

Show: