QTP10.com is a new and completely free website that offers help in all the versions of HP QTP (including latest version 10). More importantly, it offers free code for users of HP QuickTest Professioal. This site helps you in learning the basics of QTP and descriptive/advanced programming in (QTP) on various environments like - .Net, Infragistics, Web, Windows, etc.

Note -
This blog is NOT affiliated with HP / Hewlett-Packard in any way. The data/questions come from various sources and we have our own testing questions. I am just another Software Tester like you.

QTP Interview Questions and Answers – Part 5

Share This Post -

Sponsored Links:

[Source of answers: HP QTP User Guide]
41. How can we run standard DOS commands in QTP tests?
You can run standard DOS commands in your QTP test or function using the VBScript Windows Scripting Host Shell object (WSCript.shell).
For example, you can open a DOS command window, change the path to C:\, and run the DIR command using the following statements:
Dim oShell
Set oShell = CreateObject ("WSCript.shell")
oShell.run "cmd /K CD C:\ & Dir"
Set oShell = Nothing
For more information, refer to the Microsoft VBScript Language Reference (choose Help > QTP Professional Help > VBScript Reference > VBScript).

42. How can we switch to Low Level Recording mode while editing a test script in QTP?
You can switch to Low Level Recording mode only while recording a test. The option is not available while editing a test.

43. How can we verify the data content of XML files in QTP?
By adding XML checkpoints to your tests, you can verify that the data and structure in your XML documents or files has not changed unexpectedly. When you run your test, QTP compares the expected results of the checkpoint to the actual results of the run session. If the results do not match, the checkpoint fails.
You can verify the data content of XML files with XML checkpoints. A few common uses of XML checkpoints are described below:

An XML file can be a static data file that is accessed to retrieve commonly used data for which a quick response time is needed—for example, country names, zip codes, or area codes. Although this data can change over time, it is normally quite static. You can use an XML file checkpoint to validate that the data has not changed from one application release to another.

An XML file can consist of elements with attributes and values (character data). There is a parent and child relationship between the elements, and elements can have attributes associated with them. If any part of this hierarchy (including data) changes, your application's ability to process the XML file may be affected. Using an XML checkpoint, you can check the content of an element to make sure that its tags, attributes, and values have not changed.

Web service operations often return XML values. If the Web Service Add-in is installed on your computer, you can send a Web service operation command to the service and use an XML checkpoint to verify that the service returns the XML in the expected structure and with the expected values.

XML files are often an intermediary that retrieves dynamically changing data from one system. The data is then accessed by another system using Document Type Definitions (DTD), enabling the accessing system to read and display the information in the file. You can use an XML checkpoint and parameterize the captured data values if you want to check an XML document or file whose data changes in a predictable way.

XML documents and files often need a well-defined structure to be portable across platforms and development systems. One way to accomplish this is by developing an XML schema, which describes the structure of the XML elements and data types. You can use schema validation to check that each item of content in an XML file adheres to the schema description of the element in which the content is to be placed.

44. How do we analyze our application to determine our testing needs using QTP?
1) Determine the development environments that QTP 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.

45. How do we compare actual cell values with the expected cell values in Tables in QTP?.
The Settings tab includes options that determine how the actual cell values are compared with the expected cell values. For example, you can instruct QTP to treat the value as a number so that 45 or 45.00 are treated as the same value, or you can instruct QTP to ignore spaces when comparing the values. The settings in this tab apply to all selected cells.

(click on he above image to see the clear view)

The default setting is to treat cell values as strings and to check for the exact text, while ignoring spaces.
The Settings tab includes the following options:
Verification type
Exact match
Ignore space
Match case
Min / Max

46. How does QTP handle session IDs?
The server, not the browser, handles session IDs, usually by a cookie or by embedding the session ID in all links. This does not affect QTP.

47. How do we store output values in Environment Variable?
When you define an output value, you can specify where and how each value is stored during the run session.
You can output a value to:
- a test or action parameter
- the run-time Data Table
- an environment variable
When you output a value to an internal user-defined environment variable, you can use the environment variable input parameter at a later stage in the run session.

Note: You can output values only to internal user-defined environment variables and not to external or built-in environment variables, which are read-only.
For example, suppose you are testing an application that prompts the user to input an account number on a Welcome page and then displays the user's name. You can use a text output value to capture the value of the displayed name and store it in an environment variable.

