Web Test Authoring and Debugging Techniques for Visual Studio 2010

A New Name, But Under the Covers Still the Same

In this release we renamed "Web Test” to “Web Performance Test” to highlight the primary scenario for Web tests, which is using them as scripts in a load test to model user actions. Load tests are used to drive load against a server, and then measure server response times and server response errors. Because we want to generate high loads with a relatively low amount of hardware, we chose to drive Web performance tests at the protocol layer rather than instantiating a browser. While Web performance tests can be used as functional tests, this is not their primary focus (see my post Are Web Tests Functional Tests?). You will see that I still refer to “Web Performance Tests” as “Web Tests” for short.

If you really want to test the user experience from the browser, use a Coded UI test to drive the browser.

In order to be successful working with Web Performance Tests, it is important you understand the fundamentals about how they work.
Web Performance Tests Work at the HTTP Layer

The most common source of confusion is that users do not realize Web Performance Tests work at the HTTP layer. The tool adds to that misconception. After all, you record in IE, and when running a Web test you can select which browser to use, and then the result viewer shows the results in a browser window. So that means the tests run through the browser, right? NO! The Web test engine works at the HTTP layer, and does not instantiate a browser. What does that mean? In the diagram below, you can see there are no browsers running when the engine is sending and receiving requests

Read more: Ed Glas's blog on VSTS load testing
Read more: VS 2005: Web Test Authoring and Debugging Techniques
Read more: VS 2008: Web Test Authoring and Debugging Techniques for VS 2008

Posted via email from jasper22's posterous