82 LoadRunner interview questions with answers

What they are assessing

Basic orientation.

Model answer

LoadRunner is a performance testing product, originally from Mercury, then HP, then Micro Focus, and now part of OpenText. It simulates many concurrent users against an application to measure response time, throughput and resource consumption. Its distinguishing strength against open source alternatives is protocol breadth: beyond web it supports SAP, Citrix, Oracle, mainframe terminal emulation, Java and .NET, which is why it persists in large enterprises where the system under test is not simply a website.

Likely follow-up

Why does protocol breadth still matter when most systems are web based?

What they are assessing

Core vocabulary.

Model answer

A simulated user, usually called a vuser, that executes a script to generate load. Each vuser runs independently with its own session, its own parameter values and its own set of measurements. Vusers are not threads or processes in a fixed sense: LoadRunner can run them as threads, which is more memory efficient and allows more per load generator, or as processes, which isolates them from one another at the cost of resources.

What they are assessing

Whether they know the workflow end to end.

Model answer

Plan the test, meaning the workload model and the requirements. Record and enhance the script in VuGen, which includes correlation, parameterisation and adding transactions. Verify the script runs correctly for a single user and then for a few. Design the scenario in Controller, setting the user counts, ramp and duration. Execute while monitoring the system under test. Then analyse the results in Analysis and report. The step people skip is single user verification, which is why a two hour test often turns out to have been generating errors from the first minute.

What they are assessing

Comparison with the common open source alternative.

Model answer

LoadRunner is commercial with licence cost tied to virtual user counts and protocols, and it brings far wider protocol support, stronger built-in monitoring and integration with enterprise infrastructure. JMeter is free, Java based, and strong for HTTP and common protocols, with a large plugin ecosystem. The practical differences are that LoadRunner scripts are C based and give fine grained control, its correlation tooling is more mature, and its Analysis component is considerably better than what JMeter provides without additional tooling. Against that, JMeter has no licence constraint on scale, which matters when you need tens of thousands of users.

Trap to avoid

Arguing one is simply better. The interviewer is usually checking whether you select tools on constraints such as protocol and scale rather than on preference.

What they are assessing

Architecture basics, asked in almost every interview.

Model answer

VuGen, the Virtual User Generator, where scripts are recorded and edited. Controller, where scenarios are designed, executed and monitored. Load Generators, the machines that actually run the vusers. And Analysis, which processes the results into graphs and reports. In an enterprise deployment there is also LoadRunner Enterprise, previously called Performance Center, which adds web based management, scheduling and resource allocation across teams.

What they are assessing

Understanding of the distributed model.

Model answer

A load generator is a machine running the agent that executes vusers and sends results back to the Controller. It is separate because generating substantial load is resource intensive and the Controller needs headroom to coordinate, collect results and run monitors. Keeping them separate also allows horizontal scaling by adding generators, and allows generating load from different network locations. A Controller also acting as a load generator is acceptable for small tests and a common cause of distorted results on large ones.

Likely follow-up

How do you know when a load generator is the bottleneck rather than the application?

What they are assessing

Reporting workflow.

Model answer

Analysis processes the raw results file collected during the run into graphs and reports: transaction response times with percentiles, hits per second, throughput, error counts, and any monitored server resources. It supports merging and correlating graphs, which is how you overlay response time against CPU to see whether they move together, and it evaluates SLAs defined before the run. The output is an HTML or Word report plus the Analysis session, which is worth keeping because it is the only artefact that lets someone re-examine a result later.

What they are assessing

Deployment knowledge for restricted networks.

Model answer

The MI Listener is a component that allows the Controller and load generators to communicate across a firewall. Normally the Controller initiates connections to generators on port 54345, which a firewall usually blocks. With an MI Listener placed in the DMZ, both the Controller and the generators initiate outbound connections to it instead, so no inbound rule is needed. You need it whenever load must be generated from outside the network hosting the Controller, which is the usual case when testing from a cloud region or a remote office.

What they are assessing

The decision that determines whether a script is viable at all.

Model answer

By what the client actually sends, not by what the application looks like. VuGen includes a Protocol Advisor that records a sample interaction and recommends, which is a reasonable starting point. For most web applications the answer is Web HTTP/HTML. If the application uses a thick client such as SAP GUI or Citrix, you need that specific protocol. Where a page is heavily JavaScript driven and the HTTP traffic cannot be reliably reproduced, TruClient is the fallback. Choosing wrongly is expensive, because it is discovered during correlation after the script is largely written.

Likely follow-up

What is a multi protocol script and when would you need one?

What they are assessing

A choice that shapes the whole script.

Model answer

HTML mode records at the level of user actions, generating web_link and web_submit_form style calls, with resources such as images and stylesheets retrieved automatically. Scripts are shorter and more readable, and they adapt somewhat to page changes. URL mode records every individual HTTP request explicitly as web_url and web_submit_data, producing longer scripts that are harder to read but more faithful and more controllable. HTML mode is the default for browser applications. URL mode is needed for non browser clients, for applications using heavy JavaScript where HTML mode fails to capture requests, and when you need precise control over what is requested.

