These are the parameters sent along with the request if the method used for the request is POST. All field entries made by the user in the web page are sent to the server as Form POST Parameters. After recording we can check the actual values of the parameters that were sent during the request.

In the following screenshot, the Middle Name field was not entered by the user before submitting the form, so it contains nothing. The tester can change the parameter value by selecting the form parameter property and changing the value field.

Sometimes, there are additional properties based on the type of control we use on the web page. In that case, we may have to set those properties as well. For example, if we use the File Upload control, we may have to set the type of file that can be uploaded.

This is very similar to Form POST Parameters. These query string parameters are listed under the request which uses the QueryString method for the request.

The properties and the usage of QueryString Parameters are the same as Form Post Parameters properties, except for an additional property which is Show Separate Request Result. This property is used for grouping the requests based on the value of this query string parameter. This is very useful when Load Testing for grouping a bunch of requests based on this field value. The default is False.

Extraction rules are useful for extracting data or information from the HTTP response. Normally in any web application, the web forms are interdependent. This means that the request is based on the data collected from the previous request's response. Each request from the client in the web receives some kind of response from the server with the expected data within it. The data from the response has to be extracted and then passed on to the next request by passing the values using query strings or values persisted in the ViewState object, or using Hidden fields.

In previous examples, we used the new employee creation page where the user can enter details to create new employee details, or the user can select the employee from the list page and get the employee details displayed, or select the emergency contacts or absence details for the employee. In this case, once the user selects a particular employee from the list, we have to validate the user and pass on the user information to the next absence.aspx or emergencycontacts.aspx page where the absence details and emergency contact details are displayed.

This validated user information is hidden somewhere in the request using ViewState or Hidden fields. In this case, we can use the extraction rules to extract the user information and pass it on to the next request, or to further requests. We can extract the information and store it in the context parameter and use it globally across all requests following this.

Visual Studio 2010 provides several built-in types of extraction rules. This helps us to extract the values based on the HTML tags or different type of fields available in the web form. If we need additional extraction behavior, which is not supported by the existing one, then we can go for the custom rules. The following are the existing Extraction rule types.

The screenshot below shows the sample image added to the employee maintenance web pages. The image source is highlighted in the following screenshot of the code:

Now let us add an extraction rule for the image that we have for the employee maintenance web pages. The following screenshot shows how to set the properties of the Extraction Rules. This extraction rule is created for a sample HTML image used on the page. The extraction rule type is an Attribute Value rule to find the image source URL used for the image.

We can add as many rules as we want, but should make sure that the Context Parameter Names are unique across the application. It is like a global variable used in the application, which is referred to in all the forms.

By default, Visual Studio adds extraction rules for hidden fields automatically. The references to the hidden fields are also automatically added to the Form POST Parameters and Query String Parameters.

For coded Web Performance Tests we can create a custom extraction rule by deriving from the ExtractionRule class.

Every application has some sort of validation done on the input and output data, for example, a valid e-mail address, a valid username without any special characters, or a valid password which is not less than six letters. All these validations are performed using the validation rules against the fields as per expectation.

Validation rules are simply defining criteria which the information contained in the response has to pass through. All the data collected from the response is validated against the set of defined rules. If it passes it means that the response is validated, otherwise the test fails. For example, if the user has to enter a specific value or if the user has to select a value from a set of values then we can define these validations as rules and use them against the values returned in the response fields.

Visual Studio 2010 provides a set of predefined rules for validations. These rules are used for checking the text returned by the response.

To add the validation rules, just right-click on the request and select the Add Validation Rule option which opens the validation rules' dialog. Select the type of validation rule required and fill in the parameters required for the rule.

We can keep adding as many number of validation rules as we want, but as the number grows, the performance or the time taken for the test will also grow. So we should decide which one is the most important for Load Testing. These rules will affect the time taken for the test.

In all the above rule types, we have a special parameter known as the Level that can be set to Low, Medium, or High. As mentioned earlier, the Load Test performance is affected directly by the number of validation rules we have. So to control the execution of rules in a request during the Load Test, we can use the Level property. The level does not mean the priority for the rule, but it defines when it should get executed based on the Load Test property. The Load Test also has properties of Low, Medium, or High.

