VarioTest — composite multi-scenario tests
Production traffic is never a single request pattern. A storefront sees browsing traffic, checkout traffic, and background jobs polling order status, all sharing the same database connections, caches, and thread pools at the same time. Testing each of those alone is useful, but it misses the interaction effects you get in production. VarioTest combines several of your existing single tests into one composite run.
What VarioTest is
Section titled “What VarioTest is”A VarioTest is a composite test definition. It references two or more single tests that already exist in the same project, each with its own engine, scenario files, and load profile, and runs them together as one coordinated run. You don’t write a new scenario. You combine tests you already have.
You assemble one in the New VarioTest wizard from the single tests in one project:
When to use it
Section titled “When to use it”- You want to reproduce a realistic mix of user behavior (browse : checkout : background jobs) in one run instead of guessing at the interaction effects from separate runs.
- You want to detect resource contention: one scenario’s latency climbs because another scenario competes for the same database connections, caches, or thread pools.
- You want an A/B comparison of the same workload against two API versions or two configurations, side by side in the same test-wide time window. Otherwise you get two runs you have to line up by hand afterwards.
If you only need one workload pattern, use a single test. It is simpler, and it is what a VarioTest is built from. Use VarioTest when you need more than one pattern running together.
The scenario, weight, and variant model
Section titled “The scenario, weight, and variant model”VarioTest has three parts. Once you know them, the console wizard and the results view make sense.
Scenario
Section titled “Scenario”In VarioTest, a scenario is one of your existing single tests. It is the same “Test” object you create on the Tests surface: a scenario file (or set of files), a detected engine, and a load profile (total VUs, ramp-up, duration, locations). A VarioTest is an ordered list of scenarios from a single project, up to 20 per composite test.
Weight
Section titled “Weight”The composition wizard has no separate “VU weight” slider. Each scenario brings its own weight
into the mix through its own load profile. When they run together, a scenario configured for
600 total VUs sends proportionally more traffic than a scenario configured for 100 VUs. You set
the mix by editing each constituent test’s Load configuration (total virtual users, ramp-up,
locations) before or after you add it to the VarioTest, as you would for any single test. To
override VUs per scenario for one VarioTest run without changing the underlying test’s default
profile, use the scenarios payload field in the API reference.
Variant
Section titled “Variant”A variant is two or more scenarios in the same VarioTest that exercise the same behavior with one deliberate difference: a different target API version, a different backend configuration, or a different data set driving an otherwise identical script. To compare variants, add both versions as separate scenarios to one VarioTest and give each the same load profile. Then use the Scenario filter in the results view to compare them side by side under identical conditions. Worked example: mixed traffic walks through a concrete case, including an A/B variant pattern.
How a VarioTest run is organized
Section titled “How a VarioTest run is organized”Starting a VarioTest launches every constituent scenario as part of one coordinated run. By default, the run detail page aggregates throughput, latency, and error metrics across all scenarios. A Scenario scope filter, next to the usual Location, Label, and Runner filters, lets you isolate one constituent’s metrics without leaving the combined view. Runs: read results is the full guide to reading results.
EUX probe
Section titled “EUX probe”A load test tells you throughput and latency under load. It doesn’t tell you what a real browser experiences while that load is running. EUX probe answers that with one toggle: measure real browser end-user experience (EUX) — page load, Core Web Vitals-style timing — concurrently with a performance test’s load, without hand-building a second coordinated test.
Open a performance test’s Configuration tab and turn on the EUX probe card. Pick (or
create) a browser test to probe with. Starting the perf test then starts two runs together: the
perf test itself, labelled Load, and the browser probe, labelled EUX probe, running one
virtual user for the Load run’s full duration so it measures the whole window, not a single
snapshot. The parent run reports as a perf_eux composite — the same run layout a VarioTest uses
— with both children under it.
The parent run’s pass/fail verdict is the Load child’s verdict alone; the probe’s own result is shown but is informational and never fails the run. The probe requires the browser testing entitlement, not the VarioTest entitlement — EUX probe is not sold as a VarioTest feature (it is built on the same composite-run mechanism, which is why its layout matches).