Useful Questions & Answers on HP - QTP
1. What are the Features & Benefits of Quick Test Pro(QTP)..?
1. Key word driven testing
2. Suitable for both client server and web based application
3. VB script as the script language
4. Better error handling mechanism
5. Excellent data driven testing features
2. How to handle the exceptions using recovery scenario manager in QTP?
You can instruct QTP to recover unexpected events or errors that occurred in your testing environment during test run. Recovery scenario manager provides a wizard that guides you through the defining recovery scenario. Recovery scenario has three steps
1. Triggered Events
2. Recovery steps
3. Post Recovery Test-Run
3. How to handle the exceptions using recovery scenario manager in QTP?
You can instruct QTP to recover unexpected events or errors that occurred in your testing environment during test run. Recovery scenario manager provides a wizard that guides you through the defining recovery scenario. Recovery scenario has three steps:
1. Triggered Events
2. Recovery steps
3. Post Recovery Test-Run
3. What is the use of Text output value in QTP?
Output values enable to view the values that the application talks during run time. When parameterized, the values change for every iteration. Thus by creating output values, we can capture the values that the application takes for each run and output them to the data table.
4. How to use the Object spy in QTP?
There are two ways to Spy the objects in QTP
1) Thru file toolbar
---In the File Tool Bar click on the last toolbar button (an icon showing a person with hat).
2) Thru Object repository Dialog
---In Object repository dialog click on the button “object spy...”
In the Object spy Dialog click on the button showing hand symbol.
The pointer now changes in to a hand symbol and we have to point out the object to spy the state of the object
If at all the object is not visible or window is minimized then Hold the Ctrl button and activate the required window to and release the Ctrl button.
5. What is the file extension of the code file & object repository file in QTP?
File extension of
-- Per test object rep: - filename.mtr
-- Shared Object rep: - filename.tsr
-- Codes file extension id: - script.mts
6. Explain the concept of object repository & how QTP recognizes objects?
Object Repository: displays a tree of all objects in the current component or in the current action or entire test (depending on the object repository mode you selected).
We can view or modify the test object description of any test object in the repository or to add new objects to the repository.
Quick test learns the default property values and determines in which test object class it fits. If it is not enough it adds assistive properties, one by one to the description until it has compiled the unique description. If no assistive properties are available, then it adds a special Ordinal identifier such as objects location on the page or in the source code.
7. What are the properties you would use for identifying a browser & page when using descriptive programming?
"Name" would be another property apart from "title" that we can use.
OR
We can also use the property "micClass".
Ex: Browser("micClass:=browser").page("micClass:=page")....
8. What are the different scripting languages you could use when working with QTP?
Visual Basic (VB), XML, JavaScript, Java, HTML
9 Give example where you have used a COM interface in your QTP project?
COM interface appears in the scenario of front end and back end. for eg:if you r using oracle as back end and front end as VB or any language then for better compatibility we will go for an interface. of which COM will be one among those interfaces. Create object creates handle to the instance of the specified object so that we program can use the methods on the specified object. It is used for implementing Automation(as defined by Microsoft).
10. Few basic questions on commonly used Excel VBA functions.
Common functions are:
Coloring the cell
Auto fit cell
Setting navigation from link in one cell to other
Saving
11. Explain the keyword create object with an example.
Creates and returns a reference to an Automation object
Syntax: CreateObject(servername.typename [, location])
Arguments
SERVERNAME: Required. The name of the application providing the object
TYPENAME: Required. The type or class of the object to create
LOCATION: Optional. The name of the network server where the object is to be created
12. Explain in brief about the QTP Automation Object Model.
Essentially all configuration and run functionality provided via the QTP interface is in some way represented in the QTP automation object model via objects, methods, and properties. Although a one-on-one comparison cannot always be made, most dialog boxes in QTP have a corresponding automation object, most options in dialog boxes can be set and/or retrieved using the corresponding object property, and most menu commands and other operations have corresponding automation methods. You can use the objects, methods, and properties exposed by the QTP automation object model, along with standard programming elements such as loops and conditional statements to design your program.
13. How to handle dynamic objects in QTP?
QTP has a unique feature called Smart Object Identification/recognition. QTP generally identifies an object by matching its test object and run time object properties. QTP may fail to recognize the dynamic objects whose properties change during run time. Hence it has an option of enabling Smart Identification, wherein it can identify the objects even if their properties changes during run time.
Check this out-
If QuickTest is unable to find any object that matches the recorded object description, or if it finds more than one object that fits the description, then QuickTest ignores the recorded description, and uses the Smart Identification mechanism to try to identify the object.
While the Smart Identification mechanism is more complex, it is more flexible, and thus, if configured logically, a Smart Identification definition can probably help QuickTest identify an object, if it is present, even when the recorded description fails.
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 as they are unlikely to change on a regular basis, but which can be ignored if they are no longer applicable.
14. What is a Run-Time Data Table? Where can I find and view this table?
In QTP, there is data table used, which is used at runtime.
-In QTP, select the option View->Data table.
-This is basically an excel file, which is stored in the folder of the test created, its name is Default.xls by default.
15. How does Parameterization and Data-Driving relate to each other in QTP?
To data drive we have to parameterize i.e. we have to make the constant value as parameter, so that in each iteration (cycle) it takes a value that is supplied in run-time data table. Through parameterization only we can drive a transaction (action) with different sets of data. You know running the script with the same set of data several times is not suggestible, & it's also of no use.
16. What is the difference between Call to Action and Copy Action.?
Call to Action: The changes made in Call to Action, will be reflected in the original action (from where the script is called).But where as in Copy Action, the changes made in the script, will not affect the original script (Action)
17. Discuss QTP Environment.
QuickTest Pro environment using the graphical interface and Active Screen technologies - A testing process for creating test scripts, relating manual test requirements to automated verification features - Data driving to use several sets of data using one test script.
18. Explain the concept of how QTP identifies object.
During recording QTP looks at the object and stores it as test object. For each test object QT learns a set of default properties called mandatory properties, and look at the rest of the objects to check whether this properties are enough to uniquely identify the object. During test run, QT searches for the run time objects that match with the test object it learned while recording.
19. Differentiate the two Object Repository Types of QTP.
Object repository is used to store all the objects in the application being tested. 2 types of object repository per action and shared. In shared repository only one centralized repository for all the tests, where as in per action for each test a separate per action repository is created.
20. What the differences are and best practical application of each.
Per Action: For Each Action, one Object Repository is created.
Shared: One Object Repository is used by entire application
21. Explain what the difference between Shared Repository and Per_Action Repository
Shared Repository: Entire application uses one Object Repository, that similar to Global GUI Map file in WinRunner
Per Action: For each Action, one Object Repository is created, like GUI map file per test in WinRunner
22. Have you ever written a compiled module? If yes tell me about some of the functions that you wrote.
I used the functions for capturing the dynamic data during runtime. Function used for Capturing Desktop, browser and pages.
23. What projects have you used WinRunner on? Tell me about some of the challenges that arose and how you handled them.
PBS: WR fails to identify the object in GUI. If there is a non standard window object cannot recognize it, we use GUI SPY for that to handle such situation.
24. Can you do more than just capture and playback?
I have done dynamically capturing the objects during runtime in which no recording, no playback and no use of repository is done AT ALL.
-It was done by the windows scripting using the DOM (Document Object Model) of the windows.
25. How to do the scripting. Are there any inbuilt functions in QTP as in QTP-S.? What is the difference between them? How to handle script issues?
Yes, there's an in-built functionality called "Step Generator" in Insert->Step->Step Generator -F7, which will generate the scripts as u enter the appropriate steps.
26. What is the difference between check point and output value.
I would like to add some stuff to Kalpana's comments.
It is as follows:-
An outPut value is a value captured during the test run and entered in the run-time but to a specified location.
EX:-Location in Data Table [Global sheet / local sheet]
27. IF we use batch testing the result shown for last action only in that how can i get result for every action.
u can click on the icon in the tree view to view the result of every action.
28. How the exception handling can be done using QTP
It can be done using the Recovery Scenario Manager which provides a wizard that guides you through the process of defining a recovery scenario. FYI The wizard could be accessed in QTP> Tools-> Recovery Scenario Manager.......
29. How many types of Actions are there in QTP?
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.
30. I want to open a Notepad window without recording a test and I do not want to use SystemUtil.Run command as well. How do I do this?
U can still make the notepad open without using the record or System utility script, just by mentioning the path of the notepad "( i.e., where the notepad.exe is stored in the system) in the "Windows Applications Tab" of the "Record and Run Settings window. Try it out.
Create QTP Test Scripts – QTP Tutorial 1
You can create tests using the keyword-driven methodology, step recording, or a combination of both. The keyword-driven methodology enables you to select keywords to indicate the operations you want to perform on your application. Step recording enables you to record the operations you perform on your application.
After you create your tests, you can enhance them using checkpoints and other special testing options.
This section includes:
* About Creating Tests
* Deciding Which Methodology to Use - Keyword-Driven or Recording
* Enhancing Your Test
* Using Relative Paths in QTP
About Creating Tests
You can create tests using the keyword-driven methodology, step recording, or a combination of both.
Creating tests using the keyword-driven methodology requires an infrastructure for all of the required resources. Resources include shared object repositories, function libraries, and recovery scenarios. Setting up the infrastructure requires in-depth knowledge of your application and a high level of QTP expertise.
Although setting up the infrastructure may initially require a longer time-investment in comparison to recording tests, using the keyword-driven methodology enables you to create tests at a more application-specific level and with a more structured design. This enables you to maintain your tests more efficiently and provides you with more flexibility than a recorded test.
In some cases, you may want to let QTP generate test steps by recording the typical processes that you perform on your application. As you navigate through your application, QTP graphically displays each step you perform as a row in the Keyword View. A step is anything a user does that changes the content of a page or object in your application, for example, clicking a link or typing data into an edit box. Recording may be easier for new QTP users or when beginning to design tests for a new application or a new feature.
While creating your test, you can insert checkpoints. A checkpoint compares the value of an element captured when the object was saved in the object repository, with the value of the same element captured during the run session. This helps you determine whether or not your application is functioning correctly.
When you test your application, you may want to check how it performs the same operations with different data. This is called parameterizing your test. You can supply data in the Data Table, define environment variables, instruct QuickTest to generate random numbers, and so on.
Deciding Which Methodology to Use - Keyword-Driven or Recording
You can create the steps in your tests using the keyword-driven methodology, recording, or a combination of both.
Recording Tests
Recording can be useful in the following situations:
* Recording helps novice QTP users learn how QTP interprets the operations you perform on your application, and how it converts them to QTP objects and built-in operations.
* Recording can be useful for more advanced QTP users when working with a new application or major new features of an existing application (for the same reasons described above). Recording is also helpful while developing functions that incorporate built-in QTP keywords.
* Recording can be useful when you need to quickly create a test that tests the basic functionality of an application or feature, but does not require long-term maintenance.
Creating Tests Using Keyword-Driven Testing
Keyword-driven testing advantages include the following:
* Keyword-driven testing enables you to design your tests at a business level rather than at the object level. For example, QTP may recognize a single option selection in your application as several steps: a click on a button object, a mouse operation on a list object, and then a keyboard operation on a list sub-item. You can create an appropriately-named function to represent all of these lower-level operations in a single, business-level keyword.
* By incorporating technical operations, such as a synchronization statement that waits for client-server communications to finish, into higher level keywords, tests are easier to read and easier for less technical application testers to maintain when the application changes.
* Keyword-driven testing naturally leads to a more efficient separation between resource maintenance and test maintenance. This enables the automation experts to focus on maintaining objects and functions while application testers focus on maintaining the test structure and design.
* When you record tests, you may not notice that new objects are being added to the local object repository. This may result in many testers maintaining local object repositories with copies of the same objects. When using a keyword-driven methodology, you select the objects for your steps from the existing object repository. When you need a new object, you can add it to your local object repository temporarily, but you are also aware that you need to add it to the shared object repository for future use.
* When you record a test, QTP enters the correct objects, methods, and argument values for you. Therefore, it is possible to create a test with little preparation or planning. Although this makes it easier to create tests quickly, such tests are harder to maintain when the application changes and often require re-recording large parts of the test.
* When you use a keyword-driven methodology, you select from existing objects and operation keywords. Therefore, you must be familiar with both the object repositories and the function libraries that are available. You must also have a good idea of what you want your test to look like before you begin inserting steps. This usually results in well-planned and better-structured tests, which also results in easier long-term maintenance.
* Automation experts can add objects and functions based on detailed product specifications even before a feature has been added to a product. Using keyword-driven testing, you can begin to develop tests for a new product or feature earlier in the development cycle.
Enhancing Your Test
You can use a variety of options to enhance your existing tests. This section describes some of the ways in which you can enhance your existing tests.
Checkpoints
You can add checkpoints to your test. A checkpoint is a step in your test that compares the a specified item during a run session with the values stored for the same item within the test. This enables you to identify whether or not your application is functioning correctly. There are several different checkpoint types.
Tip: You can also use the CheckProperty method, which enables you to verify the property value of an object without using the checkpoint interface.
Parameterization
You can parameterize your test to replace fixed values with values from an external source during your run session. The values can come from a Data Table, environment variables you define, or values that QTP generates during the run session.
Output Values
You can retrieve values from your test and store them in the Data Table as output values. You can subsequently use these values as an input parameter in your test. This enables you to use data retrieved during a test in other parts of the test.
Actions
You can divide your test into actions to streamline the testing process of your application.
Programming Statements
You can use special QTP options to enhance your test with programming statements. The Step Generator guides you step-by-step through the process of adding recordable and non-recordable operations (methods and properties) to your test. You can also synchronize your test to ensure that your application is ready for QTP to perform the next step in your test, and you can measure the amount of time it takes for your application to perform steps in a test by defining and measuring transactions.
You can also manually enter standard VBScript statements, as well as statements using QTP test objects and operations, in the Expert View
Using Relative Paths in QTP
QTP enables you to define the path to a resource that you are adding to the file system or to Quality Center, as a relative or an absolute path.
Note: If you are working with the Resources and Dependencies model with Quality Center 10.00, specify an absolute Quality Center path.
When you specify a path to a function library, shared object repository, recovery scenario, or environment variable file, QTP checks if the path, or the initial part of the path, exists in the Folders pane of the Options dialog box (Tools > Options > Folders node). The Folders pane contains a search list in which you can define where QTP searches for tests, actions, or files.
QTP then opens one of the following two dialog boxes, depending on whether the path you specified, or a part of the path, exists in the Folders pane.
Note: If you are connected to QualityCenter 10.00, these dialog boxes are displayed only if you select a path in the file system or in a QualityCenter 9.x project.
Notes:
You can choose not to show one or both of these dialog boxes when you enter a path to a resource by selecting the Do not show this message again check box. To show these dialog boxes again, select the Remind me to use relative paths when specifying a path to a resource check box in the Folders pane of the Options dialog box. This check box is selected by default when you first start QTP.
Managing QTP Test Scripts - QTP Tutorial 2
We can use the File menu to create, open, save, zip, unzip, and print tests, as well as create standalone, portable tests.
This section includes:
* Creating a New Test
* Opening an Existing Test
* Saving a Test
* Creating Portable Copies of Your Tests
* Zipping a Test
* Unzipping a Test
* Printing a Test
Creating a New QTP Test
To create a new test, click the New button or select File > New > Test. A new test opens, with a new action selected in the Keyword View. You are ready to start creating your test.
If the test you select was last saved in an older version of QuickTest, you may be asked whether to convert the test to the current version or view it in read-only format.
To open an existing test:
* (Optional) Connect to a Quality Center server and project.
* Select File > Open > Test, or click the Open down arrow and select Test. The Open Test dialog box opens.
* In the sidebar, select the location of the test, for example, File System or Quality Center Test Plan.
* Browse to and select a test. You can select the Open in read-only mode option at the bottom of the dialog box. Click Open. The test opens and the title bar displays the test name.
Note: If the test is stored in a version control-enabled Quality Center project, the Open button contains a down arrow, enabling you to open the test and immediately check it out.
Tip: You can open a recently used test by selecting it from the Recent Files list in the File menu.
Saving a Test
You can save a new test or save changes to an existing test.
Tip: If changes are made to an existing test, an asterisk (*) is displayed in the title bar until the test is saved.
Note: You must use the Save As option in QTP if you want to save a test under another name or create a copy of a test. You cannot copy a test or change its name directly in the file system or in Quality Center.
To save a new test:
1. (Optional) Connect to a Quality Center server and project. QTP information, see Connecting to and Disconnecting from Quality Center.
2. Click the Save button or select File > Save to save the test. The Save QTP Test dialog box opens.
3. In the sidebar, select the location to save the test, for example, File System or Quality Center Test Plan.
4. Browse to and choose the folder in which to save the test. Note: In the file system, QTP suggests a default folder called Tests. For all supported operating systems except Windows Vista, this folder is located under your QTP Professional installation folder. For Windows Vista, this folder is located under MyDocuments\HP\QTP Professional.
5. Type a name for the test in the File name box. Note that the test name cannot exceed 220 characters (including the path), cannot begin or end with a space, and cannot contain the following characters: \ / : * ? " < > | % '
If you save the test to Quality Center, the file path must not contain two consecutive semicolons (;;).
6. If you are recording and want to save the Active Screen files with your test, confirm that Save Active Screen files is selected. If you clear this box, your Active Screen files will not be saved, and you will not be able to edit your test using the options that are normally available from the Active Screen.
7. Clearing the Save Active Screen files check box can be especially useful for conserving disk space once you have finished designing the test and you are using the test only for test runs.
Tip: If you clear the Save Active Screen files check box and then later want to edit your test using Active Screen options, you can regenerate the Active Screen information by performing an Update Run operation.
Note: You can also instruct QTP not to capture Active Screen files while recording or to only capture Active Screen information under certain conditions. You can set these preferences in the Active Screen pane of the Options dialog box.
Click Save. QTP displays the test name in the title bar.
To save changes to an existing test:
1. Click the Save button to save changes to the current test.
2. Select File > Save As to save an existing test to a new name or a new location. If you select File > Save As, the following options are available:
* Select or clear the Save Active Screen files check box to indicate whether or not you want to save the Active Screen files with the new test. For more information, see step 6 above.
* Select or clear the Save test results check box to indicate whether or not you want to save any existing test results with your test.
Note that if you clear this box, your test result files will not be saved, and you will not be able to view them later. Clearing the Save test results check box can be useful for conserving disk space if you do not require the test results for later analysis, or if you are saving an existing test under a new name and do not need the test results.
Creating Portable Copies of QTP Test Scripts
Tests and their resource files are often stored on a network drive or in Quality Center, as this enables the reuse of actions and other resources, and helps ease test management.
Sometimes, you may need to open or run a test when you do not have access to a network drive or Quality Center. For example, you may need to create a portable copy of a test for use when travelling to other sites. You can save a standalone copy of your test and its resource files to a local drive or to another storage device using the File > Save Test with Resources command.
When you save a test in this manner, QTP creates a copy of the following and saves the files in the location you specify:
* Source test. QTP saves a copy of this test in the location you specify.
* Resource files. QTP saves a copy of all resource files associated with the source test, such as function libraries and shared object repositories. QTP stores these files in sub-folders of the copied test.
* Called actions. QTP saves a copy of any external actions called by the source test. For example, if Test A calls actions that are stored in Test B, QTP creates a local copy of the actions stored in Test B and stores them in a sub-folder of Test A. The sub-folder has the same name as the test from which the called actions were copied. In this example, the sub-folder is named Test_B. QTP also creates a copy of any resources associated directly with these actions, such as its local shared object repositories and action sheets in the Data Table. QTP does not, however, save the resource files associated with Test B, so you must ensure that these resources are associated with the source test, Test A.
This enables you to modify or run the test without access to a network drive or Quality Center.
Tip: If you use QTP with a concurrent license but do not have access to the concurrent license server (for example, during a business trip), you can install a commuter license.
Zipping QTP Test Scripts
QTP tests contain a series of configuration, run-time, setup data, and (optionally) Active Screen files. QTP saves these files together with the test. You can zip these files to conserve space and make the tests easier to transfer.
To zip a test:
* Do one of the following:
Select File > Export Test to Zip File to open the Export to Zip File dialog box.
* Select the Archive test and resource files in a .zip file check box in the Save Test with Resources dialog box (File > Save Test with Resources).
* Type a zip file name and path, or accept the default name and path, and click OK. QTP zips the test and its associated files.
Unzipping a Test
You can unzip a test when needed.
To unzip a zipped test:
* Select File > Import Test from Zip File. The Import from Zip File dialog box opens.
*
Enter or select the name of the zip file that you want to unzip, choose a target folder into which you want to unzip the files, and click OK. QTP unzips the test and its associated files.
Print QTP Test Scripts
You can print your entire test from the Keyword View (in table format). You can also print a single action either from the Keyword View (in table format) or the Expert View (in statement format). When printing from the Expert View, you can also specify additional information that you want to be included in the printout.
To print from the Keyword View:
* Click the Print button or select File > Print. A standard Print dialog box opens.
* Click OK to print the content of the Keyword View to your default Windows printer.
Tip: You can select File > Print Preview to display the Keyword View on screen as it will look when printed. Note that the Print Preview option works only with tests created using QTP 8.0 and later.
To print from the Expert View
* Click the Print button or select File > Print. The Print dialog box opens.
* Specify the print options that you want to use.
If you want to print to a different printer, or change your printer preferences, click Setup to display the Print Setup dialog box.
* Click Print to print according to your selections.
Understanding the QTP Keyword-Driven Methodology
You can create a test using the keyword-driven methodology, which enables you to select keywords to indicate the operations you want to perform on your application. This enables you to create structured tests that are easier to update and maintain over time.
The keyword-driven methodology is especially useful for organizations that have both technical and less technical users because it offers a clear division of automation tasks. This enables a few experts to maintain the resource framework while less technical users design and maintain automated test steps. Additionally, once the basic infrastructure is in place, both types of users can often do their tasks simultaneously.
Before you begin creating tests, you need to plan your tests to ensure that your tests cover your testing requirements.
Tip: You can also create a test by recording the operations you perform on your application, as described in Creating Tests Using the Recording Mechanism. After you create your test, you can enhance it using checkpoints and other special testing options.
Understanding the Keyword-Driven Methodology
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.
This section provides a general overview of the steps you perform when planning and implementing your tests.
Stage 1: Analyzing Your Application
Before you begin creating a test, you need to analyze your application and determine your testing needs.
First, determine the development environments in which your application controls were developed, such as Web, Java, or .NET, so that you can load the required QTP add-ins.
Then determine the functionality that you want to test. To do this, consider the various activities that customers perform in your application to accomplish specific tasks. Which objects and operations are relevant for the set of business processes that need to be tested? Which operations require customized keywords to provide additional functionality?
While you are thinking about the business processes you want to test, consider how you can divide these processes into smaller units, which will be represented by your test's actions. Each action should emulate an activity that a customer might perform when using your application.
As you plan, try to keep the amount of steps you plan to include in each action to a minimum. Creating small, modular actions helps make your tests easier to read, follow, and maintain.
Stage 2: Preparing the Testing Infrastructure
To complete the infrastructure that is part of the planning process, you need to build the set of resources to be used by your tests, including shared object repositories containing test objects (which are representations of the objects in your application), function libraries containing functions that enhance QTP functionality, and so on.
At this stage you also need to configure QTP according to your testing needs. This can include setting up your global testing preferences, your run session preferences, any test-specific preferences, and recovery scenarios. You can also create automation scripts that automatically set the required configurations (such as the add-ins to load) on the QTP client at the beginning of a run session.
Lastly, you create one or more tests that serve as action repositories in which you can store the actions to be used in your tests. Generally, you create an action repository test for each area of your application to be tested. Storing all of your actions in specific tests enables you to maintain your actions in a central location. When you update an action in the action repository, the update is reflected in all tests that contain a call to that action. When you run a test, only the relevant action repository tests are loaded.
You then associate the shared object repositories with the relevant actions. This enables you to later insert steps using the objects stored in the object repositories.
When you create your tests, you insert calls to one or more of the actions stored in this repository.
Stage 3: Adding Steps to Your Actions
In this stage, you add steps to the actions in your test action repository.
Before you begin adding steps, make sure that you associate your function libraries and recovery scenarios with the relevant tests, so that you can insert steps using keywords.
You can create steps using the keyword-driven functionality available in the table-like, graphical Keyword View—or you can use the Expert View, if you prefer to program steps directly in VBScript. You can add steps to your test in one or both of the following ways:
* Drag objects from your object repository or the from Available Keywords pane to add keyword-driven steps in the Keyword View or Expert View. The object repository and Available Keywords pane contain all of the objects that you want to test in your application. (You create one or more object repositories when you prepare the testing infrastructure, as described in Stage 2: Preparing the Testing Infrastructure.)
When you drag an object into the Keyword View, a step is created in the action with the default operation for that object. For example, if you drag a button object into the Keyword View, the click operation is automatically defined for the step. You can then modify the step as needed.
Record on your application.
As you navigate through your application during a recording session, QTP graphically displays each step you perform as a row in the Keyword View. A step is something that causes or makes a change in your application, such as clicking a link or image, or submitting a data form. In the Expert View, these steps are displayed as lines in a test script (VBScript). The Documentation column of the Keyword View also displays a description of each step in easy-to-understand sentences.
Stage 4: Enhancing Your Test
You can enhance the testing process by modifying your test with special testing options and/or with programming statements, such as:
o Insert checkpoints and output values into your test.
A checkpoint checks specific properties or other characteristics of an object and enables you to identify whether or not your application is functioning correctly.
You can also use output values to extract data from your test. An output value is a value retrieved during the run session and entered into your Data Table or stored in a variable or a parameter. You can subsequently use this output value as input data in your test. This enables you to use data retrieved during a run session in other parts of the test.
o Broaden the scope of your test by replacing fixed values with parameters.
When you test your application, you can parameterize your steps to check how your application performs the same operations with different data. You may supply data in the Data Table, define environment variables and values, define test or action parameters and values, or instruct QTP to generate random numbers for current user and test data.
When you parameterize your test, QTP substitutes the fixed values in your test with the values stored in the relevant parameters. When you use Data Table parameters, QTP uses the values from a different row in the Data Table for each iteration of the test or action. (Each run session that uses a different set of parameterized data is called an iteration.)
o Add user-defined functions by creating function libraries and calling their functions from your test.
o Use the many functional testing features included in QTP to enhance your test and/or add programming statements to achieve more complex testing goals.
Stage 5: Running and Debugging Your Test
After you create your test, you can perform different types of runs to achieve different goals.
o Run your test to debug it. You can control your run session to help you identify and eliminate defects in your test. You can use the Step Into, Step Over, and Step Out commands to run your test step by step. You can begin your run session from a specific step in your test, or run the test until a specific step is reached. You can also set breakpoints to pause your test at predetermined points. You can view or change the value of variables in your test each time it stops at a breakpoint in the Debug Viewer. You can also manually run VBScript commands in the Debug Viewer.
o Run your test to check your application. The test starts running from the first line in your test and stops at the end of the test. While running, QTP connects to your application and performs each operation in your test, including any checkpoints, such as checking any text strings, objects, tables, and so forth. If you parameterized your test with Data Table parameters, QTP repeats the test (or specific actions in your test) for each set of data values in the Data Table.
o Run your test to update it.
+ You can run your test using Maintenance Run Mode when you know that your application has changed, and you therefore expect that QTP will not be able to identify the objects in your test. When you run a test in Maintenance Run Mode, a wizard opens for steps that fail because an object could not be found in the application. The wizard then guides you through the steps of resolving the issue, and, after you resolve the issue, the run continues.
+ You can run your test using Update Run Mode to update the property sets used for test object descriptions, the expected checkpoint values, the data available to retrieve in output values, and/or the Active Screen images and values.
Stage 6: Analyzing Test Results and Reporting
After you run your test, you can view the results of the run in the Test Results window. You can view a summary of your results as well as a detailed report. If you captured still images or movies of your application during the run, you can view these from the Screen Recorder tab of the Test Results window.
If you enabled local system monitoring for your test, you can view the results in the System Monitor tab of the Test Results window.
No comments:
Post a Comment