J-Meter

Creating a Script :

I’ll use https://dummyjson.com/ (a public API for testing) so you can run it without needing a private server.

📌 Scenario

Login with username & password
Search for a product
Logout

Step-by-Step JMeter Script

1️⃣ Create a New Test Plan

Open JMeter → File → New
Right-click Test Plan → Add → Threads (Users) → Thread Group
- Number of Threads (users): 5
- Ramp-Up Period: 10 seconds
- Loop Count: 1

2️⃣ Add HTTP Request Defaults

Right-click Thread Group → Add → Config Element → HTTP Request Defaults
- Server Name or IP: dummyjson.com
- Protocol: https

This avoids repeating the base URL for every request.

Right-click Thread Group → Add → Sampler → HTTP Request

Name: Login
Method: POST
Path: /auth/login
Body Data:
```
  {
    "username": "kminchelle",
    "password": "0lelplR"
  }
```
- Click "Body Data" tab and paste above.
- Add HTTP Header Manager (Right-click Login → Add → Config Element → HTTP Header Manager):
  - Name: Content-Type
  - Value: application/json

4️⃣ Extract Auth Token

Right-click Login → Add → Post Processors → JSON Extractor
- Variable name: authToken
- JSON Path Expressions: token

This stores the token for later requests.

5️⃣ Add Search Request (GET)

Right-click Thread Group → Add → Sampler → HTTP Request
- Name: Search Product
- Method: GET
- Path: /products/search
- Parameters:
  - Name: q
  - Value: phone
Add HTTP Header Manager here:
- Name: Authorization
- Value: Bearer ${authToken}

6️⃣ Add Logout Request (POST)

(Since the API doesn’t have a logout endpoint, we’ll simulate it)

Right-click Thread Group → Add → Sampler → HTTP Request
- Name: Logout
- Method: POST
- Path: /auth/logout
- Body Data:

{
  "token": "${authToken}"
}

7️⃣ Add Listeners

Right-click Thread Group → Add → Listener → View Results Tree
Add → Listener → Summary Report

8️⃣ Save & Run

Save as LoginSearchLogout.jmx
Click Start ▶
View the responses in "View Results Tree" and stats in "Summary Report".

📊 Flow Diagram

Test Plan
 └── Thread Group (5 users, Ramp-Up 10s)
      ├── HTTP Request Defaults (dummyjson.com)
      ├── HTTP Request: Login
      │    ├── HTTP Header Manager
      │    └── JSON Extractor (authToken)
      ├── HTTP Request: Search Product
      │    └── HTTP Header Manager (Authorization)
      ├── HTTP Request: Logout
      ├── View Results Tree
      └── Summary Report

If you want, I can prepare the full .jmx file for you so you can just import it into JMeter and run without doing all these steps manually. That way you can see a working real-time example immediately.

Result Tree Elements

Left Panel

This shows the execution tree of all your samplers (requests) for the current test run.
✅ Green tick → request succeeded (HTTP status 200 or equivalent).
Login-1 here means it’s the second iteration of your Login request (because loop count > 1 or multiple users/threads were used).

Sampler result (Right Panel)

Thread Name: Thread Group 1-1
- First number (1) → Thread Group number.
- Second number (1) → Thread (user) number.
  So, this was executed by the first virtual user in Thread Group 1.
Sample Start
- Timestamp when JMeter started sending the request.
Load time: 134
- Total time taken (in milliseconds) from sending request → receiving full response.
- 134 ms = 0.134 seconds.
Connect Time: 117
- Time taken (in ms) to establish the TCP connection to the server.
Latency: 134
- Time until the first byte of the response was received.
- Here, latency = total load time, meaning the response was received quickly after connection.
Size in bytes: 3403
- Total size of the response (headers + body) from the server.
Sent bytes: 210
- Size of the request you sent.
Headers size in bytes: 164
- Size of HTTP headers in the response.
Body size in bytes: 3239
- Size of the actual response body (JSON, HTML, etc.).
Sample Count: 1
- This request executed once in this result view.
Error Count: 0
- No errors occurred (good sign).
Data type ("text" | "bin" | ""): text
- Response is textual (likely JSON or HTML), not binary.
Response code: 200
- HTTP 200 = success.
Response message: OK
- Standard HTTP OK message.
ContentType: text/html
- The server responded with text/html instead of application/json.
- This might mean the API is returning HTML (or an HTML error page) even though it worked. You’d confirm in the Response Data tab.
DataEncoding: null
- Server didn’t specify a character encoding.

