LoadRunner Controller: Designing a Load Test Scenario

A Controller scenario is where individual VuGen scripts become an actual load test — defining how many virtual users run each script, on which machines, and according to what schedule.

Vuser Groups

A scenario organizes virtual users into Vuser Groups, each group tied to a specific script. A realistic scenario typically has multiple groups representing different user behaviors or roles (e.g. “Browsers,” “Buyers,” “Admins”), each potentially running a different script and a different virtual user count, modeling a realistic mix rather than one monolithic user type.

Scheduling: by group or by scenario

Controller supports scheduling either per Vuser Group independently, or as one scenario-wide schedule applied across all groups together. Per-group scheduling gives finer control — useful when different user types should ramp up at different rates or start at different times (e.g. “Buyers” only become active after “Browsers” have been running for a few minutes, modeling a realistic session funnel).

Ramp-up, steady state, and ramp-down

Similar in concept to JMeter’s ramp-up: define how quickly Vusers start (ramp-up), how long the test holds at full load (steady state/duration), and how Vusers stop at the end (ramp-down, or an abrupt stop). A scenario that ramps down abruptly mid-transaction can generate misleading “failures” that are really just artifacts of the test stopping mid-flow, not real application failures — gradual ramp-down avoids this noise.

Assigning Load Generators

Each Vuser Group is assigned to run on one or more Load Generators. For larger scenarios, distributing groups across multiple Load Generators avoids any single machine becoming the bottleneck — the same concern as JMeter’s distributed testing, with Controller providing the coordination natively as a core feature rather than a separate add-on mode.

Rendezvous points: synchronizing virtual users

A Rendezvous Point (covered in more depth in the next article in this series) forces virtual users to wait until a specified number have reached that point before all being released simultaneously — used to create deliberate concurrency spikes (e.g. simulating many users clicking “submit” at the exact same moment), something a plain ramp-up schedule can’t reliably produce on its own.

Monitoring during the run

Controller’s live view shows running Vuser status (running, ready, failed), transaction response times, and — if configured with monitoring integrations — server-side resource graphs, all updating during the run itself, rather than requiring you to wait until the run finishes to see anything (Analysis is for deeper post-run review, not the only way to observe a running scenario).

A realistic scenario design checklist

1. Does the Vuser Group mix reflect realistic proportions of actual user behavior, not an arbitrary even split?
2. Is the ramp-up schedule modeling what you actually intend (steady capacity test vs. spike resilience test require different ramp-up shapes)?
3. Are Load Generators sized and distributed appropriately for the total virtual user count?
4. Is there a clear ramp-down to avoid misleading end-of-test artifacts?

Takeaway: scenario design is where most of the “does this test actually represent reality” decisions live — the underlying scripts matter, but a poorly designed scenario (wrong group mix, unrealistic scheduling) can make even well-written scripts produce misleading results.