What they are assessing

Knowledge of browser level testing in LoadRunner.

Model answer

TruClient is a browser based protocol where the script drives an actual browser engine rather than replaying HTTP requests, so JavaScript executes and the page renders. It is useful when the application is so JavaScript heavy that protocol level correlation is impractical, and when you need client side timing that protocol level scripts cannot measure. The cost is substantial: each vuser needs a browser instance, so resource consumption per user is perhaps two orders of magnitude higher, which caps how many you can run. The usual pattern is protocol level scripts for load and a small number of TruClient users for experienced response time.

Trap to avoid

Proposing TruClient for the whole load. The resource cost makes it impractical at scale, and an interviewer asking this often wants to hear that you would mix approaches.

What they are assessing

Enterprise protocol experience.

Model answer

By identifying which SAP interface is in use, since the protocol differs: SAP GUI for the thick client, SAP Web for the browser based front end, and SAP Web Services for integration points. SAP GUI scripting must be enabled on both the client and the server for recording to work, which is an administrative step people forget. Scripts need careful parameterisation of transaction codes and business data, and SAP GUI vusers are heavy, so the load generator sizing is far more demanding than for a web protocol. Correlation is less of an issue than with web, but screen synchronisation is more so.

What they are assessing

Script structure, asked constantly.

Model answer

vuser_init, which runs once when the vuser starts and is where login and one time setup belong. Action, which contains the business process and is the part that iterates. And vuser_end, which runs once when the vuser finishes and is where logout and cleanup belong. The distinction matters because putting login in Action means every iteration logs in again, which both distorts the load profile and usually fails once the session already exists.

Likely follow-up

Does vuser_end run if the test is stopped abruptly?

What they are assessing

Practical scripting knowledge.

Model answer

Predominantly ANSI C for most protocols, with LoadRunner specific functions prefixed by lr_ for general operations and web_ for web protocol actions. Some protocols use other languages: Java protocols use Java, .NET protocols use C sharp or VB.NET, and TruClient uses a JavaScript based step model. The C basis matters in practice because you have full access to standard C constructs, including string handling and control flow, which is what makes complex correlation and data manipulation possible.

What they are assessing

Logging detail.

Model answer

lr_output_message writes to the output log and the Controller output window. lr_error_message writes an error, which is counted in the results and shown in red, and it marks the vuser as having errored without stopping it. lr_log_message writes only to the log file without appearing in the Controller output. The practical point is that lr_error_message affects the reported error count, so using it for informational messages inflates the error statistics and makes the run look worse than it was.

What they are assessing

The most common VuGen scripting mistake.

Model answer

Functions beginning web_reg, such as web_reg_save_param_ex and web_reg_find, do not act immediately. They register a request that applies to the next web request the script issues. So they must be placed before the step whose response you want to capture or check, not after it. Placing a correlation function after the request that returns the value is the single most common scripting error, and it fails silently in the sense that the parameter is simply never populated, which then surfaces as an apparently unrelated failure later in the script.

Trap to avoid

Placing web_reg_save_param_ex after the request. It is the error interviewers probe for, because it demonstrates whether someone has actually debugged a script.

What they are assessing

Content validation, which many scripts omit.

Model answer

With web_reg_find, registered before the request, specifying text that should be present or absent, and optionally saving a count. This matters because HTTP status alone is a weak check: an application returning a friendly error page responds with 200, so a script checking only the status records a fast success while the application is failing. In a load test that produces excellent response times from a broken system, which is one of the most dangerous false results in performance testing. Content checks are also enabled or disabled globally in runtime settings, which is worth knowing because they can be silently off.

What they are assessing

Parameter handling in C code.

Model answer

It returns the value of a parameter as a string, resolving the parameter notation. You need it whenever a parameter value must be used in C code rather than passed directly to a LoadRunner function, because LoadRunner functions substitute parameters automatically while C functions such as strcmp or sprintf do not. So comparing a correlated value against an expected one, or building a string from several parameters, requires lr_eval_string. Forgetting it produces code that compares the literal parameter name rather than its value, which never matches and is confusing to debug.

What they are assessing

The defining scripting concept.

Model answer

Capturing a dynamic value from a server response and using it in subsequent requests. It is necessary because a recorded script contains values valid only for the recorded session: session identifiers, view state, tokens, generated record ids. Replayed as recorded they are rejected, or worse accepted while doing nothing meaningful. Correlation is what turns a recording into a script that produces real load, and on a complex application it is the majority of the scripting effort.

Likely follow-up

How do you find which values need correlating?

What they are assessing

Practical method.

Model answer

Several approaches, usually combined. Record the same business process twice and compare the scripts with a comparison tool, since anything that differs between two recordings of identical actions is dynamic and probably needs correlating. Use the automatic correlation scan in VuGen, which detects known patterns and application specific rules. Replay with extended logging and look for the first failure, then trace back to the value the server rejected. And rely on experience of what is typically dynamic for the technology in use, since ASP.NET view state, Java session identifiers and CSRF tokens all have recognisable signatures.