You can then retrieve the value in the environment variable to enter the user's name in other places in the application. For example, in an Order Check-book Web page, which for security reasons requires users to enter the name to appear on the checks, you could use the value to insert the user's name into the Name edit box.

48. How do we store output values in Run-time Data Table?
The option to output a value to the run-time Data Table is especially useful with a data-driven test (or action) that runs several times. In each repetition, or iteration, QTP retrieves the current value and stores it in the appropriate row in the run-time Data Table.
For example, suppose you are testing a flight reservation application and you design a test to create a new reservation and then view the reservation details. Every time you run the test, the application generates a unique order number for the new reservation. To view the reservation, the application requires the user to input the same order number. You do not know the order number before you run the test.

To solve this problem, you output a value to the Data Table for the unique order number generated when creating a new reservation. Then, in the View Reservation screen, you use the column containing the stored value to insert the output value into the order number input field.

When you run the test, QTP retrieves the unique order number generated by the site for the new reservation and enters this output value in the run-time Data Table. When the test reaches the order number input field required to view the reservation, QTP inserts the unique order number stored in the run-time Data Table into the order number field.

49. How do we store output values in Test and Action Parameters?
You can output a value to an action parameter, so that values from one part of a run session can be used later in the run session, or be passed back to the application that ran (called) the test.
For example, suppose you are testing a shopping application that calculates your purchases and automatically debits your account with the amount that you purchased. You want to test that the application correctly debits the purchase amount from the account each time that the action is run with a different list of items to purchase. You could output the total amount spent to an action parameter value, and then use that value later in your run session in the action that debits the account.

50. How do we use Random Number Parameters for Non-Numeric Values?
- Random number parameters are not appropriate for non-numeric values, such as text or hypertext links.
- If you select an existing parameter, then changing the settings in the dialog box affects all instances of that parameter in the test.
- You can also define random number variables using parameterization objects and methods in the Expert View.

51. How do we use Regular Expressions in Checkpoints?
When creating a standard checkpoint to verify the property values of an object, you can set the expected value of an object's property as a regular expression so that an object with a varying value can be verified.
For example, suppose you want to check that every window and dialog box in your application contains the name of your application followed by a hyphen (-) and a descriptive title. You can add a checkpoint to each dialog box object in your test to check that the first part of the title contains the name of your application followed by a hyphen.

When creating a text checkpoint to check that a varying text string is displayed on your Web site or application, you can define the text string as a regular expression.
For example, when booking a flight in the Mercury Tours sample Web site, the total cost charged to a credit card number should not be less than $300. You define the amount as a regular expression, so that QTP will ignore variations in the text string as long as the value is not less than $300.
You can apply the same principles to any checkpoint type whose dialog box contains a Configure Value area.

For example, for table checkpoints you can set cell values as regular expressions, and for XML checkpoints you can set attribute or element values as regular expressions. For more information on specific checkpoint types, see the relevant section for the checkpoint type.

52. How does QTP handle server redirections?
When the server redirects the client, the client generally does not notice the redirection, and misdirections generally do not occur. In most cases, the client is redirected to another script on the server. This additional script produces the HTML code for the subsequent page to be viewed. This has no effect on QTP or the browser.

53. How do we use User-Defined External Environment Variables in QTP?
You can create a list of variable-value pairs in an external file in .xml format. You can then select the file as the active external environment variable file for a test and use the variables from the file as parameters.
You can set up your environment variable files manually, or you can define the variables in the Environment tab of the Test Settings dialog box and use the Export button to create the file with the correct structure.
- You can also store environment variable files in Quality Center.
- You can create several external variable files with the same variable names and different values and then run the test several times, using a different file each time. This is especially useful for localization testing.
If you create your files manually, you must use the correct format, as defined below. You can use the QTP environment variable file schema in:

54. How many types of Actions are there in QTP?
When you create a test, it includes one action. All the steps you record and all the modifications you make while editing your test are part of a single action.
You can divide your test into multiple actions by creating new actions and inserting calls to them, or by inserting calls to existing actions.
There are three kinds of actions:
non-reusable action. an action that can be called only in the test with which it is stored, and can be called only once.

reusable action. an action that can be called multiple times by the test with which it is stored (the local test), as well as by other tests.

