Recovery Scenario
When executing the scripts we may get unexpected errors, to recover the test and continue running script from these unexpected errors we use Recovery Scenario
What happens in Recovery Scenario
Recovery Scenario consists of the following options
Trigger Events
The event that interrupt your run session. For example a Window that may pop up on your screen.
Recovery Operations
The operations to perform to enable QTP to continiue test after trigger events interrupt the run
session. For Example Clicking on "ok" button in a pop up window
Post Recovery Test Run Options
The instructions on how QTP should processed after the recovery operations have been performed, and from which point in the test QTP should continue. 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.
A recovery scenarios are saved in recovery scenario files having the extension .qrs, A recovery file is logical collection of recovery scenarios, grouped according to our specific requirements.
Recovery scenario manager can handle the following four events
Pop up window: To handle the unwanted pop ups
Object state: To handle the object related errors at run time
Test Run error: To handle the vb script statements error at run time
Application Crash: To handle the crashed application at run time
When to use Error Handling (On Error Resume Next) 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 is 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
Example:
A recovery scenario can handle a printer erro by clicking the default buttton in the Printer Error message box. You cannot handle this error directly in your test, since you cannot know at what point the network will return the printer error. You could try to handle this event in your test 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 may have progressed several steps before the error is displayed. Therefore, for this type of event, only a recovery scenario can handle it.
On Error Statements:
Following are the error statements
On Error resume Next
On Error Go to 0
Error.Number
Error.Description
On Error Resume Next
On Error Resume Next Statement enables the Error handling in the code. If there is error in the code "On Error Resume Next" ignores it and continue with next line of code.
ON Error Go to 0
On Error go to 0 statement disables error handling we have previously enabled it by using On Error Resume Next
Err.Number and Err.Description
Provides the Error Number and the Description of the Error
Example:
'Call the function to divide
Call Divide
Call Divide()
On Error Resume Next
'Divided by Zero
C=100/0
Report the error occured and you can see the error number and error description in result summary
'disables error handling
When executing the scripts we may get unexpected errors, to recover the test and continue running script from these unexpected errors we use Recovery Scenario
What happens in Recovery Scenario
Recovery Scenario consists of the following options
Trigger Events
The event that interrupt your run session. For example a Window that may pop up on your screen.
Recovery Operations
The operations to perform to enable QTP to continiue test after trigger events interrupt the run
session. For Example Clicking on "ok" button in a pop up window
Post Recovery Test Run Options
The instructions on how QTP should processed after the recovery operations have been performed, and from which point in the test QTP should continue. 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.
A recovery scenarios are saved in recovery scenario files having the extension .qrs, A recovery file is logical collection of recovery scenarios, grouped according to our specific requirements.
Recovery scenario manager can handle the following four events
Pop up window: To handle the unwanted pop ups
Object state: To handle the object related errors at run time
Test Run error: To handle the vb script statements error at run time
Application Crash: To handle the crashed application at run time
When to use Error Handling (On Error Resume Next) 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 is 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
Example:
A recovery scenario can handle a printer erro by clicking the default buttton in the Printer Error message box. You cannot handle this error directly in your test, since you cannot know at what point the network will return the printer error. You could try to handle this event in your test 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 may have progressed several steps before the error is displayed. Therefore, for this type of event, only a recovery scenario can handle it.
On Error Statements:
Following are the error statements
On Error resume Next
On Error Go to 0
Error.Number
Error.Description
On Error Resume Next
On Error Resume Next Statement enables the Error handling in the code. If there is error in the code "On Error Resume Next" ignores it and continue with next line of code.
ON Error Go to 0
On Error go to 0 statement disables error handling we have previously enabled it by using On Error Resume Next
Err.Number and Err.Description
Provides the Error Number and the Description of the Error
Example:
'Call the function to divide
Call Divide
Call Divide()
On Error Resume Next
'Divided by Zero
C=100/0
Report the error occured and you can see the error number and error description in result summary
If Err.Number <> 0 then
Reporter.ReportEvent micWarning,"Error Occured","Error number is " & Err.Number & " and
description is : " & Err.Description
On Error goto 0
End If
End function
No comments:
Post a Comment