Create a JMeter Test Plan with AI
Returns a JMeter test plan as a valid .jmx-shaped XML skeleton with thread groups per scenario type, HTTP request samplers, response assertions, timers, and CSV-driven data — ready to import into JMeter 5.x for refinement and distributed runs.
When to use it
- Adding endpoints to an existing JMeter-based load suite.
- Standardizing JMeter plan structure across teams that share scripts.
- Migrating from GUI-built JMeter plans to maintainable, code-reviewable plans.
- You work in an enterprise environment where JMeter is the standard (banking, telecom).
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a JMeter veteran. You produce .jmx files that import cleanly, follow the standard structure (Test Plan → Thread Group → HTTP Request → Response Assertion + Timer + Listener), and externalize data via CSV Data Set Config.
</role>
<context>
JMeter 5.x is the target version. Plans use Thread Groups as scenarios. Each Thread Group has: HTTP Request Defaults, HTTP samplers, a Response Assertion per sampler, a constant or Gaussian timer for think time, and a backend listener (InfluxDB / Prometheus). Test data lives in CSV files loaded via CSV Data Set Config — never inline.
</context>
<task>
For the endpoint(s) below, produce:
1. A complete .jmx XML structure (top-level TestPlan with one ThreadGroup per scenario type)
2. HTTP Request Defaults for shared configuration
3. HTTP Request samplers per endpoint
4. Response Assertion per sampler (status + payload sanity)
5. A timer (Gaussian random) per thread group
6. CSV Data Set Config for test data
7. Backend Listener pointed at InfluxDB or Prometheus
</task>
<input>
Endpoint(s) (method, URL, payload): {endpoints}
Scenarios needed (steady, ramp, spike, etc.): {scenarios}
Target concurrent users / RPS: {target}
SLA: {sla}
</input>
<constraints>
- Output must be VALID .jmx structure — proper XML with hashTree elements.
- Externalize test data via CSV Data Set Config — never inline data.
- One thread group per scenario type, not one per endpoint.
- Response Assertion on every sampler (don't ship without).
- Timer present per thread group (without it, JMeter goes full throttle = unrealistic).
</constraints>
<output_format>
Three sections:
1. **Plan structure (overview)** — text outline of the .jmx tree
2. **.jmx code block** — XML snippet (truncated if very long, but core structure complete)
3. **CSV data file** — sample data.csv content
4. **Notes** — how to wire backend listener and run distributed
</output_format>
Before writing, decide thread-group structure based on the scenarios (one per scenario, not per endpoint).Example
Common pitfalls
- Model produces pseudo-XML that won't import; demand 'valid .jmx XML with hashTree elements'.
- Test data goes inline into the sampler body instead of CSV — fine for 5 users, broken at 500.
- Timer omitted; results show unrealistically high throughput because JMeter goes flat-out.
- Response Assertion only checks 200 — no payload sanity. Adds risk of 'green' tests that didn't actually work.
Tips
- Always run in CLI mode (`-n`) for actual measurements. GUI mode adds ~30% overhead and skews results.
- Externalize URL, ramp, duration via `-J` at run time — same plan, multiple environments.
- Keep the GUI version in git too; reviewers find pure XML hard to diff. Generate one from the other.
- Pair with `design-load-test-strategy` to ensure thread group structure matches strategy.
FAQ
JMeter dominates enterprise (banking, telecom) where institutional knowledge runs deep. k6 dominates new projects and code-first teams. Either is capable; choose based on team familiarity and CI integration costs.
Related prompts
Generate k6 Test Script from Endpoint
Reads an endpoint description and returns a ready-to-run k6 script with `options.scenarios` (ramping-arrival-rate), thresholds for p95/p99/error rate, realistic think times, and a `handleSummary()` for exporting to Grafana / InfluxDB or k6 Cloud.
Open →Design a Load Test Strategy
Returns a load test strategy covering 5 scenario types (baseline / load / stress / spike / soak) with thresholds for response time, throughput, and error rate, environment requirements, monitoring checkpoints, and pass/fail criteria — and explicit environment-parity statement.
Open →Analyze Performance Bottlenecks from Results
Reads a load test result summary (latency percentiles, throughput, error rate, system metrics) and returns a ranked list of suspected bottleneck layers — network, application, database, dependent service, or infrastructure — each with evidence cited from the metrics and a recommended next investigation step.
Open →Generate Synthetic Monitoring Scenario
Reads a critical user journey and returns a Playwright-based synthetic monitoring script with business-step checkpoints, failure-screenshot capture, an alerting threshold tied to a stated SLO/SLI, and a recommended run frequency.
Open →