skip to content

Before JMeter's HTTP(S) Test Script Recorder will start, what must the test plan already contain?

level: juniorimportance: must knowfreq 68%

answer

  1. Recording happens in the GUI tree
  2. Added under Non-Test Elements
  3. One dropdown picks the landing node
  4. Its default entry names a controller

basics

~20 s

A Thread Group with a Recording Controller under it. The recorder's Target Controller defaults to Use Recording Controller, and pressing Start with no Recording Controller anywhere in the tree raises an error instead of opening the proxy.

solid answer

~50 s

You add the element from **Add > Non-Test Elements > HTTP(S) Test Script Recorder**, so it sits beside the Thread Groups rather than inside one, and it listens on port `8888` unless you change the Port field. Where the generated samplers land is decided by the **Target Controller** dropdown: its first entry is *Use Recording Controller*, and the rest of the list is every Controller in the tree, shown by its path. With *Use Recording Controller* selected, JMeter looks for the first **Recording Controller** in the tree and stores samplers under it; if there is none, Start shows an error telling you to add one as a child of a Thread Group and the proxy never opens. A Recording Controller is only a marker — at run time it behaves like a Simple Controller. `File > Templates... > Recording` builds the whole skeleton for you.

code

text · 5 lines
text
Test Plan
├─ Thread Group
│   └─ Recording Controller          <- "Use Recording Controller" finds this one
└─ HTTP(S) Test Script Recorder     <- Non-Test Element, Port 8888
    └─ View Results Tree            <- optional: shows every request the proxy saw

go deeper

for a junior

Be able to name the menu path, the default port 8888, and the fact that a Recording Controller has to exist before Start will work. Knowing the bundled Recording template exists is a cheap win.

for a middle

Explain the Target Controller dropdown properly: default entry, the list of every Controller by path, and that the Recording Controller is inert at run time. Say what Start does when the target cannot be resolved.

for a senior

Show how you organise recording sessions in practice — one Recording Controller per journey, aiming the target at a fresh one for the next capture, and a View Results Tree under the recorder to see what was filtered.

for a principal

Own the convention: whether recorded output is allowed into a committed plan at all, and where it must be rehoused before it is. The recorder decides tree shape, so leaving it unspecified is how plans drift apart across a team.

JMeter's recorder is a GUI-time tool. It is an HTTP(S) proxy that JMeter runs inside the same JVM as the GUI, and everything it produces is written into the **in-memory test tree** you are looking at — not into a file, and not during a run. That single fact explains the whole setup ritual. ## Adding the element The recorder lives under **Add > Non-Test Elements > HTTP(S) Test Script Recorder** on the Test Plan node. "Non-test element" is the important part: it is not a sampler, not a config element, and it takes no part in a run. The stock port is `8888`, which is what you point the browser's HTTP and HTTPS proxy settings at. Only HTTP and HTTPS go through it — JMeter cannot proxy FTP or anything else, so do not set the browser's global proxy to it if the browser also speaks other protocols. ## Where the samplers land The **Target Controller** dropdown is the answer to "where do the recorded requests go": - the first entry is **Use Recording Controller** — the default, meaning "find the landing spot yourself"; - every other entry is a Controller that already exists in the tree, listed by its full path (`Test Plan > Thread Group > Checkout`), so you can also aim the recorder straight at a Transaction Controller or a Simple Controller. With **Use Recording Controller** selected, JMeter searches the tree for the first **Recording Controller** and adds the samplers under it. The Recording Controller itself is a placeholder: the manual is explicit that during a test run it has no effect, in the same way a Simple Controller has none. Its whole job is to be findable, and to give the recorded steps one obvious home you can name after the journey — `Guest checkout`, say. ## What happens when it is missing This is the part candidates usually get wrong. If the Target Controller is left on *Use Recording Controller* and no Recording Controller exists, the recorder does **not** quietly fall back to the Thread Group and it does not start and drop traffic. Pressing **Start** raises an error dialog — "Target Controller is configured to \"Use Recording Controller\" but no such controller exists" — and the proxy is never opened. Nothing is listening on the port, so the browser fails to load anything at all, which is a confusing symptom if you did not read the dialog. ## The rest of the start-up sequence Once the target check passes, Start does three more things worth knowing about: 1. it initialises the keystore, generating certificates if this is the first run — the GUI is unresponsive for a moment and the cursor turns to an hour-glass; 2. it opens the listener and logs that the recorder is up; 3. it shows an informational pop-up with the root CA details, which matters only for HTTPS recording — it appears once the proxy is already accepting connections, only when dynamic certificate mode is on, and it closes itself after about seven seconds. **Stop** shuts the proxy down; **Restart** stops and restarts it, which is what you use after editing a filter pattern, because the filters are read when the proxy starts. ## The shipped skeleton You rarely need to build this by hand. `File > Templates...` offers a **Recording** template (and a **Recording with Think Time** variant) whose plan already contains a Test Plan, an HTTP Request Defaults, an HTTP Cookie Manager, a Thread Group with a Recording Controller under it, a View Results Tree, and a pre-configured but disabled HTTP(S) Test Script Recorder with a long list of exclude patterns already filled in. Starting from it removes every one of the mistakes above. ## Practical shape of the tree A minimal working arrangement is: - **Test Plan** - **Thread Group** — holds the journey you are about to record - **Recording Controller** — the landing spot - **HTTP(S) Test Script Recorder** — outside the Thread Group - **View Results Tree** — optional, shows what the proxy actually saw Putting a View Results Tree as a child of the recorder is the standard way to watch requests arrive, including ones that were filtered out of the plan. Adding a second Recording Controller and switching the Target Controller to it lets you record a second journey without disturbing the first.

  • Can you point the recorder somewhere other than a Recording Controller?
    Yes. The Target Controller dropdown lists every Controller in the tree by its path, so you can record straight into a Transaction Controller, a Simple Controller or a Thread Group. Choosing a node explicitly is also how you record a second journey into a fresh controller without touching the first one.
  • JMeter also offers Tools > Import from cURL. When is that the better way in?
    When you already have the request rather than a browsing session — a cURL line copied out of browser devtools or pasted into a bug report. The dialog accepts commands typed in or read from a file, handles several at once, and builds HTTP Requests from them; options it cannot map are written into the sampler's Comment field.

saying these in an interview costs you the question

  • Thinks the recorder runs during a non-GUI load test
  • Believes the recorder writes samplers straight into the .jmx file on disk
  • Assumes recorded samplers land wherever the tree selection happens to be
  • Says the Recording Controller replays its children as a group at run time
  • Cannot say what happens when no Recording Controller exists