Based on the following Load Test property, the rules with the corresponding levels will get run during the Load Test:

Based on the importance of the Load Test, we can set the properties of the rules.

We will see more details about this in the chapter which talks about Load Test

Transactions are very useful when grouping a set of activities. In this case, we can group a set of requests so that we can track the total time taken for this set of requests for our analysis. This is also helpful in collecting the timing of the individual requests.

We simply need to state the starting request and the ending request for the transaction so that all the requests in between will be part of the transaction, including these two requests.

To add a transaction, select the starting request and right-click and choose the Insert Transaction option.

The Transaction dialog requires a name for the transaction and then the requests for the first item and the last item of the transaction. When you choose both and say OK, the transaction is added before the first item is selected for the transaction and all the other requests between the first and last item including the first and last are part of the transaction as shown here:

So when the test is run you can see the total time taken for all the requests under the transaction.

We have seen the Form POST parameters and QueryString parameters and how to set the values of the parameters using the property. Now, each and every time we test the application, we have to change the property. In the case of load or web performance testing, it is difficult and time consuming to test for more users. To automate the process, we can directly link the parameters to the available data from a different data source.

Visual Studio supports different types of data sources such as CSV, SQL Server database, XML File, Access, Excel, and any other database using the OLE DB provider connection.

To add a new data source:

You can add any number of data sources based on the requirement and on the sources of data we have for testing.

The following screenshot shows two data sources, CSVFileDataSource is for new user data and XMLCountriesDataSource is for the list of countries for the user.

Once the data source is ready, we can change the source of the Form Post or QueryString properties. To do this, select the Form Post Parameter under the request, then right-click and choose Properties. In the Value property, select the data source and select the field from the data source.

