Configuring Test Cases¶
A raw recording captures one specific session, with one user's session cookies, one set of CSRF tokens, and a wall of recorded values frozen in time. Replaying that recording without configuration will fail almost immediately. The server expects fresh tokens for the new session, fresh session cookies, and (if you're running multiple virtual users) different inputs per user. This chapter covers the work of making a recorded test case generic enough to replay successfully and realistic enough to load-test against.
The work falls into a handful of distinct concerns, in roughly the order you'll hit them. Each step usually depends on the previous one. Don't move on until the previous step works.
Foundation: Web Application State¶
Before configuring anything, understand what kinds of state real applications maintain across requests: session cookies, CSRF tokens, hidden form fields, dynamic URL segments, and the JavaScript-managed state that powers single-page apps. Web Pages & Application State is the conceptual orientation. Read it once.
Automatic Correlation: ASM¶
Application State Management is Load Tester's automatic correlation engine. You reach it through the Configure for Replay wizard, which has two pages: hostname restriction first (so you're not load-testing Google Analytics and the other third parties your recording happened to capture), then ASM. The wizard detects and configures most dynamic values for you: session tokens, CSRF tokens, OAuth bearer tokens, .NET ViewState, Salesforce session IDs, and other common patterns. For most sites this is the only correlation step you need. The ASM subpages cover what to do when the wizard doesn't catch something: basic field overrides, advanced extraction, dynamic field names, auto-ignore rules, and writing your own extractors.
Run the wizard early. The pre-replay walkthrough is in Run the Configure for Replay Wizard.
Authentication¶
Authentication is the hardest single problem in load testing, and it's getting harder thanks to anti-bot defenses like CAPTCHA, MFA, and device fingerprinting. The Authentication section covers the patterns: basic and form auth, OAuth and bearer tokens, client certificates, and modern SSO / OIDC / SAML flows. If your target has serious security, read The Anti-Bot Reality early. It will save you from spending a week trying to script around a CAPTCHA that nobody will let you bypass.
User Data: Datasets¶
Once a single user can replay successfully, you need to vary the inputs across virtual users so the load test isn't a thousand copies of the same user doing the same thing. Datasets supply per-user data (usernames, search terms, product IDs) and provide the variation real users have.
Validation Rules¶
A response with status 200 means the server didn't crash. It doesn't mean the response is right. Validation Rules let you assert what a correct response actually contains: the user's name on the dashboard, the absence of a "session expired" page, a specific JSON key in an API response. Without validation rules, a load test where every page silently returned an error page would still report a 0% error rate, because every page returned 200.
Content Edits¶
Some recordings need direct edits to the captured content: a file upload that should use different files per user, a dynamic file download with extracted URLs, JSON or XML payloads that need to vary, recorded hostnames that point at the wrong environment, or third-party trackers that have no business in the test. Modifying Test Case Content walks through those recipes.
Advanced Configuration¶
Anything that doesn't fit the standard patterns above lives in Advanced Configuration: user agent overrides, header manipulation, bandwidth limits, custom JavaScript execution, IP aliasing, and similar edge cases.
A useful shortcut: run ASM first, then attempt a replay. The replay either succeeds (you're mostly done with correlation and can move on to datasets), or it surfaces exactly which transactions still need work. Either way you stop guessing and start fixing the right thing.