Load Testing

Load Testing is a performance testing method that checks how an application behaves under an expected, realistic load. The goal is to catch performance problems early, before users encounter them in production. Load Testing provides insight into throughput, response times, stability, and resource consumption under normal operating conditions.

In a Nutshell

• Load Testing simulates the expected user load of an application.
• It measures throughput, response time, error rate, and resource utilization.
• Key tools include k6, JMeter, and Gatling.
• Load Testing differs from Stress, Spike, and Soak Testing.
• Load profiles define how load is distributed over time.

What is Load Testing and Why Does It Matter?

Load Testing verifies whether an application can handle its expected user load. The application is subjected to a defined number of virtual users or requests over a specific period. The results show whether the application performs within acceptable boundaries or if bottlenecks emerge.

Load Testing typically answers these questions:

• How many users can work simultaneously without unacceptable response time increases?
• How many requests per second can the system handle stably?
• Does the error rate rise under increased load?
• How do CPU, memory, and database perform under load?
• Does the system meet defined Service Level Agreements?

How It Differs from Other Performance Testing Types

Performance Testing is an umbrella term covering various test types. Load Testing is one of them, but not the only one.

• Load Testing: Checks behavior under expected, realistic load.
• Stress Testing: Pushes beyond expected load to find system limits.
• Spike Testing: Creates sudden, extreme load spikes—for example, during ticket sales launches.
• Soak Testing: Runs continuously over extended periods under constant load to surface resource leaks.

Key Metrics

Throughput

Throughput indicates how many requests or transactions the system can process in a given time. It’s commonly expressed as requests per second.

Response Time

Response time is the duration from a request to a complete response. It’s often analyzed as an average, median, or percentile. The 95th percentile shows how slow requests are for most users.

Error Rate

Error rate is the proportion of requests that don’t complete successfully. A sudden spike indicates a bottleneck.

Resource Utilization

Resource utilization covers CPU, memory, network, and disk. It helps identify the root cause of performance problems.

Concurrent Users

Concurrent Users are actively connected users sending requests simultaneously. They’re essential for planning realistic load profiles.

Load Profiles

Load profiles define how load is distributed over time. They help model realistic scenarios.

Constant Load

With constant load, the number of users or requests remains steady over an extended period. This profile works well for testing stability under a defined baseline.

Ramp-up

Ramp-up gradually increases load until reaching the target. This reveals how the application behaves as more users arrive. Ramp-up is especially important for testing the transition from idle to normal operation.

Peak Load

Peak load simulates sudden, short load bursts. A ticket shop surge right after sales opens is a classic example. This profile shows how well the system handles abrupt load changes.

Soak Test

A Soak Test runs the application for hours or even days under constant load. It uncovers resource leaks like growing memory consumption, connection leaks, or filling log files.

Step Load

Step load increases load in multiple stages, with brief plateaus between them. This profile works well for comparing performance at different load levels and finding the point where performance degrades.

Practical Example

The following example shows a typical load test for a web application. It combines the most important load profiles: ramp-up, constant load, and wind-down. The aim is to demonstrate how a realistic test is structured and which metrics are monitored.

Goal: 1,000 concurrent users, response time under 500ms

Phases:
1. 100 users for 2 minutes      (Warm-up / Ramp-up)
2. 500 users for 5 minutes        (first plateau)
3. 1,000 users for 10 minutes     (target load / plateau)
4. Wind-down for 2 minutes        (gradual decline)

Why these phases?

• Warm-up with 100 users: The application and infrastructure gradually reach operating temperature. Database caches fill, and connection pools initialize.
• 500 users for 5 minutes: First plateau to observe behavior at moderate load and spot early bottlenecks.
• 1,000 users for 10 minutes: The actual target. This verifies the application handles expected peak load stably over an extended period.
• Wind-down: The controlled reduction shows whether the system recovers quickly and whether resources like memory are released.

Throughout the test, throughput, response time, error rate, and resource utilization are continuously recorded. Results are compared against defined SLAs.

Key Tools

k6

k6 is a modern open-source load testing tool developed by Grafana Labs. Tests are written in JavaScript and integrate with CI/CD pipelines. k6 is popular with development teams because it’s lightweight, script-based, and well-documented.

Apache JMeter

JMeter is one of the most established load testing tools. It offers a graphical user interface and supports many protocols including HTTP, SOAP, JDBC, and JMS. JMeter excels at complex scenarios and enterprise environments.

Gatling

Gatling is a high-performance load testing tool where tests are written in Scala, Kotlin, or Java. It stands out for efficient load generation and is ideal for large-scale tests with many virtual users.

Other Tools

• Locust: Python-based tool with simple script creation.
• Artillery: Modern Node.js tool for load testing.
• Loader.io: Cloud-based load testing service.
• NeoLoad: Enterprise solution for complex test environments.

Advantages and Disadvantages

Advantages	Disadvantages
Early detection of performance problems	Extensive test environment preparation required
Better infrastructure planning	Production-like test environment needed
Validation of SLAs and Service Level Objectives	Result interpretation requires experience
Reduced production downtime	Test data must be realistic and anonymized
Objective measurement of user experience	Tools and infrastructure incur costs
Early planning of scaling measures	Load tests can strain production-like systems

Best Practices

• Define clear objectives and SLAs before testing.
• Create realistic load profiles based on production data.
• Use a production-like test environment.
• Isolate external systems such as payment gateways or email servers.
• Monitor server and application metrics throughout the test.
• Document your test setup, results, and findings.
• Repeat tests after any major changes.

Key Exam Topics

• Load Testing: Tests how an application behaves under expected, realistic load.
• Difference from Stress Testing: Load testing stays within expected ranges; stress testing pushes beyond them.
• Spike Testing: Simulates sudden, extreme load spikes.
• Soak Testing: Long-duration test under constant load to identify resource leaks.
• Key Metrics: Throughput, response time, error rate, resource utilization, concurrent users.
• Percentiles: The 95th percentile matters more than average for understanding user experience.
• Load Profiles: Constant load, ramp-up, peak load, step load, soak test.
• Essential Tools: k6, JMeter, Gatling, Locust, Artillery.
• SLA: Service Level Agreement defines acceptable performance boundaries.
• Production-like Test Environment: Required to obtain realistic results.
• Test Data: Must be realistic, anonymized, and representative.

Key Resources

1. https://k6.io
2. https://jmeter.apache.org
3. https://en.wikipedia.org/wiki/Load_testing

Continue Your Software Testing Learning Path

The next article in the Software Testing Learning Path covers Performance Testing — how performance testing comprehensively evaluates system performance.