You can see the value assigned to the form post parameters. It is pointing to the field in the selected data source as in: {{CSVFileDataSource.EmpData#csv.First_Name}}

At runtime, this field is replaced with the exact value extracted from the CSV file and the test runs successfully.

This is useful for setting other user credentials to be used for the test instead of the current user credentials. You can apply this user credential to test the page, which uses basic authentication or integrated authentication. If we have multiple user credentials to be tested against this web page, and if the user credentials are stored somewhere, we can use this as a data source for credentials and bind the credentials field to these data source fields.

Credentials can be set using the option in the Web Performance Test editor toolbar. Click the Set Credentials option and enter the User Name and Password values. If you have the data source already, you can click on the Bind... option and choose the data source and the field for the multiple user credentials test for the test page.

This option adds a new request recording to the existing test. Sometimes we may forget to browse certain web pages during the recording. So after recording is done, we can still add requests to the recording using this option. On clicking the option Add Recording in the Web Performance Test editor toolbar, you will see the recording window opened up for new recording. After completing the recording, this current recording will get added to the existing Web test recording. This is one of the ways to edit the recording. We can also delete a request from the existing recording and add a new one.

All Web Performance Tests are recorded and conducted using one web server. If we have to test the same test on another web server, we then have to re-record the testing on the new server and test again. But now Visual Studio provides a feature for parameterizing the web servers. It means that the web server to which all the Web Performance Test requests should point is identified at runtime using these parameters.

For example, this is required when performing the same kind of testing but with different hardware configurations. The requests in the Web Performance Test should point to different hardware every time the configuration is changed. The test scenario is the same in all these cases, but only the configuration changes based on the parameter values set at runtime. This is very useful when the application is tested for load testing, performance testing, and integration testing where only the configuration has changed.

To parameterize the web server in a Web Performance Test:

If you are planning to use the local ASP.NET development server, choose the second option, Use ASP.NET Development Server, and provide the local website path and the application root.

After changing the value for the new context parameter, close the Parameterize Web Server dialog box. Now we can see the context parameter added to the Web Performance Test under the Context Parameters folder. Also, we can see that the server addresses in all the request URLs of the Web Performance Tests are replaced with this new parameter, and the value is held by the context parameter.

We can see that the context parameters are used in the requests within the brackets as in {{WebServer1}}, which is replaced by the actual value at runtime.

// Sample plug-in assembly code to create new context parameter
public override void PreWebTest(object sender, PreWebTestEventArgs e)
{
e.WebTest.Context["CountryParameter"] = System.Environment.UserName.ToString();
e.WebTest.Context["ctl00$ContentPlaceHolder1 $FormView1$ctl04$ctl08$_Country$TextBox1"] = e.WebTest.Context["CountryParameter"];
}

Plug-ins are a set of external libraries or assemblies written for custom functionality which can run along with the Web Performance Test. Each plug-in runs once for every iteration of the test. For example, a currency converter could be an external service, which can be used as a plug-in to convert a currency value in the test.

To add a plug-in, we need to first create an assembly or a separate class library with a class containing the custom code. The class should inherit from Microsoft.VisualStudio.TestTools.WebTesting.WebTestPlugin and should implement the PreWebTest() and PostWebTest() methods. At least one of the following methods should be implemented:

To get this namespace, we have to add the Microsoft.VisualStudio.QualityTools.WebTestFramework reference to the assembly. After completing the coding, add this assembly project reference to the Web Performance Test project. Then select the Web Performance Test and choose the Add Web Test Plug-in option from the toolbar, which will list the classes within the assembly. On selection, the class for the plug-in will get added to the test project.

For example, if the class contains the following code, we can see the context variable with the value added to each request in the Web Performance Test. Create an assembly containing the class derived from WebTestPlugin and add the reference to this assembly in the test project.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.VisualStudio.TestTools.WebTesting;
namespace ClassLibrary1forPlugIn
{
public class Class1 : WebTestPlugin
{
public override void PostWebTest(object sender,
PostWebTestEventArgs e)
{
}
public override void PreWebTest(object sender,
PreWebTestEventArgs e)
{
e.WebTest.Context["TestParameter"] = "Test Value";
}
}
}

e.WebTest.Context contains the current context of the Web Performance Test. The e is the current object that fires the event. The parameters and properties for the current context can be accessed using the e.WebTest.Context object. Click on Add Web Test Plug-in in the Web Performance Test toolbar to open the dialog box that displays the available plug-ins.

Now when the test is run, you can see the context variable added to each request's context.

This is very similar to the Web Performance Test plug-in, but the only difference is that the plug-in code runs for every request in the Web Performance Test. This is the custom code written for complex functionality which should run before or after every request in the Web Performance Test.

The code assembly should reference the library, Microsoft.VisualStudio.QualityTools.WebTestFramework, and the class should inherit from Microsoft.VisualStudio.TestTools.WebTesting.WebTestPlugin and implement the PreRequest() or PostRequest() methods based on whether the code should execute before the request or after the request.

After running the test we will only see the success or failure result of the test, and the different parameter values handled in the test. To get the actual performance of the functions or method calls and the time taken for all the methods within the test, VSTS provides the option to create a performance session. This performance session uses the profiling tool that collects runtime performance data for the application.

Performance session reports various information such as method calls, memory allocations, and time spent in running the methods. To run the performance session:

Performance Explorer opens with the new performance session for the selected test. The explorer contains two folders, Targets and Reports. Targets is the applications under profiling. The Report folder contains the list of reports collected on every test run from the performance explorer.

Now launch the test application from Performance Explorer using the options in the explorer. This starts the application at the same time the profiler starts, collecting the execution data from the running application. We need to enter the details and browse through the application UI so that the performance profiler will collect the details up until we finish working with the application. At the end of completing the application run, the profiler produces a report, with all the information collected, by grouping them based on the functionality, as shown below. This is the default summary view of the report that shows the hot path that takes most of the CPU time during the run and the functions that are performing most of the work.

We can change the summary view to show different types of views like Call tree, Modules, Functions, Processes and so on, by selecting the different options given in the toolbar or using the link provided under the reports section in the summary view. The result can be exported for further analysis.

Performance Explorer also provides options to set or change different properties of the profiling. We can change the type of profiling and the data to be collected during data collection like clock cycles, page faults, system calls, and performance counters. We can also set properties for CPU Counters, Windows Events, and Windows Counters.