Protocol Bot Scripting

Import JMeter, k6, and Locust Scripts

If you already have load test scripts from another tool, Loadster can import them so you don’t have to start over. The importer accepts:

  • JMeter test plans (.jmx, or .xml)
  • k6 scripts (.js)
  • Locust locustfiles (.py)

Each import produces a protocol script for Protocol Bots, with HTTP steps, wait steps, and sometimes JavaScript Code Blocks. There’s no importer for Browser Bot or Playwright scripts, and there’s no LoadRunner (VuGen) importer.

Every tool has its own concepts that don’t map one-to-one, so the importer also gives you a report of anything it couldn’t translate or had to approximate. Expect to review the script and play it at least once before you load test with it.

Importing a Script into Loadster

You can start an import from a few places:

  • On your project’s Scripts tab, open the Create Script menu and choose Import Script.
  • In the protocol script editor, click Import in the toolbar to import into the script you have open.
  • On a brand new account with no projects yet, the dashboard’s quick start offers a tile for each tool.

The import dialog asks for:

  • External Tool: JMeter, k6, or Locust.
  • External File: the file to import. You can’t paste a script into the dialog, so save it to a file first.
  • Destination Script Name: the name for the new script, filled in from the file name. When you import into an existing script, you choose instead whether to Append the imported steps to the end of the script or Replace its contents.
  • Base URL (optional): a host such as https://example.com. Some scripts use relative paths and set the host somewhere the importer can’t see (a command line flag, an environment variable). If yours does, enter the host here, and Loadster puts it in front of any relative request URLs.

When the import finishes, the dialog links to the new script, plus any scenario or datasets the import created, and shows the import report.

Reviewing the Import Report

The import report has two lists:

  • Some items might need your attention: things you’ll probably need to fix by hand, like a CSV dataset that needs its rows uploaded, an assertion that couldn’t be converted, or Groovy code that needs rewriting in JavaScript.
  • Other notes: informational entries for what was converted and how, such as which requests were imported or that a random think time became a fixed wait.

Each entry names the part of the original script it came from, so you can find it in both places. Work through the first list before you run a load test. The second list is worth a skim, especially the approximations.

Importing JMeter Test Plans (.jmx)

The JMeter importer reads the test plan’s XML and converts its HTTP Request samplers into HTTP steps, including the method, URL, query parameters, request body, and headers.

What comes across from a JMeter test plan:

  • HTTP Request samplers become HTTP steps. Other sampler types (JDBC, TCP, and so on) aren’t converted.
  • HTTP Header Manager headers become request headers, either on every following request or on a single request, depending on where the Header Manager sits.
  • HTTP Request Defaults supply the protocol, host, and port for requests that don’t have their own.
  • Extractors become capturing rules: the Regular Expression Extractor becomes a regex rule, the Boundary Extractor a text boundary rule, the JSON Extractor a JSONPath rule, and the XPath Extractor an XPath rule.
  • Assertions become validation rules: Response Assertions on the status code or response text, Duration Assertions, Size Assertions, JSON Assertions, and XPath Assertions. A few variants are approximated, such as a “matches” Response Assertion, which becomes a JavaScript validation rule, and the report says so.
  • Timers (constant, uniform random, and Gaussian random) become wait steps. Random timers become a fixed wait of their average delay.
  • Transaction Controllers become a comment step followed by their requests, since transactions are only labels in Loadster.
  • If, While, Loop, and ForEach Controllers become a code block that makes the same requests in JavaScript. Assertions and extractors inside those controllers aren’t carried into the code block, so review it carefully.
  • CSV Data Set Config creates an empty dataset named after the CSV file and rewires the script’s ${column} references to it. Upload the rows from your CSV file to finish it.
  • Thread Groups become a new load test scenario, with a bot group for each thread group, using its thread count, ramp-up, and duration.

