Microsoft Visual Studio 2010 – Web Performance Test – Overview

See Also

A Web performance test (previously "web test") consists of a chain of HTTP requests. Web testing has been supported in Visual Studio Team System ever since the 2005 release, but Visual Studio 2010 offers key improvements. Web tests work at the protocol layer by functioning with HTTP requests. So, web tests do not run client side scripts, but events as performed through JavaScript can be simulated at runtime with assistance of customization using test plug-ins, request plug-ins, extraction rules, or coded web tests (also recognized as declarative web test). Web performance tests are used to test the functionality of web applications and to test web applications under load. Web tests are used in performance testing such as capacity, stress and performance tests. Web performance tests are driven at the HTTP Layer to enable creating high loads with a fairly low amount of hardware; web performance tests do not instantiate a browser.

Web performance tests can be formed by recording the activities in a browser session. These tests can also be built by hand using the Web Test Editor. To test a web application, a web test can be produced by recording that navigates all the way through various application paths as per test scenario/case. A web performance test can be recorded by creating a new web performance test in Visual Studio Ultimate. The web performance test activates the incorporated Web Performance Test Recorder and starts Internet Explorer browser to record the requests. The Web Performance Test Recorder is component of Visual Studio Ultimate installation. As the site is navigated, recorded requests are added to the web performance test. After a web performance test is recorded, it can be altered using the Web Performance Test Editor. The Web Performance Test Recorder does not capture traffic that is sent among the client and server. That means dependent requests are not recorded. The Web Performance Test Results Viewer determines dependent requests at run time. When a web application is run, the application dynamically generates data or sends dynamic data. A cycle known as promotion of dynamic parameters is used to extract such values and bind it to subsequent requests. Dynamic parameter promotion makes the test more dynamic and prevents various failures.

Web performance tests are executed through Web Performance Test Engine. Web performance tests hold a list of HTTP requests. The Web Performance Test Engine executes these HTTP requests, retrieves the responses from the server(s), and collects timing data. Web Performance Test Engine does not run client-side scripting like JavaScript or ActiveX controls. Client-side scripting that only affects the facade of a web page is not significant to the web performance test because principal aim of web performance test is to test web server performance by generating load. Client-side scripting that result in additional HTTP requests is required to be added manually. All requests in a web performance test are executed directly using the Engine and no communication with browser occurs. The embedded Internet Explorer control in the Web Performance Test Viewer only displays response pages received by the Engine. This browser control is configured exclusively not to run JavaScript or ActiveX controls. Different browser templates can be chosen when running a web test. These templates only affect the default set of HTTP headers sent with every request.

Web tests are normally created using the Internet Explorer Web Testing toolbar, which records a human user clicking throughout a web application. In the web performance tests, the addition of Loops and Conditions enables to author more complex and clever tests without writing code! Newly recorded web tests don't have a lot of smarts and are not doing much job of any value. A web test merely plays back the web requests that were originally performed. It doesn't check the return values and it doesn't know anything about how your application works but it is the starting point for creating a more difficult and comprehensive test. Tests can be prepared smarter by using Validation Rules, Extraction Rules, and Test Context. Validation Rules look at the HTML returned from the server and verify that the application has done what was expected. Extraction Rules look at the HTML, pull out values, and store them in memory.