Recording Your First Script in VuGen

Recording is usually the fastest way to get a working starting point in VuGen, even though the recorded script will almost always need correlation and cleanup afterward (covered in this series’ correlation article) before it’s ready for real load.

Choosing a protocol before recording

VuGen asks for a protocol when creating a new script. For a standard web application, Web - HTTP/HTML is the right choice; for a Citrix-delivered thick client, SAP GUI, or other specialized environments, pick the matching protocol — recording at the wrong layer produces a script that either won’t work at all or won’t scale realistically (e.g. recording browser-level HTML interactions for an app that should really be tested at the underlying API level).

The recording session

Starting a recording opens a browser (or the target application, for non-web protocols) wrapped by VuGen’s recording engine, which captures every request/interaction as you manually click through the flow you want to test (login, search, checkout, etc.). Keep recorded flows focused and short — a single recording covering ten unrelated flows is harder to correlate, parameterize, and maintain than several smaller, single-purpose scripts.

What gets generated

VuGen converts your recorded actions into a C-based script using LoadRunner’s runtime API (lr_think_time, web_submit_data, and similar functions depending on protocol) organized into sections: vuser_init (one-time setup, e.g. login), Action (the repeatable main flow), and vuser_end (cleanup, e.g. logout) — mirroring the “once per user” vs. “repeated per iteration” distinction also seen in JMeter’s Once Only Controller pattern.

Replay before you scale

Before doing anything else, use VuGen’s Replay feature to run the recorded script as a single virtual user and confirm it works exactly as recorded. This step catches obvious problems (missing correlation causing an immediate failure, a recorded step that doesn’t replay correctly) while they’re cheap to diagnose, rather than discovering them for the first time during an expensive 500-Vuser Controller run.

Recording Options worth checking

VuGen’s Recording Options (accessible before or after recording) control things like whether to record at the HTML-based or URL-based level for web protocols — HTML-based recording produces scripts that are somewhat more resilient to certain application changes, while URL-based gives more granular control. For most modern web apps, HTML-based recording is the more commonly recommended starting point.

After recording: expect to do real work

A freshly recorded script is a starting point, not a finished test asset. Expect to immediately need: correlation of dynamic values (session tokens, view-state-style fields), parameterization of hardcoded test data, and removal or adjustment of any incidental requests the recorder captured that don’t belong in a clean reusable script (browser-only analytics calls, for instance).

Takeaway: recording gets you a working skeleton fast, especially for unfamiliar applications — but treat it as step one of the process, and always replay-validate a recorded script standalone before investing further scripting effort on top of it.