What they are assessing

The core correlation function.

Model answer

The function that captures a value from a server response into a parameter. The key arguments are ParamName for the destination parameter, LB and RB for the left and right boundaries delimiting the value, Ord for which occurrence to take when the boundary appears several times, and optionally SaveOffset and SaveLen for finer control. Ord accepts ALL, which saves every match into an indexed array along with a count parameter, which is how you handle a list of items. It must be registered before the request whose response contains the value.

What they are assessing

Modern application handling.

Model answer

Boundary based correlation still works, using the JSON key and the surrounding punctuation as boundaries, and for simple cases it is fine. For anything structured, LoadRunner supports JSON path extraction through web_reg_save_param_json, which is far more robust because it addresses the value by its path rather than by surrounding text, so it survives field reordering and whitespace changes. The general principle is that boundary correlation is fragile against formatting changes, so where a structured extraction is available it should be preferred.

Likely follow-up

Why is boundary correlation fragile for JSON specifically?

What they are assessing

Balance on a convenient feature.

Model answer

VuGen can correlate automatically in two ways: rules based correlation using known patterns for common frameworks, applied during recording, and correlation studio, which compares a recording against a replay and suggests values that differ. Both are genuinely useful and neither is sufficient. Rules only cover known frameworks. Studio produces false positives, suggesting correlation of values that merely happen to differ such as timestamps, and false negatives where a value is dynamic but happened to match. So automatic correlation is a first pass, and the script still needs manual verification against a clean replay.

What they are assessing

Diagnosis of a scenario specific failure.

Model answer

Most often a value that is unique per session but was hardcoded or shared, so under load several vusers use the same identifier and collide. Or a correlated value captured with a boundary that matches a different occurrence when the page content varies with data, which is why Ord matters. Or a value with a short validity window that expires when the system slows under load, such as a token with a timeout. The diagnostic step is to enable extended logging for a small number of vusers during a loaded run and compare what they actually sent against a clean single user replay.

What they are assessing

Tool mechanics rather than the general principle.

Model answer

Each parameter is defined in the script with a type and a set of properties, and file parameters store their values in a dat file inside the script directory, which is why a script folder contains considerably more than the c file. The parameter list is edited through VuGen, and a value is referenced in code by its name in braces, which VuGen substitutes at run time. The practical consequences are that the dat files travel with the script and must reach every load generator, that editing them outside VuGen risks a mismatch with the declared properties, and that large data files increase the footprint copied to every generator in a distributed run.

Likely follow-up

What happens if a data file is missing on one load generator in a distributed test?

What they are assessing

Breadth.

Model answer

File, reading values from a data file, which is the most common. Table, for multi column data. Unique Number, which guarantees distinct values across vusers. Random Number. Date/Time, with configurable offsets, which is how you generate dates relative to the run. Iteration Number and Vuser ID, useful for building unique identifiers. Load Generator Name. Group Name. And user defined functions, where a C function supplies the value, which covers anything the built in types cannot.

What they are assessing

A configuration that determines data behaviour.

Model answer

Select next row controls which row is taken: Sequential, reading in order, Random, or Unique, which guarantees no two vusers get the same value. Update value on controls when a new value is taken: Each iteration, Each occurrence, or Once, which takes a value at the start and keeps it for the whole vuser. The combination matters a great deal. Unique with Once is how you give each vuser its own login for the duration. Sequential with Each iteration is how you walk a data file. Choosing wrongly produces either data collisions or a test where every vuser uses the same record.

Likely follow-up

What happens when a Unique parameter runs out of values?

What they are assessing

Planning rather than scripting.

Model answer

By calculating the requirement before the run: vusers multiplied by iterations multiplied by values consumed per iteration, with margin. For Unique parameters the allocation strategy matters, since LoadRunner can block allocate values per vuser, and an undersized file causes vusers to fail or to wrap depending on the when out of values setting. Beyond the file, the application side matters too: if each iteration creates a record, a long soak test accumulates data that changes system behaviour, so a plan for cleanup or for accepting the growth is part of the design.

What they are assessing

A distinction candidates frequently blur.

Model answer

Parameterisation supplies input data from a source you control, so the script sends different values. Correlation captures values the server generated and feeds them back, so the script responds correctly to what the application returned. Parameterisation is about varying the input; correlation is about maintaining a valid conversation. A script can be fully parameterised and still fail entirely because it is not correlated, and the reverse. They are solved by different mechanisms and the interviewer is usually checking you do not treat them as the same activity.

What they are assessing

The measurement unit.

Model answer

A named block of script bracketed by lr_start_transaction and lr_end_transaction, whose duration is measured and reported. Transactions are how results are reported, so the names you choose become the report, and a script without transactions produces a run you cannot interpret at a business level. They should map to meaningful business steps such as Login, Search, Add to basket and Checkout, rather than to individual HTTP requests.

What they are assessing

Detail on measurement accuracy.

Model answer

