Scriptless test builders

Every test type in MaxoPerf has a Scriptless builder action alongside Upload script. Instead of bringing a .jmx, a k6 script, or a Selenium file, you build the scenario in the console. MaxoPerf renders the underlying test from what you build. You can inspect the generated scenario at any time, and switch back to file upload later if you outgrow the builder.

Create and run your first load test.

The three test types share two builders:

• The HTTP request builder powers both Performance API tests and Functional API tests. The request model is the same. The card you started from sets the load profile (continuous VUs vs. a single locked iteration).
• The Browser step builder powers Browser tests.

HTTP request builder

Used for performance tests and functional API tests. Build a sequence of HTTP requests and configure each one on its own:

The HTTP request builder. Add requests to the sequence and configure each one without writing a script.

For each request in the sequence:

Field	Notes
Method	GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS
URL	Query parameters can be typed inline or added as separate rows
Headers	Literal values, or bound to a workspace secret. The builder never shows secret values again
Body	application/json, application/x-www-form-urlencoded, text/plain, or application/xml
Assertions	Status code, body-contains (one or more literal strings), and JSON path (with an optional expected value)

Order matters

Requests run in the order you add them. On a functional API test, the whole sequence runs once. On a performance test, it runs once per iteration, per virtual user.

You can also type what you want instead of filling the fields: see Describe with AI.

For a browser test you can also write the journey as numbered sentences and let a real browser turn them into steps: see AI steps.

The builder enforces the same abuse limits as the API: up to 50 requests per test, 50 headers and 50 query parameters per request, and a 256 KB body cap.

Browser step builder

Used for browser tests. Drag steps from a palette onto a canvas to build one or more transactions inside one or more scenarios. A transaction is a named group of steps, similar to a JMeter transaction controller:

The browser step builder. Drag steps from the palette to build transactions without writing Selenium or Playwright code.

The step palette groups steps by category:

Category	Example steps
Navigation	Go to URL, open/switch/close window, switch frame, maximize/resize window
Interaction	Click, double click, type, send keys, select an option, drag and drop, submit
Wait	Wait for a condition, pause for a fixed duration
Assertion	Assert text, assert value, assert title, assert page contains, assert JavaScript expression
Store	Store text, value, title, a literal string, or a JavaScript expression into a variable
Output	Take a screenshot, run arbitrary JavaScript, clear cookies, echo a string
Control flow	If / else, loop, for-each element, loop over a data file

1. Add a scenario and a transaction. A scenario groups the transactions that make up one flow. A browser test can have multiple scenarios.
2. Drag steps onto the canvas from the palette, or use the Frequently used shortcuts once you’ve added a few.
3. Configure each step. Most interaction, wait, and assertion steps need a locator (how to find the element) plus a value (text to type, condition to wait for, expected text, …).
4. Reorder or nest steps. If, Loop, For each element, and Loop over data are containers that hold their own child steps.
5. Preview the generated scenario before saving, and adjust scenario-level settings (browser, viewport) alongside the canvas.

You can also import a MaxoPerf Recorder session into the builder instead of starting from an empty canvas. Record yourself clicking through the flow in the browser extension, import the captured steps as a starting point, and keep editing them in the canvas.

Assert page contains

Assert page contains checks that the text of the page, as a visitor sees it, includes (or, with negate, does not include) the text you give it. It needs no locator.

• Match is contains or regex. contains ignores differences in whitespace (runs of spaces and line breaks count as one space); regex is tested against the raw page text, so use [\s\S] to span lines. Turn on ignore case for case-insensitive matching.
• Negate flips the check: the step fails when the text is on the page, for example to catch a Fatal error message.
• The text or pattern is at most 500 characters. An invalid regular expression is rejected when you save, and a pattern that hangs the page can stall a run, so keep patterns simple.
• The check reads the visible text of the current frame at run time (after a switch frame step, that frame; frames are never merged), and of the top frame while AI steps compile.
• A miss fails the step, but only after waiting up to about 5 seconds for the text to appear. For longer waits, add a Wait for or Pause for step first.

Recorder behavior

The MaxoPerf Recorder is predictable about what it captures, so nothing is silently lost:

• Only the tab where you press Record is recorded. Other tabs, including tabs the page opens, are ignored and the panel tells you how many were skipped. Closing the recorded tab pauses the recording; open the page you want to continue on and press Resume to record that tab instead.
• Content inside iframes and shadow DOM is not captured. The panel counts every action it could not capture, per reason, so you can add those steps by hand with Add step.
• Every step shows what it supports. Each step carries a badge for the Taurus, Playwright and Selenium exports and for in-panel replay. A step a format cannot express is marked and explained, never dropped without notice.
• Replay asks before it uses a secret or runs custom code. Replaying a recorded password step prompts you once for the value, which is kept in memory for that replay only and never saved or exported. Steps that run your own JavaScript (script, assert-expression and store-expression steps) show the exact code and ask for your consent every time they run. Anything skipped or failed during a replay is listed in the replay summary with its reason.
• Empty transactions are skipped when you save, preview or export, and the panel says how many.

Where to go next

Performance tests Load-test with the HTTP request builder.

Functional API tests Single-iteration correctness checks with the same builder.

Browser tests Real-browser tests with the step builder.

Executors When you outgrow the builder and want to bring your own script.