Articles

LoadRunner Interview Questions: Correlation, Replay Failures, and Workload Pacing

Practice LoadRunner interview questions on correlation, failed replay, business assertions, pacing, think time and credible workload calculations.

LoadRunner interview questions are easiest to answer when you separate correct replay from credible load. A script that finishes is not necessarily a successful customer journey. A test with 100 virtual users does not necessarily offer the same workload after response times change.

Begin with Improve and measure service performance, then rehearse a narrower LoadRunner explanation: find the first response that issued a dynamic value, prove the next request used it, and reconcile iteration timing with successful business throughput.

Evidence boundary: The product behavior below comes from linked OpenText documentation. The checkout ledger, timing calculations and follow-up exercises are original preparation examples. They are not candidate reports, leaked assessments or claims about an employer's interview process. The scripting example concerns VuGen's Web HTTP/HTML C API; other protocols have different functions and runtime controls.

LoadRunner interview questions: correlation or parameterization?

OpenText's correlation overview distinguishes server-issued values used in subsequent requests from input values supplied by your test. Both can appear as parameters in the script, but their origin determines how you obtain them.

In an original checkout exercise, the username comes from a controlled test-data file. The server returns a session-specific anti-forgery token in a login form. After authentication, it returns a cart identifier used by checkout. Substituting a different username does not repair either server-issued value.

A strong answer names the producer, consumer and lifetime. “I parameterize the token” leaves the important question unanswered: where does the current value come from? Explain whether it changes per session, per form or per operation. Refresh it at that boundary, and identify whether the matching cookie or authenticated session must remain valid too.

Do not correlate every changing string. A timestamp in an analytics request may have different semantics from a protected checkout token. Compare two recordings and the corresponding responses, then confirm that the value participates in the business operation. A textual difference is a candidate for investigation, not proof that a substitution is required.

Where should the extraction function go?

The manual correlation guide places the registration before the request whose response contains the value. The web_reg_save_param_ex reference explains that it registers extraction for the next action function; it does not search a response that has already arrived.

This abbreviated C fragment uses a synthetic HTML contract. Replace the URL and boundaries with evidence from the application under test:

web_reg_save_param_ex(
    "ParamName=csrf",
    "LB=name=\"csrf\" value=\"",
    "RB=\"",
    "NotFound=error",
    SEARCH_FILTERS,
    "Scope=Body",
    LAST);

web_url("login_form",
    "URL=https://example.test/login",
    "Resource=0",
    "Mode=HTTP",
    LAST);

/* The subsequent form submission uses {csrf}. */

The important ordering is registration, producing request, then consuming request. Registering immediately before the POST is too late if the token was issued by the earlier GET. The extracted value also needs the representation expected by the consumer; HTML escaping and URL encoding are not interchangeable.

For a JSON response, consider the documented JSON extraction function rather than brittle HTML boundaries. Scope the search to the relevant response and inspect multiple matches. A token for a different form can be syntactically valid while failing the intended operation. Never choose an occurrence merely because it makes the error disappear.

The fragment is a reasoning aid, not a replay-tested application script. In practice, prove extraction, substitution and business outcome across multiple iterations and independent Vusers before increasing load.

How do you locate the first replay divergence?

Use this original ledger to resist fixing only the final error:

Step	Expected replay evidence	Observed failure	Next investigation
GET login form	Current session issues a new token	Fresh token appears in response	Confirm extraction and scope
POST sign-in	Request sends that token with matching session	Recorded token is still submitted	Repair the producer-to-consumer substitution
POST checkout	Authenticated cart produces an order confirmation	HTTP 200 contains the login page	Treat this as a failed journey, not a fast checkout

Compare request bodies, relevant headers and response content at the earliest mismatch. Keep secrets out of shared evidence. A status code, error message and elapsed time describe different properties; retain all three when they affect the diagnosis.

If the POST sends the current token but still fails, the hypothesis changes. Inspect cookie handling, expiry, redirects, account state, permissions and one-time-use behavior. If the application returns a new token after each submission, capturing it once during initialization does not satisfy the next iteration's contract.

OpenText's automatic correlation documentation describes rule, recording and replay approaches. Explain how you validate a suggested replacement. A broad rule that captures a neighboring field or rewrites an unrelated identifier can conceal the original error and introduce a new one.

Why is HTTP 200 insufficient for a passed transaction?

The web_reg_find reference supports checking returned content. Its registration return value reports whether registration succeeded, not whether the later response passed the check. When using SaveCount without Fail, inspect the saved count after the producing request; a zero count does not automatically fail that configuration.

For the checkout fixture, define success as an order confirmation associated with the current cart. Searching for the word “Order” anywhere is weak because navigation or an error page may contain it. Choose an assertion that tests the intended state, and use a structured response field when that is the application's contract.

