Software Testing Fundamentals

The Virtual User Generator in LoadRunner creates script files with the .usr extension. These files contain the recorded user actions and can be edited and replayed. The .usr format is the standard for LoadRunner Vuser scripts.

In LoadRunner, scenario runtime settings take precedence over individual script runtime settings. When a scenario runs, any settings configured at the scenario level override the default or script-level settings. This hierarchy allows testers to customize behavior without modifying individual scripts.

LoadRunner's Virtual User Generator generates scripts in C language by default. These C-based scripts contain the recorded user actions and can be enhanced with C programming constructs. The use of C allows for flexible script modification and customization.

LoadRunner is primarily a performance testing tool used to simulate user load and measure system behavior under stress. While it can be part of a broader testing strategy, its core purpose is performance and load testing, not functional, regression, or unit testing.

Regression testing specifically checks that recent code or configuration changes haven't adversely affected existing features. When any module is modified, regression testing validates that the entire application still functions correctly, catching unintended side effects.

Usability testing directly measures how easily users can interact with a system - evaluating user-friendliness through factors like learnability, efficiency, memorability, error prevention, and user satisfaction. User Acceptance Testing (UAT) is different - it validates business requirements before deployment.

Black box testing validates functionality based on requirements without examining internal code structure. Testers focus on inputs and outputs against functional specifications, making it ideal for testing based on functional requirements. System testing is broader (entire system), while unit testing is narrower (individual components).

Glass box testing (also called white box or clear box testing) examines internal code structure, logic flow, algorithms, and implementation details. Testers need knowledge of the code's internal workings to design tests. This directly matches 'testing based on internal logic'.

Incremental integration testing continuously validates integrated modules as new functionality is added. Each increment is tested immediately upon integration, ensuring smooth ongoing integration rather than waiting until all features are complete.

Static testing examines software artifacts (requirements, design documents, code) without executing the program. It includes reviews, walkthroughs, and inspections. Options A and C both describe aspects of testing, but C is more precise for static testing. Option B describes model-based testing, which is dynamic.

Acceptance testing is primarily designed to establish confidence in the system and demonstrate that it meets user needs and business requirements, rather than finding defects. Conversely, system, integration, and migration testing are focused directly on identifying and fixing defects.

Boundary value analysis tests at the edges of valid input ranges. For 1000-2000, test just below the lower bound (999), at the lower bound (1000), at the upper bound (2000), and just above the upper bound (2001). This catches off-by-one errors. Option B captures all four critical boundary values.

Non-functional testing evaluates system characteristics rather than specific behaviors. Performance testing measures speed, scalability, and stability. Usability testing assesses user experience. Both are non-functional. System testing is functional (validates features work correctly).

Functional testing validates what the system does - its features, functions, and interoperability. Option B correctly describes this. Option A lists non-functional tests (performance, load, stress). Option C describes non-functional characteristics. Option D is incorrect - functional testing tests 'what' the system does, not 'how' it works internally.

Test management tools organize test cases, execution, and reporting. Quality Center (now HP ALM) is a comprehensive test management tool. Quick Test Professional is automated functional testing. Load Runner is performance testing. JMeter is load/performance testing. Only Quality Center manages the entire testing process.

Validation determines whether the software meets the user's actual needs, which is commonly summarized as building the right software. Verification, by contrast, is checking if the software was built right according to the specifications, which makes the other options incorrect.

Regression testing verifies that existing functionality still works after changes. Capture/Playback tools record test actions and replay them automatically, making them ideal for repeated regression tests. Test management tools organize tests but don't execute them. Boundary testers focus on edge cases, not regression. Data comparators validate data integrity.

White-box testing examines internal code structure. Mutation Testing alters code to verify tests catch changes. Fault Injection introduces errors to test system response. Code coverage measures how much code is executed. Specification-based testing uses requirements without code knowledge - it's black-box, not white-box.

Security testing is essential for software handling confidential data as it identifies vulnerabilities that hackers could exploit to intrude into the system. Destructive testing tests system stability under stress, usability testing evaluates user experience, and stability testing checks system reliability under load - none specifically address hacker intrusion prevention.

Smoke testing is a quick, initial suite of tests run on a new build to determine if the software is stable enough to proceed with further, more detailed testing. Distractors like end-user testing refer to acceptance testing, while the distinction between possible and reasonable is minor.