What are Recover Scenarios?
While executing your scripts you may get some UNEXPECTED/UNPREDICTABLE errors. (like printer out of paper). To "recover" the test (and continue running) from these unexpected errors you use Recovery Scenarios.
Next question arises,
When to use "on error resume next" or programmatic handling of errors VS Recovery Scenarios ?
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. 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.
For Example:
A recovery scenario can handle a printer error by clicking the default button in the Printer Error message box.
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. 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. Therefore, for this type of event, only a recovery scenario can handle it.
I would not go into details of how to create files and how to define them since they are fully covered in QTP Documentation. Mercury QuickTest Professional User's Guide > Working with Advanced Testing Features > Defining and Using Recovery Scenarios >
What constitute Recovery Scenarios?
A recovery scenario consists of the following:
While executing your scripts you may get some UNEXPECTED/UNPREDICTABLE errors. (like printer out of paper). To "recover" the test (and continue running) from these unexpected errors you use Recovery Scenarios.
Next question arises,
When to use "on error resume next" or programmatic handling of errors VS Recovery Scenarios ?
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. 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.
For Example:
A recovery scenario can handle a printer error by clicking the default button in the Printer Error message box.
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. 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. Therefore, for this type of event, only a recovery scenario can handle it.
I would not go into details of how to create files and how to define them since they are fully covered in QTP Documentation. Mercury QuickTest Professional User's Guide > Working with Advanced Testing Features > Defining and Using Recovery Scenarios >
What constitute Recovery Scenarios?
A recovery scenario consists of the following:
- Trigger Event. The event that interrupts your run session. For example, a window that may pop up on screen, or a QTP run error.
- Recovery Operations. The operations to perform to enable QTP to continue running the test after the trigger event interrupts the run session. For example, clicking an OK button in a pop-up window, or restarting Microsoft Windows.
- Post-Recovery Test Run Option. 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, you may want to restart a test from the beginning, or skip a step entirely and continue with the next step in the test.
Recovery scenarios are saved in recovery scenario files having the extension .rs. A recovery scenario file is a logical collection of recovery scenarios, grouped according to your own specific requirements.
Is there a method to programmatically call them?
By default, QTP checks for recovery triggers when an error is returned during the run session. You can use the Recovery object's method to force QTP to check for triggers after a specific step in the run session.
For a complete list go to QTP Documentation > Quick Test Advanced References > Quick Test Automation > Recovery Object
0 comments:
Post a Comment