LoadRunner Performance Testing

VuGen (Virtual User Generator) is the tool used to create scripts in LoadRunner. It records user actions and generates the script code. Controller manages load tests, Analyzer analyzes results, and Generator is not a standard LoadRunner component.

The Controller is the central console for managing and executing load tests in LoadRunner. It orchestrates load generators, manages the test execution, and monitors results. VuGen creates scripts, Analyzer analyzes results after test completion, and Generator is not a standard component.

In LoadRunner performance testing, the Analyzer is the component that processes and displays run results. The Controller manages test execution, the Generator creates load via Vusers, and the Analyzer provides detailed analysis and reports of the test run.

In LoadRunner, the Generator is responsible for creating load on the system under test. It runs Vusers (virtual users) that simulate real user activity. The Controller orchestrates the test, while the Analyzer examines results afterward.

QTP (QuickTest Professional, now UFT) is a functional/automation testing tool, not a performance testing tool. LoadRunner, JMeter, and RadView WebLoad are all performance testing tools used for load and stress testing applications.

RTE (Remote Terminal Emulator) protocol is specifically used in LoadRunner for testing terminal emulator and mainframe applications. HTTP is for web applications and RMI is for Java distributed objects.

HP/Micro Focus LoadRunner is highly capable but notoriously expensive to license compared to open-source tools like JMeter. It fully supports XML and middleware protocols, meaning those options are incorrect.

To perform manual correlation, you need to identify dynamic values returned by the server. The recommended logging setting is 'Extended -> Data Returned by Server', which logs the complete HTTP responses. 'Parameter Substitution' only logs evaluated parameters, and standard or disabled logging lacks response details.

The animated run delay setting in VuGen specifies a delay (in milliseconds) introduced between the execution of each step/line of code during replay. Setting it to 5,000 ms makes each line pause for 5 seconds before running the next.

To perform automatic correlation in LoadRunner, you must play back the script at least once. This execution generates the replay logs and response data necessary for VuGen to compare the recording and replay snapshots and identify dynamic values.

A for loop that executes 10 times requires starting at 1, continuing while i is less than or equal to 10, and incrementing i each iteration. Option A and B use i-- which would decrement, causing infinite loops. Option C only runs 9 times (i from 1 to 9). Option D correctly runs from i=1 to i=10 inclusive.

In VuGen (LoadRunner), the Group Name parameter type will always have the value of one when replayed. This is because Group Name represents the Vuser group assignment, and during replay, all Vusers in the same group execute together. Vuser ID varies per Vuser, Iteration Number increments each iteration, and Random Number changes each call.

In LoadRunner, lr_advance_param is the standard utility function used to advance to the next value of a specified parameter. lr_next_value, web_next_param, and web_advance_parameter are not valid built-in LoadRunner API functions.

URL-based recording level in LoadRunner always generates the web_submit_data function because it captures each request at the URL level regardless of the form submission method. HTML-based recording may generate web_submit_form or web_submit_data depending on the form structure. ICA and RDP are different protocols (Citrix and Remote Desktop).

The correct run logic is Create 67%, Search 16%, Block0 17%, then Search Modify. The math checks out: 40 Create / 60 total actions = 67%, and the dependency (Modify requires Search) is satisfied by the Block0 structure. Other options either don't satisfy the Modify-Search dependency or miscalculate the percentages (57% would be incorrect for 40/60).

web_reg_save_param is the classic LoadRunner function used to register a request to save dynamic data (correlation) from the server. web_reg_find checks for text, and other functions like web_reg_save_find or web_reg_save_value either do not exist or do not serve this purpose.

The If keyword is a conditional statement that executes code based on whether a condition is true or false. For, Do, and While are loop constructs that repeat code blocks multiple times. Conditional statements control program flow based on conditions, while loops control iteration.

In HP LoadRunner (or Micro Focus VuGen) Run Logic block properties, the block execution logic can be set to either 'Sequential' or 'Random' to control how the containing actions are called. 'File' and 'Unique' are parameter types, not block run logic settings.

To generate unique emails formatted like [email protected] (note the lowercase 't' in the prompt's testing99999 and the option's lowercase testing), a Unique Number parameter is used with standard format testing%[email protected]. However, the option marked correct uses capitalization Testing%[email protected] which differs from the question requirement, and Option 603638 specifies a File parameter which is incorrect for purely generating unique numeric sequences. Actually, a Unique Number parameter generates values per Vuser block. The casing difference makes the options slightly imperfect, but Option 603639 is the intended unique parameter option.

When performing manual correlation in VuGen, you search for dynamic values in the Server Response (Tree view) because that's where the server sends back session IDs, timestamps, and other dynamically generated values. The Script view shows your code, Recording Log shows the capture process, and Client Request shows what you sent to the server.