Software Testing and Quality Control

JProbe supports two session types: Local Session (profiling an application running on the same machine as JProbe) and Remote Session (profiling an application running on a different machine). This allows flexible profiling setups for both local development and production-like environments. The other options (Managed/Unmanaged, Local/Current, Current/Remote) are not JProbe concepts.

Memory Analysis in JProbe helps identify Java garbage collection issues (objects not being collected, memory leaks) and object cycling problems (objects being created and destroyed excessively). It's not for finding bottlenecks/deadlocks (that's Performance Analysis), identifying unexecuted code (that's Code Coverage), or is irrelevant.

Code Coverage Analysis is used during unit testing to measure which lines/branches/paths of code are executed by test cases. It helps QA developers identify untested code, improve test completeness, and ensure critical code paths are exercised. It's not primarily for functional, performance, or integration testing (though it can complement them).

JProbe licensing supports Node Locked, Per Seat, Concurrent, and Enterprise models to accommodate different organizational deployment and usage needs. The other options are incorrect because they omit concurrent licensing or contain invalid license types like Current Licensing or Starter License.

JProbe is a Java profiling tool designed specifically for Java applications. J2SE (Java 2 Standard Edition) is the core Java platform for desktop and standalone applications, while J2EE (Java 2 Enterprise Edition) extends it for enterprise applications with web services, EJBs, and other enterprise features. JProbe cannot profile Mainframe, C/C++, or Perl applications as these are completely different technology stacks.

JProbe's Code Coverage Analysis provides multiple granularity levels for measuring how thoroughly your tests exercise the code. Method coverage tracks which methods were called, Line coverage tracks which lines of code were executed, and Line With Condition (also called branch coverage) tracks whether all possible outcomes in conditional statements were tested. The 'All' option means all these coverage levels are available for comprehensive testing assessment.

The correct workflow in JProbe is to first create or edit the analysis settings to configure what you want to measure, then attach to the application session to start profiling, and finally load snapshots to view the collected data. Loading snapshots before attaching would mean there's no data to view yet. This logical sequence ensures the profiler is configured before data collection begins.

The 'Set Recording Level' option in JProbe allows you to control the granularity and amount of data collected during profiling. You can choose from different recording levels based on your needs - from detailed method-level tracking to high-level overviews. This helps manage the trade-off between comprehensive data collection and runtime overhead. Trigger, Configure Pool, and Leak Doctor are other JProbe features with different purposes.

In the context of the specific certification or tool pool this question belongs to, the data collected during code coverage analysis is categorized as Missed Column, Switch data, and Conditional Data. The other options contain incorrect combinations of coverage types.

Visual Studio Coded UI Tests support automation of UI interactions, adding validation assertions, and can be integrated into build cycles for regression testing. Since it supports all these capabilities (automation, validation, build integration), 'All of the Above' is correct. Coded UI Tests are part of Visual Studio Enterprise for automated functional testing of applications.

Coded UI Tests in Visual Studio 2010 were designed to work seamlessly with Team Foundation Server for automated testing within the application lifecycle management workflow. Project Server, Integration Server, and Exchange Server are not directly integrated with Coded UI testing capabilities.

Visual Studio 2010 introduced Coded UI Tests as a new test type, enabling automation of user interface actions through code rather than just manual or web performance tests.

GetRoProperty is a generic QTP method that retrieves any runtime property of an object, including 'items count' for a WebList. The other options (GetList, GetItem, GetItemsCount) are not standard QTP methods. GetRoProperty('items count') returns the number of items as a string or number.

The ChildObjects method returns a collection object containing all child objects matching the description properties you specify. It returns a Collection object (not a simple count or boolean), which you can then iterate through using .Count and .Item(index). This is essential for dynamic object handling when you don't know exactly how many objects exist.

In QTP, you mark an action as reusable through the Action Properties dialog (right-click the action → Action Properties). This is not done through Action Settings (which handles iteration), Action Run Settings (for action call parameters), or Action Call properties (which configures how an action is called, not its reusability). Option B correctly identifies the location.