Software Testing Performance Testing

Performance testing measures how a system behaves under a specific workload — how fast it responds, how much it can handle, and whether it stays stable over time. A system that works correctly but responds slowly will still drive users away.

Why Performance Testing Is Critical

  Research on user behaviour shows:
  ────────────────────────────────────────────────
  Page load > 3 seconds  → 53% of mobile users leave
  Page load > 5 seconds  → Conversion rates drop sharply
  1-second delay         → Measurable drop in customer satisfaction

  A fast, stable system retains users.
  A slow or crashing system loses them — permanently.

Types of Performance Testing

Load Testing

Tests the system under the expected normal and peak user load. The goal is to verify that performance stays within acceptable limits at anticipated traffic levels.

  Scenario: University exam registration portal

  Normal day:    500 students online → Response: 300ms  ✔
  Registration   day: 15,000 students → Response: 900ms ✔
  First-day rush: 30,000 students → Response: 8000ms ✘

  Load test reveals the system cannot handle the first-day rush.

Stress Testing

Pushes the system beyond its maximum capacity to find where and how it breaks. This determines the system's breaking point and checks whether it fails gracefully.

  Gradually increase users:
  1,000 → 5,000 → 10,000 → 20,000 → 30,000 (system crashes)

  Key questions:
  → At what point did response time degrade?
  → At what point did the system crash?
  → Did it recover automatically when load was reduced?
  → Were any data loss or corruption issues caused by the crash?

Spike Testing

Simulates a sudden, dramatic increase in traffic — then an equally sudden drop — to see whether the system can absorb the spike and return to normal.

  Traffic pattern:
  100 users ──────────►────────────► 100 users
                   ↑            ↓
               50,000 users (spike for 2 min)

  Does the system survive the spike? ✔ or ✘
  Does it return to normal after the spike? ✔ or ✘

Endurance Testing (Soak Testing)

Runs the system at normal load for an extended period — 8, 24, or 72 hours — to detect memory leaks, connection pool exhaustion, and performance degradation that only appears over time.

  Hour 1:  Response = 250ms ✔
  Hour 8:  Response = 350ms (slight increase) ✔
  Hour 24: Response = 2,500ms ✘ (memory leak detected)

Scalability Testing

Tests how well the system scales up when more resources (servers, CPU, RAM) are added. Confirms that adding hardware actually improves performance proportionally.

Volume Testing

Checks system behaviour when it handles large volumes of data — millions of database records, large file uploads, or massive report generation requests.

Key Performance Metrics

  METRIC              WHAT IT MEASURES                  TARGET
  ──────              ────────────────                  ──────
  Response Time       Time from request to response     < 2 seconds
  Throughput          Requests processed per second     Depends on app
  Concurrent Users    Users active at the same time     Project-specific
  Error Rate          % of failed requests              < 0.1%
  CPU Usage           % of server processor used        < 80%
  Memory Usage        RAM consumed by the application   < 75%
  Latency             Network delay                     < 100ms

Performance Testing Tools

  TOOL           BEST FOR                     TYPE
  ────           ────────                     ────
  Apache JMeter  Load testing web apps        Open source
  k6             Developer-friendly scripting Open source
  Gatling        High-throughput load tests   Open source
  Locust         Python-based load testing    Open source
  BlazeMeter     Cloud-based load testing     Commercial
  LoadRunner     Enterprise performance       Commercial

A Simple JMeter Test Plan Structure

  Test Plan
  └── Thread Group (simulates 1,000 users)
       ├── HTTP Request: GET /home
       ├── HTTP Request: POST /login
       ├── HTTP Request: GET /dashboard
       └── Listener: View Results Tree
                      Summary Report
                      Response Time Graph

Performance Test Report: What to Look For

• Average response time: Is it within the agreed threshold?
• 90th/95th percentile response time: What did the slowest 10% or 5% of users experience?
• Peak concurrent users before degradation: At what point does performance noticeably drop?
• Error rate under load: Do requests start failing as load increases?
• Resource utilisation over time: Does CPU or memory climb continuously, suggesting a leak?

Performance Testing vs Functional Testing

  FUNCTIONAL TESTING      PERFORMANCE TESTING
  ──────────────────      ───────────────────
  Does it work?           How well does it work?
  1 user, 1 action        Thousands of users, concurrent
  Pass / Fail             Metrics and thresholds
  Always done             Often skipped (a mistake)