howtodatabindingvsnet2005

How To: Use Data binding in Load Tests in VS.NET 2005

Applies to:

VS .NET 2005
Performance Testing

Summary:
This How to will explain the process of using Data binding techniques in Visual Studio 2005 to create realistic load patterns during the execution of a Load Test.

Contents:

Objectives
Overview
Summary of Steps
Step 1 - Create Load test containing one or more Web tests in a test mix.
Step 2 - Define the characteristics of the data to be parameterized in the transactions to meet business scenarios.
Step 3 - Create the SQL table in database containing the data values.
Step 4 - Create the Data source and bind it to the form field or query string in the Web test.
Step 5 - Validate if the data binding is correct by running a manual Web test.
Step 6 – Run a Load test and validate if data binding is correct.

Objectives

Learn the importance of doing data binding to design realistic load tests.
Learn how to design correct data binding to meet business requirements.
Learn about the techniques of data binding in VS. NET 2005.
Learn how to do data binding using SQL data source.

Overview:
In Visual Studio Data binding in the process of parameterization of data in test scripts: in Web tests and coded Web tests dynamic data parameterization is used to realistically simulate user exchanging data and interacting with Web applications. Parameterization is the process of passing different data to the variables in Web requests so it can simulate how real users use the Web site. It is used to pass multiple values in the application for modeling the user behavior, avoiding the cache hit across different components in different tiers of the system being tested. Not accounting for dynamic data replacement in load testing may cause unrealistic performance results. Data binding is a critical component for designing load tests. Typically in each test iteration, when the test simulates a user session, will entail a transaction where a data value will need to be replaced during runtime. The following items can be replaced during runtime execution of a Load test.

Query String Parameters: they are the strings appended to the URL, typically configuring an item selection. Below is a hypothetical example of query performed based on product id in a query string for different users: after a user logs on the web site and searches for product information. Each user is searching for a different product during search.

Iteration
USER
SEARCH DATA
1
Bob
http://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=394
2
Mary
http://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=6897
3
Peter
http://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=389
4
John
http://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=3770
5
Joe
http://Dnnstore/StoreCSVS/ProductDetails.aspx?productID=3773
6
Chris
http://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.

Form post requests: they are the input web form fields that users enter, login, password, product name, or any other data selection from the Web application UI. Below is a depiction of a hypothetical Web site where user name and password are entered by the user.

Iteration
USER Login
Form post parameter
Email
USER Password
Form post parameter
password
1
Bob
Password1
2
Mary
Password2
3
Peter
Password3
4
John
Password4
5
Joe
Password5
6
Chris
Password6

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

Parameter consumption in coded Web tests: data bound values from data sources are available during runtime in coded Web tests that can be programmatically consumed to meet business scenarios, which may require manipulation during runtime. For example URLS can be replaced during runtime execution, where a large number of identical sites are deployed by an ISP. For How to data bind URLS refer to How to do databinding in a coded Web test to parameterize URLs. Another scenario would be a Data bound value that needs to be programmatically altered, before submitted to the Web site: an order Id or customer id that needs to be incremented, after it has been used use in a previous request or configuring a data value that is supposed to be associated to an existing value, a GUID or an encryption key.
Web site credentials: those are the credentials submitted in authenticated Web sites in ASP.NET scenarios. For how to do data binding in authenticated Web sites refer to How to do databinding to parameterize Web credentials in authenticated scenarios
Web services: method values in soap body of Web services requests can be parameterized, with the same functionality as form field parameters, constituting a business scenario when test Web services. For how to do data binding in Web services refer to How to do databinding in Web services testing

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 your individual Web tests that reflect key business user scenarios. Then create a Load Test, to which you will add your Web tests. While creating Load Test you can set many runtime properties to generate desired load simulation, for example you can specify the load pattern, browser and the network types and add the performance counters to be monitored. For more information on creating load tests please refer "How To: Create a Load Test Using VS.NET 2005" at << to link to how to >>

Step 2 - Define the characteristics of the data to be parameterized in the transactions to meet business scenarios.
Define the data characteristics for the data to be parameterized in the Web test form field or query string to be replaced during runtime. This data definition will meet the requirements for the business scenario that the Web test is simulating. Important considerations of data definition characteristics:

For each step you should define the data inputs and outputs for each step in a table:

Scenario Step
Data Inputs
Data Outputs
Log on to the application
Username (unique)
Password (matched to username)

Browse a product catalog
Catalog Tree/Structure (static)
User Type (weighted)
Product Description
Sku#
Catalog Page Title
Advertisement Category
Search for Specific Product
Unique Product Id’s (random)

Product Description
Sku#

Add items to the shopping cart
Product Descriptions
Sku#
Quantity of items in cart
Product Description
Sku#
Cart/Checkout Process Step
Calculated Subtotal
Validate credit card details
Card Type
Credit Card #
Expiry Date
Name on Card

