Description of Access methods in data sources

This blog post will discuss the access methods of data sources. Data sources are used when you want to bind a field in your web test to a database, csv file, xml file, etc. For example you might have a database that contains a list of users for your system. If you add this database to your web test, you can then bind the usernames and password to your web test. This way each iteration of the web test will use a different username and password. Here is a help link on adding data sources to a web test:


The feature of data sources that I want to go over are the access methods. Access methods tell the web test how to fetch data from the data source. There are 3 access methods for data sources in web tests: Sequential, Random, and Unique. Here is a description of how each access method executes inside a load test.


Sequential – This is the default and tells the web test to start with the first row then fetch rows in order from the data source. When it reaches the end of the data source, loop back to the beginning and start again. Continue until the load test completes.


Random – This indicates to choose rows at random. Continue until the load test completes.


Unique – This indicates to start with the first row and fetch rows in order. Once every row is used, stop the web test. If this is the only web test in the load test, then the load test will stop.


This seems fairly straight forward when running the load test on a single machine. But what if you are running your load test on multiple agents? How is the data from the data source distributed if you are running on 3 agents?


Sequential – This works that same as if you are on one machine. Each agent receives a full copy of the data and each starts with row 1 in the data source. Then each agent will run through each row in the data source and continue looping until the load test completes.


Random – This also works the same as if you run the test on one machine. Each agent will receive a full copy of the data source and randomly select rows.


Unique – This one works a little differently. Each row in the data source will be used once. So if you have 3 agents, the data will be spread across the 3 agents and no row will be used more than once. As with one machine, once every row is used, the web test will stop executing.


I have seen a few posts indicating that they want to use the sequential access method, but don’t want each agent to execute all of the data. They would like to partition the data evenly across each agent. You can do this with a WebTestPlugin. Here is an example plugin which can be used to evenly distribute the data across the agents.


using Microsoft.VisualStudio.TestTools.WebTesting;

namespace Example


    public class DatasourcePlugin : WebTestPlugin


        static int counter = 0;

        public override void PreWebTest(object sender, PreWebTestEventArgs e)


            while ((counter++ % e.WebTest.Context.AgentCount) != (e.WebTest.Context.AgentId - 1))


                e.WebTest.MoveDataTableCursor("DatasourceName", "TableName");






In the above plug-in, I use some of the built in context parameters to move the data cursor to unique rows. I use the AgentCount and the AgentId to figure out which rows to use. This plugin performs modular division using the agent count and then compares that to the agent id. The modular division will return a value which is greater than or equal to 0 and less than the agent count. I then compare this to the agent id – 1. If these values are equal, then the plug-in returns. If the values are not equal, then I call MoveDataTableCursor. This method will move the data source to the next row. This loop continues until the modular division matches the agent id. The values passed into MoveDataTableCursor are the name of the data source and the name of the table in the data source.


Follow the steps in the following help link for creating a plugin:


Once you add this to your web test, change the DatasourceName and TableName parameters to match your test. Then your data should be evenly spread across each of the agents in you rig.


Hopefully this explains how the different data access methods work.