LR_PASS, LR_FAIL, LR_STOP and LR_AUTO. LR_AUTO sets the status based on what happened during the transaction, which is the usual choice. The significant point is that a failed transaction is excluded from the response time statistics by default, which is correct because the time taken to fail is not a measure of how long the operation takes. It also means that if a large proportion of transactions fail, the reported response times describe only the successful minority, which is a frequent source of over optimistic reporting.

Likely follow-up

Why does excluding failed transactions from response times matter when reading a result?

What they are assessing

A feature often misused.

Model answer

lr_rendezvous holds vusers at a point in the script until a configured number have arrived, then releases them together, creating a burst of simultaneous requests. It is used to test genuine simultaneity on a specific operation, such as everyone submitting at the moment a sale opens. It should not be used to create general load, because real users do not synchronise, and a scenario built around rendezvous points produces an artificial pattern that measures lock contention rather than throughput. The rendezvous policy in Controller sets how many vusers must arrive and the timeout.

Trap to avoid

Using rendezvous points routinely to increase concurrency. It produces unrealistic spikes and results that do not correspond to any real condition.

What they are assessing

Nested measurement.

Model answer

With nested transactions, which LoadRunner supports: a sub transaction inside an outer one is reported separately while the outer continues to measure the whole. This is how you break a Checkout transaction into its component steps to see which contributes the time, without losing the business level measurement. There is also lr_wasted_time, which subtracts time spent on script activity that is not part of the operation being measured, such as file I/O or correlation logic, so the reported duration reflects the application rather than the script.

What they are assessing

Configuration knowledge.

Model answer

Settings controlling how a script executes, configured in VuGen and overridable in Controller. The ones that matter most are Pacing, which controls iteration rate, Think Time, which controls whether recorded pauses are replayed and how, Run Logic, which sets iteration counts and action order, Log, which determines how much is written, Browser Emulation including cache behaviour, and Miscellaneous for error handling and whether vusers run as threads or processes. Pacing and think time together determine the actual load the test applies, so they are the settings most likely to invalidate a run if set carelessly.

What they are assessing

A setting that changes results by an order of magnitude.

Model answer

Ignore think time, replay as recorded, multiply by a factor, use a random percentage of the recorded value, or limit to a maximum. The right choice for a realistic load test is random within a range around the recorded value, because it models real variation and avoids vusers synchronising into artificial waves. Ignoring think time entirely turns the test into a throughput maximisation exercise: a hundred vusers with no think time generate far more load than a hundred real users, so the concurrency figure in the report becomes meaningless.

Likely follow-up

When is ignoring think time legitimate?

What they are assessing

A distinction that separates practitioners.

Model answer

Think time is the pause within an iteration, between steps. Pacing controls when the next iteration begins. The options are to start a new iteration immediately, after a fixed or random delay, or at a fixed or random interval from the start of the previous one. That last option is the important one, because it gives controlled throughput independent of response time. Without it, throughput falls as the system slows, so a stress test quietly reduces its own applied load exactly when you need it held constant, and the test never reaches the pressure it was designed to apply.

What they are assessing

A practical setting with a performance cost.

Model answer

Minimal or disabled during the actual run, because extended logging with parameter substitution and server responses produces enormous volumes and consumes load generator resources, which reduces the load you can generate and can distort timing. Extended logging is for debugging a single vuser in VuGen or for a small subset during investigation. A common and useful compromise in Controller is to enable logging only on error, so a normal run is quiet and failures still produce diagnostic detail.

What they are assessing

Realism in web testing.

Model answer

Runtime settings control whether the vuser simulates a browser cache and whether it is cleared between iterations. It matters because caching substantially changes the load profile: a cached browser requests only the dynamic content, while an uncached one fetches every static resource. A test with caching disabled overstates the load on static content and understates the proportion hitting the application. The right configuration depends on the user population being modelled, so a mix of first time and returning users is more realistic than either extreme, which can be achieved with separate scripts or groups.

What they are assessing

Controller scenario types.

Model answer

In a manual scenario you specify the number of vusers and the schedule explicitly, retaining full control over the load profile. In a goal oriented scenario you specify a target such as a number of transactions per second, a hit rate or a response time, and LoadRunner adjusts the vuser count to reach it. Manual is the normal choice because it is predictable and repeatable. Goal oriented is useful for capacity questions, such as finding how many users are needed to reach a target throughput, but it produces a varying load profile that is harder to compare between runs.

What they are assessing

Workload mix configuration.

Model answer

A mode where you specify a total number of vusers and allocate them across scripts by percentage, rather than assigning absolute counts to each group. It is convenient for implementing a workload model expressed as a transaction mix, and for scaling the whole test up or down while keeping proportions. The caution is that percentages of vusers do not translate directly into percentages of transactions, because scripts have different durations, so a script taking twice as long produces half the transactions from the same vuser count.

Likely follow-up

How would you achieve a specific transaction mix rather than a vuser mix?

What they are assessing

Ramp configuration.

Model answer