external action. a reusable action stored with another test. External actions are read-only in the calling test, but you can choose to use a local, editable copy of the Data Table information for the external action.

55. How many types of Checkpoints are available in QTP?
You can insert the following checkpoint types to check various objects in a Web site or application.
Standard Checkpoint checks the property value of an object in your application or Web page. The standard checkpoint checks a variety of objects such as buttons, radio buttons, combo boxes, lists, and so forth. For example, you can check that a radio button is activated after it is selected or you can check the value of an edit box.

Standard checkpoints are supported for all add-in environments (see Supported Checkpoints).
Image Checkpoint checks the value of an image in your application or Web page. For example, you can check that a selected image's source file is correct.
Note: You create an image checkpoint by inserting a standard checkpoint on an image object.
Image checkpoints are supported for the Web add-in environment (see Supported Checkpoints).
Bitmap Checkpoint checks an area of your Web page or application as a bitmap. For example, suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. You can record the new map that is displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, you can check that the map zooms in correctly.

Bitmap checkpoints are supported for all add-in
Table Checkpoint checks information within a table. For example, suppose your application or Web site contains a table listing all available flights from New York to San Francisco. You can add a table checkpoint to check that the time of the first flight in the table is correct.

Note: You create a table checkpoint by inserting a standard checkpoint on a table object.
Text Checkpoint checks that a text string is displayed in the appropriate place on a Web page or application. For example, suppose a Web page displays the sentence Flight departing from New York to San Francisco. You can create a text checkpoint that checks that the words "New York" are displayed between "Flight departing from" and "to San Francisco".

Text checkpoints are supported for most add-in
Text Area Checkpoint checks that a text string is displayed within a defined area in a Windows application, according to specified criteria. For example, suppose your Visual Basic application has a button that says View Doc , where is replaced by the four digit code entered in a form elsewhere in the application. You can create a text area checkpoint to confirm that the number displayed on the button is the same as the number entered in the form.

Text area checkpoints are supported for Standard Windows, Visual Basic, and ActiveX add-in environments.

Text area checkpoints are also supported for some external add-in environments, such as Java.

Accessibility Checkpoint identifies areas of your Web site that may not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines. For example, guideline 1.1 of the W3C Web Content Accessibility Guidelines requires you to provide a text equivalent for every non-text element. You can add an Alt property check to check whether objects that require the Alt property under this guideline, do in fact have this tag.

Accessibility checkpoints are supported for the Web add-in.
Page Checkpoint checks the characteristics of a Web page. For example, you can check how long a Web page takes to load or whether a Web page contains broken links.

Note: You create a page checkpoint by inserting a standard checkpoint on a page object.

Page checkpoints are supported for the Web add-in environment.
Database Checkpoint checks the contents of a database accessed by your application. For example, you can use a database checkpoint to check the contents of a database containing flight information for your Web site.

Database checkpoints are supported for all add-in environments.

XML Checkpoint checks the data content of XML documents in XML files or XML documents in Web pages and frames.

The XML Checkpoint (Web Page/Frame) option is supported for the Web add-in environment. The XML Checkpoint option is supported for all add-in environments

56. How many types of element checks are available in XML Checkpoints in QTP?
The following element checks are available:
Check number of attributes: Checks the number of attributes that are attached to the element.
Check number of child element occurrences in block: Displays the number of child elements associated with the selected parent element. If you select this option, QTP verifies that the number of child elements in your XML tree (with the specified name, if applicable) corresponds to the number that appears in the Check number of child element occurrences in block field.

You can specify the child element name for the Number of child element occurrences check. If you select a child element name, QTP verifies that the number of child elements with that name corresponds to the number that you specify in the Number of child element occurrences in block field.

Select Any Child (default) to check the total number of child elements associated with the selected parent element.

57. How many types of main views of a script are available in QTP?
Two views of Scripts are available in QTP:
Keyword View in QTP
The Keyword View enables you to create and view the steps of your test in a keyword-driven, modular, table format. The Keyword View is comprised of a table-like view, in which each step is a separate row in the table, and each column represents different parts of the steps. You can modify the columns displayed to suit your requirements.

You create and modify tests by selecting items and operations in the Keyword View and entering information as required. Each step is automatically documented as you complete it, enabling you to view a description of your test steps in understandable English.

