Building Web Tests
A web application is a conglomeration of individual requests, interactions, and responses. Therefore, to test it well, you need to be able to simulate a series of such requests, interactions, and responses. Web Tests let you record requests, user interaction, and navigation from one web page to another so you can later execute the sequences as tests to validate the build. Recorded, replayable Web Tests can save you a lot of time and help in doing regression (verifying the fixed bugs), smoke (making sure that new changes do not cause the basic functionality to fail), or sometimes full-build testing.
Suppose you have the following test case:
Summary: Test the User login
Steps to execute the test:
1. Navigate to http://webtest/default.aspx
2. Enter user name and password
3. Click the Login button
Expected result: Users should be directed to
the home page:
and see a welcome message.
Here are the steps to record a Web Test:
- Create a new test project and name it WebTest.WebTests.
- Right click and select the "Add a New Test" option.
- Next, select the "Choose Web Test" option from the displayed list of templates.
- Name the test UC1 _TestLogin.webtest.
|Figure 7. Executing a Web Test: Select the test you want to run, and click the green Play button on the top left-hand side of the Web Test toolbar.|
When you've completed those steps, VSTET launches an IE browser window. Type the URL of the web site for which you want to record the Web Test—in this case http://localhost/Webtest
. Enter a user name and password and click the Login button, and then close the browser window. That's it!
To run the Web Test you just created, open it and click the green Play button on the top left-hand side of the Web Test toolbar (see Figure 7
|Author's Note: If you are hosting the web site on a file server, make sure that you have the ASP.NET development server (Cassini) running on one of the ports. Replace the port number in the Web Test requests with the port number that you are using.
The Web Test will execute, sending each of the requests you recorded using the Web Test recorder in their original sequence. The test will record the response time of each request-response cycle, and the size of the response. It will use the appropriate protocols and handle passing any parameters.
|Figure 8. Web Test Result: In this Web Test Result you can see each requested URL along with the response status, time, and size.|
As shown in Figure 8
, this Web Test result example consists of three HTTP responses. The Response tab shows the exact response retrieved from the server, including the status, response time, and size of the each request. The Request tab shows the full request sent to the server, including parameter values.
Web Test Structure
Web Tests consist of rules and parameters that let you manipulate the test so it does exactly what you want.
Extraction rules are primarily used for extracting the data from one response and using it as an input to another request. If you expand the first request in the Web Test, you'll see an Extraction Rules folder that contains one item: "Extract hidden fields." This is an extraction rule created by the web recorder for extracting the View state, which it stores as a hidden field and feeds to the next page (Home.aspx
If you try to view the properties of the WebTest request, you will notice that there is a "Think Time" parameter. Think time is time that elapses before a user takes an action that causes the web test to generate the next request.
Think time does not include the time required for a page to load.
Form Post Parameters
The Form Post Parameters contain any parameters posted back to the page, which may include control values, Viewstate, the EventTarget, event arguments etc.
At this point, you can see from Figure 8
that the Web Test is running fine, but just because it ran doesn't mean that it's running according to the test case rules. You need to validate the test results. Remember, the test case "Test the User login," states that "After clicking on the Login button, users should be directed to the home page, http://webtest/home.aspx
, which displays the welcome message." In other words, the test case should pass only if it meets the use case conditions.
|Figure 9. Adding a Validation Rule: The figure illustrates how to add a validation rule for a required attribute value.|
You can use Validation Rules to verify both conditions. To create a Validation Rule to verify whether users who logged in were successfully directed to Home.aspx
right-click the second request in the Web Test Result, and select "Add validation rule." You'll see the Add Validation Rule dialog. Select the "Required Attribute Value" item from the left side and fill in the values on the right as shown in Figure 9
This validation rule verifies that the response to the second request should contain a <form> tag with an id
attribute of "form1" and an action
attribute of "Home.aspx:"
<form name="form1" method="post"
In other words, this rule will fail if users are not directed to Home.aspx
|Figure 10. Validating Content: Using the Find Text rule, you can verify that the browser has loaded content containing specific words or phrases.|
Similarly, to verify that users saw the welcome screen, right-click the third request and select "Add validation rule." Select the "Find Text" item from the left pane, and then in the right pane, fill in the values shown in Figure 10
Coded Web Tests
Coded Web Tests are useful when simply following a prerecorded path isn't sufficient for verification, and you need to plug in your own custom logic to generate Web Test Request properties. For example, using the already-recorded Web Test example from the preceding section, suppose you want to analyze how the login page behaves if 1000 users try to login at the same time. You could simulate that by running the existing test inside a Coded Web Test class and looping 1000 times.
You can create a Coded Web Test from an existing recorded Web Test. To do that, open the UC1 _TestLogin.webtest
and click the "Generate Code" button on the Web Test toolbar. Name the class CodedWebTest.cs
and click OK. That generates a class file so you can see and modify the code.
VSTET's support for Coded Web Tests makes web testing extensible, and simplifies the process of mapping real-world test cases to Web Tests.
With all the attractive features available in VSTET for Test-Driven Design, there are still a few that you might wish were available:
- VSTET does not support NUnit tests. Converting NUnit tests to Visual Studio unit tests takes time—and sometimes isn't possible. But there is a workaround; see http://www.codeplex.com/NUnitForVS for further details.
- VSTET tests do not support inheritance. So you can't write a base test and inherit from it.
Used in conjunction with properly planned code reviews, test-driven development can prove beneficial in designing and implementing high quality applications that conform to the quality standards and meet the stated requirements. Visual Studio Team Edition for Testers builds on the familiar VS.NET IDE by adding robust support for TDD, letting you define, execute, manage, and view test reports. These features promise to reduce development time, code complexity, and post-deployment bugs.