Test data dos and don'ts

Test data is one of the most overlooked sources of unrealistic results in load testing. Using the same hardcoded values for every virtual user bypasses caches, creates artificial database hotspots, and makes your test behave nothing like production traffic. This page shows you how to use MaxoPerf’s data features correctly — and what to avoid.

Before you start

Understand MaxoPerf data entities and parameters before reading this page.
Know the difference between a data entity (a CSV file attached to a workspace) and a variant (a parameterized version of a test that selects a different row subset or column mapping from the same entity).
Have a CSV file with realistic data ready, or understand how to generate synthetic data that covers your key paths.

Why test data matters

When 200 virtual users all log in as user@example.com in parallel:

Your session table gets hammered by a single user ID.
Your auth token cache serves the same token to all VUs — no realistic token refresh.
Your rate-limiter sees one user making 200 requests/second and blocks them all.
Your database row-level locking causes artificial contention on a single row.

None of these behaviours exist in production. Your test results are telling you about a pathological edge case, not your system under real load.

Dos

Do use a MaxoPerf data entity (CSV) for user credentials, IDs, and any value that should vary per VU. Upload your CSV at workspace level, attach it to the test, and reference it via the parameter name in your script. Each VU gets a unique row.

In Taurus, reference the attached CSV entity by the parameter name you mapped:
```
scenarios:
  authenticated-browse:
    requests:
      - url: /api/products
        headers:
          Authorization: 'Bearer ${AUTH_TOKEN}'
```
The AUTH_TOKEN parameter is supplied by the attached data entity — each VU draws its own row.
Do use MaxoPerf Test Data variants when you want to run the same test against different data sets without duplicating test configurations. A variant selects a different row range or column mapping from the same entity. This is the correct way to run the same profile against dev, staging, and prod data sets.
Do generate enough rows for your peak VU count plus a buffer. If your test runs 500 VUs for 30 minutes with a 2-second think time, each VU makes roughly 900 requests. With 500 rows in your CSV and sequential allocation, rows will repeat. Use at least 1.5× your VU count in rows for non-repeating runs; for realistic variety, target 10× or more.
Do validate your CSV before uploading. A malformed CSV (wrong delimiter, missing header, BOM characters) causes Taurus to silently fall back to empty parameter values. Validate the file locally with a CSV linter or by running a smoke test first.
Do use MaxoPerf Secrets for credentials you do not want visible in plain text in your script files. Upload secrets at account or workspace level; reference them as environment variables in your script. The secret value is never stored in the test file.
```
env:
  API_KEY: '${API_KEY_SECRET}'
```
Do prefer synthetic data over production data when possible. Synthetic data sidesteps GDPR/privacy concerns (no real PII in test artifacts), lets you generate edge-case rows deliberately, and avoids accidentally deleting or mutating real production records.
Do scope your data to the test environment. Use test-environment user accounts, test product IDs, and test payment tokens. Running a load test against production data risks creating real orders, charging real payment methods, or triggering real notifications.

Don’ts

Don’t hardcode usernames, tokens, or IDs in your Taurus YAML or JMeter JMX. Hardcoded values are checked into version control where they become stale, and they create the single-user contention problem described above.
Don’t put secrets (API keys, passwords, tokens) directly in script files. Even in a private repository, secrets in script files leak into build logs, test artifacts, and run history. Use MaxoPerf Secrets instead.
Don’t upload real production user data (names, emails, addresses) as a CSV data entity. Test artifacts — including attached data entities — may be visible to all workspace members. Replace PII with synthetic equivalents before uploading.
Don’t use a CSV with fewer rows than your VU count for uniqueness-sensitive operations. Uniqueness matters for: login (session conflicts), resource creation (unique constraint violations), and rate-limiting (per-user limits). Fewer rows than VUs guarantees collisions.
Don’t share a single CSV across tests with incompatible column layouts. A CSV shared between two tests that map columns differently will silently produce wrong parameter values for one of them. Name columns descriptively and create separate entities for incompatible layouts.
Don’t use static correlation values (tokens, CSRF nonces) copied from a manual session. Static tokens expire. Your VUs will start failing with 401/403 errors after the token TTL expires. Use dynamic token extraction (Taurus extract-jsonpath or JMeter Extractor) to fetch a fresh token in each VU’s session setup.
Don’t ignore the “attached to count” indicator on your data entity. If a data entity is attached to many tests, changing its column mapping or deleting rows can break all of them. Keep high-traffic entities stable; create a new entity (or variant) for changes.

Test data checklist

Question	Why it matters
Does every credential/ID vary per VU?	Avoids single-user contention
Does the CSV have ≥ 1.5× the VU count in rows?	Avoids row wrap-around collisions
Are secrets stored in MaxoPerf Secrets (not the script)?	No credential leakage in artifacts
Is the data synthetic or de-identified?	No PII in test artifacts
Are tokens fetched dynamically (not hardcoded)?	Tokens stay valid for the full run
Does the data belong to the correct test environment?	No accidental production mutations

Where to go next

Data entities and parameters concept page — full reference
CSV data-driven test recipe — step-by-step walkthrough
Secrets hub recipe — managing auth tokens in MaxoPerf
Designing realistic load — scenario mix and pacing