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.

Read more

Read moreLess
When you start a load test, ReadyAPI generates multiple virtual users going through the test steps simultaneously.

Test Suite, Project, and Global properties are shared between all the virtual users. When you modify a property value in a test case, each virtual user will modify the value when simulating the test case. It causes the value to change multiple times during a load test, which leads to unpredictable behavior and errors.

Also, each virtual user exists in a separate thread that uses its own context containing information on test case properties. ReadyAPI reads data from the context much faster, that is why storing data in the test case custom properties improves performance of your load test.
Do not use the Run Test Case test step.

Read more

Read moreLess
The Run Test Case test step is not designed for load testing. Because of test step specifics, load tests based on test cases with this test step are not stable and can work incorrectly. We do not recommend that you use this test step in load tests.

Enable sharing for the Data Sources and DataGen test steps.

Read More

Read MoreLess
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:

Click the image to enlarge it.

To stop the load test after 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.

Read More
Read MoreLess
When you run a load test with Data Sink, by default, each virtual user that ReadyAPI Performance simulates will have a separate copy of 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:
  
  Click the image to enlarge it.
  
  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 that 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:
1. In ReadyAPI Test, open the functional test on which your load test is based.
2. In the Navigator panel, find the needed test case and its Data Sink.
3. Open Data Sink and click in the Data Sink editor.
4. In the Data Sink Options dialog, select Shared:
  
  Click the image to enlarge it.
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.

Read more

Read moreLess
During a load test, the scripts in the target test cases may behave differently as compared to functional tests. Each virtual user runs its own instance of a test case, and therefore, the script in it. So, they most likely will be run in parallel. Besides that, the set of scripting objects available for the script is different. That is why, you must prepare your scripts before using them in load testing. To learn how to do that, see Scripting for load tests.

Preparing Functional Test Cases for Load Test

See Also