Through the schedule definition, which can be applied by scenario, treating all groups together, or by group, allowing each script its own profile. The elements are the start time, the ramp up in vusers per interval, the duration, which can be a fixed time or until all iterations complete, and the ramp down. Scheduling by group is what lets you model realistic patterns such as a background load running continuously with a batch process starting partway through, which a single scenario level schedule cannot express.

What they are assessing

Test design judgement.

Model answer

Because an instantaneous start is a spike test regardless of what it is called, and because the system needs time to warm caches, fill connection pools and compile code. A gradual ramp also lets you observe the load level at which degradation begins, which a step change hides. I would choose a rate matched to the realistic arrival pattern, typically reaching full load over several minutes, then hold a steady state long enough to measure properly. Results from the ramp period should be excluded from the analysis, because they describe a system that is still stabilising.

What they are assessing

A specific feature with a real purpose.

Model answer

Also called multiple IP addressing, it makes vusers originate from a range of IP addresses rather than all sharing the load generator address. It is used because network components treat traffic by source address: load balancers may apply session affinity and send all traffic from one address to a single server, caches may behave differently, and rate limiting or intrusion prevention may throttle what looks like a flood from one host. Without it, a test can produce results that reflect the load balancer behaviour rather than the application. It requires the addresses to be configured on the generator and routable.

Likely follow-up

What symptom would suggest you need IP spoofing?

What they are assessing

Preparation discipline.

Model answer

That the script replays cleanly for a single vuser with no errors, which is the step most often skipped. That it replays cleanly for a small group, since some issues only appear with concurrency. That the environment is exclusively available and nobody is deploying. That the data is in place and sufficient. That monitors are connected and collecting. That the load generators are reachable and have capacity. And that the baseline and the previous results are to hand for comparison. A failed two hour run because a monitor was not connected is entirely avoidable.

What they are assessing

A check many testers omit.

Model answer

By monitoring the generator itself: CPU, memory, network utilisation and, on Windows, available ports. A generator above roughly seventy percent CPU is suspect, and port exhaustion presents as connection errors that look exactly like application failures. The telling symptom is throughput plateauing while the application tier shows idle resources. The resolution is to add generators or reduce vusers per generator, and vusers running as threads rather than processes substantially increases how many a single machine supports.

Trap to avoid

Reporting a throughput ceiling without checking the generators. It is an embarrassing finding to have to retract after the result has been circulated.

What they are assessing

A configuration with real consequences.

Model answer

Threads share a process, so memory consumption per vuser is far lower and a generator supports many more. Processes isolate each vuser, so a crash affects only that user and there is no shared state. The default is threads because of the capacity advantage. Processes become necessary when the protocol or a third party library used by the script is not thread safe, which produces intermittent and very confusing failures under load that disappear when run as processes. If a script behaves inexplicably only at concurrency, this is worth testing as a hypothesis.

What they are assessing

Practical constraint management.

Model answer

By booking exclusive windows and verifying exclusivity rather than trusting it, because another team deploying or running their own tests invalidates the results and the cause is usually not obvious afterwards. Practically that means a documented booking, a check of the environment immediately before starting, and monitoring that would reveal foreign activity, such as unexplained load in the server metrics. Where exclusivity genuinely cannot be obtained, I would say so in the report as a limitation rather than presenting the numbers as clean, since results from a contended environment are indicative at best.

What they are assessing

Built in observability.

Model answer

Controller includes monitors for Windows and UNIX resources, web servers, application servers, databases and network delay, configured per scenario and displayed live during the run. It also integrates with SiteScope for broader infrastructure monitoring, and LoadRunner Diagnostics provides transaction breakdown into application tiers for Java and .NET. The value of having monitoring in the same tool is correlation: Analysis can overlay a server CPU graph on a response time graph and compute the correlation between them, which is how you move from something is slow to the database tier saturated at this point.

Likely follow-up

What would you monitor on the database tier specifically?

What they are assessing

Diagnostic capability beyond timing.

Model answer

The Web Page Diagnostics breakdown splits a transaction into DNS resolution, connection time, SSL handshake, time to first buffer split into network and server, receive time and client time. It tells you where the time actually went, which is the difference between knowing a page took four seconds and knowing that three and a half of those were server time to first buffer. That distinction changes who investigates: network time points at infrastructure, server time at the application. It needs to be enabled in runtime settings before the run, which is a frequent omission.

What they are assessing

Practical troubleshooting.

Model answer

Credentials or permissions, since Windows resource monitoring needs an account with access to performance counters on the target and remote registry enabled. Firewall rules blocking the monitoring ports. The monitored service not running, such as the remote registry service on Windows. An incorrect host name or an address not resolvable from the Controller. Or the counters not existing on that host, which happens when a template built for one server is applied to another with different roles. The practical lesson is to verify monitors are collecting before the run starts rather than discovering the gap afterwards.

What they are assessing

Analysis method.

Model answer

Errors first, to establish whether the run is valid, because response times from a run with a high error rate describe only the transactions that succeeded. Then running vusers against time, to confirm the intended load was actually applied. Then transaction response time, with percentiles rather than averages. Then throughput and hits per second, to see whether the system kept pace. Then server resources, correlated against the response time graph. The order matters because each step can invalidate the next.

