This chapter explains the different ways of verifying the website responses for each request and the website response in different scenarios such as slow network speed, different browsers, or with different set of users at a given point in time. All these factors affect the website's performance and the response time. Web performance testing helps us to verify whether the website produces the expected result within the expected response time, to identify the problems and rectify them before they happen in an actual production environment, helps in finding out if the hardware can handle the maximum expected requests at a time, or needs additional hardware to handle the traffic and respond to multiple user requests.
Here are some of the main testing highlights that are performed on the web applications for better performance and availability:
There are many other types of testing that can be performed as part of web performance testing such as using different operating systems, using different databases, or installing different versions of an operating system.
All these testing types, with many additional capabilities, are supported by Microsoft Visual Studio. The dynamic web pages can be created by any of the supported .NET languages through Visual Studio using the ASP.NET web project and web page templates. Custom services, components, and libraries are used in the web application to get the functionality and make it more dynamic. Other scripting languages and technologies, such as JavaScript, Silverlight, and Flash are used in web pages for validations and better presentation on the client machine. Once the web application is ready, it needs to be deployed and tested to check if the web site functionalities and qualities are satisfied as per requirements. To get to this point, Microsoft Visual Studio provides tools for testing the web applications in different ways. One is to use the user interface to record and then add the validation rules and parameters to make it dynamic. The other way is to record the requests and then create the coded web test for the recorded web test, and customize it using the code.
This chapter explains the basic way of web testing using Visual Studio and using the features, such as adding rules and parameterization of dynamic variables. Microsoft Visual Studio 2012 provides many new features to the web performance testing, such as adding new APIs to the Test Results, keeping web performance Test Results in a separate file, looping and branching, and new validation and extraction rules. This chapter provides detailed information on features given in the following list:
The web performance test activates the web performance test recorder to record all the actions performed while browsing the websites and adds it to the performance test. Creating a performance web test is similar to creating any other test in Visual Studio. The different ways to create a new web performance test are as follows:
The above option will create the new project, add the web performance test to the project, and then open the recorder as well.
The web test recorder is used mainly to record all the actions performed while browsing the web pages. The recorder records all the requests made and responses received while navigating through the web page.
The test scenario is created by navigating through the web pages and recording. Once the scenario is created, build the scenario or customize it to make it more dynamic using parameters and adding dynamic data source.
As stated earlier, after starting the web performance test, a new browser window opens with the web test recorder. The recorder has five different options discussed as follows:
Following is a screenshot that shows all these options available on the recorder:
Before proceeding with web testing, create a sample web application for testing. Consider a new employee creation page wherein the user has to provide information, such as First Name, Last Name, Middle Name, Occupation, and Address. This is the minimum information required to keep track of users in the website, which is common in most of the websites. Consider the following simple web page for this example. It contains a Save option which collects all the information entered by the user and saves it to the database table. The user entries are validated as per the requirement, which we will see through the examples in the subsections. The database is the SQL Server Express database, with one table for storing all the information. The following screenshot shows the database table for the sample application:
The Add new Employee web page from the sample application is shown here with some required fields, including fields to show the validation error messages and the Insert option to send the details and save it to the database:
The application can be tested when it is hosted on a web server, or when it is running on the local development web server within Visual Studio. The examples given in this chapter are based on the local Visual Studio development server. The approach is the same for hosted applications on a web server.
While using the Visual Studio local development web server, build the new web project and keep it running. Get the web address from the running web application which has the web address with a dynamic port assigned to it.
First, let us look at the features of the web performance test and then go into the details of collecting information from a test and the actual testing.
Create a new web performance test which opens the new web test browser recorder window. The web test tool opens the Microsoft Internet Explorer browser for the recording as Internet Explorer is the default web browser for testing. Now in the Address bar, enter the web page address and hit Enter. In this case it is going to be http://localhost:3062/Employee/Insert.aspx
(this is a test address using the local web server and will vary based on the dynamic port assigned to it). If you are planning to test the application from the hosted server, then record the test by browsing the web pages from the hosted server. Whether it is hosted on server or a local development server, the web application should be up and running for testing. Once the web page is up, enter all the required details and click on Insert to save the new employee details. Each row gets added to the tree view below the recorder toolbar. All request details are recorded until the test is stopped or paused. To get the correct test scenario, enter all required fields and perform a positive test so that there are no error messages. After recording the scenario, perform invalid entries and test the application.
After entering the URL and hitting Enter in the Address bar, the web page is loaded on the right while the requests are captured on the left as they are recorded.
Enter all request details and then click on the Insert button. Once the insert is successful, stop the recording to complete the insert scenario. The web test shows the recorded pages and the parameters captured while recording the insert page as follows:
Three requests are captured during recording: one for the main page to select the employee details page, second one is to select the Insert option to enter a new employee's details, and the third one is to save the employee details and display the mail screen. The details of these requests are displayed in the tree view. Expanding the third root node in the tree view shows different values and strings passed through the web page on clicking the Insert button which are captured under the folder Form Post Parameters. Note that the event took place on clicking the Insert button in the web page. All other details are the parameter values posted by the request.
There are different protocols used for sending these requests as follows:
Recording shows that only the independent requests (GET or POST) are recorded, not the dependent requests such as requests for getting images and other such requests. These requests are reported only when the test is run, but during recording, it will neither be shown nor captured.
When the web application is run, it dynamically generates data, such as session ID and is sent through the Query String
parameter values and Form Post
parameter values. The web performance test uses such generated parameter values by capturing it from the HTTP response using an extraction rule, and then binding it to the HTTP request. This is known as the promotion of dynamic parameters. Detection of dynamic parameters happens immediately after finishing the web performance test recording. On clicking the Stop button in the recorder window, notice a dialog window with the message Detecting Dynamic Parameters and the progress bar. The dialog displays a message as Did not detect any dynamic parameters for our sample site. If the dynamic parameters are detected, a Promote Dynamic Parameters to Web Test Parameters dialog box appears.
While recording the web page requests, some additional comments may be required to be added to the recording about the page or the test. This comment could be any text with additional information for reference. This is similar to the comments added to the code during development. Sometimes it is required to add information about the steps to be followed during the test. Basically comments are there to record the information about the additional task required during the test, but could easily forget to do. These comments can be added simply by clicking on the Add Comments button in the Web Test Recorder toolbar.
While recording the scenario, all user actions are recorded irrespective of the application under test. Sometimes user navigates to other areas which is irrelevant to the current test. The recording should be paused, not to record the request outside of the current test. But, in case it is not paused during the recording, use the Delete option to remove those requests from the recorded details.
In some situations, same requests may be required to be tested multiple times, for example, page refresh. To simulate this, copy the recorded request and paste it into the recording list. The same request can be copied any number of times. Select the request from the list from the tree view, right-click and Copy or use (Ctrl + C) and then select the destination folder and right-click and choose Paste.
By copying the requests, the order of testing is also changed. This is an easy way to change the order. Instead of copying, cut and paste the request to a different place just to change the order. But be careful when changing the order in this way, that dependent requests are not affected. For example, if request B is dependent on request A, then do not move request B before A. Take extra care while copying and changing the order of tests.
Loop logic is very useful in running the same web request multiple times. Conditional rules and properties can be set to verify whether any specified condition is met or not. The loop logic can be added at the web performance test level or at the web request level. The looping should be used to reproduce a user scenario but should not be used to simulate the number of users.
Let's take the scenario of creating multiple temporary users or employees using the user interface. One way of doing this is to create it manually by entering all the details using the user interface and the other way is to use a data driven UI test by feeding the data from the predefined data source with all user details. In either case there is a good amount of manual work involved. The other best option is to use the recording of a single user creation through UI, use the recording, and loop the request for multiple times. Let's see the step-by-step approach of this feature to create four users. The following steps use two context parameters to hold the values and then use the parameters to increment the value and insert employee details:
User
for the First name. Add another parameter and set the value as 1
. The second parameter is to increment the value and set it as the last name to differentiate between the users.The following screenshot shows two context parameters added to the web test:
If you check the web requests during the test, you will notice that the same web request is called four times with only the Parameter2 value changing for each iteration.
The following are some of the Conditional rules and items that can be looped:
Conditional rule |
Rule description |
---|---|
Context parameter exists |
Test whether or not the specified context parameter exists in the current context. |
Cookie exists |
Test whether or not the specified cookie is set. |
Cookie value comparison |
The condition is met when the provided string matches the value of the specified cookie. |
For loop |
The rule represents a traditional For loop. The context parameter is initialized before the first loop iteration. The loop statements get executed while the content of the context parameter satisfies the comparison with the provided value. The step value is applied at the end of each loop iteration. |
Number comparison |
The condition is met when the value of the context parameter satisfies the comparison with the provided value. |
Probability rule |
Randomly returns pass or fail based on the percentage provided. |
Counting loop |
Executes the requests contained in the loop a specified number of times. |
String comparison |
The condition is met when the provided string matches the content of the provided context parameter. |
The Items in loop section in the Add Conditional Rule and Items to Loop window denotes the first and last web request within the loop out of all the recorded requests in the order.
The web performance test that contains loop with a lot of iterations may consume a lot of memory while running the test, as the web Test Results are kept in the memory.
When the web performance test in a load test takes a long time to run, it will have an impact on the test mix. The load test engine will treat running the web performance test as a single iteration.
18.217.254.118