LoadRunner
The original enterprise load testing platform. Heavy-duty protocol support for complex enterprise systems and mission-critical applications.
Overview
LoadRunner, originally created by Mercury Interactive in 1993 and now owned by OpenText, is the oldest and most comprehensive enterprise load testing platform. It supports more protocols than any other tool — from web and mobile to ERP systems, legacy mainframes, and proprietary protocols. LoadRunner is the tool of choice for enterprises with complex, heterogeneous technology stacks.
In 2026, LoadRunner remains relevant for large enterprises with legacy systems, though modern web-focused teams increasingly prefer k6, Gatling, or JMeter.
What it's used for
LoadRunner is essential when:
- Complex enterprise stack: SAP, Oracle, mainframe, Citrix, and custom protocols in one test.
- Mission-critical applications: Banking, telecom, and government systems where failure is not an option.
- Protocol breadth required: No other tool supports as many protocols natively.
- Enterprise governance: Compliance, audit trails, and professional support are mandatory.
Pros & Cons
Pros
- Widest protocol support of any load testing tool
- Mature, battle-tested for 30+ years
- Professional support and enterprise SLAs
- Advanced correlation and parameterisation for complex apps
- Industry standard for government and banking RFPs
Cons
- Extremely expensive — licences cost tens to hundreds of thousands
- Heavy resource requirements for controllers and generators
- Steeper learning curve than modern tools
- Smaller talent pool — fewer professionals know LoadRunner than JMeter
- Overkill for modern web/API-only testing
Platforms & Integrations
LoadRunner runs on Windows (primary) and Linux. It requires significant infrastructure for large-scale tests. Cloud execution is available via LoadRunner Cloud.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Professional | Custom | GUI-based testing, basic protocols, local execution |
| Enterprise | Custom | All protocols, distributed load, advanced analytics, support |
| LoadRunner Cloud | Custom | On-demand cloud execution, flexible licensing |
NZ Context
LoadRunner is used by NZ's largest enterprises — primarily major banks and central government agencies running legacy systems that demand its deep protocol support. NZ financial services organisations with IBM middleware, ISO 8583 payment messaging, or Citrix-based internal tooling rely on LoadRunner because no open-source alternative covers those protocols at scale. Several central government agencies include LoadRunner by name in their RFP and procurement requirements, making it a compliance necessity rather than a free choice. For NZ professionals, LoadRunner skills command premium salaries but opportunities are concentrated in a small number of large employers — primarily the main trading banks and a handful of government IT shared-services providers.
Alternatives
- NeoLoad — Modern enterprise alternative with better CI integration.
- JMeter — Free alternative for web and API testing.
- k6 — Developer-friendly modern alternative for API and web testing.
When to choose LoadRunner
A quick decision guide for NZ teams evaluating enterprise performance testing options.
| Choose LoadRunner when… | Choose something else when… | Combine with… |
|---|---|---|
| You have SAP, Oracle, or Citrix in your stack and need to load-test them alongside web and API tiers in a single scenario | Your stack is REST/GraphQL-only — k6 or Gatling will get you results faster and at a fraction of the cost | Grafana for real-time dashboards (LoadRunner's built-in Analysis reports are powerful but slow to produce during a run) |
| An RFP or government contract explicitly names LoadRunner as the required tool — this is common in central government procurement | Your team is small (under 10 engineers) and doesn't have a dedicated performance engineer — the licensing and learning investment won't pay off | Dynatrace or Datadog APM to correlate load patterns with backend traces — LoadRunner shows throughput, APM shows why it degrades |
| You are testing a mainframe transaction system (CICS, IMS) or a legacy Citrix desktop application with no REST interface to test through | You need results in CI/CD pipelines on every PR — JMeter or k6 integrate far more cleanly with GitHub Actions and Azure DevOps | SolarWinds or PRTG for infrastructure monitoring during test runs — LoadRunner VU metrics alone won't tell you if a host is starving for CPU |
| Your organisation already holds an OpenText licence (e.g. via an existing ALM or Quality Centre subscription) — reuse it rather than introduce another tool | You want open-source, community-driven tooling with a large talent pool — JMeter has far more NZ practitioners available | Micro Focus (OpenText) ALM for test management and defect linking — the native integration eliminates a lot of manual reporting effort |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I were joining Revenue NZ's performance testing team — where a significant portion of the tax platform still runs on IBM middleware with bespoke integration layers
I would…
Invest proper time in LoadRunner's Virtual User Generator (VuGen) scripting and correlation patterns before touching anything near a run. Revenue NZ's protocols are too diverse for a tool with shallower support. I'd also set up a k6 suite alongside it for the REST-facing APIs, keeping LoadRunner only where its protocol depth is genuinely necessary — don't use a sledgehammer to crack a nut on modern endpoints.
If…
I were a performance tester at Harbour Bank being asked to evaluate whether the team should renew the LoadRunner enterprise licence or migrate to a modern alternative
I would…
Audit every active test scenario and tag each one with the protocol it exercises. Anything hitting standard HTTP/REST, I'd migrate to Gatling or k6 within a quarter. Anything touching banking middleware, ISO 8583 payment protocols, or Citrix-based internal tooling, I'd keep in LoadRunner — those protocols have no credible open-source alternative. Present the audit findings as a cost-reduction case: you're not abandoning LoadRunner, you're right-sizing it.
If…
I were onboarding a junior performance tester at TechServNZ into a team that uses LoadRunner for government clients
I would…
Start them on JMeter first, not LoadRunner. The concepts — think time, concurrency, ramp-up, correlation — transfer directly, and JMeter's feedback loop is much faster. Once they can read a load test results page and explain what a percentile means, introduce VuGen scripting. Throwing someone at LoadRunner's GUI on day one produces engineers who can click through wizards but can't diagnose a correlation failure under pressure.
The bottom line: LoadRunner earns its licence fee exactly once — when your protocol list includes something no open-source tool supports natively. Every other scenario is a cost you're paying for brand recognition, not capability.
Interview questions
Questions you are likely to get if you list LoadRunner on your CV — with what interviewers are really testing for.
What is the difference between a VUser and a Virtual User Generator script in LoadRunner, and why does that distinction matter?
What they’re really testing: Whether you understand LoadRunner’s core architecture or have only ever run pre-built scenarios without touching VuGen.
Strong answer covers: VuGen is the IDE for recording and editing scripts that simulate a single user’s actions; a VUser is one running instance of that script during a test execution. Explain how a single VuGen script can be parameterised so each VUser uses different data (e.g. different NZ Revenue NZ numbers or customer IDs). Mention that script quality — especially correlation — determines whether VUsers behave realistically or all replay the same recorded session token.
When would you choose LoadRunner over k6 or JMeter for a performance testing engagement?
What they’re really testing: Whether you can justify the cost of a premium licence with a concrete technical argument rather than just defaulting to what you know.
Strong answer covers: LoadRunner is the right call when the stack includes protocols that open-source tools don’t support natively — SAP GUI, Citrix, IBM MQ, ISO 8583 payment messaging, or legacy CORBA. Contrast with k6 (best for modern REST/GraphQL in CI pipelines) and JMeter (good free option for HTTP but no enterprise protocol depth). Note that many NZ government contracts and banking RFPs name LoadRunner explicitly, making the licence a procurement requirement rather than a pure technical choice.
You’re joining Revenue NZ’s performance testing team. Their tax platform mixes IBM middleware with modern REST APIs. How would you structure the LoadRunner test suite?
What they’re really testing: Whether you can apply LoadRunner strategically rather than using it for everything by default, and whether you understand the real-world constraints of large NZ public-sector environments.
Strong answer covers: Audit every active scenario and tag each by protocol — keep IBM middleware, MQ, and any Citrix-based internal tooling in LoadRunner where its protocol depth earns its cost. Route all HTTP/REST-facing APIs to k6 or Gatling for faster CI feedback loops. Mention data privacy considerations (Revenue NZ handles sensitive taxpayer data) requiring parameterised test data that is synthetic, not copied from production. Coordinate test windows carefully given Revenue NZ’s high-availability obligations during tax filing peaks.
Your LoadRunner scenario passes in the controlled test environment but produces large numbers of failed transactions in the CI pipeline. How do you diagnose it?
What they’re really testing: Whether you understand correlation and dynamic value handling — the most common source of LoadRunner failures in automated environments.
Strong answer covers: Start by checking the VuGen replay log for HTTP 4xx errors or unexpected redirects, which usually point to a session token or CSRF value that wasn’t correlated and is replaying a stale recorded value. Check whether the CI environment uses a different base URL or certificate that requires script-level changes. Also verify that parameterisation data files are available to the CI agent and that think-time settings are appropriate for the faster infrastructure. Mention using LoadRunner’s built-in correlation wizard as a starting point, then validating manually for custom dynamic fields.
How would you structure a LoadRunner Controller scenario to simulate realistic load for a banking application serving 50,000 concurrent users at peak?
What they’re really testing: Whether you understand scenario design fundamentals — ramp-up strategy, load generator distribution, and the difference between concurrent users and throughput targets.
Strong answer covers: Distribute load across multiple load generator machines so no single host saturates its NIC or CPU — rule of thumb is 500–1,000 VUsers per generator depending on protocol weight. Use a realistic ramp-up (not a step load that instantly hammers the system) modelled on actual login curves from production APM data. Define transaction-based SLAs in the Controller rather than just watching throughput: for a bank, response time at the 95th percentile on payment submission is more meaningful than average response time. Reference Harbour Bank or Pacific Bank as context where payment throughput SLAs are contractually defined and must be evidenced under test.