What they are assessing

Statistical reporting in the tool.

Model answer

The Transaction Response Time Percentile graph shows the distribution directly, and the summary report includes the 90th percentile by default with the percentile configurable in the Analysis options. Reporting percentiles rather than averages matters because response time distributions have a long tail, so a mean is pulled by outliers while simultaneously hiding them. I would normally report median, 90th and 95th together, since each answers a different question and the gap between them describes the consistency of the experience.

Likely follow-up

Why is the gap between the median and the 95th percentile informative?

What they are assessing

The feature that turns measurement into diagnosis.

Model answer

Analysis can merge graphs onto a common time axis and compute how closely two measures move together, so you can overlay transaction response time against database CPU, or against the number of running vusers. The correlation value quantifies the relationship. It is how you move from an observation to a cause: response time rising in step with database CPU points somewhere quite different from response time rising while all resources stay flat, which indicates a logical constraint such as a pool or a lock rather than saturation.

What they are assessing

Automated pass and fail criteria.

Model answer

Service level agreements defined in Controller or Analysis, setting thresholds for transaction response times, error rate or throughput, either over the whole run or per time interval. Analysis then evaluates the results against them and reports pass or fail per transaction. The value is that it turns an interpretation into a stated criterion agreed in advance, which removes the argument about whether a result was acceptable. Per interval SLAs are more informative than whole run ones, because a run that meets its average while failing during the peak has not really passed.

What they are assessing

Diagnostic reasoning.

Model answer

Something accumulating. The candidates are a memory leak driving increasing garbage collection, connection or thread pool exhaustion, data growth from records the test itself created, unbounded cache or session growth, and log files filling disk. I would correlate the response time curve against memory and garbage collection on the application tier, and against database size and lock waits. A useful discriminator is whether response times recover after load stops: if they do, it points to contention, and if they do not, to an accumulation that persists.

What they are assessing

Debugging method.

Model answer

Enable extended logging with server responses and replay, which shows exactly what was sent and received. Check whether the failing request depends on a correlated value and whether that parameter was actually populated, since an empty parameter is the most common cause. Check whether a registration function is placed after rather than before its request. Compare the replay against the original recording. And check whether the timeout is genuine, meaning the server really is slow, by issuing the same request manually, which separates a script defect from an application problem.

What they are assessing

Reading errors correctly.

Model answer

Server side failures, which mean the run is measuring a failing system rather than a working one under load. The first question is whether they began at a particular load level, which suggests saturation or resource exhaustion, or from the start, which suggests a script or data problem. Server logs are the authoritative source rather than the LoadRunner output, since the status code alone does not say what failed. Crucially, the response time figures from that run should not be reported as results, because failures are excluded from the statistics and the remaining numbers describe only the subset that worked.

What they are assessing

Infrastructure troubleshooting.

Model answer

Connectivity between Controller and generator, and whether the agent is running, since the agent must be running as a process or service and the service version has limitations with some protocols. Firewall rules on the agent port. Whether the generator has the required protocol installed and licensed. Resource availability, since vusers fail to start when memory is exhausted. Path and permission issues where the script references files the generator account cannot read. And for Windows, whether the agent is running as a service without a desktop session for protocols that need one.

What they are assessing

Data dependent failure analysis.

Model answer

Treat it as a finding rather than a nuisance, because data dependent failure in a load test often reflects a real application defect. The method is to identify which values fail and what they have in common: length, special characters, a different record state, or a path through different code. Then determine whether the application genuinely fails for those inputs, which is a defect worth raising, or whether the script assumes something about the response that only holds for some data, such as a boundary that appears in one layout and not another. The second is a correlation problem and is the more common cause.

What they are assessing

Error handling strategy.

Model answer

A function that enables or disables continue on error for a section of script, overriding the runtime setting. The default behaviour stops a vuser on error, which is usually right because a vuser continuing after a failed login generates meaningless traffic. Selective use is legitimate around a step known to fail harmlessly, such as an optional dialogue, so the vuser continues rather than being lost. The caution is that enabling it globally hides failures and produces a run that appears to complete while generating errors throughout, so it should be scoped narrowly and documented.

Trap to avoid

Enabling continue on error globally to get a run to complete. It converts a visible failure into a quiet one and the results become meaningless.

What they are assessing

Awareness of the enterprise deployment.

Model answer

Formerly Performance Center, it is the web based, multi user deployment of LoadRunner. It adds centralised management of scripts, scenarios and results, scheduling and reservation of load generators across teams, role based access, and project separation. The reason organisations move to it is resource contention: when several teams need load generators and licences, allocating them manually does not scale. Scripts are still authored in VuGen and results still analysed in Analysis, so the scripting work is unchanged.

What they are assessing

Current product awareness.

Model answer

