Types of Performance Testing

Performance testing is not a single activity. It encompasses 12 distinct types of tests, each designed to uncover specific performance characteristics and bottlenecks within your application.

1. Load Test

Testing the application under its expected, normal 100% peak load. The goal is to verify if the system can meet its SLA under normal conditions.

2. Stress Test

Testing beyond normal capacity to find the breaking point. e.g., if expected load is 100 users, test with 200 to see how it fails.

3. Endurance (Soak) Test

Applying 50-60% of peak load for an extended duration (12, 18, or 24 hours). The primary goal is to find Memory Leaks.

The 12 Performance Testing Types

Warm Up / Dry-run / Discovery Test

A preliminary test run at 10% or 100% load for a very short duration (e.g., 5-10 minutes) before the actual load test. It ensures all Load Generators are functioning properly, data is valid, and the environment is warmed up (caches populated).

Performance / Baseline Test

A test executed with a Single User, Single Script, for a Single Iteration. It is usually run in Standalone mode (without the Controller) to capture the best possible response times. This forms the "Baseline" against which the full Load Test results will be compared.

3. Load Test

Testing the application under 100% of the anticipated peak load. The primary objective is to verify that the application meets its Service Level Agreements (SLAs) under normal expected conditions.

4. Endurance / Soak / Longevity Test

The application is subjected to a moderate load (usually 50% to 60% of peak load) for an extended period, typically 12, 18, or 24 hours. The main goal is to identify Memory Leaks that slowly consume resources over time and cause crashes.

5. Stress Test

Testing the system by applying a load well beyond its expected capacity (1.25x to 5x normal load). The goal is to identify the application's breaking point and observe how it fails and recovers. To increase stress without adding users, testers often reduce Think Time or Pacing.

Real-world Scenario: If you only have a 500-user LoadRunner license, but need to stress test for 700 users, you can reduce Pacing and Think Time in your scripts to force the 500 Vusers to generate the throughput equivalent to 700 real users.

6. Failover Test

Tests the system's high availability and redundancy. During a load test, a critical component (like a database node or application server) is intentionally shut down or "unplugged." The test verifies if the Load Balancer successfully redirects traffic to the backup node without impacting the users.

7. Benchmark Test

A test used to establish quantifiable, repeatable results for a system. It is often used to compare the performance of two different systems, configurations, or competing vendor products under the exact same conditions.

8. Capacity Planning Test

Used to forecast future hardware requirements. It answers the question: "If our user base grows by 20% next year, how many additional application servers will we need to maintain our current response times?"

9. Spike Test

A subset of Stress Testing. The system is subjected to a sudden, extreme, and abnormal increase in load for a very short duration, followed by a rapid decrease. Example: A flash sale or breaking news event on a website.

10. Volume Test

Focuses on the database rather than the number of users. It tests the application's performance when processing huge amounts of data (e.g., executing a batch job that processes 1 million records).

11. Scalability Test

Measures the system's ability to scale up.
- Vertical Scaling: Adding more CPU, RAM, or Cores to an existing server.
- Horizontal Scaling: Adding more server nodes to the cluster.

12. Network Latency / WAN Emulation Test

Tests the application's performance over different network conditions (e.g., 3G, 4G, high latency, packet loss). In LoadRunner, this is often achieved by integrating with HP Shunra Network Virtualization to simulate real-world WAN behavior.

Controller Crash Recovery

If the Controller crashes during a 24-hour Soak Test, how do you recover the results?

If the Controller machine crashes (e.g., power failure) at the 20th hour of a 24-hour test, you do not necessarily lose all your data. LoadRunner continuously saves raw results in the temporary directory during execution.

Recovery Process:

Restart the Controller machine.
Navigate to the temporary results directory (usually defined in the Scenario settings, or %TEMP%).
Locate the .lrr (LoadRunner Raw Results) file generated for that specific test run.
Open LoadRunner Analyzer and use it to open the recovered .lrr file. The Analyzer will generate the graphs up to the point of the crash.