Test Script: Performance and Load

This is a ready-to-use performance and load test script. It verifies that a GxP computerized system stays responsive, correct, and stable under the user load and data volume it will actually carry, both at expected load and at the peak the system is sized for. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and execute it under an approved OQ or PQ protocol or validation plan. A worked filled specimen follows the template so you can see how a completed version reads. A test script is contemporaneous GxP evidence: write each actual result as you observe it, in the validated tool or in ink, never reconstructed afterward. Verify each cited regulation against the current source before you rely on it.

What this script is, and where it sits

Functional scripts prove the system does the right thing with one user and a clean data set. A performance and load script proves it keeps doing the right thing when many users hit it at once, when the database is full, and when the day’s busiest hour arrives. The two are different kinds of evidence. A function can be perfectly correct in isolation and still time out, return a partial result, or corrupt a record when fifty analysts save at the same second. That failure mode is what this script is built to catch.

This script sits below the OQ or PQ protocol, which states what will be load-tested and why, and feeds the traceability matrix, which links each performance and capacity requirement to the evidence that exercised it. Performance requirements have to exist before you can test them: a response-time target, a concurrent-user count, a throughput rate, a data-volume the system must hold. If the URS or FS does not state those numbers, fix that first, because “fast enough” is not a testable expected result.

Match the rigor to risk. Under FDA’s Computer Software Assurance approach, a system whose slowness or instability could delay a batch release, drop a record, or put patient-affecting data at risk earns the scripted, instrumented treatment below. A low-risk reporting system used by two people may justify a lighter check. Decide that risk in the risk assessment, then write the script.

Document control header

1. Performance requirements traced

State every performance, capacity, and concurrency requirement this script verifies, so the matrix can link requirement to evidence in both directions. Each requirement must carry a number, not an adjective. Every requirement listed here must be exercised by at least one numbered step below.

2. Objective

In one or two sentences, state what passing this script demonstrates. Keep it tied to the numbers in section 1.

Example: this script verifies that the system meets its response-time targets at expected load, sustains the specified concurrent-user count and throughput at peak load with no functional error or data loss, stays within resource limits, and degrades gracefully rather than failing, against a production-representative data volume.

<<FILL: objective>>

3. Workload model and load profiles

Define the load before you run it. A performance result means nothing unless the load that produced it is recorded exactly, so it can be repeated. Build the workload from real usage: the transaction mix, the per-user pacing (think time), and the data the transactions touch. Then set the load levels you will hold at.

3.1 Transaction mix

3.2 Load levels

3.3 Data volume at execution

4. Metrics and how each is measured

Name every metric, its unit, and the exact point of measurement, so two people would read the same result the same way. Decide whether you report a mean, a 95th percentile, or a maximum, and apply that consistently. Percentiles, not averages, are what an inspector and a real user care about, because the average hides the slow tail.

5. Prerequisites

List everything that must be true before execution starts. If any prerequisite is not met, do not execute; record the gap as a test deviation and stop.

6. Execution conventions

Read these before executing, then apply them to every step. They are the rules an inspector expects to see followed consistently.

• Record the actual measured values contemporaneously, from the tool’s report and the server monitor, into the actual result cell. Do not pre-fill, do not batch at the end.
• “Meets expected result” is not an actual result. Write the number you observed: the 95th-percentile seconds, the sustained users, the throughput, the CPU percent.
• Report the statistic you committed to in section 4 (for example the 95th percentile), not a friendlier average chosen after the fact.
• Functional correctness still counts under load. Sample completed transactions and confirm the data saved is correct and complete; a fast wrong answer is a Fail.
• Capture objective evidence for every step: the load-tool summary report, the response-time distribution, and the server resource graphs, each with a unique reference recorded in the step.
• If a target is missed, that is a Fail, not a tuning opportunity to be quietly applied mid-run. Mark it Fail, record the configuration as tested, and handle any change under section 9 with a retest.
• The expected result (the threshold) must be written before execution and not amended after you have seen the actual one.

7. Test steps

Each step gives the action, the precise expected result, the actual result as observed, pass or fail, and the evidence reference. Number steps continuously. Run the levels in order so a clean baseline precedes the harder loads.

Add or remove rows so every requirement in section 1 is exercised and every load level in section 3.2 you committed to is run. Do not reuse a step number after a revision.

8. Acceptance criteria

This script passes only when all of the following are true:

• At expected load, the response-time statistic for every measured transaction is at or below its threshold in section 4, with no functional errors.
• At peak load, the system sustains the required concurrent users and throughput, holds response times at or below threshold, and records no functional error and no data loss, duplication, or truncation in the sampled records.
• Server resource use stays within the stated limits at peak, with headroom that supports the sizing conclusion.
• Under stress, the system degrades gracefully and protects committed data; it does not crash, corrupt, or silently drop records, and it recovers when load returns to normal.
• Over the soak run, there is no upward memory-leak trend, no progressive slowdown, and no accumulating error.
• Every deviation raised during execution is resolved with a documented disposition, and any retest is run on a recorded configuration and traced to the original failure.
• The completed script is reviewed and approved per section 11, by a reviewer who did not execute it.

