Playwright 與 Gatling：從瀏覽操作建立負載測試

You can now build a Gatling load test by browsing your app. Walk your user journey in a Playwright browser, and your AI coding agent turns the recording into a correlated Gatling test that replays it.

The first script has always been the slowest part of load testing. You dig through the browser's network tab, work out which API calls matter, and chain IDs and tokens by hand. A recorder speeds up the capture, but the IDs and tokens it hardcodes fail on the next run. Written by hand, a first working test takes days. Recorded, it takes hours. With Playwright and Gatling's AI skills and MCP server, it takes minutes.

Key takeaways

Playwright + Gatling

Quick start

You'll need:

• A 64-bit OpenJDK LTS from 11 to 25
• Node.js 24 or later
• A coding agent (the docs use Claude Code)
• Gatling AI extensions plugin
• Install playwright-cli

npm install -g @playwright/cli@latest playwright-cli install --skills --global

The second command installs the skill for Claude Code. For other agents, use --skills agents.

Start your agent from an empty workspace folder:

cd ~/path/to/your/workspace claude

Paste the prompt from the docs verbatim. It sets the page where the journey starts, the API base URL to model, and the guardrails that keep the capture reliable.

A headed browser opens on the site. Before each action, post a step marker in the chat and wait for the agent to confirm. Type done when you're finished:

starting: browse the catalogue starting: add first product to cart starting: unauthenticated checkout starting: login starting: authenticated checkout done

The agent writes a Gatling Java/Maven project in a new directory, compiles it and runs it once with a single user:

./mvnw gatling:test

On Windows, use mvnw.cmd gatling:test. When the local run passes, one more prompt starts it on Gatling Enterprise:

> Deploy and start the test on Gatling Enterprise

How it works

Capture: you browse, the agent saves each step

The agent opens a headed browser with playwright-cli, which lists the network requests of your session. Requests sent before your first marker form a first step, initial load. Each starting: marker ends the current step: the agent saves its requests to discovery/, clears the list and confirms. There is no timeout between steps, and steps don't imply each other, so you can abandon a flow halfway. A typical e-commerce journey:

1. Initial load (saved automatically, before your first marker)
2. Browse the catalogue
3. Add the first product to the cart
4. Try to check out without being logged in
5. Log in
6. Check out again, authenticated

Every request of a step is listed, static assets included. Only calls to the API base URL set in the prompt get their full request and response saved, and only those make it into the test.

Analysis: the agent works from the saved files

Once you type done, the agent closes the browser and works only from discovery/. Capture and analysis are separate on purpose: the agent sees the whole recording before deciding what matters, which gives better correlations, and it can re-check the capture without asking you to redo the journey.

It maps each API call to the step you named and turns every step into a block of the Gatling scenario, in the order you walked them. In the demo journey, 8 API calls map to 6 steps.

Dynamic values are handled for you. IDs and tokens are extracted from responses and reused, not hardcoded, so the test keeps working when the data changes. Checks follow your step names: a step called "unauthenticated checkout" gets an expected 401. Because the check expects it, Gatling counts that 401 as OK, not as an error. The agent also adds an assertion that fails the run if any request fails.

// Excerpt: request bodies and setUp omitted ScenarioBuilder ecommJourney = scenario("Ecomm journey")  .group("02 - browse the catalogue").on(http("GET /products").get("/products?page=1")    .check(jsonPath("$.products[0].id").saveAs("firstProductId")))  .group("03 - add first product to cart").on(http("POST /cart").post("/cart")    .check(jsonPath("$.cart[0].id").isEL("#{firstProductId}")))  .group("04 - unauthenticated checkout").on(http("POST /checkout").post("/checkout")    .check(status().is(401)))  .group("05 - login").on(http("POST /login").post("/login")    .check(jsonPath("$.accessToken").saveAs("accessToken")))  .group("06 - authenticated checkout").on(http("POST /checkout").post("/checkout")    .header("authorization", "#{accessToken}")    .check(status().is(200)));

You stay in control throughout. If a request can't be cleanly attributed to one step, or a step looks like it's missing requests, the agent asks you before going further. Depending on your agent settings, it asks for approval before each command it runs, and the output is plain Java you can review.

Replay: run it locally, then scale it

The agent runs the test once locally with the Maven wrapper (./mvnw gatling:test), with one virtual user and the steps in the order you walked them. In the demo, that first run returns 8 requests, 8 OK, 0 KO and BUILD SUCCESS. You know the journey replays before you add load.

One more prompt takes it to Gatling Enterprise. The agent writes the configuration as code, asks a few questions (reuse a package, pick a load generator location, add stop criteria), packages the project and starts the run. It returns a link to the live report.

Why replay the API, not the browser

Playwright is also used to load test with real headless browsers as virtual users. That approach measures what a user perceives, page rendering included, and it is a good fit when front-end performance is the question.

The cost is compute. Every virtual user is a full headless browser, so CPU and memory grow with each user you add. Here Playwright is only the capture tool. The test it produces replays your API traffic on Gatling's async engine, where a single load generator sustains up to 60,000 concurrent virtual users, depending on protocol complexity and service architecture.

Workflow comparison

Or let the agent drive

You can also describe the journey in the prompt and have the agent walk it itself with playwright-cli in a headless browser. Capture and analysis then happen in a single pass, with no browser window and no discovery/ folder. On the demo site, it produces the same API requests as walking the journey yourself.

Driving yourself stays the default, for three reasons. The agent picks its own route through the UI, which may not be your users' route. It can get stuck on login flows, CAPTCHAs, bot checks or UI it can't read. And the capture carries a headless browser's User-Agent, with estimated pauses instead of your think times. Let the agent drive for public journeys you can describe in a sentence.

Requirements, limits and gotchas

• Coding agent. It must support MCP servers and skills. Claude Code, Cursor, Codex, Windsurf and Antigravity do.
• Gatling Enterprise API token. The skills and MCP server need a token with at least the Configure role, set as GATLING_ENTERPRISE_API_TOKEN.
• Java and Node.js. You need a 64-bit OpenJDK LTS from 11 to 25, and Node.js 24 or later for playwright-cli. Maven is optional, since the project ships with the Maven Wrapper. The generated project is Java/Maven.
• It tests your API, not the page. Only calls to the API base URL in your prompt end up in the test. If your front end calls several APIs, list them all. Front-end rendering time is not measured.
• Marker first, then click. Wait for the agent's confirmation before you act. Traffic sent before a marker belongs to the previous step.
• One step per full page load. playwright-cli lists the requests of the current page only, so a full page load in the middle of a step loses the requests sent before it, and the agent can't detect it. Route changes in a single-page app are fine.
• discovery/ holds real session data. That includes cookies, tokens and the credentials you typed. Record on a test or staging environment with a test account, and review the folder or add it to .gitignore before you commit.
• The first test is a smoke test. It runs one virtual user. To add load, edit the injection profile in the simulation's setUp. For a public web app, use an open model (an arrival rate, such as rampUsersPerSec), so a slowdown shows up instead of being masked.

See it live on December 10

Heather Thacker, Developer Advocate at Gatling, builds a load test from an empty folder on Thursday, December 10, 2026, at 6 PM CET / 12 PM EST. In 60 minutes with live Q&A, you'll see:

• How to turn a browser session into a Gatling simulation, with step markers naming each part of the journey
• How prompt guardrails keep generated tests accurate, with tokens and IDs extracted instead of hardcoded
• How to go from a one-user smoke test to a load test on Gatling Enterprise

It's free. Can't make it live? Register and we'll send you the recording.