Using Databanks in LoadNinja Tests

Last modified on May 05, 2021

Why use databanks in tests?

By default, LoadNinja simulates script events by using hard-coded parameter values, the ones you specified during script recording or editing.

To get larger coverage and to check how your web application works with different input values, you need to associate a databank (a file containing the data you want to input) with a script. LoadNinja will read it row by row, and will run test commands for each row in that databank. Such tests are called data-driven load tests.

Databank formats

  • The databank must be a CSV or TXT file, with either commas or tabs as a value delimiter. The first line may contain column headers.

    If a value contains a comma, you need to add quotes. If a value contains a quote, you need to duplicate it.

  • In order for LoadNinja to use the databank, the latter should not contain cells with empty values.

  • If you have column headers in the first row of the databank, then the number of values in each of subsequent rows should not exceed the number of headers.


Attach a databank with a test

In LoadNinja, you can create UI tests and API tests. The ways you add databanks to your test are similar for both test types. However, there is a difference in mapping databank values to parameters of test events (UI tests) or requests (API tests):

Note: Databanks are not shared among tests. To use the same databank in another test, associate it with that test separately.

How it works in LoadNinja

To create a data-driven load test in LoadNinja, attach databanks to individual scripts that your load scenario will run. Then, map databank columns to event parameters as explained above.

LoadNinja supports this type of parameterization for the Keyboard Input events, Select Input events, and web page URLs.

During the load test execution, each script will typically run several times. For each iteration, LoadNinja will pick a databank row and insert column values from this row into event parameters:

Data-driven testing with LoadNinja: Using data rows in test iterations

Click the image to enlarge it.

How LoadNinja picks values from the databank

By default, LoadNinja picks databank rows randomly. To change this behavior, go to the script recorder  Settings and change the value of Run Databank Rows:

Run Databank Rows setting

Click the image to enlarge it.

Possible options are —

Value Description
Random Default value. LoadNinja will pick random data rows from the databank for each iteration and each virtual user.
During the load test run, there is a possibility that multiple users will use the same data at the same time.
Depending on the number of iterations and the number of rows, some rows are used more or less frequently than others. If the number of iterations is significantly larger than the number of rows, each row will be used approximately the same number of times.
Sequential For each virtual user, LoadNinja will pick data sequentially for each iteration, that is, the first iteration of a virtual user will use the first databank row, the second iteration will use the second databank row, and so on.
Each virtual user processes the databank on its own, so it means that multiple virtual users may be using the same data at the same time.
Unique At any given time instance, LoadNinja will pick unique data rows for virtual users, so they will never use the same data at the same time.
The number of databank rows should be equal to or greater than the number of virtual users that will run this load test.


  • LoadNinja loads data from the data file to your test when you are attaching the databank to the test. It doesn’t refresh data from the file later. For example, it doesn’t load them before the test run.

    To update a databank, delete it and append anew.

  • Databanks are not shared among tests. If you want to use the same databank in another test, attach it to that test separately.

  • A test can have up to 4 databanks attached to it.

Note: Databanks are not shared among tests. To use the same databank in another test, associate it with that test separately.

See Also

Typical Use Cases

Highlight search results