JMXPress

Recording a journey#

Capturing a real journey through a browser and turning it into a JMeter plan, rather than writing one by hand.

How it works#

Recording starts a capture proxy and opens a browser pointed at it. Both of those have to happen near you, not on the server — a browser opened on a shared server is invisible to whoever clicked and points at a network that server may not even reach.

So there are two ways to record:

  • On the machine running JMXPress, if you are using it on your own desktop.
  • Through an agent on your own machine, which is the usual case when JMXPress is on a shared server. See Distributed agents for pairing one.

Either way the capture itself is identical: the agent downloads the same capture addon the server uses, so a recording made through an agent is the same shape as one made locally, and every downstream feature reads it without knowing which it was.

Recording#

  1. Open Recording → Browser Recording.
  2. Choose where to record — this server, or one of your paired computers.
  3. Press Start recording. A browser opens with a throwaway profile, already pointed at the capture proxy.
  4. Walk through the journey.
  5. Press Stop.

The capture proxy is bound to 127.0.0.1 explicitly, so even on your own machine it is not a proxy the rest of the network can use.

Naming transactions#

A recording is a long list of requests. What makes it a readable test plan is grouping them into transactions — Sign in, Search, Checkout.

You can name them while recording or afterwards from the captured list. Requests that belong to no transaction are still captured; they simply sit outside the named groups.

Filtering out what you do not want#

A real journey picks up analytics beacons, font requests and third-party calls that have nothing to do with the application under test. Filter them out before generating the plan, or the test spends its load on somebody else's CDN.

Masking credentials#

There is an option to mask passwords, tokens and cookies in the stored capture. It replaces Authorization, Cookie, Set-Cookie, API-key headers and sensitive query values with ***masked***.

Careful It is off by default, and that is a deliberate trade rather than an oversight. Those values are load-bearing: masked, the generated plan will not run until somebody supplies them again. Turn it on for a journey whose credentials should not be stored at all, and expect to re-supply them.

Redaction of logs and the audit trail is unconditional and separate — nothing there needs the real value.

Turning it into a plan#

From the captured session, generate the plan. You get a JMeter .jmx with the transactions you named, the requests you kept, and the headers they carried.

From there it is a plan like any other: put it in a project, or run it straight away from the Run page.