📌 Key takeaways here:

The request was successful (status 200, no errors).
Very fast response (0.134s total).
The content type is text/html, so if you expect JSON, you might need to double-check the API or headers you’re sending.
This is the second login iteration (Login-1).

Summary Report

This is the Summary Report listener in JMeter, which shows aggregated performance statistics for all your samplers.
Let’s break down what each column and row means:

Columns

Label
- The name of your sampler (Login, Search Product, Logout).
- TOTAL → combined stats for all samplers.
# Samples
- Total number of requests sent for that sampler.
- Example: Login has 20, meaning 20 login requests were executed.
Average
- Average response time (in milliseconds) for that sampler.
- Login: 1332 ms (~1.3 seconds average).
- Search Product is much faster at 191 ms.
Min / Max
- The shortest and longest response times recorded for that sampler.
- Example: Login min = 100 ms, max = 8446 ms (8.4 seconds — big jump!).
Std. Dev. (Standard Deviation)
- Measures how much the response times vary from the average.
- Higher = less consistent performance.
- Login’s 2296 ms Std. Dev. shows it’s unstable — some requests are very slow.
Error %
- Percentage of failed requests.
- Login has 50% error rate → half of your logins failed.
- Search Product & Logout = 0% errors.
Throughput
- Number of requests handled per unit of time (default = per minute).
- Login is at 5.2/min → around 1 request every 11–12 seconds.
Received KB/sec
- Data received from the server per second.
- Search Product has higher here (1.77 KB/s) — probably because product list responses are bigger.
Sent KB/sec
- Data sent to the server per second.
Avg. Bytes
- Average size (in bytes) of responses.
- Search Product has huge values (20911.5 bytes ≈ 20 KB) compared to Login (~2.2 KB).

Row Insights

Login → Problem area. 50% errors, unstable response times (min 100 ms, max 8.4 sec). Likely token extraction or credentials issue.
Search Product → Very fast, 0% errors, large response payloads.
Logout → Small, quick, 0% errors.
TOTAL → Average for all requests combined: 574 ms with 16.67% error rate (mostly caused by Login failures).

💡 Why Login errors might be so high
If your ${authToken} is not extracted correctly from Login’s JSON response, the Authorization header for Search Product might fail for half of the logins — depending on timing or server state.

HTTP Test Script Recorder

The HTTP(S) Test Script Recorder in JMeter is basically a built-in proxy recorder that lets you capture real-world browser or app requests and turn them into a JMeter test script.

Think of it as:

"Instead of manually creating HTTP Requests in JMeter, you just perform the actions in your browser/app, and JMeter records them into your test plan."

What It Does

Acts as an HTTP proxy between your browser/app and the server.
Captures:
- URLs
- Methods (GET, POST, etc.)
- Parameters
- Headers
- Cookies
Converts them into HTTP Request Samplers in JMeter.

⚙ Steps to Use HTTP(S) Test Script Recorder (Real-Time)

1️⃣ Prepare Your Test Plan

Create a Test Plan in JMeter.
Add a Thread Group inside it.
Inside Thread Group, add a Recording Controller:
Right-click Thread Group → Add → Logic Controller → Recording Controller
(This is where recorded requests will be stored).

2️⃣ Start the Recorder

From JMeter’s menu:
File → Templates → Select “Recording” → Create
(This automatically adds the HTTP(S) Test Script Recorder and configures basics)
OR
Manually:
- Add HTTP(S) Test Script Recorder:
  Right-click Workbench → Add → Non-Test Elements → HTTP(S) Test Script Recorder.
