pnp.GIF

How To: Use Data Binding in Load Tests in Microsoft Visual Studio Team System

J. D. Meier, Carlos Farre, Prashant Bansode, Scott Barber

Applies to:

Summary

When running a Web test as part of a load test, you can use data binding to let a database serve as the source for the user inputs to the HTTP request in the Web test Data binding is the process of binding data from a data source to a part of a Web request that requires data, such as a Form POST parameter. This How to explains the process of using data-binding techniques in Visual Studio Team System to create realistic load patterns during the execution of a load test.

Contents

Objectives

Overview

In the Visual Studio context, data binding is the process of parameterizing data in test scripts. Parameterization is the process of passing different data to the variables in Web requests so that it can simulate how real users use a Web site. In Web tests and coded Web tests, dynamic data parameterization is used to realistically simulate users exchanging data and interacting with Web applications. Parameterization is used to pass multiple values in the application for the purpose of modeling user behavior, while avoiding hitting the cachecaching across different components in different tiers of the system being tested, which would not happen in regular production operations. Not accounting for dynamic data replacement in load testing may cause unrealistic performance results. Data binding is a critical component of load test design. Typically, in each test iteration, simulation of a user session will entail a transaction where a data value will need to be replaced during run time. The following items can be replaced during run-time execution of a load test:

IterationUserSearch data
1Bobhttp://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=394
2Maryhttp://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=6897
3Peterhttp://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=38
4Johnhttp://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=3770
5Joehttp://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=3773
6Chrishttp://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=1918


In the Web request from a recorded Web test, we have a tree view with the query string productID.

[image:DataBinding1.GIF]

IterationUSER Login Form post parameter email USER Password Form post parameter password
1BobPassword1
2MaryPassword2
3PeterPassword3
4JohnPassword4
5JoePassword5
6ChrisPassword6


In the Web request from a recorded Web test, we have a tree view with the form post parameters email=Bob and password=Password1.

[image:DataBinding2.GIF]

Summary of Steps

Step 1. Create Load Test Containing One or More Web Tests in a Test Mix

First, create a test project that will contain your load test and Web tests. Then, create individual Web tests that reflect key business user scenarios. Finally, create a load test to which you will add your Web tests. While creating the load test, you can set many run-time properties to generate desired load simulation; for example, you can specify the load pattern, browser, and network types and add the performance counters to be monitored.
For more information on creating load tests, refer to “How To: Create a Load Test Using Visual Studio 2005” at << to link to how to >>

Step 2. Verify All Web Requests Where Dynamic Data Exchange Should Take Place

In this step, details of data exchange at each Web request of the test script should be traced for data consumption in the application. This could be achieved after recording the user interaction with the application. Look for the following traceable data items:

You can use SQL Profiler to analyze data exchange with the application if data is read or written to a Microsoft SQL Server™ database. To do so, run a simulation of one user scenario while trace data is being collected.

You can also analyze Microsoft Internet Information Services (IIS) logs to analyze data exchange with the application. To do so, run a simulation of one user scenario while trace data is being collected.

Step 3 - Define the Characteristics of the Data to Be Parameterized

In this step, you define the data characteristics of the data to be parameterized in the Web test form field or query string to be replaced during run time. This data definition will meet the requirements for the business scenario that the Web test is simulating. Important considerations for data definition characteristics include:
Determine the data volume needed to simulate the scenario. How many records are moving throughout the end-to-end transaction? How big are the queried results sets? How much unique data will you need to feed the automation for the testing scenarios in order to emulate real-world conditions?
The data volume will determine how many data items need to be created in the data source. It is important to remember that data feed sizes will have a performance impact on both the server and the machines that are generating the load test. Larger sizes will imply better client machines, because there will be more memory pressure on the agents generating the load. Before initializing the load test, the data feeds are sent to the agents and cached for performance purposes. Data feed sizes will also impact performance results because IIS and SQL will cache the data sent from Web test requests. Important considerations need to be addressed; for example: How many orders will need to be simulated for regular and peak loads so that different products will be created in the data source? How many users will log on to the Web site for regular and peak loads?

Step 4. Create a SQL Table in the Database Containing the Data Values

In this step, you create a table in the database with columns containing the values that will be bound to the Web test requests during run time. The data row fetching in the database happens per test iteration. Two different values from distinct columns in the same row can be bound to different Web test requests in the same test iteration. For example, one Web test request may post the category of the product, while a subsequent Web test request may post the product ID for that category. If in the same test iteration is needed to use two bound values in different Web test requests, these need to be extracted from the same row in the table. If the values are in different tables you can use a database view joining the two different tables. It is common to use correlated data binding in different Web test requests when the second value is dependent on the first one. A typical example would be a Web site that sells cars, where the user is first offered a choice of manufacturers and then a choice of models.

Consider the following key points when creating data sources:

Step 5. Create the Data Source and Bind it to the Form Field or Query String in the Web Test

In this step, you create a data source inside the Web test. Data sources in Web tests need to point to existing databases.
[image:DataBinding3.GIF] [image:DataBinding4.GIF] [image:DataBinding5.GIF] [image:DataBinding6.GIF] [image:DataBinding7.GIF] [image:DataBinding8.GIF]

Step 5. Run a Manual Web Test to Validate if the Data Binding Is Correct

It is important to validate the data binding by manually running Web tests because it is more difficult to debug load tests. This procedure also allows graphical views of the Web pages with the data-bound values. There are two possible approaches to validating data binding runs in Web tests.
[image:DataBinding9.GIF]
At this point, a single data value will be replaced from the database, with one test iteration being executed. Additionally, you can increase the number of data rows that will replace and then validate a higher number of iterations for data binding.
[image:DataBinding10.GIF] This change of settings will only affect the run settings for this particular run. Note that validating data-binding values when data sources contain larger data sets can be time-consuming. Another option is to reduce the run count for a smaller subset, thus validating the test run. [image:DataBinding11.GIF]
The Web test now will execute for every data row in the database. By clicking the Web test request where the data binding was done, it is possible to see the values being parameterized.
[image:DataBinding12.GIF]
Another option is to globally set the execution of the Web test on a data row basis. To do this, select Test from the main menu of visual studio and then click Edit Test Run Configurations.
[image:DataBinding13.GIF] [image:DataBinding14.GIF]

Step 6 – Run a Load Test and Validate if Data Binding is Correct.

In this step, you validate the data binding during the execution of a load test. You can use either of the following procedures for data binding validation:

Resources

<<TBD>>