A script with one or more open Fail steps, or a passing response time obtained only by tuning the system between runs without retesting the whole profile, does not support the conclusion in the parent report.

9. Deviations raised during execution

Any step that misses its threshold, any departure from the written workload or steps, and any prerequisite not met is recorded here and managed per the parent protocol and <<FILL: deviation / test-incident SOP-ID>>. Cross-reference the deviation number on the failing step.

A missed performance target is data, not a tester error. The discipline an inspector looks for is that the miss was captured with the actual number and the configuration in force, that any tuning (more memory, an index, a connection-pool change) was made under change control, and that the affected load profile was re-run in full afterward, not patched mid-run with the original numbers left standing.

10. Execution summary

11. Sign-off

The tester executes and signs; an independent reviewer who did not execute the test confirms the record is complete, the load profile and environment are representative, the evidence supports each pass, and any deviation is resolved. The reviewer should not be the same person who executed the script.

12. References

21 CFR Part 11 (electronic records and electronic signatures), where the system is Part 11 in scope. 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (Computerised Systems), sections on validation, capacity, and security. EU GMP Annex 15 (Qualification and Validation), 2015 revision. FDA Guidance, Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 (superseding the 24 September 2025 final) (risk-based scaling of test rigor). FDA Guidance, General Principles of Software Validation (2002). GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition). ICH Q9, Quality Risk Management (for the risk basis of test depth and acceptance limits). For medical device software: 21 CFR Part 820 (QMSR, effective 2 February 2026, incorporating ISO 13485:2016 by reference) and IEC 62304.

Confirm the current version and clause numbers of each reference before issue.

13. Revision history

Filled specimen

The following shows the script executed for an example laboratory information management system (LIMS), verifying response time at expected load, stability and integrity at a 50-user peak, graceful degradation under stress, and no leak over a soak run, against a production-representative data volume. The company, system, tool, and numbers are illustrative; replace them with your own.

Header (extract)

Performance requirements traced

Load levels run

Test steps (executed)

Execution summary

Sign-off

In this example the tester populated the database to a realistic two-year volume before testing, reported the 95th percentile rather than the average, sampled real transactions under load to confirm data integrity (not just speed), pushed past peak to find and document the breaking point, and confirmed the system recovered and held steady over a 12-hour soak. A reviewer who did not run the test confirmed the environment was representative and the evidence supported each pass. Had step 7.4 returned a 95th-percentile save of 5.5 s, the tester would have marked it Fail, recorded the configuration in force, opened a test incident, and any retune (an added index, a larger connection pool) would have been made under change control with the entire peak profile re-run, which is the behavior section 9 is built to capture.

Common inspection findings this script prevents

• A performance requirement stated only as “the system shall be responsive”, with no number, so the test has no real acceptance criterion.
• Load testing run against an empty or near-empty database, so the response times bear no relation to a full production system after two years of records.
• Average response time reported as a pass while the 95th-percentile or maximum, the number real users feel, was never measured or quietly hid a slow tail.
• Speed measured but data integrity under load never checked, so duplicated, truncated, or lost records during concurrent saves go undetected.
• The test environment far smaller than production, with the sizing gap neither documented nor assessed, so the result does not support the production sizing conclusion.
• No stress test, so the system’s behavior at and beyond its limit (graceful queueing versus a crash that loses committed data) is unknown.
• A response target met only by tuning the system between runs, with the favorable number kept and the full load profile never re-run on the changed configuration under change control.
• No soak or endurance run, so a memory leak or slow degradation that only appears after hours of real use is never caught.
• The load-generation tool itself never confirmed correct, so an artificially low load produced artificially good numbers.
• The same person executing and reviewing, with no independent check that the load profile and environment were representative of production.

How to adapt this script

1. Set your test script ID, parent protocol, software version, and configuration baseline in the header, and document how the test environment matches production sizing, with any gap stated and assessed.
2. Confirm the performance requirements in section 1 carry real numbers (response time with a percentile, concurrent users, throughput, data volume). If the URS or FS only says “fast”, fix the requirement under change control before you test.
3. Build the workload model in section 3 from real usage: the transaction mix, the think times, and the load levels you will hold at, and populate the database to a production-representative volume first.
4. Decide in section 4 whether each metric is a mean, a 95th percentile, or a maximum, and report that statistic consistently; prefer percentiles over averages for anything users feel.
5. Run expected, peak, stress, and soak in order, sample real transactions under load to confirm data integrity, and capture the load-tool report and server resource graphs as evidence for every step.
6. Point the cross-references in sections 5, 9, and 11 to your real OQ or PQ protocol, deviation or test-incident procedure, and review and approval process.
7. Confirm every regulation in section 12 against the current published version before issue.