Anyone who has written a script in LoadRunner has probably used parameters before. A parameter is a substitution for a hard coded values when there needs to be different data values submitted on each new iteration if the script. One way to feed new information in is by creating a data file (similar to a CSV delimited file). You can create your own .DAT files with multiple columns, convert them from excel spreadsheets, or from SQL extracts from the database. Then point your parameter to the .DAT file. HP's Virtual User Generator (VuGEN) scripting tool for LoadRunner has multiple options for choosing which data will be selected upon each new iteration. Select the drop down menu for "Select next row" and you will see the following choices:
Sequential
Random
Unique
Same Line as (if there are multiple parameters in the script)
Check out the LoadRunner books online or help documentation if you need details on how these choices work and how to get there in VuGEN.
With a larger data set, you might want to visualize just how random the "Random" option is - how LoadRunner will use these data values throughout the duration of the test. With LoadRunner 9 we have a new feature, Simulate Parameter, to do that. When you look at the Parameter Properties sheet, there is a new button. See the graphic #1 below:
[attach]48149[/attach]
In this particular case I want to see how often my users will be chosen for logging in throughout the test if I have a load of 10 virtual users iterating 10 times each. By clicking on the "Simulate Parameter" button, it launches the Parameter Simulation sheet, which will allow me to select the number of virtual users I plan on running, and the number of iterations. I can also tell it to look at the current Run-Time setting values I have set up in the script for this information. See graphic #2 below:
[attach]48150[/attach]
Now I have an idea of how the test scenario will play out by virtual user, and by iteration. This would help if you suspected that you had too few values in your parameter file and the timings were getting skewed. It you were getting errors within scripts, you might find out that its due to database locks because the same data is being used at the same time, or some other data violation. Note that by viewing this, it does not modify the data file to match the listing you see. It's simply a way to see how the data would be used if you kicked off a test. Now you have a way to visualize a dry run on those Parameters without launching a test.