Load tests are based on functional test cases. Usually, you create a functional test case simulating real user behavior. But, not every functional test can comply with load testing specifics completely. To adopt a functional test for load testing, follow these recommendations:
Use Test Case custom properties rather than Test Suite, Project, or Global ones.
Do not use the Run Test Case test step.
Enable sharing for the Data Sources and DataGen test steps.
By default, each virtual user will use an individual copy of the data source. Set the Shared option of Data Source test step to force all users to use the same copy of the data source. This will exhaust it much faster. Set the Restart Shared option to restart shared data source after it was used and continue the load test. You can configure the relative options directly in the ReadyAPI Performance:
To stop the load test after the data source has been exhausted, set the Fail on Empty option. See Data Source Test Step.
For the DataGen test step, you can choose which properties should be shared between virtual users. For example, if you use the generated property with the Number type to create unique IDs, select the Shared check box to make them unique. You can then use a different value from DataGen without selecting the Shared check box. This value will be the same for all the users. See DataGen Test Step.
Share the Data Sink test step.
When you run a load test with Data Sink, by default, each virtual user that ReadyAPI Performance simulates will have a separate copy of the used Data Sink. Depending on the storage type you use, this will have the following effect on the test:
JDBC or Data Connection – All test cases will write data to the same database in parallel.
File or Excel – All virtual users will write data to the same file. This may cause concurrency or IO errors. To avoid possible issues, you can share the data storage or configure the test case to write data to a unique file. To do the latter, you can add a context variable to the target file name:
The variable will have unique values for each virtual user (or thread) running the test case. Select the Append check box to add data to the end of the specified file and not to overwrite previous results with new results.
Property – The property will store unique values for each virtual user that runs the test case.
Groovy – You configure your scripts to handle the Data Sink storage as you need.
Note
We do not recommend using Groovy data sinks in load tests because many parallel threads may handle writing to a file incorrectly which will cause errors.
There can be situations when you want to change this default behavior and gather data from all virtual users running your load tests to a single Data Sink storage. For example, you may want the virtual users to write data to the same Excel file during the load test run.
To do this, share your Data Sink storage:
In ReadyAPI Test, open the functional test on which your load test is based.
In the Navigator panel, find the needed test case and its Data Sink.
Open Data Sink and click
in the Data Sink editor.In the Data Sink Options dialog, select Shared:
Now, when you run your load test containing a shared Data Sink storage, all virtual users in the test will use the same Data Sink storage instance.
Prepare scripts in the target test cases.