What doesn’t come across from a JMeter test plan:

  • JSR223 and BeanShell elements (Groovy or BeanShell code) can’t be translated automatically. The importer keeps the original code in a code block, commented out, for you to rewrite in JavaScript.
  • User Defined Variables at the test plan level are left as ${name} references, since Loadster has no global constants. Define them as variables or put the values inline.
  • HTTP Authorization Manager settings aren’t converted. Authentication headers set in a Header Manager do come across.
  • Arrival and throughput thread groups don’t produce a scenario, since Loadster doesn’t model arrival rates. Set up the load in a scenario yourself.
  • Disabled elements are skipped. The Cookie Manager, Cache Manager, and listeners aren’t needed, because Loadster handles cookies and caching automatically and reports results on its own.

Importing k6 Scripts (.js)

The k6 importer reads your script’s default function without running it, and converts the calls it recognizes.

What comes across from a k6 script:

  • http.get(), http.post(), http.request() and the other request functions become HTTP steps, including headers from the params object. URLs and bodies that are string literals or string constants come across as they are, and template literals like `${BASE_URL}/api` keep their ${...} references.
  • sleep() becomes a wait step. Note that k6 sleeps in seconds and Loadster waits in milliseconds; the importer converts it for you.
  • check() predicates that test the status code (r.status === 200) become status validation rules, and those that test .includes('text') become text validation rules. Other checks are listed in the report to add by hand.
  • res.json('path') assignments become JSONPath capturing rules.
  • group() becomes a comment step followed by the grouped steps.
  • options.stages, or options.vus with options.duration, become a new load test scenario. Stage durations are rounded up to whole minutes.

What doesn’t come across from a k6 script:

  • Other logic (conditionals, loops, other function calls) is copied as-is into JavaScript Code Blocks. Code blocks look a lot like k6, but the functions aren’t identical, so review them. For example, sleep takes milliseconds and the response body is response.string().
  • setup() and teardown() functions aren’t imported.
  • Request params other than headers, such as tags, timeouts, and auth, aren’t imported.
  • options.scenarios, thresholds, and iterations aren’t read.
  • Request bodies built from expressions, rather than string literals or constants, need to be set by hand.

Importing Locust Scripts (locustfile.py)

The Locust importer scans your locustfile for an HttpUser or FastHttpUser class and imports each @task method, plus on_start and on_stop, in the order they appear in the file.

What comes across from a Locust script:

  • self.client.get(), post(), and the other client methods become HTTP steps, including json=, data=, and headers= arguments. Each call needs to fit on one line.
  • host on the user class is used as the host for relative URLs.
  • f-strings in URLs keep their references, so f"/items/{item_id}" becomes /items/${item_id}.
  • r.json()["key"] assignments become JSONPath capturing rules.
  • wait_time (between, constant, or constant_pacing) becomes a wait step after each task, using the average of a between range.
  • Each task starts with a comment step naming it.

What doesn’t come across from a Locust script:

  • Other lines of Python aren’t converted. Each one is listed in the report, so you can recreate it as a step or a code block.
  • Locust picks tasks at random (optionally weighted), but a Loadster script runs its steps in order. If your locustfile has several tasks, reorder them, or split them into separate scripts and bot groups.
  • Users and spawn rate come from the Locust command line or a load shape, not the file, so no scenario is created. Build a matching load test scenario yourself.
  • params=, name=, auth=, and other keyword arguments aren’t imported, so add query parameters to the URL by hand.
  • JSON bodies are copied from the Python source text, and a Python dict isn’t always valid JSON (single quotes, for example), so check them.

Importing Scripts With an AI Assistant Over MCP

If you’ve connected an AI assistant to Loadster’s MCP server, it can import scripts too. The import_script tool takes the file’s contents as text and imports it into an existing script, returning the same items that need attention. This is handy when the assistant can read the file from your repository, since it can then work through the report with you.

After Importing a Load Test Script

An imported script is a starting point. Before you load test with it:

  1. Work through the import report, starting with the items that need your attention.
  2. Upload rows to any datasets the import created. They start out empty.
  3. Play the script in the editor with a single bot and look at each step’s response. This catches missing hosts, bodies that need fixing, and session values that need a capturing rule.
  4. Review the scenario the import created, if there is one, before you launch a test with it. Loadster bases it on the original script’s load settings, but it’s worth confirming the bot counts, ramp-up, and duration.

If your original script was recorded from a browser, it’s sometimes quicker to record a fresh script with the free browser extension, or to write a browser script that tests the site with real browsers.