I recommend you to subscribe via RSS Feed. If you want to keep track of further articles on QTP. You can use the Recovery object’s method to force QTP to check for triggers after a specific step in the run session.įor a complete list go to QTP Documentation > Quick Test Advanced References > Quick Test Automation > Recovery Object Is there a method to programmatically call them?īy default, QTP checks for recovery triggers when an error is returned during the run session. A recovery scenario file is a logical collection of recovery scenarios, grouped according to your own specific requirements.
Recovery scenarios are saved in recovery scenario files having the extension. For example, you may want to restart a test from the beginning, or skip a step entirely and continue with the next step in the test. The instructions on how QTP should proceed after the recovery operations have been performed, and from which point in the test QTP should continue, if at all. For example, clicking an OK button in a pop-up window, or restarting Microsoft Windows. The operations to perform to enable QTP to continue running the test after the trigger event interrupts the run session. For example, a window that may pop up on screen, or a QTP run error. The event that interrupts your run session.
Uft tutorial career guru 99 professional#
Mercury QuickTest Professional User’s Guide > Working with Advanced Testing Features > Defining and Using Recovery Scenarios > What constitute Recovery Scenarios?Ī recovery scenario consists of the following:
Uft tutorial career guru 99 how to#
I would not go into details of how to create files and how to define them since they are fully covered in QTP Documentation.
Therefore, for this type of event, only a recovery scenario can handle it. You could try to handle this event in your test or component by adding an If statement immediately after the step that sent a file to the printer, but if the network takes time to return the printer error, your test or component may have progressed several steps before the error is displayed. You cannot handle this error directly in your test or component, since you cannot know at what point the network will return the printer error. Using Recovery Scenarios may result in unusually slow performance of your tests.They are designed to handle a more generic set of unpredictable events which CANNOT be handled programmatically.Ī recovery scenario can handle a printer error by clicking the default button in the Printer Error message box. If you can predict that a certain event may happen at a specific point in your test or component, it is recommended to handle that event directly within your test or component by adding steps such as If statements or optional steps or “on error resume next”, rather than depending on a recovery scenario. Next question arises, When to use “on error resume next” or programmatic handling of errors VS Recovery Scenarios ? To “recover” the test (and continue running) from these unexpected errors you use Recovery Scenarios. While executing your scripts you may get some UNEXPECTED/UNPREDICTABLE errors.
0 kommentar(er)
