1. How QTP retrieves Text while checking the text during the test?
You can check that a specified text string is displayed by adding one of the following checkpoints to your test.
* Standard Checkpoint. Enables you to check the text property of an object. You can use standard checkpoints to check text in Windows-based and other types of applications (including Web-based applications).
* Text Area Checkpoint. Enables you to check that a text string appears within a defined area in a Windows application, according to specified criteria. It is supported for Standard Windows, Visual Basic, and ActiveX environments. Text area checkpoints are also supported for various external QTP Professional add-ins. Refer to your add-in documentation for details.
* Text Checkpoint. Enables you to check that the text is displayed in a screen, window, or Web page, according to specified criteria. Text checkpoints are supported for many add-in environments (as listed in Supported Checkpoints). Text checkpoints are also supported for various external QTP Professional add-ins. Refer to your add-in documentation for details.
When checking text, QTP tries to retrieve the text directly from the test object. If QTP cannot retrieve the text (for example, because the text is part of a picture), it tries to retrieve the text using an OCR (optical character recognition) mechanism.
You can check that a specified text string is displayed by adding one of the following checkpoints to your test.
* Standard Checkpoint. Enables you to check the text property of an object. You can use standard checkpoints to check text in Windows-based and other types of applications (including Web-based applications).
* Text Area Checkpoint. Enables you to check that a text string appears within a defined area in a Windows application, according to specified criteria. It is supported for Standard Windows, Visual Basic, and ActiveX environments. Text area checkpoints are also supported for various external QTP Professional add-ins. Refer to your add-in documentation for details.
* Text Checkpoint. Enables you to check that the text is displayed in a screen, window, or Web page, according to specified criteria. Text checkpoints are supported for many add-in environments (as listed in Supported Checkpoints). Text checkpoints are also supported for various external QTP Professional add-ins. Refer to your add-in documentation for details.
When checking text, QTP tries to retrieve the text directly from the test object. If QTP cannot retrieve the text (for example, because the text is part of a picture), it tries to retrieve the text using an OCR (optical character recognition) mechanism.
2. How results are generated in QTP?
When a run session ends, you can view the run session results in the Test Results window. By default, the Test Results window opens automatically at the end of a run. If you want to change this behavior, clear the View results when run session ends check box in the Run tab of the Options dialog box.
The Test Results window contains a description of the steps performed during the run session. For a test that does not contain Data Table parameters, the Test Results window shows a single test iteration.
If the test contains Data Table parameters, and the test settings are configured to run multiple iterations, the Test Results window displays details for each iteration of the test run. The results are grouped by the actions in the test.
Note: You set the test to run for one or all iterations in the Run tab of the Test Settings dialog box.
After you run a test, the Test Results window displays all aspects of the run session, including:
* a high-level results overview report (pass/fail status)
* the data used in all runs
* an expandable tree of the steps, specifying exactly where application failures occurred
* the exact locations in the test where failures occurred
* a still image of the state of your application at a particular step
* a movie clip of the state of your application at a particular step or of the entire test
* detailed explanations of each step and checkpoint pass or failure, at each stage of the test
Note: The Test Results window can show results with up to 300 levels in the tree hierarchy. If you have results with more than 300 nested levels, you can view the entire report by manually opening the results.xml file.
When a run session ends, you can view the run session results in the Test Results window. By default, the Test Results window opens automatically at the end of a run. If you want to change this behavior, clear the View results when run session ends check box in the Run tab of the Options dialog box.
The Test Results window contains a description of the steps performed during the run session. For a test that does not contain Data Table parameters, the Test Results window shows a single test iteration.
If the test contains Data Table parameters, and the test settings are configured to run multiple iterations, the Test Results window displays details for each iteration of the test run. The results are grouped by the actions in the test.
Note: You set the test to run for one or all iterations in the Run tab of the Test Settings dialog box.
After you run a test, the Test Results window displays all aspects of the run session, including:
* a high-level results overview report (pass/fail status)
* the data used in all runs
* an expandable tree of the steps, specifying exactly where application failures occurred
* the exact locations in the test where failures occurred
* a still image of the state of your application at a particular step
* a movie clip of the state of your application at a particular step or of the entire test
* detailed explanations of each step and checkpoint pass or failure, at each stage of the test
Note: The Test Results window can show results with up to 300 levels in the tree hierarchy. If you have results with more than 300 nested levels, you can view the entire report by manually opening the results.xml file.
3. How the output values are stored during the run sessions in QTP?
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
Note: Output values are stored only for the duration of the test, and are not saved with the test. If you select to output a value to an existing parameter, Data Table column, or environment variable, the existing value is overwritten when the output value step runs. When the run session ends, the original value is restored.
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
Note: Output values are stored only for the duration of the test, and are not saved with the test. If you select to output a value to an existing parameter, Data Table column, or environment variable, the existing value is overwritten when the output value step runs. When the run session ends, the original value is restored.
4. How to use Environment Variable Files with Quality Center?
When working with Quality Center and environment variable files, you must save the environment variable file as an attachment in your Quality Center project before you specify the file in the Environment tab of the Test Settings dialog box.
You can add a new or an existing environment variable file to your Quality Center project. Note that adding an existing file from the file system to a Quality Center project creates a copy of the file in Quality Center. Thus, once you save the file to the project, changes made to the Quality Center environment variable file will not affect the file system file and vice versa.
http://futurethoughtsllc.com/QTPInterviewQuestionsAnswers.aspx
When working with Quality Center and environment variable files, you must save the environment variable file as an attachment in your Quality Center project before you specify the file in the Environment tab of the Test Settings dialog box.
You can add a new or an existing environment variable file to your Quality Center project. Note that adding an existing file from the file system to a Quality Center project creates a copy of the file in Quality Center. Thus, once you save the file to the project, changes made to the Quality Center environment variable file will not affect the file system file and vice versa.
http://futurethoughtsllc.com/QTPInterviewQuestionsAnswers.aspx
To use an environment variable file with Quality Center:
1. To add a new environment variable file, create a new .xml file in your file system.
2. In Quality Center, add the file to the project as an attachment. For more information, refer to your Quality Center documentation.
3. In QTP, connect to the Quality Center project.
4. In the Test Settings dialog box, click the Environment tab.
5. Select User-defined from the Variables type list.
6. Select Load variables and values from external file (reload each run session).
7. In the File box, click the browse button to find the user-defined variable file in the Quality Center project.
8. Save your test. QTP saves the file to the Quality Center project.
5. Does QTP work with COM?
QTP complies with the COM standard.
QTP supports COM objects embedded in Web pages (which are currently accessible only using Microsoft Internet Explorer) and you can drive COM objects in VBScript.
QTP complies with the COM standard.
QTP supports COM objects embedded in Web pages (which are currently accessible only using Microsoft Internet Explorer) and you can drive COM objects in VBScript.
6. Is there any built-in function for Scripting in QTP?
QTP uses an in-built functionality called "Step Generator" to create scripts while appropriate steps are entered into it.
The Step Generator enables you to add steps by selecting from a range of context-sensitive options and entering the required values. In the Step Generator dialog box you can define steps that use:
* test object methods and properties (tests only)
* Utility object methods and properties
* calls to library functions (tests only), VBScript functions, and internal script functions
For example, you can add a step that checks that an object exists, or that stores the returned value of a method as an output value or as part of a conditional statement. You can parameterize any of the values in your step.
Note: You can use the Step Generator to insert steps in tests and function libraries. However, in function libraries, you cannot use the Step Generator to access test object names or collections, or to access the list of library functions.
Before you open the Step Generator to define a new step, you first select where in your test the new step should be inserted.
After you open the Step Generator, you first select the category for the step operation (test object, Utility object or function) and the required object or the function library source (for example, built-in or local script functions). You can then select the appropriate method or function and define the arguments and return values, parameterizing them if required.
The Step Generator then inserts a step with the correct syntax into your test. You can continue to add further steps at the same location without closing the Step Generator.
You can open the Step Generator from the Keyword View or Expert View while recording or editing your test. You can also open the Step Generator from the Active Screen while editing.
http://futurethoughtsllc.com/QTPInterviewQuestionsAnswers.aspx
QTP uses an in-built functionality called "Step Generator" to create scripts while appropriate steps are entered into it.
The Step Generator enables you to add steps by selecting from a range of context-sensitive options and entering the required values. In the Step Generator dialog box you can define steps that use:
* test object methods and properties (tests only)
* Utility object methods and properties
* calls to library functions (tests only), VBScript functions, and internal script functions
For example, you can add a step that checks that an object exists, or that stores the returned value of a method as an output value or as part of a conditional statement. You can parameterize any of the values in your step.
Note: You can use the Step Generator to insert steps in tests and function libraries. However, in function libraries, you cannot use the Step Generator to access test object names or collections, or to access the list of library functions.
Before you open the Step Generator to define a new step, you first select where in your test the new step should be inserted.
After you open the Step Generator, you first select the category for the step operation (test object, Utility object or function) and the required object or the function library source (for example, built-in or local script functions). You can then select the appropriate method or function and define the arguments and return values, parameterizing them if required.
The Step Generator then inserts a step with the correct syntax into your test. You can continue to add further steps at the same location without closing the Step Generator.
You can open the Step Generator from the Keyword View or Expert View while recording or editing your test. You can also open the Step Generator from the Active Screen while editing.
http://futurethoughtsllc.com/QTPInterviewQuestionsAnswers.aspx
7. Please explain some real world scenario explaining Object Learning process of QTP?
QTP learns objects just as you would. For example, suppose as part of an experiment, Alex is told that he will be shown a photograph of a picnic scene for a few seconds during which someone will point out one item in the picture. Alex is told that he will be expected to identify that item again in identical or similar pictures one week from today.
Before he is shown the photograph, Alex begins preparing himself for the test by thinking about which characteristics he wants to learn about the item that the tester indicates. Obviously, he will automatically note whether it is a person, inanimate object, animal, or plant. Then, if it is a person, he will try to commit to memory the gender, skin color, and age. If it is an animal, he will try to remember the type of animal, its color, and so forth.
The tester shows the scene to Alex and points out one of three children sitting on a picnic blanket. Alex notes that it is a Caucasian girl about 8 years old. In looking at the rest of the picture, however, he realizes that one of the other children in the picture could also fit that description. In addition to learning his planned list of characteristics, he also notes that the girl he is supposed to identify has long, brown hair.
Now that only one person in the picture fits the characteristics he learned, he is fairly sure that he will be able to identify the girl again, even if the scene the tester shows him next week is slightly different.
Since he still has a few moments left to look at the picture, he attempts to notice other, more subtle differences between the child he is supposed to remember and the others in the picture—just in case.
If the two similar children in the picture appeared to be identical twins, Alex might also take note of some less permanent feature of the child, such as the child's position on the picnic blanket. That would enable him to identify the child if he were shown another picture in which the children were sitting on the blanket in the same order.
QTP uses a very similar method when it learns objects during the recording process.
First, it "looks" at the object on which you are recording and stores it as a test object, determining in which test object class it fits. Just as Alex immediately checked whether the item was a person, animal, plant, or thing. QTP might classify the test object as a standard Windows dialog box (Dialog), a Web button (WebButton), or a Visual Basic scroll bar object (VbScrollBar), for example.
Then, for each test object class, QTP has a list of mandatory properties that it always learns; similar to the list of characteristics that Alex planned to learn before seeing the picture. When you record on an object, QTP always learns these default property values, and then "looks" at the rest of the objects on the page, dialog box, or other parent object to check whether this description is enough to uniquely identify the object. If it is not, QTP adds assistive properties, one by one, to the description, until it has compiled a unique description; like when Alex added the hair length and color characteristics to his list. If no assistive properties are available, or if those available are not sufficient to create a unique description, QTP adds a special ordinal identifier, such as the object's location on the page or in the source code, to create a unique description, just as Alex would have remembered the child's position on the picnic blanket if two of the children in the picture had been identical twins.
QTP learns objects just as you would. For example, suppose as part of an experiment, Alex is told that he will be shown a photograph of a picnic scene for a few seconds during which someone will point out one item in the picture. Alex is told that he will be expected to identify that item again in identical or similar pictures one week from today.
Before he is shown the photograph, Alex begins preparing himself for the test by thinking about which characteristics he wants to learn about the item that the tester indicates. Obviously, he will automatically note whether it is a person, inanimate object, animal, or plant. Then, if it is a person, he will try to commit to memory the gender, skin color, and age. If it is an animal, he will try to remember the type of animal, its color, and so forth.
The tester shows the scene to Alex and points out one of three children sitting on a picnic blanket. Alex notes that it is a Caucasian girl about 8 years old. In looking at the rest of the picture, however, he realizes that one of the other children in the picture could also fit that description. In addition to learning his planned list of characteristics, he also notes that the girl he is supposed to identify has long, brown hair.
Now that only one person in the picture fits the characteristics he learned, he is fairly sure that he will be able to identify the girl again, even if the scene the tester shows him next week is slightly different.
Since he still has a few moments left to look at the picture, he attempts to notice other, more subtle differences between the child he is supposed to remember and the others in the picture—just in case.
If the two similar children in the picture appeared to be identical twins, Alex might also take note of some less permanent feature of the child, such as the child's position on the picnic blanket. That would enable him to identify the child if he were shown another picture in which the children were sitting on the blanket in the same order.
QTP uses a very similar method when it learns objects during the recording process.
First, it "looks" at the object on which you are recording and stores it as a test object, determining in which test object class it fits. Just as Alex immediately checked whether the item was a person, animal, plant, or thing. QTP might classify the test object as a standard Windows dialog box (Dialog), a Web button (WebButton), or a Visual Basic scroll bar object (VbScrollBar), for example.
Then, for each test object class, QTP has a list of mandatory properties that it always learns; similar to the list of characteristics that Alex planned to learn before seeing the picture. When you record on an object, QTP always learns these default property values, and then "looks" at the rest of the objects on the page, dialog box, or other parent object to check whether this description is enough to uniquely identify the object. If it is not, QTP adds assistive properties, one by one, to the description, until it has compiled a unique description; like when Alex added the hair length and color characteristics to his list. If no assistive properties are available, or if those available are not sufficient to create a unique description, QTP adds a special ordinal identifier, such as the object's location on the page or in the source code, to create a unique description, just as Alex would have remembered the child's position on the picnic blanket if two of the children in the picture had been identical twins.
8. Splitting Actions option is not available under what circumstances in QTP?
You can split an action that is stored with your test into two sibling actions or into parent-child nested actions. When you split an action, the second action starts with the step that is selected when you perform the split action operation.
You cannot split an action and the option is disabled when:
* an external action is selected
* the first step of an action is selected
* recording a test
* running a test
* you are working with a read-only test
You can split an action that is stored with your test into two sibling actions or into parent-child nested actions. When you split an action, the second action starts with the step that is selected when you perform the split action operation.
You cannot split an action and the option is disabled when:
* an external action is selected
* the first step of an action is selected
* recording a test
* running a test
* you are working with a read-only test
9. What are Absolute and Relative Paths in QTP?
absolute path: It means Direct path,
relative Path: It means indirect path
You 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.
so u can do it in two ways :
1.absolute path : C:\more\mna\users\bsp\hello.txt
so absolute path means full path of file or directory starting with "/" root of directory structure
2.relative path : users\bsp\hello.txt
absolute path: It means Direct path,
relative Path: It means indirect path
You 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.
so u can do it in two ways :
1.absolute path : C:\more\mna\users\bsp\hello.txt
so absolute path means full path of file or directory starting with "/" root of directory structure
2.relative path : users\bsp\hello.txt
10. Does QTP work with XML?
XML is eXtensible Markup Language, a pared-down version of SGML for Web documents, that enables Web designers to create their own customized tags. QTP supports XML and recognizes XML tags as objects. QTP also supports XML output and schema validation.
By adding XML checkpoints in QTP to your test scripts, you can check the contents of individual XML data files or documents that are part of your Web application.
XML is eXtensible Markup Language, a pared-down version of SGML for Web documents, that enables Web designers to create their own customized tags. QTP supports XML and recognizes XML tags as objects. QTP also supports XML output and schema validation.
By adding XML checkpoints in QTP to your test scripts, you can check the contents of individual XML data files or documents that are part of your Web application.
11. What are Conditional and Loop Statements used in the Keyword View in QTP?
Using conditional statements, you can incorporate decision making into your tests. Using loop statements, you can run a group of steps repeatedly, either while or until a condition is true. You can also use loop statements to repeat a group of steps a specific number of times. Each statement type is indicated by one of the following icons in the Keyword View:
After you insert a conditional or loop statement in the Keyword View, you can insert or record steps after the statement to include them in the conditional or loop block.
Using conditional statements, you can incorporate decision making into your tests. Using loop statements, you can run a group of steps repeatedly, either while or until a condition is true. You can also use loop statements to repeat a group of steps a specific number of times. Each statement type is indicated by one of the following icons in the Keyword View:
After you insert a conditional or loop statement in the Keyword View, you can insert or record steps after the statement to include them in the conditional or loop block.
12. What are Data Tables in QTP?
The data your test uses is stored in the design-time Data Table, which is displayed in the Data Table pane at the bottom of the screen while you insert and edit steps.
The Data Table has the characteristics of a Microsoft Excel spreadsheet, meaning that you can store and use data in its cells and you can also perform mathematical formulas within the cells. You can use the DataTable, DTSheet and DTParameter utility objects to manipulate the data in any cell in the Data Table.
Note: The use of complex and/or nested formulas in the Data Table is not supported.
You can insert Data Table parameters and output values into your test. Using Data Table parameters and/or output values in a test enables 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.
During the run session, QTP creates a run-time Data Table—a live version of the Data Table associated with your test. During the run session, QTP displays the run-time data in the Data Table pane so that you can see any changes to the Data Table as they occur.
When the run session ends, the run-time Data Table closes, and the Data Table pane again displays the stored design-time Data Table. Data entered in the run-time Data Table during the run session is not saved with the test. The final data from the run-time Data Table is displayed in the Run-Time Data Table in the Test Results window.
Tip: If it is important for you to save the resulting data from the run-time Data Table, you can insert a DataTable.Export statement to the end of your test to export the run-time Data Table to a file. You can then import the data to the design-time Data Table using the Data Table File > Import From File menu. Alternatively you can add a DataTable.Import statement to the beginning of your test to import the run-time Data Table that was exported at the end of the previous run session.
The data your test uses is stored in the design-time Data Table, which is displayed in the Data Table pane at the bottom of the screen while you insert and edit steps.
The Data Table has the characteristics of a Microsoft Excel spreadsheet, meaning that you can store and use data in its cells and you can also perform mathematical formulas within the cells. You can use the DataTable, DTSheet and DTParameter utility objects to manipulate the data in any cell in the Data Table.
Note: The use of complex and/or nested formulas in the Data Table is not supported.
You can insert Data Table parameters and output values into your test. Using Data Table parameters and/or output values in a test enables 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.
During the run session, QTP creates a run-time Data Table—a live version of the Data Table associated with your test. During the run session, QTP displays the run-time data in the Data Table pane so that you can see any changes to the Data Table as they occur.
When the run session ends, the run-time Data Table closes, and the Data Table pane again displays the stored design-time Data Table. Data entered in the run-time Data Table during the run session is not saved with the test. The final data from the run-time Data Table is displayed in the Run-Time Data Table in the Test Results window.
Tip: If it is important for you to save the resulting data from the run-time Data Table, you can insert a DataTable.Export statement to the end of your test to export the run-time Data Table to a file. You can then import the data to the design-time Data Table using the Data Table File > Import From File menu. Alternatively you can add a DataTable.Import statement to the beginning of your test to import the run-time Data Table that was exported at the end of the previous run session.
13. What are Nesting Actions in QTP & what is the use of them?
Sometimes you may want to call an action from within an action. This is called nesting. By nesting actions, you can:
* Maintain the modularity of your test.
* Run one or more actions based on the results of a conditional statement.
For example, suppose you have parameterized a step where a user selects one of three membership types as part of a registration process. When the user selects a membership type, the page that opens depends on the membership type selected in the previous page. You can create one action for each type of membership. Then you can use If statements to determine which membership type was selected in a particular iteration of the test and run the appropriate action for that selection.
Sometimes you may want to call an action from within an action. This is called nesting. By nesting actions, you can:
* Maintain the modularity of your test.
* Run one or more actions based on the results of a conditional statement.
For example, suppose you have parameterized a step where a user selects one of three membership types as part of a registration process. When the user selects a membership type, the page that opens depends on the membership type selected in the previous page. You can create one action for each type of membership. Then you can use If statements to determine which membership type was selected in a particular iteration of the test and run the appropriate action for that selection.
14. What are Object Repositories in QTP?
When QTP runs a test, it simulates a human user by moving the pointer over the application, clicking objects, and entering keyboard input. Like a human user, QTP must learn the interface of an application to be able to work with it. QTP does this by learning the application's objects and their corresponding property values and storing these object descriptions in an object repository.
As QTP learns the test objects, it stores them in the action's local object repository. You can choose to keep the stored objects in the local object repository, or you can choose to store the objects in a shared object repository. Storing the objects in the local object repository makes them available only to the specific action, but not to other actions. Storing the objects in one or more shared object repositories enables multiple tests to use them. You can also work with a combination of local and shared object repositories, as needed. For more information on local and shared object repositories
When QTP runs a test, it simulates a human user by moving the pointer over the application, clicking objects, and entering keyboard input. Like a human user, QTP must learn the interface of an application to be able to work with it. QTP does this by learning the application's objects and their corresponding property values and storing these object descriptions in an object repository.
As QTP learns the test objects, it stores them in the action's local object repository. You can choose to keep the stored objects in the local object repository, or you can choose to store the objects in a shared object repository. Storing the objects in the local object repository makes them available only to the specific action, but not to other actions. Storing the objects in one or more shared object repositories enables multiple tests to use them. You can also work with a combination of local and shared object repositories, as needed. For more information on local and shared object repositories
15. What are Optional Steps in QTP?
An optional step is a step that is not necessarily required to successfully complete a run session. For example, suppose that when recording a test, the application you are testing prompts you to enter a user name and password in a login window. When you run the test, however, the application does not prompt you to enter your user name and password because it retained the information that was previously entered. In this case, the steps that were recorded for entering the login information are not required and should, therefore, be marked optional.
During a run session, if the object of an optional step does not exist, QTP bypasses this step and continues to run the test. When the run session ends, a message is displayed for the step indicating that the step was not performed, but the step does not cause the run to fail.
However, if, during a run session, QTP cannot find the object from the optional step in the object repository (for example, if the object name was modified in the test but not in the object repository, or if the object was removed from the object repository), an error message is displayed listing the required object, and the run fails.
During a recording, QTP automatically marks steps that open certain dialog boxes as optional. You can also manually designate steps as optional.
An optional step is a step that is not necessarily required to successfully complete a run session. For example, suppose that when recording a test, the application you are testing prompts you to enter a user name and password in a login window. When you run the test, however, the application does not prompt you to enter your user name and password because it retained the information that was previously entered. In this case, the steps that were recorded for entering the login information are not required and should, therefore, be marked optional.
During a run session, if the object of an optional step does not exist, QTP bypasses this step and continues to run the test. When the run session ends, a message is displayed for the step indicating that the step was not performed, but the step does not cause the run to fail.
However, if, during a run session, QTP cannot find the object from the optional step in the object repository (for example, if the object name was modified in the test but not in the object repository, or if the object was removed from the object repository), an error message is displayed listing the required object, and the run fails.
During a recording, QTP automatically marks steps that open certain dialog boxes as optional. You can also manually designate steps as optional.
16. How can I access HTML tags directly in QTP?
QuickTest provides direct access to the browser's Document Object Model (DOM) through which you can access the HTML tags directly. Access to the DOM is performed using the .Object notation.
The test below demonstrates how to iterate over all the tags in a page. The test then outputs the inner-text of the tags (the text contained between the tags) to the Test Results using the Reporter object.
' Use the on error because not all the elements have inner-text.
On Error Resume Next
Set Doc = Browser("CNN Interactive").Page("CNN Interactive").Object
' Loop through all the objects in the page.
For Each Element In Doc.all
TagName = Element.TagName ' Get the tag name.
InnerText = Element.innerText ' Get the inner text.
' Write the information to the test results.
Reporter.ReportEvent 0, TagName, InnerText
Next
QuickTest provides direct access to the browser's Document Object Model (DOM) through which you can access the HTML tags directly. Access to the DOM is performed using the .Object notation.
The test below demonstrates how to iterate over all the tags in a page. The test then outputs the inner-text of the tags (the text contained between the tags) to the Test Results using the Reporter object.
' Use the on error because not all the elements have inner-text.
On Error Resume Next
Set Doc = Browser("CNN Interactive").Page("CNN Interactive").Object
' Loop through all the objects in the page.
For Each Element In Doc.all
TagName = Element.TagName ' Get the tag name.
InnerText = Element.innerText ' Get the inner text.
' Write the information to the test results.
Reporter.ReportEvent 0, TagName, InnerText
Next
17. What are Permissions Required to Run QTP?
You must make sure the following access permissions are set in order to run QuickTest Professional.
Permissions Required to Run QuickTest Professional
You must have the following file system permissions:
* Full read and write permissions for all the files and folders under the folder in which QuickTest is installed
* Full read and write permissions to the Temp folder
* Read permissions to the Windows folder and to the System folder
You must have the following registry key permissions:
* Full read and write permissions to all the keys under HKEY_CURRENT_USER\Software\Mercury Interactive
* Read and Query Value permissions to all the HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT keys
Permissions Required When Working with Quality Center
You must have the following permissions to use QuickTest with Quality Center:
* Full read and write permissions to the Quality Center cache folder
* Full read and write permissions to the QuickTest Add-in for Quality Center installation folder
You must make sure the following access permissions are set in order to run QuickTest Professional.
Permissions Required to Run QuickTest Professional
You must have the following file system permissions:
* Full read and write permissions for all the files and folders under the folder in which QuickTest is installed
* Full read and write permissions to the Temp folder
* Read permissions to the Windows folder and to the System folder
You must have the following registry key permissions:
* Full read and write permissions to all the keys under HKEY_CURRENT_USER\Software\Mercury Interactive
* Read and Query Value permissions to all the HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT keys
Permissions Required When Working with Quality Center
You must have the following permissions to use QuickTest with Quality Center:
* Full read and write permissions to the Quality Center cache folder
* Full read and write permissions to the QuickTest Add-in for Quality Center installation folder
18. What are the advantages of Keyword Driven testing in QTP?
Keyword-driven testing is a technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly.
Advantages:
1. Although this methodology requires more planning and a longer initial time-investment than going directly to the test creation stage and recording your steps, this methodology makes the test creation and test maintenance stages more efficient and keeps the structure of individual tests more readable and easier to modify.
2. By creating your tests with a keyword-driven methodology in mind, your tests become more modular, focusing on the operations to test using both QuickTest built-in keywords and your own user-defined keywords.
3. It is possible to add objects to the object repository before they exist in an application; it is possible to begin preparing your automated keyword-driven tests even before a build containing the new objects is available.
4. By encapsulating much of the complex programming into function libraries, and by making these functions flexible enough to use in many testing scenarios (through the use of function parameters that control the way the functions behave), one or a few automation experts can prepare the keywords that many application testers who are less technical can include in multiple tests. This also makes it possible to update testing functionality without having to update all the tests that use the keywords.
5. Developing and documenting business-level keywords in function libraries. Creating function libraries involves developing customized functions for the application you want to test. You may want to develop functions to test special application functionality that is not already supplied by the methods in the QuickTest object model. It is also useful to wrap existing methods and functions together with additional programming to create application-specific functions for testing operations or sequences that are commonly performed in your application. The functions you create will be available either as extra keywords or as replacements for built-in QuickTest keywords during the test creation stage.
Keyword-driven testing is a technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly.
Advantages:
1. Although this methodology requires more planning and a longer initial time-investment than going directly to the test creation stage and recording your steps, this methodology makes the test creation and test maintenance stages more efficient and keeps the structure of individual tests more readable and easier to modify.
2. By creating your tests with a keyword-driven methodology in mind, your tests become more modular, focusing on the operations to test using both QuickTest built-in keywords and your own user-defined keywords.
3. It is possible to add objects to the object repository before they exist in an application; it is possible to begin preparing your automated keyword-driven tests even before a build containing the new objects is available.
4. By encapsulating much of the complex programming into function libraries, and by making these functions flexible enough to use in many testing scenarios (through the use of function parameters that control the way the functions behave), one or a few automation experts can prepare the keywords that many application testers who are less technical can include in multiple tests. This also makes it possible to update testing functionality without having to update all the tests that use the keywords.
5. Developing and documenting business-level keywords in function libraries. Creating function libraries involves developing customized functions for the application you want to test. You may want to develop functions to test special application functionality that is not already supplied by the methods in the QuickTest object model. It is also useful to wrap existing methods and functions together with additional programming to create application-specific functions for testing operations or sequences that are commonly performed in your application. The functions you create will be available either as extra keywords or as replacements for built-in QuickTest keywords during the test creation stage.
19. What are the contents of the Programming Statements used in QTP tests?
The easiest way to create a test is to begin by recording typical business processes that you perform on your application or Web site. Then, to increase the power and flexibility of your test, you can add steps that contain programming logic to the recorded framework. Programming statements can contain:
* recordable test object methods. These are operations that a user can perform on an application or Web site.
* non-recordable test object methods. These are operations that users cannot perform on an application or Web site. You use these methods to retrieve or set information, or to perform operations triggered by an event.
* run-time methods of the object being tested.
* various VBScript programming commands that affect the way the test runs, such as conditions and loops. These are often used to control the logical flow of a test.
* supplemental statements, such as comments, to make your test easier to read, and messages that appear in the test results, to alert you to a specified condition.
The easiest way to create a test is to begin by recording typical business processes that you perform on your application or Web site. Then, to increase the power and flexibility of your test, you can add steps that contain programming logic to the recorded framework. Programming statements can contain:
* recordable test object methods. These are operations that a user can perform on an application or Web site.
* non-recordable test object methods. These are operations that users cannot perform on an application or Web site. You use these methods to retrieve or set information, or to perform operations triggered by an event.
* run-time methods of the object being tested.
* various VBScript programming commands that affect the way the test runs, such as conditions and loops. These are often used to control the logical flow of a test.
* supplemental statements, such as comments, to make your test easier to read, and messages that appear in the test results, to alert you to a specified condition.
20. What are the Differences between Business Components and Tests in QTP?
In Business process testing the combination of components will become a test (business process test) Components are easily-maintained, reusable units that perform a specific task. They are the building blocks of business process tests. Each component is comprised of several application steps that are logically performed together in a specific order. For example, in a Web application, a login component might be comprised of four steps. Its first step could be to open the application. Its second step could be to enter a user name. Its third step could be to enter a password, and its last step could be to click the Submit button on the Web page. By creating and calling functions stored in
function libraries, you can enhance the component with additional logic to
test important details of the login task. By design, each component tests a specific part of an application. When combined, components are incorporated into a business process test in a serial flow representing the main tasks performed within a particular business process. The task of creating and running components and business process tests is generally performed by Subject Matter Experts working in Quality Center.
If you are already familiar with using QuickTest to create action-based tests, you will find that the procedures for creating and editing components are quite similar. However, due to the design and purpose of the component model, there are certain differences in the way you create, edit, and run components. The guidelines below provide an overview of these differences.
* A component is a single entity. It cannot contain multiple actions or have calls to other actions or to other components.
* When working with components, all external files are stored in the Quality Center project to which you are currently connected.
* The name of the component node in the Keyword View is the same as the saved component. You cannot rename the node.
* Business components are created in the Keyword View, not the Expert View.
* You add resources via the component's application area, and not directly to the component.
* Components use custom keywords created in function libraries to perform operations, such as verifying property values and opening the application you are testing.
In Business process testing the combination of components will become a test (business process test) Components are easily-maintained, reusable units that perform a specific task. They are the building blocks of business process tests. Each component is comprised of several application steps that are logically performed together in a specific order. For example, in a Web application, a login component might be comprised of four steps. Its first step could be to open the application. Its second step could be to enter a user name. Its third step could be to enter a password, and its last step could be to click the Submit button on the Web page. By creating and calling functions stored in
function libraries, you can enhance the component with additional logic to
test important details of the login task. By design, each component tests a specific part of an application. When combined, components are incorporated into a business process test in a serial flow representing the main tasks performed within a particular business process. The task of creating and running components and business process tests is generally performed by Subject Matter Experts working in Quality Center.
If you are already familiar with using QuickTest to create action-based tests, you will find that the procedures for creating and editing components are quite similar. However, due to the design and purpose of the component model, there are certain differences in the way you create, edit, and run components. The guidelines below provide an overview of these differences.
* A component is a single entity. It cannot contain multiple actions or have calls to other actions or to other components.
* When working with components, all external files are stored in the Quality Center project to which you are currently connected.
* The name of the component node in the Keyword View is the same as the saved component. You cannot rename the node.
* Business components are created in the Keyword View, not the Expert View.
* You add resources via the component's application area, and not directly to the component.
* Components use custom keywords created in function libraries to perform operations, such as verifying property values and opening the application you are testing.
21. What are the Elements of Recovery Scenario in QTP?
The Recovery Scenario Wizard leads you, step-by-step, through the process of creating a recovery scenario. The Recovery Scenario Wizard contains the following main steps Elements of Recovery Scenario in QTP:
* Defining the trigger event that interrupts the run session - Trigger Event: Is an unexpected event like appearance of a Pop-up window, object state, test run error causing application crash or interruption in our running session.
* Specifying the recovery operations required to continue - Recovery Steps: Constitutes a series of steps required to be performed to enable QTP to proceed further with the process of test after some trigger event has interrupted the run session. Examples of a recovery operation can be 1) A keyboard or mouse Operation like a Click over the “OK” button in the Pop-up window 2) Close Application Process 3) Function Call 4) Restarting the OS etc.
* Choosing a post-recovery test run operation - Post-Recovery Test Run: Are a set of instructions designed to be provided to QTP on proceeding further with the test after some recovery operation has been carried out. Examples of Post Recovery actions can be repeating the complete test from the beginning or some steps may be skipped altogether & continuing with the remaining steps in the test.
* specifying a name and description for the recovery scenario
* (for tests) specifying whether to associate the recovery scenario to the current test and/or to all new tests
The Recovery Scenario Wizard leads you, step-by-step, through the process of creating a recovery scenario. The Recovery Scenario Wizard contains the following main steps Elements of Recovery Scenario in QTP:
* Defining the trigger event that interrupts the run session - Trigger Event: Is an unexpected event like appearance of a Pop-up window, object state, test run error causing application crash or interruption in our running session.
* Specifying the recovery operations required to continue - Recovery Steps: Constitutes a series of steps required to be performed to enable QTP to proceed further with the process of test after some trigger event has interrupted the run session. Examples of a recovery operation can be 1) A keyboard or mouse Operation like a Click over the “OK” button in the Pop-up window 2) Close Application Process 3) Function Call 4) Restarting the OS etc.
* Choosing a post-recovery test run operation - Post-Recovery Test Run: Are a set of instructions designed to be provided to QTP on proceeding further with the test after some recovery operation has been carried out. Examples of Post Recovery actions can be repeating the complete test from the beginning or some steps may be skipped altogether & continuing with the remaining steps in the test.
* specifying a name and description for the recovery scenario
* (for tests) specifying whether to associate the recovery scenario to the current test and/or to all new tests
22. What are the Environment Variables in QTP?
1) User-Defined Internal Variables: These are the variables that we define within the test. These variables are saved with the test and are accessible only within the test in which they were defined.
2) User-Defined External Variables: These are the variables that we predefine in the active external environment variables file. We can create as many files as we want and select an appropriate file for each test, or change files for each test run.
3) Built-in Variables: These are the variables that represent information about the test and the computer on which the test is run, such as Test path and Operating system. These variables are accessible from all tests, and are designated as read-only.
1) User-Defined Internal Variables: These are the variables that we define within the test. These variables are saved with the test and are accessible only within the test in which they were defined.
2) User-Defined External Variables: These are the variables that we predefine in the active external environment variables file. We can create as many files as we want and select an appropriate file for each test, or change files for each test run.
3) Built-in Variables: These are the variables that represent information about the test and the computer on which the test is run, such as Test path and Operating system. These variables are accessible from all tests, and are designated as read-only.
23. Where can I find information on the IE Document Object Model (NOT FOR INTERVIEW – IT IS FOR INFORMATION PURPOSE ONLY)?
For information on the IE DOM, browse to the following Web sites:
Document object: http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/obj_document.asp
Other DHTML objects: http://msdn.microsoft.com/workshop/author/dhtml/reference/objects.asp
General DHTML reference: http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp
For information on the IE DOM, browse to the following Web sites:
Document object: http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/obj_document.asp
Other DHTML objects: http://msdn.microsoft.com/workshop/author/dhtml/reference/objects.asp
General DHTML reference: http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp
24. What are the key features of QTP at a glance?
Read -> http://www.onestopsoftwaretesting.com/2008/11/what-are-key-features-of-qtp-at-glance.html
90. What are the main stages of Testing with QTP?
Testing with QuickTest involves the following main stages:
1) Planning
2) Creating Tests
3) Running Tests
4) Analyzing Results
Read -> http://www.onestopsoftwaretesting.com/2008/11/what-are-key-features-of-qtp-at-glance.html
90. What are the main stages of Testing with QTP?
Testing with QuickTest involves the following main stages:
1) Planning
2) Creating Tests
3) Running Tests
4) Analyzing Results
25. What are the methods to populate the XML Tree in QTP?
When you create an XML checkpoint for a test object operation (for a WebService test object), the expected operation return value data cannot be generated. Therefore, only a generic XML tree is created. To check the operation return values, you must first populate the XML tree with the actual elements, attributes, and values that the operation is expected to return.
You can use one of the three methods below to populate the XML tree:
* Updating the XML Tree Manually
* Importing an XML Tree from a File
* Updating the XML Tree Using Update Run Mode
When you create an XML checkpoint for a test object operation (for a WebService test object), the expected operation return value data cannot be generated. Therefore, only a generic XML tree is created. To check the operation return values, you must first populate the XML tree with the actual elements, attributes, and values that the operation is expected to return.
You can use one of the three methods below to populate the XML tree:
* Updating the XML Tree Manually
* Importing an XML Tree from a File
* Updating the XML Tree Using Update Run Mode
26. What are the modes available to open a function library in QTP?
You can open function libraries from the file system and function libraries that are part of a Quality Center project. You can open as many function libraries as you want. The QuickTest Script Editor works with .qfl, .vbs, and .txt function library files.
After you open a function library, it is displayed in a function library window in the display area, and the function library and its functions are displayed in the Opened Function Libraries folder at the top of the tree in the Resources pane. If the function library is associated with an open test, it is also displayed under the test as a function library link in the Associated Function Libraries folder in the tree in the Resources pane.
Tip: You can open an existing function library by dragging it from the file system (Windows Explorer) to the Script Editor window. You can open a recently used function library by selecting it from the Recent Files list in the File menu.
To open a function library:
1. Click the Quality Center Connection button and connect to Quality Center, if required. For more information on connecting to Quality Center, refer to the QuickTest Professional documentation.
2. Open the function library in one of the following ways:
* In the Resources pane, double-click the function library to open, or right-click the function library, and choose Show.
* Click the Open Function Library toolbar button, choose File > Open > Function Library, or press Ctrl+Shift+O. The Open Function Library dialog box opens. Select a function library, and click Open.
Note: The Open button toggles between Open Test and Open Function Library, according to the active window in the display area. To change the Open Test button to Open Function Library, click the arrow next to the button and then select Function Library, or click a function library window in the display area.
The window opens, and the function library is displayed in the Opened Function Libraries folder at the top of the tree in the Resources pane.
If you open a function library from the file system that is opened by another user, you are notified if changes are made by the other user, and given the option to accept or reject the changes made.
If you open a function library saved in Quality Center that is opened by another Quality Center user, you will be notified that the function library has been locked, and by whom, and that the function library will be opened in read-only mode. In addition, if you open a function library saved in Quality Center, it will be locked and no other user can modify it until you close it.
You can open function libraries from the file system and function libraries that are part of a Quality Center project. You can open as many function libraries as you want. The QuickTest Script Editor works with .qfl, .vbs, and .txt function library files.
After you open a function library, it is displayed in a function library window in the display area, and the function library and its functions are displayed in the Opened Function Libraries folder at the top of the tree in the Resources pane. If the function library is associated with an open test, it is also displayed under the test as a function library link in the Associated Function Libraries folder in the tree in the Resources pane.
Tip: You can open an existing function library by dragging it from the file system (Windows Explorer) to the Script Editor window. You can open a recently used function library by selecting it from the Recent Files list in the File menu.
To open a function library:
1. Click the Quality Center Connection button and connect to Quality Center, if required. For more information on connecting to Quality Center, refer to the QuickTest Professional documentation.
2. Open the function library in one of the following ways:
* In the Resources pane, double-click the function library to open, or right-click the function library, and choose Show.
* Click the Open Function Library toolbar button, choose File > Open > Function Library, or press Ctrl+Shift+O. The Open Function Library dialog box opens. Select a function library, and click Open.
Note: The Open button toggles between Open Test and Open Function Library, according to the active window in the display area. To change the Open Test button to Open Function Library, click the arrow next to the button and then select Function Library, or click a function library window in the display area.
The window opens, and the function library is displayed in the Opened Function Libraries folder at the top of the tree in the Resources pane.
If you open a function library from the file system that is opened by another user, you are notified if changes are made by the other user, and given the option to accept or reject the changes made.
If you open a function library saved in Quality Center that is opened by another Quality Center user, you will be notified that the function library has been locked, and by whom, and that the function library will be opened in read-only mode. In addition, if you open a function library saved in Quality Center, it will be locked and no other user can modify it until you close it.
27. What are the options available for configuring Data Table Parameters in QTP?
Defining the Settings for a Data Table Parameter
The following options are available for configuring Data Table parameters:
Name. Specifies the name of the parameter in the Data Table. You can create a new parameter by using the default parameter name or entering a new, descriptive name. Alternatively, you can select an existing Data Table parameter from the list.
Note: The parameter name must be unique in the sheet. It can contain letters, numbers, periods, and underscores. The first character of the parameter name must be a letter or an underscore. If you specify an invalid name, QuickTest displays a warning message when you click OK. You can choose to edit the name manually or to instruct QuickTest to fix the name automatically (by adding an underscore at the beginning of the name).
Location in Data Table. Specifies whether to store the parameter in the global or current action sheet in the Data Table.
Defining the Settings for a Data Table Parameter
The following options are available for configuring Data Table parameters:
Name. Specifies the name of the parameter in the Data Table. You can create a new parameter by using the default parameter name or entering a new, descriptive name. Alternatively, you can select an existing Data Table parameter from the list.
Note: The parameter name must be unique in the sheet. It can contain letters, numbers, periods, and underscores. The first character of the parameter name must be a letter or an underscore. If you specify an invalid name, QuickTest displays a warning message when you click OK. You can choose to edit the name manually or to instruct QuickTest to fix the name automatically (by adding an underscore at the beginning of the name).
Location in Data Table. Specifies whether to store the parameter in the global or current action sheet in the Data Table.
28. How can I send keyboard key commands (such as shortcut commands) to Web objects in QTP ?
For Web objects (or other objects that do not support the Type method), use the Windows Scripting SendKeys method.
For Web objects (or other objects that do not support the Type method), use the Windows Scripting SendKeys method.
29. What are the options available for configuring Environment Variable Parameters in QTP?
The following options are available for configuring environment variable parameters:
* Name. Specifies the name of the parameter. For an internal user-defined environment variable parameter, you can create a new parameter by using the default parameter name or entering a new, descriptive name. Alternatively, you can select an existing internal user-defined environment variable parameter from the list.
Notes:
If you edit the name displayed in the Name box for an existing parameter, you create a new internal user-defined environment variable parameter. The original environment variable parameter is not modified.
If you are parameterizing an argument that receives a predefined constant or number, only the environment variable parameters whose value is of type integer are shown in the Name list.
* Value. Specifies the value of the parameter. You can enter the value for a new user-defined internal parameter, or modify the value for an existing user-defined internal parameter. External and built-in environment variable parameter values cannot be modified in this dialog box.
If the entire value of a selected environment variable parameter cannot be displayed in the Value box, it is shown as [complex value]. For example, the value of a list's all items property is a multi-line value, where each line contains the value of an item in the list.
You can view or edit a complex value by clicking the View/Edit Complex Value button.
· Type. Specifies the type of environment variable parameter (read-only):
o internal user-defined
o external user-defined
o built-in
Tip: The value of an environment variable remains the same throughout the test run, regardless of the number of iterations, unless you change the value of the variable programmatically in your script.
* Regular expression. Sets the value of the parameter as a regular expression. This option is available only when parameterizing a checkpoint or object property text string value, and the selected environment variable parameter type is internal user-defined.
The following options are available for configuring environment variable parameters:
* Name. Specifies the name of the parameter. For an internal user-defined environment variable parameter, you can create a new parameter by using the default parameter name or entering a new, descriptive name. Alternatively, you can select an existing internal user-defined environment variable parameter from the list.
Notes:
If you edit the name displayed in the Name box for an existing parameter, you create a new internal user-defined environment variable parameter. The original environment variable parameter is not modified.
If you are parameterizing an argument that receives a predefined constant or number, only the environment variable parameters whose value is of type integer are shown in the Name list.
* Value. Specifies the value of the parameter. You can enter the value for a new user-defined internal parameter, or modify the value for an existing user-defined internal parameter. External and built-in environment variable parameter values cannot be modified in this dialog box.
If the entire value of a selected environment variable parameter cannot be displayed in the Value box, it is shown as [complex value]. For example, the value of a list's all items property is a multi-line value, where each line contains the value of an item in the list.
You can view or edit a complex value by clicking the View/Edit Complex Value button.
· Type. Specifies the type of environment variable parameter (read-only):
o internal user-defined
o external user-defined
o built-in
Tip: The value of an environment variable remains the same throughout the test run, regardless of the number of iterations, unless you change the value of the variable programmatically in your script.
* Regular expression. Sets the value of the parameter as a regular expression. This option is available only when parameterizing a checkpoint or object property text string value, and the selected environment variable parameter type is internal user-defined.
30. What are the options available when outputting a value to the Data Table in QTP?
Name. Specifies the name of the parameter in the Data Table. You can create a new parameter by using the default parameter name or entering a new, descriptive name. Alternatively, you can select an existing Data Table parameter from the list.
Note: The parameter name must be unique in the sheet. It can contain letters, numbers, periods, and underscores. The first character of the parameter name must be a letter or an underscore. If you specify an invalid name, QuickTest displays a warning message when you click OK. You can choose to edit the name manually or to instruct QuickTest to fix the name automatically (by adding an underscore at the beginning of the name).
Location in Data Table. Specifies whether to store the parameter in the global or current action sheet in the Data Table.
Advanced configuration (if applicable):
* Regular expression. Sets the value of the parameter as a regular expression. Note that this option is available only when parameterizing checkpoint and object property values.
* Use Data Table formula. (If applicable.) Inserts two columns in the Data Table. The first column contains a formula that checks the validity of output in the second column. QuickTest uses the data in the output column to compute the formula, and inserts a value of TRUE or FALSE in the table cell of the formula column. Note that this option is available only for checkpoints. For more information on using Data Table formulas,
Name. Specifies the name of the parameter in the Data Table. You can create a new parameter by using the default parameter name or entering a new, descriptive name. Alternatively, you can select an existing Data Table parameter from the list.
Note: The parameter name must be unique in the sheet. It can contain letters, numbers, periods, and underscores. The first character of the parameter name must be a letter or an underscore. If you specify an invalid name, QuickTest displays a warning message when you click OK. You can choose to edit the name manually or to instruct QuickTest to fix the name automatically (by adding an underscore at the beginning of the name).
Location in Data Table. Specifies whether to store the parameter in the global or current action sheet in the Data Table.
Advanced configuration (if applicable):
* Regular expression. Sets the value of the parameter as a regular expression. Note that this option is available only when parameterizing checkpoint and object property values.
* Use Data Table formula. (If applicable.) Inserts two columns in the Data Table. The first column contains a formula that checks the validity of output in the second column. QuickTest uses the data in the output column to compute the formula, and inserts a value of TRUE or FALSE in the table cell of the formula column. Note that this option is available only for checkpoints. For more information on using Data Table formulas,
31. What are the possibilities of exporting the data among various Object Repositories in QTP?
Exporting Local Objects to an Object Repository in QTP
You can export all of the objects contained in an action's local object repository to a new shared object repository in the file system or to a Quality Center project (if QuickTest is connected to Quality Center). This enables you to make the local objects accessible to other actions. You export local objects to a new shared object repository using the Object Repository window.
When you export local objects to a shared object repository, the parameters of any parameterized objects are converted to repository parameters using the same name as the source parameter. The default (mapped) value of each repository parameter is the corresponding source parameter. You can modify the mapping used within your action using the Map Repository Parameters dialog box.
Tip: After you export the local objects, you can use the Object Repository Merge Tool to merge the shared object repository containing the exported objects with another shared object repository.
To export local objects to a new shared object repository:
1. Open the test that has the local objects you want to export.
2. Make sure that the Object Repository window is open.
3. In the Object Repository window, in the Action box, choose the action whose local objects you want to export.
4. Choose File > Export Local Objects. The Export Object Repository dialog box opens.
Note: If you are connected to Quality Center, the dialog box that opens is different from the standard file system dialog box. You can switch between the two dialog box versions by clicking the File System and Quality Center buttons in the Export Object Repository dialog box.
5. Select the location in which to save the file, specify the file or attachment name, and click Save or OK (depending on whether you are saving it to the file system or a Quality Center project).
The object repository is exported to the specified shared object repository (a file with a .tsr extension). You can now use the new shared object repository like any other shared object repository.
98. What are the Properties used by Smart Identification Feature of QTP?
The Smart Identification mechanism uses two types of properties:
Base Filter Properties. The most fundamental properties of a particular test object class; those whose values cannot be changed without changing the essence of the original object. For example, if a Web link's tag was changed from to any other value; you could no longer call it the same object.
Optional Filter Properties. Other properties that can help identify objects of a particular class. These properties are unlikely to change on a regular basis, but can be ignored if they are no longer applicable.
Exporting Local Objects to an Object Repository in QTP
You can export all of the objects contained in an action's local object repository to a new shared object repository in the file system or to a Quality Center project (if QuickTest is connected to Quality Center). This enables you to make the local objects accessible to other actions. You export local objects to a new shared object repository using the Object Repository window.
When you export local objects to a shared object repository, the parameters of any parameterized objects are converted to repository parameters using the same name as the source parameter. The default (mapped) value of each repository parameter is the corresponding source parameter. You can modify the mapping used within your action using the Map Repository Parameters dialog box.
Tip: After you export the local objects, you can use the Object Repository Merge Tool to merge the shared object repository containing the exported objects with another shared object repository.
To export local objects to a new shared object repository:
1. Open the test that has the local objects you want to export.
2. Make sure that the Object Repository window is open.
3. In the Object Repository window, in the Action box, choose the action whose local objects you want to export.
4. Choose File > Export Local Objects. The Export Object Repository dialog box opens.
Note: If you are connected to Quality Center, the dialog box that opens is different from the standard file system dialog box. You can switch between the two dialog box versions by clicking the File System and Quality Center buttons in the Export Object Repository dialog box.
5. Select the location in which to save the file, specify the file or attachment name, and click Save or OK (depending on whether you are saving it to the file system or a Quality Center project).
The object repository is exported to the specified shared object repository (a file with a .tsr extension). You can now use the new shared object repository like any other shared object repository.
98. What are the Properties used by Smart Identification Feature of QTP?
The Smart Identification mechanism uses two types of properties:
Base Filter Properties. The most fundamental properties of a particular test object class; those whose values cannot be changed without changing the essence of the original object. For example, if a Web link's tag was changed from to any other value; you could no longer call it the same object.
Optional Filter Properties. Other properties that can help identify objects of a particular class. These properties are unlikely to change on a regular basis, but can be ignored if they are no longer applicable.
32. What are the situations best suited for using an existing Checkpoint in QTP?
If the application contains multiple edit boxes, we can reuse a checkpoint to confirm the enabled status of these edit boxes throughout our test.
If the each webpage contains same logo and same text, then we can use existing Checkpoint.
If the application contains multiple edit boxes, we can reuse a checkpoint to confirm the enabled status of these edit boxes throughout our test.
If the each webpage contains same logo and same text, then we can use existing Checkpoint.
33. How can I record on nonstandard menus in QTP?
You can modify how QuickTest behaves when it records menus. The options that control this behavior are located in the Advanced Windows Applications Options dialog box. (Tools > Options > Windows Applications > Advanced).
You can modify how QuickTest behaves when it records menus. The options that control this behavior are located in the Advanced Windows Applications Options dialog box. (Tools > Options > Windows Applications > Advanced).
34. Deciding Whether to Use Local or Shared Object Repositories in QTP
To choose where to save objects, you need to understand the differences between local and shared object repositories.
In general, the local object repository is easiest to use when you are creating simple record and run tests, especially under the following conditions:
You have only one, or very few, tests that correspond to a given application interface, or set of objects.
You expect the object properties in your application to change from time to time and/or you regularly need to update or modify test object properties.
You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options.
35. How QTP Identifies the Object?
QuickTest has a predefined set of properties that it learns for each test object. If these mandatory property values are not sufficient to uniquely identify an object you record or add, QuickTest can add some assistive properties and/or an ordinal identifier to create a unique description.
Mandatory properties are properties that QuickTest always learns for a particular test object class.
Assistive properties are properties that QuickTest learns only if the mandatory properties that QuickTest learns for a particular object in your application are not sufficient to create a unique description. If several assistive properties are defined for an object class, then QuickTest learns one assistive property at a time, and stops as soon as it creates a unique description for the object. If QuickTest does learn assistive properties, those properties are added to the test object description.
Note: If the combination of all defined mandatory and assistive properties is not sufficient to create a unique test object description, QuickTest also learns the value for the selected ordinal identifier. For more information, see Selecting an Ordinal Identifier.
When you run a test, QuickTest searches for the object that matches the description it learned (without the ordinal identifier). If it cannot find any object that matches the description, or if it finds more than one object that matches, QuickTest uses the Smart Identification mechanism (if enabled) to identify the object. In many cases, a Smart Identification definition can help QuickTest identify an object, if it is present, even when the learned description fails due to changes in one or more property values. The test object description is used together with the ordinal identifier only in cases where the Smart Identification mechanism does not succeed in narrowing down the object candidates to a single object.
You use the Object Identification dialog box (Tools > Object Identification) to configure the mandatory, assistive, and ordinal identifier properties that QuickTest uses to learn descriptions of the objects in your application, and to enable and configure the Smart Identification mechanism.
The Object Identification dialog box also enables you to configure new user-defined classes and map them to an existing test object class so that QuickTest can recognize objects from your user-defined classes when you run your test.
QuickTest has a predefined set of properties that it learns for each test object. If these mandatory property values are not sufficient to uniquely identify an object you record or add, QuickTest can add some assistive properties and/or an ordinal identifier to create a unique description.
Mandatory properties are properties that QuickTest always learns for a particular test object class.
Assistive properties are properties that QuickTest learns only if the mandatory properties that QuickTest learns for a particular object in your application are not sufficient to create a unique description. If several assistive properties are defined for an object class, then QuickTest learns one assistive property at a time, and stops as soon as it creates a unique description for the object. If QuickTest does learn assistive properties, those properties are added to the test object description.
Note: If the combination of all defined mandatory and assistive properties is not sufficient to create a unique test object description, QuickTest also learns the value for the selected ordinal identifier. For more information, see Selecting an Ordinal Identifier.
When you run a test, QuickTest searches for the object that matches the description it learned (without the ordinal identifier). If it cannot find any object that matches the description, or if it finds more than one object that matches, QuickTest uses the Smart Identification mechanism (if enabled) to identify the object. In many cases, a Smart Identification definition can help QuickTest identify an object, if it is present, even when the learned description fails due to changes in one or more property values. The test object description is used together with the ordinal identifier only in cases where the Smart Identification mechanism does not succeed in narrowing down the object candidates to a single object.
You use the Object Identification dialog box (Tools > Object Identification) to configure the mandatory, assistive, and ordinal identifier properties that QuickTest uses to learn descriptions of the objects in your application, and to enable and configure the Smart Identification mechanism.
The Object Identification dialog box also enables you to configure new user-defined classes and map them to an existing test object class so that QuickTest can recognize objects from your user-defined classes when you run your test.