Each operation performed on your application or Web site during a recording session is recorded as a row in the Keyword View.

For each row in the Keyword View, QTP displays a corresponding line of script in the Expert View. If you focus on a specific step in the Keyword View and switch to the Expert View, the cursor is located in that corresponding line of the test.

Note: The Keyword View replaces the Tree View found in earlier versions of QTP. Many of the operations you could perform from the Tree View can be performed in a similar manner from the Keyword View. For example, right-click on a step to access context-sensitive options for that step, such as checkpoint, output value and action-related operations.

Expert View in QTP
In the Expert View, QTP displays each operation performed on your application in the form of a script, comprised of VBScript statements. The Expert View is a script editor with many script editing capabilities. For each object and method in an Expert View statement, a corresponding row exists in the Keyword View. For more information on using the Expert View

58. How does QTP handle meta tags?
Meta tags do not affect how the page is displayed. Generally, they contain information only about who created the page, how often it is updated, what the page is about, and which keywords represent the page's content. Therefore, QTP has no problem handling meta tags.

59. How many types of Parameters are there in QTP?
There are four types of parameters in QTP:
Test/action parameters. Test parameters enable you to use values passed from your test. Action parameters enable you to pass values from other actions in your test.

To use a value within a specific action, you must pass the value down through the action hierarchy of your test to the required action. You can then use that parameter value to parameterize a step in your test. For example, suppose that you want to parameterize a step in Action3 using a value that is passed into your test from the external application that runs (calls) your test. You can pass the value from the test level to Action1 (a top-level action) to Action3 (a nested action of Action1), and then parameterize the required step using this action input parameter value (that was passed through from the external application).

Alternatively, you can pass an output action parameter value from an action step to a later sibling action at the same hierarchical level. For example, suppose that Action2, Action3, and Action4 are sibling actions at the same hierarchical level, and that these are all nested actions of Action1. You can parameterize a call to Action4 based on an output value retrieved from Action2 or Action3. You can then use these parameters in your action step.

Data Table parameters. Enable you to create a data-driven test (or action) that runs several times using the data you supply. In each repetition, or iteration, QTP uses a different value from the Data Table.

For example, suppose your application or Web site includes a feature that enables users to search for contact information from a membership database. When the user enters a member's name, the member's contact information is displayed, together with a button labelled View 's Picture, where is the name of the member. You can parameterize the name property of the button using a list of values so that during each iteration of the run session, QTP can identify the different picture buttons.

Environment variable parameters. Enable you to use variable values from other sources during the run session. These may be values you supply, or values that QTP generates for you based on conditions and options you choose.

For example, you can have QTP read all the values for filling in a Web form from an external file, or you can use one of QTP's built-in environment variables to insert current information about the computer running the test.

Random number parameters. Enable you to insert random numbers as values in your test. For example, to check how your application handles small and large ticket orders, you can have QTP generate a random number and insert it in a number of tickets edit box.

60. How QTP identifies various Objects?
QTP recognizes all objects in the Application under test using the set of mandatory properties that it stores for all Test Objects while recording. If QTP is not able to recognize the objects using the set of mandatory properties it uses another set of properties called the assistive properties. In case the assistive properties are also not enough to uniquely identify an object QTP resorts to using the ordinal identifiers for the object that are properties like the index, location and time of creation of the object. If all this fails QTP resorts to the smart identification mechanism.

Understanding How QTP Identifies Objects During the Run Session
QTP also uses a very human-like technique for identifying objects during the run session.
Suppose as a continuation to the experiment, Alex is now asked to identify the same "item" he initially identified but in a new, yet similar environment.

The first photograph he is shown is the original photograph. He searches for the same Caucasian girl, about eight years old, with long, brown hair that he was asked to remember and immediately picks her out. In the second photograph, the children are playing on the playground equipment, but Alex is still able to easily identify the girl using the same criteria.

Similarly, during a run session, QTP searches for a run-time object that exactly matches the description of the test object it learned while recording. It expects to find a perfect match for both the mandatory and any assistive properties it used to create a unique description while recording. As long as the object in the application does not change significantly, the description learned during recording is almost always sufficient for QTP to uniquely identify the object. This is true for most objects, but your application could include objects that are more difficult to identify during subsequent run sessions.