LoadRunner review: pricing, alternatives and tutorial

LoadRunner splits the work into tools that each do one thing. VuGen, the Virtual User Generator, records traffic and produces a script for one virtual user (a Vuser). Controller builds a scenario from scripts: how many Vusers run each one, on which load generators, on what schedule, with which monitors and SLAs. Load generators are the machines that actually run the Vusers, on Windows, Linux or Docker, either local or in a cloud. Analysis opens the result files afterwards and builds graphs and reports. The split explains much of the experience: scripts are authored and debugged in one place, scaled in another, and judged in a third, so each step has its own settings to get right.

Most LoadRunner scripts work at the protocol level. VuGen records the requests a client sends, such as HTTP calls, SAP GUI messages or Citrix ICA events, and writes them as function calls; a Web HTTP/HTML script is C by default, with calls such as web_url and web_submit_data. On replay, no browser or client runs: the Vuser sends the same kind of traffic directly. That is why one load generator can run many protocol Vusers, and why the protocol range is so wide. It is also why a script captures only what was on the wire. Client-side rendering and JavaScript timing need TruClient, which drives a real browser and costs far more per Vuser.

A recording contains values the server generated for that one session: session IDs, CSRF tokens, view state, order numbers. Replaying them verbatim fails, often with a 200 response that hides an error page. Correlation replaces each one with a parameter captured from an earlier response at run time, using web_reg_save_param_ex with left and right boundaries or web_reg_save_param_regexp. The registration call goes before the request whose response contains the value. VuGen’s Design Studio finds candidates three ways: correlation rules during code generation, a record scan, and a replay scan that compares responses after a failed replay. It is not available for DevWeb scripts, where extraction is ordinary JavaScript.

Vusers need a licence installed on the Controller machine, and licences come in protocol bundles: Web, Web 2.0, SAP, Remote access, Network, Java and so on, up to an Enterprise Suite that combines them. A multi-protocol Vuser runs only if every protocol in its script is licensed. Licence types include permanent, time-limited, evaluation and VUFD, a Virtual User Flex Day where consumption is the peak number of concurrent Vusers in a 24-hour period. The free Community licence installs with the product and allows 50 Vusers on all protocols except the COM/DCOM, Templates and GUI bundles. Licensing therefore shapes test design: protocol choice and peak concurrency are cost decisions.

The family is sold in three forms that share VuGen, scripts and protocols. Professional is the desktop suite, with a Controller you run yourself. Enterprise is a web platform for shared projects, load generator pools, timeslots and trend reports across many teams. Core is the SaaS form, with cloud load generators and licences consumed by Vuser or Vuser hour. OpenText has renamed them, as its October 2025 blog post explains: LoadRunner Professional is now OpenText Professional Performance Engineering, LoadRunner Enterprise is Enterprise Performance Engineering, LoadRunner Cloud is Core Performance Engineering, and LoadRunner Developer is Performance Engineering for Developers. OpenText states the tools, scripts and scenarios are unchanged. OpenText ships two releases a year; 26.1 and 26.3 share one help centre.

A VuGen script is a folder: the .usr file that describes it, the action files (vuser_init.c, Action.c, vuser_end.c and any others), globals.h, the .prm parameter definitions with their data files, and default.cfg and default.usp for runtime settings and run logic. Commit all of those. Ignore the recording data folder, which the docs describe as a backup of recorded data that is never read again, replay result folders, and .bak copies. Keep one folder per business journey, Controller .lrs scenarios in their own folder, and environment details such as the base URL in parameters rather than in code. Enterprise Performance Engineering’s GitHub action can sync script folders to a project, uploading runtime files only by default.

Parameterise every value that differs between users or environments: user names, passwords, search terms and the base URL. Give each parameter a sensible selection rule, for example unique per Vuser for accounts that cannot log in twice. Correlate anything the server generates. Prefer boundaries that describe the value’s context, such as an attribute name, over long runs of HTML that a redesign will break, and set NotFound=error so a changed page fails loudly at the extraction rather than three steps later. When a page lists several values, capture them all with Ordinal=All and choose one, which spreads load across data the way real users do.

Start with a manual scenario: you choose the scripts, the Vusers for each, the load generators and the schedule, so the result is easy to reason about. Use goal-oriented scenarios when the question is a capacity target, such as how many Vusers keep a checkout transaction under two seconds. Set think time and pacing deliberately in the runtime settings, because a script that ignores think time turns 100 Vusers into far more traffic than 100 people. Keep the Controller machine out of load generation for anything beyond a smoke test, and watch load generator CPU and memory, since a saturated generator reports its own slowness as server latency. Define SLAs on the transactions that matter: the Jenkins integration only accepts scenarios that have them.

The OpenText Application Automation Tools plugin, previously the Micro Focus plugin, runs Controller scenarios from Jenkins. Install the product on a Windows build agent, keep the .lrs files on that agent or in the checked-out workspace, and run the agent under an account with administrator rights rather than Local System. The loadRunnerTest pipeline step runs one or more scenarios, polls Controller, and publishes results; the SLAs in each scenario decide whether the build passes. Set perScenarioTimeOut so a hung scenario cannot hold the agent for hours, and keep pull request runs to a small smoke scenario. Azure DevOps has an equivalent extension, LoadRunner Professional Tests Automation, which needs a self-hosted Windows agent.

There is no official GitHub Action for the desktop Professional edition; a self-hosted Windows runner calling wlrun works, but wlrun documents no exit codes, so gating needs your own result parsing. The official route is Enterprise Performance Engineering’s action, MicroFocus/lre-gh-action, currently v1.0.7. It authenticates to the Enterprise server, runs an existing test by ID or creates one from a YAML file in the repository, waits for collation and analysis, writes reports to an LreResult folder and exits with a status suitable for gating. Store credentials as secrets, and set lre_status_by_sla to true so the SLA, not just a completed run, decides the job.

For HTTP and WebSocket services, DevWeb is the part of the family that suits a code review workflow. A script is a folder with main.js and rts.yml, so it diffs like any other JavaScript, runs from the command line on Windows, Linux or macOS, and scales later through Controller or Enterprise. Extraction uses load.BoundaryExtractor or other extractor objects on the request rather than separate registration calls, and transactions are objects you start and stop. Parameters come from load.params. Because Design Studio does not support DevWeb, correlation is written by hand, which is usually quicker for developers than reading recorded C.