Taurus: a YAML-first automation layer over JMeter, Gatling and Selenium

A YAML layer over JMeter, Gatling, Locust.io and Selenium WebDriver

Taurus is a Python package that sits between a test engineer and the tool doing the actual work. Its purpose, as stated in the README, is to hide the complexity of performance and functional tests with an automation-friendly convenience wrapper. Four engines carry the load: JMeter, Gatling, Locust.io and Selenium WebDriver.

Writing a load test in raw JMeter means opening a GUI, configuring thread groups and samplers, and exporting an XML file. Writing the same test in Gatling means learning a Scala simulation class. Taurus replaces both entry points with a YAML file and a single command, bzt. An engineer who knows YAML does not need to understand JMeter's internal model or Gatling's DSL to run a scenario through either engine.

That layering has a practical consequence. Each underlying engine still needs to be installed and working on the host machine. Taurus delegates execution rather than reimplementing it, so the gap between a correct YAML file and a passing test still includes the engine's own installation requirements, its version constraints and whatever runtime it depends on. Platform-specific installation details for Linux, Mac OS and Windows live at gettaurus.org/docs/Installation.md.

pip install bzt and a ten-user scenario in one YAML file

Taurus is published on PyPI under the package name bzt. The README gives a single install command.

pip install bzt

After installation, the getting-started example defines a file named test.yml with two top-level keys: execution and scenarios. The execution block specifies the load shape, the scenarios block holds the list of HTTP requests, and running bzt test.yml starts the test.

---
execution:
- concurrency: 10
  ramp-up: 1m
  hold-for: 1m30s
  scenario: simple

scenarios:
  simple:
    think-time: 0.75
    requests:
    - http://blazedemo.com/
    - http://blazedemo.com/vacation.html

When bzt finishes, it writes summary statistics to the console log and names the directory where all artifact files from the run landed. The example sends ten concurrent users to two URLs at a one-minute ramp and a one-and-a-half-minute hold. For reporting options beyond the console summary, the documentation points to gettaurus.org/docs/Reporting.md. The command-line reference is at gettaurus.org/docs/CommandLine.md.

Concurrency, ramp-up and hold-for define load shape; think-time paces individual scenarios

Three parameters in the execution block control how a load run behaves. Concurrency names the number of virtual users running in parallel. Ramp-up tells the engine how long to take reaching that count from zero. Hold-for sets how long to sustain peak load after the ramp ends. The getting-started example in the README uses 10, 1m and 1m30s respectively, giving a run that completes in roughly two and a half minutes.

Think-time sits in the scenario block, not the execution block. Setting it to 0.75 in the example introduces a pause between requests within the named scenario. Whether that pause applies per virtual user or per request depends on which executor handles the test. The README's getting-started section does not spell out that distinction, and the documentation at gettaurus.org/docs/ is where executor-specific behaviour is described.

A scenario can be shared across multiple execution blocks in the same YAML file. That arrangement lets a single test.yml run the same set of requests at two different concurrency levels without repeating the request list. The requests list in the example accepts URL strings, but each executor supports more structured request definitions for headers, methods and bodies.

jmx2yaml, soapui2yaml and swagger2yaml convert existing test files into Taurus YAML

setup.py registers three converter commands alongside bzt. jmx2yaml takes a JMeter .jmx test plan and converts it to the YAML format Taurus accepts. soapui2yaml does the same for SoapUI project files. swagger2yaml takes an OpenAPI definition and generates Taurus YAML scenarios from the API's endpoint descriptions.

These converters lower the adoption cost for teams with existing test suites. A JMeter project built inside the GUI can become a version-controlled YAML file rather than a binary XML artifact that only JMeter can read. Once in YAML, the configuration can be edited in a text editor and reviewed in a pull request like any other source file.

None of the three converters appear in the README's getting-started or installation sections. No documentation in the repository root describes which JMeter elements, SoapUI features or Swagger constructs each converter handles. A complex JMeter test plan with custom samplers or pre-processors may come out incomplete after conversion. The only way to verify is to run the conversion and compare the output against the original test plan.

Playwright, k6 and molotov appear in examples alongside the four named engines

The README names four underlying tools, but the examples directory extends that list considerably. Subdirectories under examples/ include playwright/, k6/, molotov/, apiritif/, gatling/, jmeter/ and selenium/, showing seven executor categories in the repository layout.

