Load testing 101

User rating:
4.2 (5 ratings)

The content on this page is related to a deprecated version of LoadUI, which has been superseded by LoadUI NG Pro in the Ready! API platform. Click here to learn more.

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:

Performance testing Does it work fast?
Load testing Does it work fast under the expected pressure?
Stress testing At what pressure does it stop working? Does it recover well?
Endurance testing 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:

Naïve test Real user behavior
Arrival rate Determenistic Random (exponentially distributed)
Think times Constant Random
User decisions Determenistic Random (weighted)

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.