This chapter is the continuation of the previous chapter, which explained web testing. There is another way of performing web testing using Visual studio 2010. We have seen the recording of the testing scenario as explained in Chapter 5, Web Performance Testing, which explained web performance testing in detail. After the recording is completed, we can generate the code for the same tests using the Generate Code option in the Web Performance Test toolbar. Without using this option, we should be able to create the code by creating a new class file and using the namespace, Microsoft.VisualStudio.TestTools.WebTesting, which contains all the classes required for creating the web performance test. However it is too complex to create the test as compared to generating the code from the recording. Whether it is generated code or normal web testing using the user interface, the testing is the same. The only advantage is that we can customize the testing by using the .NET Framework language. This chapter concentrates on creating the code from the recorded test and customizing it. This chapter covers the overview on the following topics:
- Dynamic parameters in Web Performance Testing
- Creating the Web Performance Test by code in Visual Studio 2010.
- Debugging coded Web Performance Test
- Custom rules to be added to the Web Performance Test
Most web applications generate data dynamically and send it via the Query String Parameter or Form Post Parameter to subsequent requests. For example, the current user session ID, and connection string or parameter values to the called method are some of the dynamic data. Web Performance Test can identify and detect these dynamic parameters from the request response and then bind it to the other requests. This process is also known as Promoting Dynamic Parameters.
Dynamic parameters are automatically detected by Web Performance Test after the Web Performance Test recording is complete and stopped. Visual Studio Web Performance Testing keeps track of the requests and finds the hard coded values, which can be replaced by dynamic parameters. The advantage of using dynamic parameters is that we can pass different values to the parameter and verify the test. The other reason is to avoid playback failure. If we don't promote the dynamic parameters, the playback of the test may fail as the parameter values would still have the same values captured during the recording and the record would already exist in the system, or may not satisfy the current test condition.
Once Web Performance Test recording is complete, all query string values used in the web page during testing are hard-coded in the recording. So, if the values that are hard-coded are not valid during the playback of the test, then the test will fail. So the Visual Studio Web Performance Test provides the feature to extract new values from the request and use these in the dependent requests. This is the same extraction rule we saw in Chapter 5. But in this case, it is automatically added by the Web Performance Test. At the same time, the parameters are also added to the subsequent request.
For example, the following screenshot shows the recording of the web site, which has obtained the links to the absence and emergency contacts page by passing the query strings, and the session ID that keeps changing every time the test is run.
When the recording is stopped, we can see the dialog saying Detecting dynamic parameters.... During this time, all the values that can be changed to a Web Performance Test parameter are detected and listed on the next screen.
Visual Studio lists the parameters that can be promoted to Web Performance Test parameters from normal hard-coded values and gives the choice to the tester who is recording the test. Either we can choose OK to promote the parameters, or we can Cancel the suggestion and keep it hard-coded. But if we leave the parameters as they are, the next playback of the test might fail because of the hard-coded value which may not be valid.
Visual Studio also provides the option for detecting dynamic parameters outside of the recording. It means that we can find the parameters, which can be promoted to Web Performance Test parameters after completing the recording of the test. The Web Performance Test toolbar also has this option to find out the dynamic parameters.
Now let's add an extraction rule to the web request to find the EmployeeID passed on to the request from the previous page. Before adding the rule, we need to check the format of the Employee ID which passed on the request so that we can set the extraction rule according to that. Select the Request from the Web Performance Test result details pages and check the Response tab and search for EmployeeID.
The query string EmployeeID will be highlighted where it contains value 186 as per the preceding image. Now let's add an extraction rule to find the value passed for EmployeeID and name the new parameter as ExtractID.
The extraction rule added to the recorded web request extracts the text value from the query string and assigns it to the parameter.
After saving the request, when the recorded test is run again, the test result details will show the value extracted for the new context variable ExtractID which is shown under the Context tab as shown in the following screenshot:
