Software Testing: QTP and Load Runner Essentials

The Controller component in Load Runner is responsible for executing and managing load test scenarios. It coordinates multiple Vuser groups generated by VuGen and monitors the test during execution. VuGen (Option A) creates scripts, and Analyzer (Option C) analyzes results after the test completes. Options D and E are incorrect.

Load Runner is primarily used for performance testing types including volume testing (testing with large data volumes) and endurance testing (testing system stability over extended periods). It is not designed for functional testing, which validates software functionality rather than performance. Option A alone is incomplete, Option C alone is incomplete, and Option E incorrectly includes functional testing.

The load testing process follows a logical sequence: Plan the test, Create scripts using VuGen, Define the scenario (load patterns, Vusers), Run the scenario using Controller, and Analyze results using Analyzer. Option A presents this correct sequence. Options B and D disrupt the logical flow by running scenarios before script creation or scenario definition, and Option C reverses the entire process.

Rendezvous points in LoadRunner are specifically designed to synchronize virtual users so they execute a transaction simultaneously, creating maximum load on that specific transaction. Parameterization is for varying data, correlation is for handling session IDs, and rendezvous points are the synchronization mechanism.

Unix/Linux machines are most commonly used as Load Generators in LoadRunner because they can efficiently simulate multiple virtual users with less overhead. The Controller and VUGen typically run on Windows, while load generators are often Unix/Linux for scalability.

Little's Law states: Number in System = Throughput × Response Time. Therefore Response Time = Number of Users / Throughput. This shows response time is inversely proportional to throughput (option B). The product of response time and throughput equals the number of users in the system (option C), which is constant for a fixed user count.

The ORD=ALL attribute in web_reg_save_param captures all occurrences of a parameter that match the specified boundaries within a response, saving them into an array. ORD=EACH would capture different instances, ORD=ALL is correct for multiple matches with same boundary.

Ramp-up time is the period during a load test where users are gradually added to the system at a constant rate until the target load is reached. Think time is user pause between transactions, Elapsed time is total duration, Spike time refers to sudden load bursts.

web_reg_find is the LoadRunner function used for text validation - it checks whether a specific text string exists in the server response. web_reg_save_param is for correlation, lr_get_attrib_string gets parameter attributes, lr_check_text doesn't exist in LoadRunner.

QTP scripts can run from LoadRunner but only if you have specific Controller licensing that supports GUI Vuser protocols. Standard LoadRunner licenses don't include this capability. The integration allows functional scripts to be used in performance testing.

QTP (QuickTest Professional, now Unified Functional Testing) is primarily used for functional testing to verify applications work as specified, and regression testing to ensure code changes don't break existing functionality. It is NOT used for load testing (that requires tools like LoadRunner) nor primarily for integration testing.

Context Sensitive recording is QTP's default and most commonly used mode because it records at the object level, making scripts more maintainable and readable. Analog recording captures exact mouse movements and keystrokes (useful for drag operations), while Low-level recording is a fallback when object recognition fails.

In QTP, an action can be associated with multiple shared object repositories (ORs). This allows you to modularize test objects across different ORs and associate them with a single action as needed, promoting reusability and organization.

The statement is false. Identification properties in QTP are properties that QTP uses to uniquely identify objects in the application under test. They're not defined within the application itself but are determined by QTP's object identification mechanism based on properties like name, class, etc.

QTP function libraries use the .vbs (VBScript) extension because QTP uses VBScript as its scripting language. .tsr is for test object repository files, .trs is for test results, and .txt would not be recognized as a function library.

QTP supports Standard, Text, Bitmap, Table, Database, XML, Accessibility, and Page checkpoints among others. There is no checkpoint type called 'Basic checkpoint'; this is the incorrect option among the listed choices.

Configuration Management (CM) ensures the integrity of test artifacts. Key purposes include identifying software version under test, controlling testware versions, and tracking changes to testware. Distractors are wrong because CM manages version control and change history rather than actively developing new testware items.

To solve this question, the user needs to know the correct sequence of the phases of a formal review. A formal review is a process of examining software artifacts by a team of individuals to detect errors, defects, and other issues. The review process is divided into several phases, each of which has a specific objective.

Now, let's go through each option and explain why it is right or wrong:

A. Planning, Review meeting, Rework, Kick off: This option is incorrect. The correct sequence for a formal review is Planning, Individual preparation, Review meeting, Rework, and Follow up. In this option, the sequence of phases is incorrect. The Kick-off phase should be before the Planning phase.

B. Planning, Individual preparation, Kick off, Rework: This option is incorrect. The correct sequence for a formal review is Planning, Individual preparation, Review meeting, Rework, and Follow up. In this option, the Kick-off phase should be after the Planning phase, not before the Individual preparation phase.

C. Planning, Review meeting, Rework, Follow up: This option is correct. The correct sequence for a formal review is Planning, Individual preparation, Review meeting, Rework, and Follow up. In this option, the flow of phases is in the correct order.

D. Planning, Individual preparation, Follow up, Kick off: This option is incorrect. The correct sequence for a formal review is Planning, Individual preparation, Review meeting, Rework, and Follow up. In this option, the Follow up phase should be after the Rework phase, not before the Kick off phase.

The Answer is: C

Static testing applies throughout the software development lifecycle - it includes reviews of requirements documents, design specifications, and code without actually executing the program. Each phase benefits from static analysis techniques.