HP QTP Question Bank: Q. 71 to 80
Q. 71: What are the various types of objects identified by the comparison tool in QTP?
1) Identical: Objects that appear in both object repository files. There is no difference in their name or in their properties.
2) Matching description, different name: Objects that appear in both object repository files that have different names, but the same description properties and values.
3) Similar description: Objects that appear in both object repository files that have similar, but not identical, description properties and values. One of the objects always has a subset of the properties set of the other object. This implies that it is likely to be a less detailed description of the same object. For example, an object named Button_1 in the second object repository has the same description properties and values as an object named Button_1 in the first object repository,
but also has additional properties and values.Objects that do not have a description, such as Page or Browser objects, are compared by name only. If the same object is contained in both the object repositories but with different names, they will be shown in the object repositories as two separate objects.
4) Unique to first file, or Unique to second file. Objects that appear in only one of the object repository files.
<<<<<< =================== >>>>>>
Q. 72: What are the situations best suited to Recording in QTP?
Recording can be useful in the following situations:
# Recording helps novice QTP users learn how QTP interprets the operations we perform on our application, and how it converts them to QTP objects and built-in operations.
# Recording can be useful for more advanced QTP users when working with a new application or major new features of an existing application. Recording is also helpful while developing functions that incorporate built-in QTP keywords.
# Recording can be useful when we need to quickly create a test that tests the basic functionality of an application or feature, but does not require long-term maintenance.
<<<<<< =================== >>>>>>
Q. 73: What are the advantages of Keyword Driven testing in QTP?
1) Keyword-driven testing enables us to design our tests at a business level rather than at the object level.
2) By incorporating technical operations, such as a synchronization statement that waits for client-server communications to finish, into higher level keywords, tests are easier to read and easier for less technical application testers to maintain when the application changes.
3) Keyword-driven testing naturally leads to a more efficient separation between resource maintenance and test maintenance. This enables the automation experts to focus on maintaining objects and functions while application testers focus on maintaining the test structure and design.
4) When we record tests, we may not notice that new objects are being added to the local object repository. This may result in many testers maintaining local object repositories with copies of the same objects. When using a keyword-driven methodology, we select the objects for our steps from the existing object repository. When we need a new object, we can add it to our local object repository temporarily, but we are also aware that we need to add it to the shared object repository for future use.
<<<<<< =================== >>>>>>
Q. 74: What are Absolute and Relative Paths in QTP?
We can save QTP resources, such as shared object repositories, function libraries, recovery scenarios or environments, using absolute or relative paths.
1) An absolute path: Describes the full path to a specific file starting from a fixed location such as the root directory, or the drive on which the file is located, and contains all the other sub-directories in the path. An absolute path always points to the specified file, regardless of the current directory.
2) A relative path: Describes the path to a specific file starting from a given directory, and is generally only a portion of the absolute path. A relative path therefore specifies the location of the file relative to the given location in the file system.
Using relative paths means that the paths remain valid when files or folders containing files are moved or copied to other locations or computers, provided that they are moved within the same folder structure. For this reason, we recommend that we use relative paths when saving resources in QTP.
<<<<<< =================== >>>>>>
Q. 75: What are the situations best suited to Keyword-driven methodology in QTP?
The keyword-driven methodology is especially useful for organizations that have both technical and less technical users because it offers a clear division of automation tasks. This enables a few experts to maintain the resource framework while less technical users design and maintain automated test steps. Additionally, once the basic infrastructure is in place, both types of users can often do their tasks simultaneously.
<<<<<< =================== >>>>>>
Q. 76: What are the steps for implementing tests with Keyword Driven Methodology?
Step 1: Analyze the application to find out the testing needs: In this step, weu determine our application�s development environment, such as Web, Java, or .NET, so that we can load the required QTP add-ins. We also find out the business processes and functionality we want to test.
Step 2: Set up object repositories: After we decide what we want to test and how to divide our actions, we build the set of resources to be used by our tests. The most widely used resource is the shared object repository.
Step 3: Create function libraries: After we create our object repositories, we create function libraries containing functions that extend QTP functionality. Application testers can use these keywords to build keyword-driven tests.
Step 4: Configure QTP according to our testing needs: Here we set up the global testing preferences, run session preferences, and any test-specific preferences. If needed, we can create recovery scenarios that instruct QTP how to proceed when a step fails. We also configure the QTP window so that we can easily access any needed panes, such as the Test Flow pane, the Resources pane, and the Available Keywords pane.
Step 5: Build the tests: We now construct our tests by inserting calls to the relevant actions from our tests. Ccreate one or more empty tests and add actions to them. Make sure that we associate our object repositories with the relevant actions, and associate our function libraries and recovery scenarios with the relevant tests, so that we can insert steps using keywords. We may also need to configure test preferences at this point.
Step 6: Add steps to the test actions: Add steps that use the keywords we created in previous steps. We can then enhance our tests by inserting checkpoints and output values to verify that our application is behaving according to expectations. We can add programmatic statements to further enhance our tests.
Step 7: Run, analyze, and troubleshoot our tests: When our tests are ready, we run them, view the run results, and troubleshoot our tests, as needed.
<<<<<< =================== >>>>>>
Q. 77: How do we analyze our application to determine our testing needs using QTP?
1) Determine the development environments that QuickTest needs to support: Our application comprises of windows containing a hierarchy of objects that were created in one or more development environments. QTP provides support for these environments using add-ins. We load QTP add-ins when QTP opens by using the Add-in Manager dialog box. We can check which add-ins are loaded by choosing Help > About QTP.
2) Prepare the information that QTP needs to identify objects in our application and to open our application at the beginning of a run session. We need to know the URL, the executable file name and path, or other command-line information. Later, we will enter this in Record and Run Settings dialog box.
3) Navigate through our application from a cusf nr5tomer�s perspective and perform the tasks that customers might perform. We create an action for each sub-process, or task, a customer might perform. Each process we perform in our application will be represented as a test in QTP. We can create our tests now.
<<<<<< =================== >>>>>>
Q. 78: In what situations recording mechanism shall be useful in creating tests in QTP?
1) We are new to QTP and want to learn how QTP interprets the operations we perform on our application and how it converts them to QTP objects and built-in operations.
2) We need to quickly create a test that tests the basic functionality of an application or feature, and the test does not require long-term maintenance.
3) We are working with a new application or with major new features of an existing application, and we want to learn how QTP interacts with the application.
4) We are developing functions that incorporate built-in QTP keywords.
<<<<<< =================== >>>>>>
Q. 79: What are the various Recording Modes in QTP?
1) Normal or the default recording mode: This records the objects in our application and the operations performed on them. This mode takes full advantage of the QTP object model, recognizing the objects in our application regardless of their location on the screen.
2) Analog Recording: This enables us to record the exact mouse and keyboard operations we perform in relation to either the screen or the application window. In this recording mode, QTP records and tracks every movement of the mouse as we drag the mouse around a screen or window.
3) Low Level Recording:This enables us to record on any object in our application, whether or not QTP recognizes the specific object or the specific operation. This mode records at the object level and records all run-time objects as Window or WinObject test objects.
<<<<<< =================== >>>>>>
Q. 80: How can we switch to Low Level Recording mode while editing a test?
We can switch to Low Level Recording mode only while recording a test. The option is not available while editing a test.
Continue to Next Part : Q 81 to 90
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.