molotov appears in requirements.txt at version 2.6 or higher, making it a direct Python dependency. Installing bzt through pip pulls in molotov automatically, without a separate install step. Playwright and k6 are absent from requirements.txt, which means they require their own separate installations before a Taurus YAML referencing them will run.

An executor-benchmark/ directory inside examples/ implies the project has some mechanism for comparing executor performance. Its contents are not part of the root listing, so what it measures and what results it produces are not visible from the repository's surface.

apiritif is the executor for Python-based functional tests. Its presence in examples/ alongside the load testing options matches the README's description of Taurus as a framework for both performance and functional tests, not only load tests.

Jenkinsfile and Dockerfile make CI and containerised runs concrete, not theoretical

The repository root contains a Jenkinsfile, a Dockerfile, a .travis.yml and an appveyor.yml. A second Jenkinsfile in examples/ provides a template for integrating a Taurus test run into an existing pipeline. Jenkinsfile-vulnerability-ai at the root implies BlazeMeter runs an automated security scan as part of its own CI process, separate from the test framework itself.

The Dockerfile builds from ubuntu:24.04 and sets Python 3.12 and Node.js 20 as build arguments. Setting PLAYWRIGHT_BROWSERS_PATH=/opt/playwright/browsers in the image means a container built from it includes Playwright browser dependencies without a separate install step inside the container. Teams that need a reproducible test environment across machines can run bzt from this image rather than managing engine installations per host.

examples/bztdocker.sh provides a shell script for the Docker path. examples/cloud/ holds configuration for running tests on BlazeMeter's cloud platform, which is a paid service separate from the open source package. The YAML syntax for cloud runs is part of the Taurus configuration schema, so cloud and local runs share the same file format.

Where the YAML abstraction stops and what the underlying engines still require

Taurus covers the most common load test patterns in its YAML model: virtual user counts, ramp shapes, think time and HTTP request lists. When a test needs JMeter-specific assertions, Gatling session handling or Selenium locator strategies, those features require either a native configuration file passed alongside the YAML or executor-specific extensions. Not every feature of every engine maps to a YAML equivalent.

Each engine also carries its own installation requirements beyond the pip install. pip install bzt covers Taurus and its Python dependencies from requirements.txt, including molotov, influxdb and lxml. A JMeter-backed test still needs Java. Gatling needs its own runtime. Playwright needs browser binaries installed separately through its own tooling. None of that dependency chain appears in the getting-started section, and a first run against a JMeter scenario on a fresh machine will fail until Java is present.

The README does not describe what happens to artifact files if bzt is interrupted mid-run by a CI timeout or a process signal. For pipeline environments where jobs terminate on a deadline, that behaviour needs to be tested against the specific executor before the output directory can be relied on.

Apache 2.0, release 1.16.51 in June 2026, and a vulnerability_history.md at the root

Taurus carries the Apache 2.0 license, recorded in the repository metadata and reproduced in LICENSE at the root. setup.py names BlazeMeter Inc. as the copyright holder. NOTICE at the repository root documents third-party attributions, which Apache 2.0 requires when distributing modified versions of the software.

Release 1.16.51 came out on 2026-06-15, following 1.16.50 and 1.16.49 in late April 2026. The last repository push was on 2026-10-06. Current development runs within the 1.16.x series, and the README gives no criteria for what would move the project to a 2.x release line.

vulnerability_history.md at the repository root is a file most open source test tools do not carry. Its name suggests BlazeMeter tracks security findings against the codebase over time. Jenkinsfile-vulnerability-ai implies automated scanning runs in the project's own pipeline. What the file records, what thresholds trigger an entry and how findings are remediated are not described in the README.

Contributors have access to tests/ and develop/ directories and a pull_request_template.md at the repository root.

Editorial conclusion

Taurus suits teams that already run JMeter, Gatling or Selenium and want one YAML entry point for CI pipelines. The Jenkinsfile and Dockerfile at the repository root make that path concrete. Skip it when tests depend on executor-specific features outside the YAML abstraction: jmx2yaml converts JMeter files but does not document what it cannot translate. Before adopting, run bzt test.yml against the README example, confirm the executor you need is installed on the host, and check vulnerability_history.md at the repository root to see what security scanning BlazeMeter runs on the codebase.

Frequently asked questions

Official sources

1. Blazemeter/taurus on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases