Setting Up the Test Plan
Start by right-clicking the Test Plan root and choosing Add > Threads (Users) > Thread Group. In the Thread Group's properties, set 'Number of Threads (users)' to how many virtual users you want, 'Ramp-Up Period' to how many seconds JMeter should take to start them all, and 'Loop Count' to how many times each thread repeats its work — a value of 1 runs the plan once per user, while checking 'Infinite' runs continuously until manually stopped or a Duration is set.
Cricket analogy: Like setting a net session's parameters before it starts — how many batsmen rotate through, how quickly each one steps up, and how many overs each faces — a Thread Group's users, ramp-up, and loop count define the shape of a JMeter run before it starts.
Adding an HTTP Request Sampler
Right-click the Thread Group and choose Add > Sampler > HTTP Request. Set 'Server Name or IP' (e.g. api.example.com), leave 'Protocol' as https, set 'Method' to GET or POST as needed, and fill 'Path' with the endpoint, such as /api/products. For a POST with a JSON body, switch to the Body Data tab and paste the payload, then add an HTTP Header Manager as a sibling element so a Content-Type: application/json header is sent alongside it.
Cricket analogy: Like filling out a bowling analysis card with the exact over, line, and length before delivering, configuring an HTTP Request sampler means specifying the exact server, method, and path before JMeter sends anything.
{
"note": "HTTP Request sampler configuration (as it appears in the GUI fields)",
"serverNameOrIP": "api.example.com",
"protocol": "https",
"method": "POST",
"path": "/api/orders",
"bodyData": {
"productId": "SKU-1024",
"quantity": 2
},
"headers": {
"Content-Type": "application/json"
}
}Adding a Listener to View Results
Add a Listener such as View Results Tree while building and debugging the plan — it shows the raw request and response for each sample, which is invaluable for confirming a sampler is configured correctly. Summary Report, by contrast, aggregates results into throughput, average/min/max response time, and error percentage per sampler, which is what you actually want to read once a plan is running with realistic user counts rather than one request at a time.
Cricket analogy: Like watching ball-by-ball replay footage during practice to check technique versus reading the end-of-innings scorecard for the overall result, View Results Tree shows raw request/response detail while Summary Report shows the aggregated outcome.
Listeners, especially View Results Tree, hold every request and response body in memory and are expensive to render. Remove or disable them before running any test with meaningful thread counts or duration — write results to a .jtl file via the command line's -l flag instead, and only load them into a Listener afterward for analysis.
Running and Reading the Results
For a small debugging run, click the green 'Start' arrow in the GUI toolbar and watch results populate a Listener in real time; the tree icon turns red if any sampler fails, and expanding a failed sample shows the response code and body that explain why. Once the plan behaves correctly, save it as a .jmx file and switch to running it headlessly for anything beyond a handful of iterations, then open the generated HTML dashboard report to review response time percentiles, throughput over time, and the error rate.
Cricket analogy: Like a coach watching a net session live to spot a batting flaw, then reviewing the full match analytics report afterward for the real numbers, a GUI debug run catches obvious errors while the HTML dashboard gives the real performance picture.
- Build a test plan by adding a Thread Group, then an HTTP Request sampler, then a Listener, in that order under the Test Plan root.
- Thread Group settings — Number of Threads, Ramp-Up Period, Loop Count — define how much virtual load is generated and how gradually.
- The HTTP Request sampler needs server name, method, path, and (for POST/PUT) a body plus a Content-Type header via HTTP Header Manager.
- View Results Tree shows detailed per-request data useful for debugging; Summary Report shows aggregated throughput and response-time statistics.
- Listeners are memory-heavy and should be removed or disabled before running any test with real load.
- Use the GUI's green Start button only for small debug runs; run larger tests headlessly and review the generated HTML dashboard report.
- A failed sample turns red in the tree; expanding it reveals the response code and body needed to diagnose the failure.
Practice what you learned
1. What is the correct order to build a basic JMeter test plan?
2. Which HTTP Request sampler field specifies the endpoint being called, such as /api/orders?
3. Which Listener aggregates throughput, average response time, and error percentage per sampler?
4. Why should View Results Tree be removed before a real load run?
5. What does a red icon on a sample in the results tree indicate?
Was this page helpful?
You May Also Like
The JMeter GUI: Test Plan Structure
A tour of the JMeter GUI and the hierarchical Test Plan tree — Thread Groups, Samplers, Listeners, Configuration, and Assertion elements — and how they execute together.
Thread Groups
How JMeter Thread Groups control the number of virtual users, ramp-up time, and loop behavior that drive load against your system under test.
Installing JMeter
Step-by-step guide to installing Apache JMeter on Windows, macOS, and Linux, including the Java prerequisite and how to verify a working install.