Test Design & Scripting

Test scripts are software. They get the same engineering discipline as production code: version control, review, modularity and meaningful assertions.

Scripting for realism

Each scripted transaction must reproduce what real clients do: correct headers and cookies, session token handling, realistic payload sizes, conditional flows (cache hits vs misses, logged-in vs anonymous), and client behaviour like retries and connection reuse. We script against the protocol the system actually serves — HTTP/2 multiplexing, WebSocket sessions, gRPC streams — because connection behaviour shapes server load.

Correlation and parameterisation

Dynamic values (session IDs, CSRF tokens, view states) are correlated from responses, never hard-coded — a script replaying a captured session token tests your cache, not your application. Input data is parameterised across realistic distributions: thousands of distinct users, products and search terms, weighted to match production frequency. Uniform random data defeats caches unrealistically; a single reused record flatters them. Both produce wrong answers.

Assertions that matter

Every request asserts on semantic success, not just HTTP 200 — login responses must contain a session token, search responses must contain results. Under stress, systems often return 200s with empty or error-bearing bodies; scripts that only check status codes report a healthy system that's actually returning garbage.

Pacing and load shape

We control load via arrival rate (open model) rather than a fixed user loop (closed model) for systems facing the open internet — real users don't wait for your slow response before sending the next request. Closed models are reserved for systems with genuinely bounded user populations, like internal call-centre applications. The choice materially changes results at saturation and we document it explicitly.

Phase outputs

A version-controlled repository of test scripts with README and run instructions, data generation/preparation scripts, scenario definitions for each planned test, and a passing low-volume "shakeout" run proving the scripts work end-to-end.