After recording all the requests, click on the Stop option in the Web Recorder pane which stops recording and closes the browser window. Now the Web Test editor window opens and the recorded details are shown in the Web Test editor window as follows:
The editor shows the tree view of all the requests captured during recording. The Web Test editor also exposes different properties of requests and the parameters for each request. Using the editor, the Properties, Extraction, and Validation rules are set for the web test and the requests. There are different levels of properties that can be set for the recorded requests using the WebTest editor as follows:
- Setting properties at the WebTest root level applies to the entire web test. For example, setting user credentials and giving a description to the test.
- Setting properties at the request level applies to the individual requests within the web test. For example, timeout, think times, and recording results properties on each request level.
- Properties for request parameter apply to the requests using HTTP-POST or HTTP-GET protocol. Each parameter in the request contains properties, such as URL encodes, value, and name.
- Extraction and validation rules are set for the responses to make sure the request gets the expected results and are validated.
Apart from all these, the WebTest editor has a toolbar that provides different functionalities, such as running the test, adding a new data source, and setting the credentials and parameters which are explained in detail in the coming sections.
The following are the properties that can be set for a web test using the editor:
|
Property |
Description |
|---|---|
|
Description |
Specifies the description for the current test. |
|
Name |
The given name for the current web test. |
|
User Name |
Specifies the name of the user for this test, if predefined users credentials are to be used, then this is associated with the data source of any type such as a CSV file, XML file, or a Database. A parameter defined within the web test also can be used for user name. |
|
Password |
Specifies or associates the password that corresponds to the user in the Username field. |
|
PreAuthenticate |
This is a Boolean field, which indicates whether the page has to be authenticated on every request or not; only if this property is set to |
|
Proxy |
In some cases, the requested web pages in the test might be outside the firewall which has to go through the proxy server; this field is to set the proxy server name to be used by the test. |
|
Test ID |
The autogenerated, unique ID to identify the test. This ID is generated while creating the test; this can be used to define the test in coded web test. This property gets the unique identifier when implemented in the derived class. |
|
Stop On Error |
Informs the application whether to stop the test or continue in case of any errors; if this value is |
The following screenshot shows the properties window for the web test file:
The following are the properties of the requests within the web tests. If you select any request from the tree view and open the properties, you can find these properties for each request:
Each request in the web test has its own properties, and each request may have many dependent requests. Properties can be set at the request level and even at the dependent request level. The properties are set based on the request submit method GET or POST used for the requests. The validation and extraction rules can be used to extract information from the request response.
These are the parameters sent along with the request if the method used for the request is POST. Recording of user actions in the form of web requests captures the actual values of the parameters that were sent during request and all the entries are sent to the server as Form POST Parameters.
- Name is generated dynamically during recording, and denotes the name of the component used for collecting the data.
- Recorded Value is a read-only field with the value assigned while recording.
- URL Encode is a Boolean value which is set to
Trueby default which determines whether the Name and Value of the parameter should be URL encoded or not. The default isTrue. - Value is the actual parameter value which is set to the same value as the recorded value, but can be changed later. This property also has the flexibility to bind the field to a different data source, such as Database, XML file, or a CSV File which is useful in the case of testing with different sources of information and multiple runs with the different sets of data. The next section covers more on how to add the new data source and map the form fields to the data source fields.
The following screenshot shows the Middle Name field, without any value assigned to it because there wasn't any value assigned while recording. But the tester can change or provide a new value to this parameter by selecting the property and modifying the value field:
The set of properties varies based on the type of control used in the web page. For example, using a File Upload control may require the file type property to be set for the upload.
This is very similar to the Form POST Parameters. These query string parameters are listed under the request which uses the QueryString method for the request.
Setting properties values and usage of the QueryString parameters are same as the Form POST Parameters properties, except the additional property which is Show Separate Request Result. This is used for grouping the requests based on the value of this query string parameter. This is very useful for load testing for grouping a bunch of requests based on this field value. The default is False.
Normally in any web applications, most of the web forms are interdependent in which the request is based on the data collected from the previous request's response. Each request from the web client receives the expected 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 by using query strings or values persisted in the ViewState object or using the Hidden fields. Extraction rules are useful for extracting the data or information from the HTTP response.
The sample application has web pages for new employee creation, selecting existing employee information from a list, absence details of an employee, and a few other web pages. For example, the user selects an employee from the list of available employees to get the detailed information about that employee. In this case, once the user selects a particular employee from the list, there needs to be a validation and then the key values are passed to the next web request like EmployeeDetails page or Absence request or EmergencyContacts details.
The key information is hidden somewhere in the request using the ViewState object or the Hidden fields property of the web page. In this case, use the extraction rules to extract the information and pass it on to the next request. Extract the information and store it in the context parameter and use it globally across all the requests.
Visual Studio provides several built-in types of extraction rules. These rules are helpful in extracting the values based on the HTML tags or based on the type of fields available in the web form. Custom rules can also be built if the default set of rules are not sufficient to extract the information. The following are the existing extraction rule types:
The following table shows the extraction rule types, their description, and usage:
|
Rule type |
Description |
|---|---|
|
Extracts the value based on the tag name and assign the value to the context parameter. The Context Parameter Name and Tag Name are the properties for this option. | |
|
Uses the attribute name and the value parameter to find the exact match of the attribute and extract the inner text from that attribute. Very useful to extract the inner text from the specified HTML tag. | |
|
Extracts the attribute value from the request page based on the tag and the attribute name; uses the optional matching attribute name and value within the same tag to find out the required attributes easily; the extracted value will be stored in the context parameter. | |
|
Extracts the value from one of the form fields in the response page; the field name is specified here. | |
|
Extracts the HTTP message header value in the response page. | |
|
Extracts the value using a regular expression to find the matching pattern in the response page. | |
|
Extracts some text from the response page; the text is identified based on its starting and ending value with text casing as optional. | |
|
Extracts all the hidden field values from the response page and assigns them to the context parameter. |
The following screenshot is an example of using an extraction rule with a tag name. The screenshot shows the sample image added to the employee maintenance web pages. The image source is highlighted in the following code:
Add an extraction rule for the image that is present in the employee maintenance web page. The following screenshot shows how to set the properties of Extraction Rules. This extraction rule is created for a sample image used on the page. The extraction rule is created against the Attribute Value to find the image source URL used for the image and assign that to the context parameter:
Add as many rules as required, but you should make sure that Context Parameter Names are unique across the application. They are like global variables used in the application.
The following Test Run result shows that the test and the extraction rule are passed, as the matching attribute and the value is extracted from the response:
The Context details in the following screenshot show the extracted value from the web response and the same is assigned to the ImageSource context parameter:
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 QueryString parameters.
In coded web tests, custom extraction rule can be added by deriving from the ExtractionRule class.
Every application has some sort of validations 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 set against the fields.
Validation rules are nothing but the defining rules against the information passed through the requests and responses. All the data collected from the response is validated against the defined rules. The test passes only if the validation rules are satisfied, 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 predefined values list, then define these as validation rules and use those against the values returned from the response fields.
Visual Studio provides a set of predefined rules for validations. These rules are used for checking the texts returned by the web response.
For adding the validation rules, just right-click on the request and select the Add Validation Rule option which opens the validation rule's dialog box. Select the type of validation rule required and fill the parameters required for the rule, as shown in the following screenshot:
Keep adding as many validation rules as required. If the number of rules increases, the performance will degrade or the time taken for the test will also increase. Decide which one is important in case of load testing and then add the rules as required.
In all the above rule types, there is a special parameter known as Level that can be set to Low, Medium, or High. Use the Level property to control the execution of rules in a request during the load test. The level does not denote the priority for the rule, but it denotes when it should get executed based on the load test property. The load test also has similar property, such as Low, Medium, or High.
Based on the following load test property, the rules with the corresponding levels will run during the test:
- Low: All validation rules with the level Low will be run
- Medium: All validation rules with level Low and Medium will be run
- High: All validation rules with level Low, Medium, and High will be run
Based on the importance of the load test, set the level property of the rules.
Transactions are very useful in grouping a set of activities. One example is to group multiple requests to track the total time taken for the set of requests. This is also helpful in collecting the timing of individual requests.
To create the set for transaction, just select the starting request or item and the ending item so that all the requests inbetween will be a part of the transaction including these two items.
To add a transaction, select the starting request from where the transaction should start and then right-click and choose the Add Transaction option, as shown in the following screenshot:
The Transaction dialog box requires a name for the transaction, the request URL for the first item and the request URL for the last item of the transaction. When you choose both and click on OK, the transaction is added just before the first item selected for the transaction and all the other requests between the first and last item including first and last would be part of the transaction, as shown here:
When the test is run, the total time taken for all the requests under the transaction is also displayed as follows:
Similar to the extraction and validation rules, conditional rules can be added to the web requests to run the test based on the success or failure of the condition. This is the if/then logic added to the requests based on the parameter values. For example, a condition can be added to a web request to run only if the context parameter equals to a specified value.
Select the web request to which the condition should be added and then right-click and choose the option Insert Condition and then select the required rule from the list. The following image is to add the String Comparison rule to the request.
The condition is to verify if the context parameter Parameter1 is equal to the expected value to execute the request. If the condition fails then the request will not get executed during the Test Run. After adding the condition, the web requests will be like the one shown in the following screenshot with the if/then branch added to the request:
The web test request will not get executed because of the failure of the condition as the parameter is not the same as expected. The following result shows the execution of the condition and action based on the condition result:
The test passes but only the web request is not executed as the condition fails.
There are multiple other conditional rules which will be useful for the web test execution. The conditional rules are listed in the following table with descriptions:
There are a few other features, such as adding comments to the condition, adding requests to condition, adding transactions to condition, adding loops to condition, and adding another condition to condition. The condition rules can be added at any level in the web test. Based on the situation and requirement of the test execution, conditions can be utilized.
The Web Test editor comes along with a toolbar to configure the web tests. There are different options, such as adding a data source, setting credentials, adding a recording, adding plugins to the test, generating code for the web test, and parameterizing web servers.
Earlier sections of this chapter explained the usage of Form POST parameters and QueryString parameters, and setting the value of parameters using the property. Executing the test every time with a different set of data is a tedious process and it requires changing the parameter values every time. If the test is to be conducted with more number of users, it requires more time particularly in case of load and performance testing. Visual Studio provides the feature of adding a data source and binding the parameters to the data source so that the data is picked from the data source for test.
Visual Studio supports different types of data sources, such as CSV file, database, and XML file.
To add a new data source:
- Select the Add Data Source option from the WebTest editor toolbar which opens the New Test Data Source Wizard.
- Name the data source and select the type of data source (Database, CSV, or XML file).
- Selecting the database type requires a connection which uses the OLE DB, ODBC, SQL Server, or the Oracle data provider. For this example, select the CSV file as the data source and in the next screen select the CSV file from the file location. The following CSV file was created with all the details required for new employee creation and kept ready for the example:
- Once you select the file you can see the data in the Preview data grid.
- Select Finish so that you can see the data source added to the Test Project.
Any number of data sources can be added based on the requirement and sources of data for testing.
The following screenshot shows two data sources, CSVFileDataSource created using the CSV file and XMLDataSource created using the XML file:
Once the data source is added, change the source of the Form POST or QueryString parameter values. To do this, select the Form Post Parameter under the web request, then right-click and choose Properties. In the Value property, select the data source and select the corresponding field from the data source as follows:
You can see the value assigned to the Form POST parameter. The first name parameter is bound to the First_Name field in the selected data source as follows: {{CSVFileDataSource.EmpData#csv.First_Name}}
Bind all the other fields to the data source and run the test. At run-time, these field values are replaced with the exact value extracted from the CSV file and the Test Runs successfully.
This option is useful for setting specific user credentials to be used during the test instead of current user credentials. Apply this user credential to test the page, which uses basic authentication or integrated authentication. If the web requests needs to be tested with multiple users credentials and if the user credentials are stored somewhere, then use this as a data source for credentials and bind the credentials field to these data source fields.
Credentials are set using the option in the Web Performance Test editor toolbar. Click on the Set Credentials option and enter the User Name and Password values. If there is a data source already with these details, then click on the Bind... option and choose the data source and the data source field for the user credentials for the test page.
This option adds a new request recording to the existing test. Sometimes there could be changes to the web pages, or new pages could be added to the web application because of the requirement change. In this case, a new web page test needs to be recorded and added to the existing web test. On clicking the option Add Recording in the Web Performance Test editor toolbar, the recording window opens up for a new recording. Completion of the recording automatically adds the recorded requests to the existing web test recording. This is also one of the ways to edit the existing recording.
Usually the recording of web tests happens based on one particular system or server where the application is hosted. Sometimes while recording the actions, the web requests are captured along with server names or with default local host and port number. To run the same test in a different environment, all requests in the recording needs to be updated with the new server or system name or the recording needs to be redone with the new environment. To re-use the same recording across multiple environments, Visual Studio provides a feature called Parameterize Web Servers in which the web server name is changed dynamically by passing the parameter value to the requests.
This is very useful when the application is tested for load testing, performance testing, and integration testing where only the configuration changes.
To parameterize the web server in a web test:
- Select the Parameterize Web Servers option in the Web Performance Test editor toolbar. This option opens a dialog box that lists the different web servers used by the web test. The list contains the context parameter names and the web server URLs associated with the context parameter.
- Change the context parameter value to point to a different server by choosing the Change... option after selecting the context parameter name from the list. The new dialog box helps us to change the name and the web server URL.
- If you plan to use the local ASP.NET development server, choose the second option which says Use ASP.NET Development Server and provide the local website path and the application root.
- After changing the value, close the Parameterize Web Server dialog box and notice the context parameter added to the web test under the Context Parameters folder. The server address in all request URLs of the web test are replaced with this new parameter, and the value is held by the context parameter.
The following screenshot shows the web server parameter as WebServer1 to hold the server address:
Notice the context parameter used in the requests are within braces as in {{WebServer1}}, which is replaced by the actual value at runtime.
There are different ways of creating context parameters:
- Context parameters can be created by just right-clicking on the Context Parameters folder and selecting Add Context Parameter.
- The plugin can create the context parameter and assign the value in the event that runs before the web test.
For example, the following plugin assembly code creates a new context parameter for the current window, Country, and adds the parameter to the web test. The code also assigns the Country value to the existing Form POST Parameter field TextBoxCountry.
//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"]; }
When the web test is run, we can see the value assigned to the context parameter as well as the Country text box form post parameter.
We can also have the context parameter added to the web test at design time and assign the value at runtime using the plug-in.
A plugin is an external library or assembly created to include custom functionality which can run along with the web test. Each plugin gets executed during each iteration of the test. For example, collecting external information, such as the current username, time taken for the test, and any other calculation required during the test can all be part of the plugin class library.
The first step is to create the class library with a class containing the custom code. The class must 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:
PreWebTest(): This code will run before web test starts execution.PostWebTest(): This code runs after the completion of web testing.
After creating the class library and adding the custom code, compile the class library project. The PreWebTest method code collects the name of the user who has logged in and the test start date and time. The PostWebTest method calculates the total time taken for the entire test and then displays the value as a comment to the web Test Results section. The e.WebTest.Context contains the current context of the web test. The parameters and properties for the current context can be accessed using the e.WebTest.Context object.
The following screenshot shows the PreWebTest and PostWebTest methods and accessing the context properties using e.WebTest.Context:
Add this project reference to the Web Test project. Then select the Web Test project and choose the Add Web Test Plugins option from the toolbar which lists the classes within the assembly. On selection of the class, the class for the plugin gets added to the Test Project:
Now when the test is run, you can see the context variable added to each request's context.
The context variable created in PostWebTest method cannot be seen in the context variables section, as it displays only the pre web test activities. For the purpose of this sample, the total time taken context variable value is shown as a comment added to the Test Result, as shown in the preceding image.
There are few other methods exposed by the WebTestPlugin class other than the PreWebTest and PostWebTest methods, such as PrePage, PostPage, PreRequest, PostRequest, PreTransaction, and PostTransaction. All these methods are to add custom code to include functionality before and after the activities.