Running a test#

Execution → Run. Everything a test needs is decided on this page, and nothing is kept unless you save it.

Choosing what to run#

Three ways, in order of how often you will use them:

A project plan. Pick the project and the plan. Its environments and bound test data come with it.
A file. Drag a .jmx onto the page, or browse for one. Nothing is saved by running it this way.
From History. Open an earlier run and start from what it used.

Load profile#

Setting	Leaving it empty means
Threads	The plan's own thread count
Ramp-up	The plan's own ramp
Loops or duration	Whatever the plan says

Leaving a box empty uses the plan's own setting, which is usually right the first time. The Load profile card shows the shape of the load before anything runs, so a ramp that is wrong is visible rather than discovered twenty minutes in.

Where a plan has several thread groups, each gets its own settings.

Test data#

JMXPress reads the plan to find which CSV files it needs and names them before the run starts. If one is missing you are told then.

Careful A missing CSV does not usually stop JMeter. It sends the literal ${username} to your application and the test "passes" while measuring nothing useful. This check exists because that failure is quiet.

For a project plan the bound files are used automatically. For an upload, attach the CSVs on the page.

Where it runs#

Where it runs chooses the machine or machines generating load:

This server — the machine JMXPress is installed on.
One or more paired computers — see Distributed agents.

With several machines, the load settings can be set per agent, so an uneven set of machines is not forced to carry an even share.

Network profile#

A network profile shapes the connection the load is generated over, to approximate a slower link. It is a property of the run, not of the plan.

Monitoring#

Collect APM metrics while this test runs switches on server-side monitoring. Choose a connection, and optionally a saved dashboard, before starting; see APM integrations.

What you choose here is fixed for the run. Editing the connection midway through a test does not change what that test recorded.

Reports by email#

Email the report when the test finishes sends the generated report to the addresses you give. This needs mail to be configured on the installation; if it is not, the page says so rather than silently not sending.

Scheduling#

Start this test later instead of now keeps the plan and its test data on the server and starts the run on its own. You do not have to stay signed in or leave the page open.

Scheduled runs have their own retention setting for how long their results are kept.

While it runs#

See Live results.

Stopping#

Stop ends the run. The results written so far are kept and can still be analysed — a stopped run is reported as stopped rather than as completed, which is the one thing a report must not get wrong.