LoadRunner Parameterization: Driving Scripts with Real Test Data

Parameterization in LoadRunner replaces hardcoded values recorded during a VuGen session (a specific username, search term, or product ID) with values pulled from a defined parameter source — the same underlying need as JMeter’s CSV Data Set Config, with LoadRunner’s own terminology and configuration options.

Creating a parameter

In VuGen, select a recorded value, right-click, and choose to parameterize it — this creates a named parameter and replaces the hardcoded value with a reference ({username}) at that point in the script. The parameter’s properties define where its values actually come from.

Parameter types worth knowing

• File — values read from a data file (similar to JMeter’s CSV approach), one value consumed per iteration according to the selected allocation method.
• Table — values from a structured table (often used alongside Table-type test data within VuGen’s data wizard).
• Random Number — generates a random number within a defined range each iteration.
• Date/Time — generates current or offset date/time values, useful for any flow needing a realistic timestamp.
• Unique Number — an incrementing counter, useful for guaranteeing distinct values across iterations without needing a pre-built data file.

Allocation method: this is where it gets important

For File-type parameters, the Select next row setting (Sequential, Random, Unique) determines how virtual users pick rows. Unique assigns each virtual user (across the whole scenario, accounting for distributed Load Generators) its own distinct row — this is the setting that avoids the same “every concurrent user hits the same data row” problem JMeter parameterization addresses, and it’s worth being deliberate about, since the wrong allocation method (e.g. Sequential with too few rows and “continue in cyclic manner” recycling aggressively) reintroduces the exact contention parameterization is meant to prevent.

Update method: each iteration, each occurrence, or once

The Update value on setting controls whether a parameter gets a new value each iteration, each occurrence (if referenced multiple times within one iteration), or only once for the entire script run — picking the wrong one here is a common source of confusing, inconsistent script behavior (e.g. a value that should stay constant for a whole user session instead changing mid-flow).

Parameterizing across distributed Load Generators

Similar to JMeter’s distributed mode caveat, when a scenario runs across multiple Load Generators, make sure your parameter file and allocation method actually account for the combined virtual user population across all generators — not just the count on a single machine — or you’ll see unintended data collisions across the cluster.

Generating large parameter data sets

For test data needs beyond what’s practical to hand-author, generate parameter files programmatically (a script producing thousands of rows of realistic, unique synthetic data) — same principle as covered for JMeter, just feeding LoadRunner’s file-based parameter type instead of a CSV Data Set Config.

Takeaway: the allocation method (Sequential/Random/Unique) and update method (each iteration/occurrence/once) are the two settings most responsible for whether parameterization actually achieves realistic data variation — both are easy to leave at a default that doesn’t match what your test actually needs.