Testdata parameters

Visual Studio Load, Web and Unit tests have the ability to use context parameters. These parameters can be defined in a loadtest run settings and in a web/unittest and each user can have a unique set of parameters while running a test. Several plugins exist that can be used together in order to accomplish a model where data can be passed down from the load test into a test to be run and also passed back up from the test after completion in order to log values or dynamic extracted parameters.

Unit tests in loadtests

In order to use these plugins for Unittests, you need to add support for a TestContext property and check for the parameter before you use/try to read it. See the Snippets section for an example on how to use a ThinkTime parameter: Unit Test Think Time and Transactions example . There is also an example working unit test in the source code of TestProject1, called UnitTest1.cs

Loadtest plugins

LoadTest Context Copy

Used to copy context parameters defined in loadtest run settings into each test in the test mix. For example, you can create a test that uses a context parameter for the hostname of the request URL's, say "WebServer1". If you define the same parameter in the loadtest run settings (case sensitive) the value for the same parameter in the test will be replaced with the value defined in the loadtest, if the test is part of that loadtests test mix. This way, parameters in tests can be controlled by the loadtest they run in (any test that uses a TestContext for parameters). If the parameter does not exist in the TestContext for the test, it will simply be added instead. You can use this in order to check for the presence of a parameter and its value if needed in the test and for example turn on or off steps or parts of the test using Condition statements. Another common use is to control thinktimes, number of loops or iterations, turn on extra logging, and so on.

Set Test Context Parameters

This plugin sets context parameters in tests in the loadtest and uses a CSV file for input rather than the run settings in the loadtest. The file needs to be accessible with the same path on all agents. You can use a network share on the controller for example. The plugin has several features to control how data rows are selected, it can use several parameters on the same row (like a username with a specific password), it can automatically split the data between agents and has several options to uniquely select data based on iterations or virtual user id's. It can also create new csv files with only testdata that actually works with a test, so you can easely make test data runs that verify that your tests work functionally with each data combination prior to a real load test. You can let it run with a single set of testdata and verify multiple tests in the same run and each test will have its working data logged to a unique file.

Think Time Emulator 10/190

This plugin will create a parameter in all tests called ThinkTime, which is set to a random value between 10% and 190% of the provided base value. This will create more deviation of Thinktimes compared to the built in normal distribution in web tests, and will make this functionality available for unittests as well. This way, if a mix of unit tests and web tests are used in a load test, the same Thinktime algorithms and average values will be used within the tests. Since Unittests lack support for thinktime, the parameter can be used in a Thread sleep call instead.

Use in Unittests

See the Snippets section for an example on how to use a ThinkTime parameter: Unit Test Think Time and Transactions example . There is also an example working unit test in the source code of TestProject1, called UnitTest1.cs.

Use in Webtests

In order for Web Tests to use the generated ThinkTime value as the Think time for requests, the web test plugin "Set Request Think Time" has to be activated/added to each webtest (currently manually). All thinktimes on all requests will be set unless the original Thinktime is set to 0. The thinktime is randomized only once at the beginning of each test run and used throughout the entire run.