Status
Cart/Checkout Process Step
Calculated Subtotal
Place an order

Confirmation Message
Cart/Checkout Process Step

Data volume: how many data items are to be created in the data source; data feed sizes will have a performance effect on both server and machines that are generating the Load test. Bigger 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. Also it will have impact on performance results, since IIS and SQL will cache the data sent from Web test requests. For example important considerations need to be addressed: how many orders for regular and peak loads will need to be simulated so different products will be created in the data source? How many users will logon to the Web site for regular and peak loads?
Data types: how many types of different products are to be processed to simulate the load test for the business scenario; for example, there might be a key business scenario to simulate the place orders scenario when one specific product is announced in a marketing campaign. In this case the load testing effects to request and place order for the same product over a period of time across different users might cause different types of performance problems than when users are browsing and ordering a random range of products from the database.
Mode of Data source access: There are three modes of data source access in VS.NET 2005 when doing data binding and they address different load test scenarios:

o Random access: the access will happen randomly in the data source endlessly in a loop cycle. Typical business scenarios are generating load not obeying any particular order, creating requests where users are unevenly distributed for the data entries in the data sources; for example orders scenario where users are consuming product information about a computers, so one specific data feed will be used in the load test. If multiple agents are used, each one of them will receive a full copy of the data source not guaranteeing that requests from different agents will be unique.
o Sequential: The access will happen sequentially in the data source endlessly in a loop cycle. Typical business scenarios are generating load obeying a sequential request from the data source. If multiple agents are used, each one of them will receive a full copy of the data source not guaranteeing that requests from different agents will be unique.
o Unique: The data replacement will happen using unique values across the virtual users, even if there are several agents running the load test. In this case each agent receives 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, there is a business scenario simulating the process of opening a new bank account. Each new account is assigned a unique number which 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 then a SQL exception occurs. The load test ends when the all the data items are used by the virtual users. For scenarios where load test is needed 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 3 - Create the SQL table in database containing the data values.
Create a table in the database with the columns containing the values that will be bound to the Web test requests during runtime. The data traversing 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 because they happen in the same test iteration. For example one Web test request may be posting the category of the product, while a subsequent Web test request may be posting the product id for that category. If in the same test iteration is needed to use two bound values in different Web test requests then those need to be residing in the same row in the database. It is common correlated data binding in different Web test requests when the second value is dependent on the first one. A typical example is web sites selling cars where first there is a choice of model then make of the vehicle. Another option to address correlating data bound in subsequent Web test requests, is to create database views from two or more tables with join statements. This is particular useful when production databases already contain test data. When doing data binding is always recommended to use SQL server separated from the SQL server being testedc1.

Step 4 - Create the Data source and bind it to the form field or query string in the Web test.
This is the process of creating a data source inside the Web test. Data sources in Web tests need to point to existing databases. Right click on the root node of the Web test or click on the icon Add data source

Connection properties will open select the following properties:

Ole DB provider: the provider name for SQL is SQL native.
Server or file Name: the SQL server name or IP address.
Use Windows Server authentication or SQL. If SQL provide username and password.
Initial catalog: the database name containing the table with the values to be data bound.
Click on Test connection to check connection to the SQL server.

		 Click Ok and the tables and data views will be displayed. Select the one containing the data source values to be data bound into the Web test request..

At this point the Data source is created. Right click on the table name and in the property pane select the data access method (random, sequential, unique), depending on your business requirement.

After having created a the Data Source expand the Web test request in the tree view. By clicking on value text box the data source entry will appear.

Select the column value to be data bound to the form field of query string in the Web test request. At this point the value will be parameterized during load test execution.

Step 5 - Validate if the data binding is correct by running a manual Web test.
Validating the Data binding by running Web tests manually should be always done because it is more difficult to debug load tests. It is also a procedure to allow graphical views of the Web pages with the data bound values. There are two possible practices for validating Data binding runs in Web tests.

Double click on the Web test and click on run

One single run for the first row in the database is executed. At this point is needed to configure the Web test run to execute for the data base row count or any other count number.

Click on Edit Run Settings and check the option One run per data source row. This change of settings will only affect the run settings for this particular run. Validating data bind values when data sources contain larger data sets can be time consuming. Another option is to reduce the run count for a smaller subset validating thus the test run. Click on Click her to run again.

The Web test now will execute for every data row in the database. By clicking on the Web test request where the data bind was done it is possible to see the values being parameterized.

Another option is to set the execution of the Web test on a data row basis globally. Click on test Edit Test Run Configurations your test configuration.

Adjust to the One run per data source row or data run count. This setting is global and for the remaining of Web tests that are doing data binding to larger data sets will cause delays in the execution of the Web tests.

Step 6 – Run a Load test and validate if data binding is correctc2.