A software as a service offering, previously StormRunner Load, where load generators are provisioned in the cloud on demand rather than maintained as infrastructure. The advantages are elastic scale without owning machines, geographic distribution for realistic network conditions, and no generator maintenance. It supports both LoadRunner scripts and open source formats including JMeter and Gatling, which is a notable change in direction. The considerations are cost at scale and whether the system under test is reachable from the cloud, which for an internal application needs a connector or a VPN.

What they are assessing

Modern delivery practice.

Model answer

Through the command line interface or the REST API of LoadRunner Enterprise or Cloud, triggered from the pipeline, with results retrieved and evaluated against SLAs so the build can fail on regression. The design decisions matter more than the mechanics: the test run in CI should be short and targeted rather than the full scenario, the thresholds should be percentiles with enough tolerance to avoid constant false failures, and the environment must be consistent enough for comparison to mean anything. Full scale tests remain scheduled activities, since neither the duration nor the infrastructure cost suits every commit.

Likely follow-up

What threshold would you set to avoid false failures while still catching regressions?

What they are assessing

Dependency handling.

Model answer

Service Virtualization simulates a dependency the system under test calls, reproducing its interface, latency and error behaviour. It integrates with LoadRunner so a scenario can start the virtual service alongside the test. It is used when the real dependency is unavailable, rate limited, charged per call, or belongs to a third party you have no permission to load test. The critical configuration detail is latency: replacing a real service that takes four hundred milliseconds with an instant mock removes the thread holding behaviour that was part of what you were measuring, so the virtual service must reproduce realistic delay.

What they are assessing

Core web protocol functions.

Model answer

web_url issues a GET request for a URL, used for navigation and resource retrieval. web_submit_data issues a form submission, typically POST, with the form fields supplied explicitly in ITEMDATA, and it does not require the form to have been loaded first. There is also web_submit_form, recorded in HTML mode, which does depend on the preceding page because it locates the form in the previously returned HTML. That dependency is why web_submit_form scripts break when the page changes, and why URL mode scripts using web_submit_data are more robust though less readable.

What they are assessing

Two common practical requirements.

Model answer

Upload is handled by web_submit_data with the file specified in ITEMDATA using the file attribute set to yes, and the file must exist on every load generator at the referenced path, which is the step people miss in a distributed run. Download is a web_url to the resource, with the response saved if you need to verify it; the important consideration is that downloading large files consumes generator bandwidth and memory, so a test with many concurrent downloads can saturate the generator rather than the application. For verification, saving the response and checking size or content is better than assuming a 200 means the right file arrived.

What they are assessing

A detail that causes subtle failures.

Model answer

Which occurrence of the matching boundary pair to capture, since the same boundaries frequently appear several times in a response. Ord equal to 1 takes the first, which is the default. Ord set to ALL captures every match into an indexed array with a count parameter, which is how you handle a list of results and then select one at random or iterate. Getting Ord wrong produces a script that works against one data set and fails against another, because the position of the value you want depends on the content, which is a classic data dependent failure.

What they are assessing

A very common realistic scripting requirement.

Model answer

Correlate with Ord set to ALL, which produces an indexed set of parameters plus a count. Then generate a random number between one and that count in C code, build the parameter name for that index, and retrieve its value with lr_eval_string or lr_paramarr_random, which does it directly. This matters for realism: a script that always selects the first search result produces a cache hit pattern nothing like real usage, and it concentrates database access on a single record, which measures lock contention rather than throughput.

Likely follow-up

Why does always selecting the first result distort the result?

What they are assessing

Applying a workload model in Controller.

Model answer

With separate scripts per user type, each assigned to its own group in the scenario, with vuser counts allocated to reproduce the required mix. Scheduling by group allows each to have its own ramp and duration, which is how you model a background population with a batch job starting partway through. The proportion to aim for is transaction mix rather than vuser mix, since scripts of different durations produce different transaction rates from the same vuser count, so some calculation is needed to convert one into the other.

What they are assessing

Comparative method in the tool.

Model answer

Analysis supports cross result graphs, which overlay the same measurement from several result sets on one chart, which is the right mechanism. The discipline around it matters more than the feature: the runs must be comparable, meaning the same environment, same data state, same workload, same duration and ideally close together in time. And run to run variance must be known, which requires repeating each configuration, because declaring a five percent regression on a system that varies by eight percent between identical runs is reporting noise as a finding.

What they are assessing

A distinction from the older product that still appears.

Model answer

Protocol vusers simulate the client by sending the underlying protocol traffic, which is efficient and allows large numbers per machine. GUI vusers drive an actual application interface, historically through WinRunner and now through TruClient or UFT integration, so they measure what a user experiences including rendering, at the cost of one application instance per user. The practical rule is the same as elsewhere: protocol vusers generate the load, a small number of interface level users measure the experience under that load.

What they are assessing

Realism configuration.

Model answer

It throttles the bandwidth available to each vuser to simulate users on slower connections rather than the load generator network. It matters when a meaningful proportion of real users are on constrained links, because bandwidth changes both the experienced response time and the duration for which server side connections are held, which affects concurrency on the server. The caution is that simulating slow connections for all vusers reduces the throughput a generator can produce, so it is usually applied to a subset representing that population rather than universally.

