k6 v0.34.0 introduced the capability to get information about the current test execution state inside the test script. You can now read in your script the execution state during the test execution and change your script logic based on the current state.
The k6/execution module provides the test execution information with the following properties:
All unique identifiers are sequentially generated starting from a base of zero (iterations) or one (VU IDs). In distributed/cloud test runs, the test-wide iteration numbers and VU identifiers are still going to be unique across instances, though there might be gaps in the sequences when, for example, some instances execute faster iterations than others or allocate more VUs mid-test.
The instance object provides information associated with the load generator instance. You can think of it as the current running k6 process, which will likely be a single process if you are running k6 on your local machine. When running a cloud/distributed test with multiple load generator instances, the values of the following properties can differ across instances.
|iterationsInterrupted||integer||The number of prematurely interrupted iterations in the current instance.|
|iterationsCompleted||integer||The number of completed iterations in the current instance.|
|vusActive||integer||The number of active VUs.|
|vusInitialized||integer||The number of currently initialized VUs.|
|currentTestRunDuration||float||The time passed from the start of the current test run in milliseconds.|
Meta information and execution details about the current running scenario.
|name||string||The assigned name of the running scenario.|
|executor||string||The name of the running Executor type.|
|startTime||integer||The Unix timestamp in milliseconds when the scenario started.|
|progress||float||Percentage in a 0 to 1 interval of the scenario progress.|
|iterationInInstance||integer||The unique and zero-based sequential number of the current iteration in the scenario, across the current instance.|
|iterationInTest||integer||The unique and zero-based sequential number of the current iteration in the scenario. It is unique in all k6 execution modes - in local, cloud and distributed/segmented test runs. However, while every instance will get non-overlapping index values in cloud/distributed tests, they might iterate over them at different speeds, so the values won't be sequential across them.|
Meta information and execution details about the current vu and iteration.
|iterationInInstance||integer||The identifier of the iteration in the current instance.|
|iterationInScenario||integer||The identifier of the iteration in the current scenario.|
|idInInstance||integer||The identifier of the VU across the instance.|
|idInTest||integer||The globally unique (across the whole test run) identifier of the VU.|
|tags||object||The map that gives control over VU's Tags. The Tags will be included in every metric emitted by the VU and the Tags' state is maintained across different iterations of the same Scenario while the VU exists. Check how to use it in the example below.|
Setting a Tag with the same key as a system tag is allowed, but it requires attention to avoid unexpected results. Overwriting system tags will not throw an error, but in most cases will not actually change the value of the emitted metrics as expected. For example, trying to set the url tag value will not result in a changed tag value when http.get() is called, since the tag value is determined by the HTTP request itself. However, it will add the tag url to the metric samples emitted by a check() or metric.add(), which is probably not the desired behavior. On the other hand, setting the name tag will work as expected, since that was already supported for http.* methods, for the purposes of the URL Grouping feature.
Not all the types are accepted as a tag value: k6 supports strings, numbers and boolean types. Under the hood, the tags object handles a Tag as a String key-value pair, so all the types will be implicitly converted into a string. If one of the denied types is used (e.g. Object or Array) and the throw option is set, an exception will be thrown. Otherwise, only a warning is printed and the tag value will be discarded.
This is a common use case for data parameterization, you can read the examples using scenario.iterationInTest and vu.idInTest.
The startTime property from the scenario object can be used to time operations.
The name property can be used for executing the logic based on which script is currently running.
Tip: If you need to run multiple scenarios in your script you can use exec option achieve a similar goal
The vu.tags property can be used for getting or setting VU's tags.