Execution Settings

Execution objects represent actual underlying tool executions. You can launch unlimited number of JMeter's, Gatling Tool's, etc. Executions are configured under top-level config key execution. Specifying single execution config is equivalent to specifying array of executions with single element, for example:

execution:
  scenario: scenario_name    

{
    "execution": {
        "scenario": "scenario_name"
    }
}

is equivalent for

execution:
- scenario: scenario_name

{
    "execution": [
        {
            "scenario": "scenario_name"
        }
    ]
}

However, users are encouraged to use array notation always to leverage the arrays auto-join capability when combining multiple config files into one. See config merge rules for more details on this.

There are load profile and scenario settings that are common for all execution types, and each executor type can also have its own settings.

Executor Types

Taurus tool may use different underlying tools as executors for scenarios. Currently, supported tools are:

• JMeter, executor type jmeter
• Selenium, executor type selenium
• Gatling, executor type gatling
• Locust, executor type locust
• Siege, executor type siege
• ApacheBenchmark, executor type ab
• Tsung, executor type tsung
• Molotov, executor type molotov
• JUnit, executor type junit
• TestNG, executor type testng
• Apiritif, executor type apiritif
• PyTest, executor type pytest
• RSpec, executor type rspec
• Mocha, executor type mocha
• NUnit, executor type nunit
• xUnit, executor type xunit
• WebdriverIO, executor type wdio
• Robot, executor type robot
• Postman/Newman, executor type newman
• K6, executor type k6

Default executor is jmeter and can be changed under general settings section.

settings:
  default-executor: jmeter

{
    "settings": {
        "default-executor": "jmeter"
    }
}

You may contribute your efforts in supporting requests-scenarios for your favorite tool by discussing this on project forum.

Load Profile

Execution has several options to set load profile settings. Support for options is specific to executor type. Available settings are:

• concurrency - number of target concurrent virtual users
• ramp-up - ramp-up time to reach target concurrency
• hold-for - time to hold target concurrency. Define this value explicitly for long-running tests to have them terminate gracefully.
• iterations - limit scenario iterations number
• throughput - apply RPS shaper, limiting maximum RPS to throughput, requires ramp-up and/or hold-for
• steps - allows users to apply stepping ramp-up for concurrency and rps, requires ramp-up
• scenario - name of scenario that described in scenarios part (see below)

execution: 
- concurrency: 10
  ramp-up: 15s
  hold-for: 2m
  iterations: 1000
  throughput: 20
  scenario: scenario_name

{
    "execution": [
        {
            "concurrency": 10,
            "ramp-up": "15s",
            "hold-for": "2m",
            "iterations": 1000,
            "throughput": 20,
            "scenario": "scenario_name"
        }
    ]
}

Scenario

Scenario is a sequence of steps that is used to build script for underlying tool (e.g. generate JMX file for JMeter). It is described in special scenarios top-level config element. There are three examples of scenario syntax:

scenarios:
  get-requests:                     # normal form: scenario is dictionary
    requests:
      - http://localhost/1
      - http://localhost/2  
  only-script: 
    script: gatling_script.scala    # short form: just script

execution:
- concurrency: 10
  hold-for: 1m
  scenario: get-requests  
- executor: gatling
  concurrency: 5
  iterations: 10
  scenario: only-script
- hold-for: 20s
  scenario: my_jmx_file.jmx         # shortest form: only script file name  

{
    "scenarios": {
        "get-requests": {
            "requests": [
                "http:\/\/localhost\/1",
                "http:\/\/localhost\/2"
            ]
        },
        "only-script": {
            "script": "gatling_script.scala"
        }
    },
    "execution": [
        {
            "concurrency": 10,
            "hold-for": "1m",
            "scenario": "get-requests"
        },
        {
            "executor": "gatling",
            "concurrency": 5,
            "iterations": 10,
            "scenario": "only-script"
        },
        {
            "hold-for": "20s",
            "scenario": "my_jmx_file.jmx"
        }
    ]
}

Another way to execute something is asking for script:

scenarios:
  with_script:
    script: some_special_file

{
    "scenarios": {
        "with_script": {
            "script": "some_special_file"
        }
    }
}

SoapUI Integration

You can specify SoapUI projects in place of script. The executor will convert them into Taurus scenarios and handle with correspond executor.

Example:

execution:
- concurrency: 10
  executor: jmeter
  hold-for: 5m
  scenario: soapui-project

scenarios:
  soapui-project:
    script: project.xml
    test-case: TestIndex

{
    "execution": [
        {
            "concurrency": 10,
            "executor": "jmeter",
            "hold-for": "5m",
            "scenario": "soapui-project"
        }
    ],
    "scenarios": {
        "soapui-project": {
            "script": "project.xml",
            "test-case": "TestIndex"
        }
    }
}

You can read more on that here.

Startup Schedule

By default, Taurus runs items under execution in parallel. To switch it into sequential mode, run it with -sequential command-line option. This is an alias for this setting:

modules:
  local:
    sequential: true  # false by default

{
    "modules": {
        "local": {
            "sequential": true
        }
    }
}

There is advanced way to limit number of executors, worked simultaneously. For that you should use capacity parameter of local with needed limit:

modules:
  local:
    capacity: 3  # no limit by default

{
    "modules": {
        "local": {
            "capacity": 3
        }
    }
}

It means "don't start the 4th executor until one of the previous 3 has finished"

Note: sequential is equivalent to capacity: 1.

Please do not use both sequential and capacity at the same time to prevent ambiguity in your configuration.

You can run different executions at different times with delay option:

execution:
- concurrency: 10
  hold-for: 20s
  scenario: main
- concurrency: 20
  hold-for: 15s
  scenario: main
  delay: 10s

scenarios:
  main:
    requests:
    - http://blazedemo.com/

{
    "execution": [
        {
            "concurrency": 10,
            "hold-for": "20s",
            "scenario": "main"
        },
        {
            "concurrency": 20,
            "hold-for": "15s",
            "scenario": "main",
            "delay": "10s"
        }
    ],
    "scenarios": {
        "main": {
            "requests": [
                "http:\/\/blazedemo.com\/"
            ]
        }
    }
}

By this way, the first execution works 10 seconds, then two executions will work 10 seconds together, then the first will stop and the second will complete its work in 5 seconds.

Another way to schedule is usage of start-at:

execution:
- concurrency: 10
  hold-for: 20s
  start-at: '2020-03-25 23:15'  # must be string
  scenario: sample
  
scenarios:
  sample:
    requests:
    - http://blazedemo.com/

{
    "execution": [
        {
            "concurrency": 10,
            "hold-for": "20s",
            "start-at": "2020-03-25 23:15",
            "scenario": "sample"
        }
    ],
    "scenarios": {
        "sample": {
            "requests": [
                "http:\/\/blazedemo.com\/"
            ]
        }
    }
}

Supported time formats are:

• YYYY-MM-DD HH:MM:SS
• YYYY-MM-DD HH:MM
• HH:MM:SS
• HH:MM

Additional Files

When your execution requires additional files (e.g. JARs, certificates etc.) and you plan to send tests to the Сloud, you may use files option of execution and list paths for files there.

Environment Variables

In addition to global env vars, you can specify execution-specific environment variables. This is done by specifying key-value pairs under env option of execution:

execution:
- concurrency: 10
  hold-for: 20s
  scenario: main
  env:
    base_url: http://foo.bar/

{
    "execution": [
        {
            "concurrency": 10,
            "hold-for": "20s",
            "scenario": "main",
            "env": {
                "base_url": "http:\/\/foo.bar\/"
            }
        }
    ]
}