What they are assessing

Test duration judgement.

Model answer

Long enough to reach and hold a steady state, which usually means at least thirty to sixty minutes of measurement after ramp up for a standard load test, and considerably longer for a soak. The steady state window is chosen in Analysis by filtering the time range to exclude ramp up and ramp down, because including them drags the averages and hides the actual behaviour at full load. The test for whether the duration was sufficient is simply whether the metrics stabilised: if response times are still trending upward at the end, the run has not told you where they settle.

What they are assessing

A basic graph with an important purpose.

Model answer

It shows how many vusers were active over time, which is the first validity check on a run. If the graph does not match the intended schedule, the applied load was not what was planned, and everything downstream is suspect. The common causes of a mismatch are vusers failing and exiting, which reduces load silently as the run proceeds, generators unable to start the full count, and scripts ending early because iterations completed. Overlaying it against throughput is how you confirm that falling throughput was caused by the system rather than by losing vusers.

What they are assessing

Diagnosis of a specific pattern.

Model answer

Either the system slowed, so each vuser completes fewer iterations, or vusers are failing and retrying, or a data source was exhausted and vusers are erroring. The discriminator is the error graph and the running vusers graph: if vusers are still active and errors are flat, the system genuinely slowed and the response time graph will show it. If errors rose at the same point, the drop is a test problem rather than a finding. A third possibility worth checking is pacing, since without a fixed interval pacing setting throughput falls automatically as response time rises, which is a property of the test design rather than a change in the system.

What they are assessing

A routine scripting requirement.

Model answer

Several options. A Unique Number parameter, configured with a block size per vuser so no two collide. A combination of vuser id and iteration number, which guarantees uniqueness across a distributed run without a shared counter. A timestamp from lr_save_datetime, though timestamps alone collide when several vusers execute within the same second, so they need a suffix. For anything persisted to the application, uniqueness must hold across runs as well as within one, which usually means including a run identifier.

What they are assessing

Rigour about result validity.

Model answer

A significant error rate, since the response times then describe only the successful subset. Load generators saturated, meaning the ceiling was ours rather than the application. The applied load not matching the plan, visible in the running vusers or throughput graph. Monitors not collecting, leaving no way to diagnose anything found. The environment shared during the run. Or test data exhausted partway. I would rather repeat a run than publish numbers I cannot defend, because a bad result circulated to stakeholders takes a long time to correct and damages the credibility of the next one.

What they are assessing

A practical commercial constraint.

Model answer

Licences are typically bound to vuser counts and to specific protocol bundles, so the constraints are both how many users you can run and which protocols you can use. In LoadRunner Enterprise, licences are pooled and allocated per project, with reservation to prevent one team consuming the capacity. The planning consequence is real: a test needing more vusers than licensed cannot simply be scaled up, and discovering a protocol is not licensed on the day of the test is a common and avoidable delay. Checking both before scripting begins is part of planning rather than an administrative detail.

What they are assessing

Tool strategy without vendor loyalty.

Model answer

When the protocol requirement is met by the alternative, which for a purely web or API based system it usually is, and when the licence cost is material relative to the value. Also when the team is engineering heavy and would benefit from scripts in a language they already use and keep in version control alongside the application, which suits Gatling or k6 better. I would recommend staying with LoadRunner when the estate includes protocols the alternatives do not support, such as SAP GUI or Citrix, when the built in monitoring and Analysis genuinely save time the team does not have, or when the existing script library represents years of correlation work that would need rebuilding.

Likely follow-up

How would you handle a mixed estate where some systems need LoadRunner and others do not?

What they are assessing

Measurement accuracy.

Model answer

It subtracts time from a transaction that was spent on activity not attributable to the application, such as file I/O in the script, parameter manipulation or custom logging. LoadRunner already deducts the time its own correlation and logging functions take, but custom C code inside a transaction is counted unless you declare it. It matters because a transaction containing a loop that writes to a file reports a duration including that work, which overstates the application response time and makes the result wrong in a direction nobody questions, since slower looks conservative.

What they are assessing

Capacity testing design.

Model answer

With an incremental ramp rather than a single load level: step up the vuser count in defined increments, holding each step long enough to reach steady state and measure, and continuing until the response time requirement is breached or errors appear. The output is a curve of response time and throughput against load, from which the knee is visible and the supported capacity can be stated with a figure. The design details that matter are holding each step long enough that the measurement is not a transient, and using fixed interval pacing so the applied load does not fall as the system slows, which would otherwise mask the limit.

What they are assessing

A closing question revealing depth of experience.

Model answer

Treating the scripting as the work. A technically accomplished script, fully correlated and parameterised, running against a workload model nobody validated, produces a confident and useless result. Close behind are think time removed or ignored so the stated vuser count bears no relation to the load applied, and reporting response times from a run without first checking the error rate. All three share the same character: they do not produce an obviously broken test, they produce a plausible one, which is considerably more dangerous than a run that visibly fails.