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:

  • Visual Studio Team System
  • Visual Studio Team Edition for Software Testers
  • Performance Testing

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
  • Summary of Steps
  • Step 1. Create a Load Test Containing One or More Web Tests in a Test Mix
  • Step 2. Verify All Web Requests Where Dynamic Data Exchange Should Take Place
  • Step 3. Define the Characteristics of the Data to Be Parameterized
  • Step 4. Create a SQL Table in the Database Containing the Data Values
  • Step 5. Create the Data Source and Bind It to the Form Field or Query String in the Web Test
  • Step 6. Run a Manual Web Test to Validate if the Data Binding Is Correct
  • Step 7. Run a Load Test and Validate if Data Binding Is Correct

Objectives

  • Learn how to design correct data binding to meet specified business requirements.
  • Learn techniques for data binding in Visual Studio 2005.
  • Learn how to perform data binding using a SQL data source.

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:
  • Query string parameters. These are the strings appended to the URL, typically configuring an item selection. The figure below shows a hypothetical example of a query based on the product ID in a query string for different users, after a user logs on to the Web site and searches for product information. In this example, each user is searching for a different product.

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]
  • Form post requests. These are the Web form input fields in which users log in and enter a password, product name, or any other data selection from the Web application user interface (UI). The figure below depicts a hypothetical Web site where the user enters his or her user name and password

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]
  • Parameter consumption in coded Web tests. Data-bound values from data sources are available during run time in coded Web tests that can be programmatically consumed to meet business scenarios, which may require manipulation during run time. For example, URLs can be replaced during run-time execution where a large number of identical sites are deployed by an Internet service provider (ISP). Another scenario would be a data-bound value that needs to be programmatically altered before being submitted to the Web site; for example, an order ID or customer ID that needs to be incremented after it has been used in a previous request or configuring a data value that is supposed to be associated to an existing value, a globally unique identifier (GUID), or an encryption key.
  • Web site credentials. These are the credentials submitted in authenticated Web sites in ASP.NET scenarios.
  • Web services. Method values in the Simple Object Access Protocol (SOAP) body of Web services requests can be parameterized with the same functionality as form field parameters, constituting a business scenario when testing Web services.

Summary of Steps

  • Step 1. Create a Load Test Containing One or More Web Tests in a Test Mix
  • Step 2. Verify All Web Requests Where Dynamic Data Exchange Should Take Place
  • Step 3. Define the Characteristics of the Data to Be Parameterized
  • Step 4. Create a SQL Table in the Database Containing the Data Values
  • Step 5. Create the Data Source and Bind It to the Form Field or Query String in the Web Test
  • Step 6. Run a Manual Web Test to Validate if the Data Binding Is Correct
  • Step 7. Run a Load Test and Validate if Data Binding Is Correct

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:
  • Post parameters in Web requests: login, product IDs, etc.
  • Query strings in Web requests: product IDs, category IDs, etc.

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:
  • Data volume
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?
  • Data types. When defining data type characteristics, consider how many types of different products are to be processed to simulate the load test for the specified business scenario. For example, you might need to simulate the “place orders” scenario for a situation in which a specific product is announced in a marketing campaign. In this case, load testing a scenario where different users place orders for the same product over a period of time might cause different types of performance problems than those encountered when users browse and order a random range of products from the database.
  • Mode of data source access. Three modes of data source access are possible in Visual Studio 2005 when performing data binding. Each mode addresses different load test scenarios:
    • Random access. In random access mode, the data source is accessed randomly in an endless loop cycle. Typical business scenarios involving random access might include generating a load that does not follow any particular order, or creating requests where there is an uneven distribution of users for the data entries in the data sources—for example, an orders scenario where users are consuming product information about computers—so one specific data feed can be used in the load test. If multiple agents are used, each will receive a full copy of the data source, which does not guarantee that requests from different agents will be unique.
    • Sequential. In this mode, the data source is accessed sequentially in a loop cycle. Typical business scenarios involving sequential access might include generating a load that obeys a sequential request from the data source. If multiple agents are used, each will receive a full copy of the data source, which does not guarantee that requests from different agents will be unique.
    • Unique. In this mode, the data replacement uses unique values across the virtual users, even if there are several agents running the load test. In this case, each agent receives a unique copy of the data source. Certain applications (for example, databases) require the use of unique values. A value that was unique during recording is no longer unique for script execution. For example, in a business scenario simulating the process of opening a new bank account, each new account is assigned a unique number that is unknown to the user. This account number is inserted into a table with a unique key constraint during recording. If the account is not unique, a SQL exception occurs. The load test ends when all the data items are used by the virtual users. Scenarios where a load test needs to run for longer periods of time with unique data binding will require more entries in the database and consequently more agent resources for memory to run the load tests.

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:
  • If database production is available, restore a backup in a dedicated SQL server to act as data source repository.
  • Always use a dedicated SQL server that is separate from both the results test database and the test SQL server, as a data source repository.
  • Use database views to be able to correlate two different columns residing in different tables, in case they need to be used as if they were to be correlated in different sequential Web requests; for example, a user choosing a car manufacturer and model via different Web request posts.

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.
  • In the Web Test Editor, right-click the top node of your Web test and then click Add Data Source.
[image:DataBinding3.GIF]
  • In the Connection Properties dialog box, in the OLE DB Provider drop-down list, select SQL Native Client.
  • In the Server or file name text box, type the SQL server name or IP address.
  • In the Log on to the Server section, select either Use Windows NT Integrated Security or Use a specific user name and password for server authentication. If you select Use a specific user name and password: provide a username and password for SQL authentication.
  • In the Initial catalog: drop-down list, select the database containing the table with the values to be data-bound.
  • Click Test connection to check the connection to the SQL server.
[image:DataBinding4.GIF]
  • Click OK to close the Connection Properties dialog box. The Choose Tables dialog box containing the tables and data views appears.
  • Select the table or data view containing the data source values to be data-bound into the Web test request.
[image:DataBinding5.GIF]
  • Click OK to close the Choose Tables dialog box. A Data Sources node will be added to your Web test.
  • Expand the data source, right-click the table, and then in the Properties pane, select the data access method (Random, Sequential, or Unique), depending on your specific business requirement.
[image:DataBinding6.GIF]
  • After you have created the data source, expand the Web test request in the tree view. Right-click the relevant Form Post Parameters or QueryString Parameters that you want to be data-bound.
  • Click the value text box. The data source entry appears.
[image:DataBinding7.GIF]
  • Select the column value to be data-bound to the form field of the query string in the Web test request. At this point the value will be parameterized during load test execution.
[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.
  • In the Web Test Editor, double-click the Web test and then click Run, represented by the green arrow.
[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]
  • In the Web Test Editor, click the Edit Run Settings link.
  • In the Web Test Run Settings dialog box, select the One run per data source row option.
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.
  • In the Web Test Editor, click the Click here to run again link.
[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]
  • In the localtestrun.testrunconfig dialog box, select either One run per data source row or Fixed run count to set the data row count. Note that because this setting is global, it will apply to all Web tests that involve data binding to larger data sets and will cause delays in the execution of the Web tests.
[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:
  • Check the IIS logs for the values of post or query string parameters.
  • Check SQL Profiler traces when data is submitted to or read from SQL servers.

Resources

<<TBD>>

Last edited Mar 19, 2007 at 3:08 AM by prashantbansode, version 2

Comments

hcmehta Nov 6, 2012 at 4:31 AM 
It is really precious blog