Tips for Recording Web Tests with Team System 2008

Article
02/22/2012

Microsoft Visual Studio Team System 2008 Test Edition includes several improvements for load testing Web sites by using Web tests. This article is the first in a series of three articles related to creating and debugging Web tests in Team System 2008. This article highlights features and techniques testers and developers can use to improve the effectiveness of their Web tests. For more information, see Techniques for Testing Web Site Performance with Team System 2008.

How do Web Tests Work?

Web tests work at the HTTP protocol layer. The Web Test Recorder hooks into the Internet Explorer object model and listens for various navigation events. The Web test engine uses the .NET Framework System.Net HTTP-related classes to send requests and receive responses from the Web site. Web tests do not test client-side code; they do not load responses into a Web browser, nor do they run JavaScript. A better way to think of these tests are as Web Application tests, because Web tests actually test the server part of a Web site.

Although dependent requests, such as images, cascading style sheet (.css) files, and JavaScript files, are not recorded into the Web test, these types of requests are parsed out of HTML pages when the Web test is run and are requested automatically. You can disable parsing of dependent requests by setting the request's ParseDependentRequests property to false. For more information, see About JavaScript and ActiveX Controls in Web Tests.

Tips for Recording a Web Test

To make recording Web tests more successful, Team System 2008 Test Edition includes the following features:

Inserting Comments
Recording with Think Time in Mind
Filtering Dependent Requests
Filtering HTTP Headers
Detecting Dynamic Parameters

For more information, see How to: Record a Web Test.

Inserting Comments

Inserting comments during recording can help you create an effective Web test, especially when the Web test contains many requests. You should use comments to make notes about what logical action is about to occur at different points in the Web test such as "Logging in," "Adding item X to the shopping cart," and so on. These comments can be very helpful when you later modify the Web test in the Web test editor.

You can also use comments to make notes about validation rules you add to make sure that the Web test is successful. It is much easier to decide what has to be validated on each request while you are recording and looking at the pages than when you are looking at a list of HTTP requests in the Web test editor. For more information, see How to: Add Comments to a Web Test.

Recording with Think Time in Mind

The ThinkTime property on a Web test request refers to the period of time that a user spends on the current page before issuing the next request. Think time delays are used to approximate real user behavior during a load test. Because think time can significantly affect the amount of load a Web test can generate, it can be globally disabled in a load test to apply more load to a target server. Disabling think time enables you to issue requests to the server as fast as possible without delay between requests. For more information, see About Think Times and How to: Set Think Times in a Web Test.

The Web test recorder automatically records think time at the same time that requests to the Web application are recorded. During recording, try to approximate the period of time that a user would ordinarily spend on each page. When the recording is finished, it is very important to check the recorded think time for each request. Inadvertently long think times can significantly affect the rate at which a Web test generates requests. By default, think times are turned off in the Web Test Viewer. As a result, long think times might not be immediately apparent. When think times are turned on in the Web Test Viewer, you will see "Thinking…[n]" displayed in the HTTP Status column until the next request starts. Think times are turned on by default in load tests. The think time counter is paused when recording is paused and when you enter a comment.

Filtering Dependent Requests

When Web tests are recorded, some requests are filtered out by default. These requests include page resources such as images, JavaScript, and cascading style sheets. These resources are classified as dependent requests. At run time, the Web test engine parses the response, finds all references to dependent sources, and then fetches them. Specifically, the Parse Dependent Links feature looks for all IMG, SCRIPT, and LINK tags. This technique helps make Web tests more resistant to cosmetic Web site changes and keeps the tests more focused on the actual use of the Web application.

You can override what is filtered or recorded by using the registry settings that are shown here. These settings are the default (set in code, these registry entries are not present after install):

Windows Registry Editor

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\EnterpriseTools\QualityTools\WebLoadTest]
"WebTestRecorderMode"="exclude"
"ExcludeMimeTypes"="image;application/x-javascript;application/x-ns-proxy-autoconfig;text/css"
"ExcludeExtensions"=".js;.vbscript;.gif;.jpg;.jpeg;.jpe;.png;.css;.rss"

You can see that these settings will filter out images, JavaScript source files, and .css files. If you want to record everything, you can just set “ExcludeMimeTypes” and “ExcludeExtensions” to the empty string " ".

The recorder will also work in an “include” mode, where you specify a list of mime types and extensions to include. For example, the default include list is as follows:

Windows Registry Editor

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\EnterpriseTools\QualityTools\WebLoadTest]
"WebTestRecorderMode"="include"
"IncludeMimeTypes"="text/html;text/xml;text/xhtml;application/xml;application/xhtml+xml;application/soap+xml;application/json"
"IncludeExtensions"=""

Currently, requests picked up by the low-level recorder are treated as top-level requests in the Web Test Viewer. For example, if you set the recorder to include images or other dependent requests, the recorder does not determine which request the dependent came from. Instead, all requests for the dependent are stored as top-level requests, instead of grouped under the appropriate requestor. Asynchronous requests are also recorded at the top level of the Web test and played back synchronously.

Note

Dependents are fetched in parallel over two connections in the same way an Internet browser fetches them.

Filtering HTTP Headers

HTTP header filtering works in a similar manner to dependent request filtering. Typically, in a Web test, most HTTP headers are set from the browser template file. For example, the contents of the Internet Explorer 7.0 browser template file include the following:

<Browser Name="Internet Explorer 7.0">
  <Headers>
    <Header Name="User-Agent" Value="Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)" />
    <Header Name="Accept" Value="*/*" />
    <Header Name="Accept-Language" Value="{{$IEAcceptLanguage}}" />
    <Header Name="Accept-Encoding" Value="GZIP" />
  </Headers>
</Browser>

By default, the recorder only records these additional HTTP headers:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\EnterpriseTools\QualityTools\WebLoadTest]
"RequestHeadersToRecord"="SOAPAction;Pragma;x-microsoftajax"

Your application might send additional custom headers. In that case, you can change the recorder settings to add the headers your application sends.

The recorder is set not to record the following headers, because the HTTP engine handles these headers automatically:

Authorization
Proxy-Connection
Connection
Host
Expect
Content-Length

Detecting Dynamic Parameters

Team System 2008 Test Edition includes updates to dynamic parameter detection in Web tests. A dynamic parameter is any parameter whose value is generated every time that a user runs the Web application. In Team System 2005, Web tests could only detect cookies and hidden fields. For Team System 2008, query string parameters and additional form fields have been added, in addition to fixes for hidden field binding issues.

When a Web test is recorded, the value of each parameter is recorded, and an appropriate extraction rule is computed. Immediately after it is recorded, the Web test is played back by the correlation tool. During playback, the correlation tool applies the extraction rule and compares the extracted value with the recorded value. If the values differ, the correlation tool flags the parameter as a dynamic parameter. If, for some reason, playback fails, you might not receive a complete list of parameters to promote. You can determine whether playback has failed by looking in the Web Test Results window.

Playback might also incorrectly identify a parameter as dynamic even though it is not. For example, cookies can be used in Internet Explorer to populate fields, such as user name. If you record a Web test with this setting turned on, a cookie is used to set the value of the field so that it is automatically populated. During playback, the correlation tool will compare the extracted value with the recorded value, and will determine whether the values differ. The parameter will be flagged as a dynamic parameter. If you accept the parameter as dynamic, the Web test engine will use the field value from the cookie instead of playing back what you typed in the field. You can avoid this issue by deleting cached cookies in Internet Explorer before recording Web tests.