- Set Port (default 8888).
- Set Target Controller → your Recording Controller.
- Click Start → JMeter will show a security warning about the certificate.

3️⃣ Install the JMeter Root Certificate (For HTTPS)

The first time you start the recorder, JMeter creates a ApacheJMeterTemporaryRootCA.crt file in the bin/ folder.
Install this certificate in your browser/system:
- Open Chrome → Settings → Security → Manage Certificates → Import → Select the .crt file.
- Mark it as trusted for website identification.
This step is required to capture HTTPS traffic.

4️⃣ Configure Browser Proxy

Open your browser’s proxy settings:
- Manual Proxy Configuration
  - HTTP Proxy: localhost
  - Port: 8888 (or whatever you set in the recorder)
This routes all browser traffic through JMeter.

5️⃣ Start Recording Actions

In JMeter, click Start on the HTTP(S) Test Script Recorder.
In the browser, visit the site you want to test.
Perform the actions you want to simulate later (login, search, checkout, etc.).
JMeter will capture them and add them as HTTP Request Samplers inside the Recording Controller.

6️⃣ Stop Recording

In JMeter, click Stop on the recorder.
Turn off browser proxy or switch back to system default.

📍 Real-Time Example

Let’s say we want to test https://dummyjson.com login & search:

Start Recorder (port 8888), import the certificate.
Set browser proxy to localhost:8888.
In browser:
- Open https://dummyjson.com
- Send POST request for login (via Postman or frontend)
- Search for a product.
Stop recorder.
Your Thread Group will now have:
- HTTP Request (Login)
- HTTP Request (Search)
You can edit parameters, add assertions, loop counts, and run the test with many users.

💡 Best Practices

Filter requests: Use “URL Patterns to Include/Exclude” in the recorder to avoid capturing irrelevant requests (like ads, analytics scripts).
Group by Transaction Controller: Makes test plan more readable.
Replace static values with variables for reusability.
Always remove sensitive data before saving the test.

Once recorded, we can do many things with the Recorder result , such as :

Once you’ve stopped recording and disabled the proxy, you now have a raw recorded test script in your Recording Controller.
Here’s how you can turn it into a proper load test by editing parameters, adding assertions, setting loops, and adding users:

1️⃣ Edit Parameters

Expand your Recording Controller in the Thread Group.
Click on each HTTP Request sampler you recorded.
Go to the Parameters tab:
- Change any hardcoded search terms, credentials, etc.
- You can replace them with JMeter Variables (e.g., ${username}, ${authToken}).
- Example: If you recorded /products/search?q=phone, you can change Value from phone to ${searchTerm} and define that in a User Defined Variables config element.

2️⃣ Add Assertions

Assertions validate that the server’s response is correct.

Right-click a sampler → Add → Assertions → Response Assertion.
In "Patterns to Test," add text that must appear in the response (e.g., "Login successful", "products", "token").
This way, if the server returns an error page, JMeter marks the request as failed.

3️⃣ Set Loop Counts

Click your Thread Group.
Find Loop Count:
- If you want the same user to repeat the scenario multiple times, set it here (e.g., Loop Count = 5 means each thread will run the script 5 times).
- You can also check Forever for continuous load until you stop the test.

4️⃣ Run the Test with Many Users

Still in Thread Group:
- Number of Threads (users) → Set the number of virtual users (e.g., 50).
- Ramp-Up Period (seconds) → Time to start all threads (e.g., 10 means JMeter will start 50 users over 10 seconds).
Example:
```
  yamlCopyEditThreads: 50
  Ramp-Up: 10
  Loop Count: 5
```
→ 50 users will start over 10 seconds, each running the test 5 times.

5️⃣ Add Listeners to See Results

Right-click Thread Group → Add → Listener → View Results Tree (for debugging).
Also add Summary Report or Aggregate Report for performance metrics.

6️⃣ Run the Test

Click the Start button (green triangle).
Monitor errors, response times, and throughput in the listeners.
If your assertions fail, they’ll appear as red in the results.

Command Palette