Performance Test Plan and Report: [System or release name]

Combined performance test plan and results report. Part A plans the testing (objectives, workload model, test types, environment, criteria, scenarios); Part B records results, bottlenecks and recommendations. Based on common industry practice for load and performance engineering. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

Part A: Plan

1. Introduction
2. Objectives and service level targets
3. Workload model
4. Test types
5. Test environment and data
6. Tools and monitoring
7. Entry and exit criteria
8. Test scenarios
9. Risks, assumptions and schedule

Part B: Report

10. Results summary
11. Detailed results
12. Bottleneck analysis
13. Recommendations

1. Introduction

1.1 Purpose

This document plans and reports performance testing for [system name] [version] ahead of [launch / seasonal peak / migration], to show that the system meets its latency, throughput and resource targets at forecast peak load plus headroom, and to find the limits before users do.

1.2 Scope

1.3 System under test

[One paragraph or diagram reference describing the architecture: entry points, services, data stores, caches, queues and external dependencies, with the instance sizes used in production.]

2. Objectives and service level targets

Objectives beyond pass or fail:

• Find the breaking point (load at which an SLA is first violated) and the failure mode.
• Confirm the system recovers within [5 minutes] after overload ends.
• Detect memory or connection leaks over a [8-hour] soak.

3. Workload model

3.1 Source data

Peak hour analysed: [YYYY-MM-DD HH:00, from APM and web analytics]. Forecast growth to the test date: [+35%]. Headroom applied: [20%].

3.2 Transaction mix

3.3 Concurrency estimate

The number of concurrent users needed to produce the target throughput follows from Little's law:

$N = X \cdot R$

where $N$ is the average number of users in the system, $X$ is throughput (requests per second) and $R$ is the average time each user spends per request cycle, including think time.

Example: With $X = 200$ req/s and an average cycle of response time 0.3 s plus think time 7.7 s, $R = 8$ s, so $N = 200 \times 8 = 1{,}600$ virtual users at peak. At 120% of peak, the test needs $1{,}920$ users.

3.4 User journeys

4. Test types

Tests run in the order shown; stress, soak and spike start only after the load test passes or its failures are understood.

5. Test environment and data

Data: database populated with [2 million orders, 500,000 customers, 50,000 SKUs] of synthetic data matching production distributions. No personal data. Caches warmed for [10 minutes] before measured runs.

Load generators: [4 instances in the same region, 8 vCPU each]; generator CPU kept under 70% so the generator is never the bottleneck.

6. Tools and monitoring

Metrics captured for every run: response time percentiles (p50, p90, p95, p99, max) per transaction; throughput; error rate by type; CPU, memory, garbage collection; connection pools; queue depths; database locks and slow queries.

7. Entry and exit criteria

8. Test scenarios

9. Risks, assumptions and schedule

Schedule: scripts ready YYYY-MM-DD; PT-01 to PT-03 YYYY-MM-DD; PT-04 to PT-06 YYYY-MM-DD; report YYYY-MM-DD; retest window YYYY-MM-DD.

10. Results summary

Overall verdict: [Pass / Pass with conditions / Fail]. Example: Fail on search latency and throughput at 120%; see 12.1. Breaking point at about 2,250 users, where search errors exceeded 5%.

11. Detailed results

11.1 Run PT-02 (load, 100% of peak)

Raw results: [link to result files and dashboards snapshot].

11.2 Other runs

12. Bottleneck analysis

12.1 Capacity projection

With utilisation $U = X \cdot S$ (throughput times service demand), the search service at $S = 16$ ms CPU per request on 1 vCPU saturates near $X = 1 / 0.016 \approx 62$ req/s, and at the peak search rate of 50 req/s it runs at $U = 50 \times 0.016 = 0.8$, which matches the 83% observed. Meeting 120% of peak search load with CPU under 70% needs roughly $\lceil 60 \times 0.016 / 0.7 \rceil = 2$ vCPU for search alone, so [describe the sizing change].

13. Recommendations

Release recommendation: [Release / Release after REC-01 and REC-02 are verified by retest / Do not release].

Standard and licence note

Based on common industry practice for performance test planning and reporting, including workload modelling and queueing relationships such as Little's law and the utilisation law. This template is original text written for this collection. Template licence: MIT.