A useful outline is: start the checkout transaction, register the outcome check, perform the request, inspect the outcome, and end the transaction with the appropriate status. The transaction reference permits explicit pass/fail status. Do not assume LR_AUTO independently understands business success.

Decide how a failed prerequisite affects later steps. Continuing into checkout after sign-in failed measures a different path. Stop or skip that path according to a declared policy, count the failure, and preserve enough diagnostic evidence to identify its cause. Suppressing failures to obtain a tidy response-time graph destroys the test's meaning.

How do pacing and think time change the workload?

OpenText's runtime settings guide distinguishes pacing between iterations from think time between actions. Its manual configuration reference lists interval and after-iteration settings. Confirm the selected protocol's wording and behavior in your installed version; do not transfer configuration keys between protocols.

Consider an original simplified model with 100 independently staggered Vusers. Each iteration contains one checkout and takes eight seconds, including any modeled pauses inside it. Initialization, ramp-up and failures are excluded from this steady-state calculation.

Pacing assumption	Start-to-start time	Approximate iteration rate
Ten-second start interval	10 seconds: 8 work + 2 wait	100 / 10 = 10 per second
Ten-second delay after completion	18 seconds: 8 work + 10 wait	100 / 18 ≈ 5.56 per second
Ten-second start interval, work rises to 14 seconds, no overlapping iterations	At least 14 seconds	At most about 100 / 14 ≈ 7.14 per second

The final row is an explicit modeling assumption, not a universal scheduler promise. A sequential user cannot start another iteration while its current one is still running. Inspect actual iteration timestamps and overruns to establish what your runtime did.

The timing illustration is schematic. The labels, not the drawn lengths, define the example. This distinction matters in an interview: identical user counts can generate different iteration rates, and slowing responses can reduce offered work in a sequential-user test. That reduction can hide deterioration if you look only at completed throughput.

Can you infer request rate from Vuser count?

Not without the journey, timing and outcome definitions. An iteration may contain several requests, redirects and resource downloads. A checkout transaction may include multiple calls. “Ten iterations per second” and “ten HTTP requests per second” are different measurements.

In the original model, suppose each completed iteration makes three relevant application calls. Ten iterations per second would imply roughly 30 such calls per second under those assumptions. It does not include incidental resources or retries. If only 90% of iterations complete a valid checkout, successful checkout throughput is approximately nine per second, even when iteration throughput remains ten.

These are planning estimates to compare against observed results. State the measurement window and distinguish starts, completions, failed attempts and business successes. During ramp-up or a growing queue, completions can lag starts substantially. Avoid comparing an arrival count from one interval with a completion count from another.

The DevWeb runtime guide explicitly describes delay and interval pacing. It does not turn every sequential-user scenario into an independent arrival process. If the requirement is an arrival rate that persists as responses slow, explain the workload model you need and verify that the selected tool configuration implements it.

Consider an original failure-mix exercise: a baseline has 100 successful checkouts averaging 700 ms. A later run has 80 successful checkouts averaging 800 ms and 20 failed login responses averaging 50 ms. Averaging all 100 durations gives 650 ms: (80 × 800 + 20 × 50) / 100. The combined average looks better while successful journeys became slower and one fifth of attempts failed.

Report successful-journey latency alongside the failure rate and failed-path timings. Retain the failed attempts rather than dropping them from the workload denominator. A separate successful-latency distribution answers how completed customers experienced the service; the failure rate answers how many attempts never reached that outcome. Neither replaces the other. Check whether the transaction boundaries changed between runs before attributing the difference to an application improvement.

What would you show after repairing the script?

Present three pieces of evidence: the dynamic-value chain now matches the current session, the business assertion succeeds, and the observed iteration timeline matches the intended workload. Then compare performance under the same script, data allocation, environment and scenario settings.

Test more than the first successful iteration. A token may expire, a cart may be consumed, or a test account may run out of usable records. Reusing one shared account across Vusers can introduce contention or invalid state that is unrelated to server capacity. Document the ownership and reset policy for test data.

Keep detailed response and substitution logging for targeted debugging, then check the overhead of the measurement setup before a larger run. Monitor load-generator resources alongside application resources. An exhausted generator can reduce offered work and make a server look healthy.

A convincing answer closes with a bounded conclusion: “The replay defect is fixed for these exercised sessions; the configured workload produced this observed start rate; successful checkout latency and failure rate met these declared criteria.” Name the untested expiry, concurrency or duration case that would limit that conclusion.

Sources and Further Reading

Research checked October 4, 2026. Verify protocol-specific controls against the version used in your interview or workplace.