1. Understanding load testing
The purpose of functional tests (such as the tests done in SoapUI) is to answer the question Does it work?. The purpose of a load test is to answer the question Does it perform (while still working)? This is a quite general question, that can be divided into a few more specific questions:
||Does it work fast?
||Does it work fast under the expected pressure?
||At what pressure does it stop working? Does it recover well?
||Does it work for a long time, while under the expected pressure?
Remember: If you can't break it, you don't understand it!
2. Gather requirements
Even if you don't have any formal requirements set by the product owner, it's always good to think about requirements before starting testing. These articles are good places to start:
3. Exploratory testing
Get to know the system under test! Start by simply connecting a Fixed Rate Generator to a Runner and run the test. Change the user arrival rate and see how the TPS and Time Taken statistics are affected. If you're not sure how to do this, refer to:
4. Design and run a test
If you've never created a load test before, I recommend that you start with the Your first load test tutorial. My recommendation is to start simple - you can strive for more realistic and valuable tests later.
5. Find the bottleneck
If you can't achieve the load that you want, how can you know if it's the SUT or your own testing system (your computer and agents) that's holding the load back?
- Is Sent requests higher than Completed requests (this will result in a growing number of Running and Queued requests)? Then the SUT is the bottleneck.
- Is Sent requests lower than it should be (according to your Generator components)? Then your testing system is the bottleneck.
5.1. Monitor SUT
If your SUT is the bottle neck, you probably want to know why - is it the database, the CPU or the network? Or something completely different? To find out, you should monitor your servers.
5.2. Distribute testing system
If your testing system is holding your back, it's time to distribute it.
6. Automate test runs
Now that you have a load test, you want it to run automatically (on every new build, on every night, etc.). However, before you do this, it's good to archive a baseline result.
7. Make the test more realistic
In real-life, users doesn't arrive exactly X times a second or always login, wait X seconds, purchase, wait X seconds, logout. Here are some of the ways that naïve load tests differs from realistic user behavior:
||Real user behavior
||Random (exponentially distributed)
This might be a bigger issue than you realize -- but also easier to fix than you might realize! The Realistic User Flows article explains how you can make your load tests much more realistic.