Being able to make use of appropriate test data is integral to running successful performance tests. From making sure each Virtual User has its own set of credentials to log in to your application, to providing them with a list of variables to arbitrarily choose from, eggPlant Performance has you covered. But, there are two different ways of adding this data to your tests, so which is the right one? Read on to find out more!
Test Level Data
As the name suggests, Test Level Data is data that is accessible to all VUs in a test (by default). If you open up the Test Level Data tab when you select a test, you will notice that there are actually two distinct panes within this view: the first is for the In-line Data Dictionary and the second for Data Source Bindings.
The In-line Data Dictionary allows you to assign simple Key=Value pairs to the test as a whole. This can be convenient for certain test-wide variables, such as the hostname of a server (which might vary between test environments) or boolean flags for triggering extra debug output in your scripts. The In-line Data Dictionary essentially just removes the need to create a physical Data Source Dictionary with the Key=Value pairs inside of it; one can quickly see a test’s settings simply by opening the Test Level Data tab.
The Data Source Bindings pane is where you would link to an actual Data Source file. Data Sources linked at the Test Level operate on a one row per VU basis; there is simply no way of assigning more rows per VU. This makes Test Level Data the most appropriate choice for data that should be unique to each VU. The prime example here is usernames (but there are likely other types of test data that benefit from this one-row-per-VU restriction): adding a data file at the Test Level ensures that no other VU will ever receive the same data.
Data Source Bindings added at the Test Level can still be modified to only become accessible to particular Groups within the Test, however when this level of granularity is needed, it is often more benefical to instead simply make use of Group Level Data owing to the greater flexibility given over how data can be assigned to the VUs.
Group Level Data
As soon as you need to make more than one row of data available to your Virtual Users, you must use Group Level Data. Here, you can assign not only multiple rows per VU, you can also define the order in which these rows should be accessed (sequential or random), as well as what should happen when the data is exhausted (the default policy is for the rows to be recycled). The “Start Row” can also be modified, and if needed you can even disable the automatic row advancement that takes place on each iteration, replacing it with logic defined somewhere in your scripts.
Use Test Level Data for…
=> assigning unique rows to each Virtual User in your test (e.g. usernames & passwords)
=> assigning test-wide Key=Value pairs that are prone to frequent change as an alternative to creating Data Source files (these variables are available to all VUs)
Use Group Level Data for…
=> more granular control over the test data (assigning multiple rows per VU, modifying the order in which rows are accessed)
=> manual control using script code
For more information, check out the Parameterization article in the documentation or simply ask your questions here!