How Vuser counting inflates a LoadRunner finding

LoadRunner is licensed by Vusers, the virtual users that simulate load during a performance test, and a finding inflates when an audit counts the largest Vuser number it can find rather than the entitlement the organization actually runs against. How Vusers are counted, peak versus sustained, provisioned versus used, is where a LoadRunner finding either holds or comes apart.

A Vuser is a unit of simulated load, not a person, and a LoadRunner entitlement licenses a number of Vusers that can be run concurrently in a test. The audit risk is that the measurement captures a momentary peak, a single test that briefly spun up a large number of Vusers, and treats that peak as the standing requirement, or counts Vuser capacity that was provisioned in configuration but never actually executed. Performance testing is bursty by nature: a load test pushes a high Vuser count for a short window, then returns to nothing, and a finding that prices the burst as if it were the permanent entitlement overstates the requirement substantially. Because the EULA makes compliance the licensee's responsibility, the buyer must show what the genuine Vuser requirement is, and the execution data that proves it is in the buyer's own test records.

How Vuser counting goes wrong

The licensed unit is the concurrent Vuser, and the question that matters is how many Vusers the organization genuinely needs to run at the same time. An audit can inflate the count in several ways: by taking the single highest Vuser figure ever recorded and treating it as the sustained requirement, by counting Vusers configured across multiple test assets as though they all ran simultaneously, or by including non production and trial runs that do not represent a standing need. The defensible position reconstructs actual concurrent Vuser execution from the test records, distinguishing the brief peak of a one off test from the level the organization actually operates at. A burst is not an entitlement, and a configured but unexecuted Vuser pool is not a requirement.

The principle is that Vusers are licensed for concurrent execution, so the count must reflect genuine concurrent use, not the maximum number that ever appeared in a log or a configuration file. Establishing the real concurrency is the heart of the defense.

Where the Vuser count overstates

Peak treated as sustained

The most common inflation is pricing a one off peak as the standing requirement. Separating burst from sustained is the work described in how to scope LoadRunner Vuser bursts and supported by execution evidence as in reducing a LoadRunner finding with concurrency evidence.

Configured but unexecuted capacity

Vuser pools defined across test assets do not all run at once. The question of whether peak Vusers can be charged at all is examined in can OpenText count peak Vusers against your license, and the underlying unit is explained in what is a Vuser and how is it licensed.

Non production and environment counting

Test and non production runs do not represent a standing entitlement, and environment counting carries its own traps, set out in LoadRunner non production and test environment scope.

How we defend a LoadRunner Vuser finding under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. We take over the single controlled channel and preserve the test execution records, the controller and load generator data, and the entitlement, because the concurrency argument depends on capturing what actually ran.

Reconstruct. We build the effective license position by reconstructing genuine concurrent Vuser execution from the test records, separating peaks from sustained use and removing configured but unexecuted capacity, before any vendor script runs.

Rebut. We challenge every line that prices a burst as a standing requirement or counts unexecuted Vusers. The finding falls by the difference between the inflated peak and the genuine concurrent requirement the records support.

Resolve. We settle on the reconstructed Vuser count and, where it serves you, convert forward into an OpenPass agreement that records how Vusers are measured, so a future test peak does not become the next finding.

An anonymised outcome

The reason Vuser concurrency matters is the remedy behind the finding. On noncompliance the licensee is deemed to have acquired licenses at then current list price, owes back maintenance and support, owes first year maintenance on the new licenses, and reimburses the cost OpenText incurs performing the audit, so collapsing an inflated peak to the genuine requirement removes that fourfold charge on every Vuser disqualified. Our anonymised case files show reductions of similar scale across the estate, a banking ArcSight finding built on burst versus sustained fell 70 percent from $6.0M to $1.8M, and the LoadRunner Vuser argument follows the same logic: the burst is not the entitlement, and once the records separate the two, the finding falls to what the organization actually runs.

Count what runs, not what peaked

The lasting lesson is that a Vuser is a unit of concurrent simulated load, and a LoadRunner finding that prices the highest number it can find ignores the bursty nature of the very testing it is measuring. A buyer who reconstructs genuine concurrent execution from the test records, and holds the count to that, removes the inflation that peak based measurement creates. To prepare that argument, read reconciling ALM entitlements before an audit, and to go deeper on the unit, read what is a Vuser and how is it licensed. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If a LoadRunner finding has priced a test peak as your entitlement, open a case.

Why test records are the buyer's strongest asset

The evidence that defeats an inflated Vuser count lives in the buyer's own test execution records, and that is the buyer's advantage. Controller logs, scenario results, and load generator data show what actually ran and when, which is exactly the information needed to separate a momentary peak from the sustained concurrent requirement. An audit working from configuration or a single high figure does not have this granularity unless the buyer chooses to share it.

Preserving and organizing those records is therefore the heart of the defense, because they convert the argument from assertion into demonstrated execution. The same evidence discipline runs through reducing a LoadRunner finding with concurrency evidence, where genuine concurrent use, not peak capacity, sets the count.