Error Handling & Recovery Scenario

Recovery Scenario:

When executing scripts we may get some Unexpected errors.To recover the test and continue running script from these unexpected errors we use Recovery Scenarios.


What happens in  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.

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.

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. 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 .qrs. A recovery scenario file is a logical collection of recovery scenarios, grouped according to our specific requirements.


Recovery scenario manger can handle following four events:

1. Pop-up window: To handle unwanted pop ups.

2. Object state: To handle object related errors at runtime.

3. Test run error: To handle vb script statement errors at runtime.

4. Application crash: To handle crashed applications at runtime.



1.Recovery Scenario for Popup Window:

Steps to follow to handle unwanted popups:

Trigger Event Steps:

Resources Menu -->Recovery Scenario Manager -->New -->Next -->Select “Popup Window” as Trigger event -->Next -->Click on Hand Icon -->Show unwanted window with Hand icon -->Next -->Next -->(Continue below mentioned steps)

Recovery Operations steps:

Select function call as Recovery Operation -->Next {Open Notepad -->Save empty file with .vbs extension} -->Browse the .vbs fie path -->Next -->Uncheck Add another Recovery Operation -->Next -->(Continue below mentioned steps)

Post-Recovery Test Run Option Steps:

Select Post-Recovery Test Run Option {Repeat current step and continue, Proceed to Next step, Proceed to Next Action, Proceed to next test iteration, Restart current test run, Stop the Test Run} -->Next -->Enter Scenario Name -->Next -->Select Option --> Finish -->Save the scenario with “.qrs” -->Record required Recovery Operation {Click ok, Click Cancel} take the script into function -->Save the library file -->Click Run


2.Recovery Scenario for Object State:

Steps to follow to check Property values of an object in the application match specified values. User can specify property values for each object in the hierarchy.

Trigger Event steps:


Resources Menu --> Recovery Scenario Manager --> New --> Next --> Select “Object state Window” as Trigger event --> Next --> Click on Hand Icon --> Show object with and icon --> Next --> Next-->select object property with value (enabled ,false)-->click next --> (Continue below mentioned steps)

Recovery Operations steps:

Select function call as Recovery Operation --> Next {Open Notepad --> Save empty file with .vbs extension} --> Browse the .vbs fie path --> Next --> Uncheck Add another Recovery Operation --> Next -->(Continue below mentioned steps)

Post-Recovery Test Run Option Steps:

Select Post-Recovery Test Run Option {Repeat current step and continue, Proceed to Next step, Proceed to Next Action, Proceed to next test iteration, Restart current test run, Stop the Test Run} --> Next--> Enter Scenario Name --> Next --> Select Option -->Finish --> Save the scenario with “.qrs” --> Record required Recovery Operation {Click ok, Click Cancel} take the script into function --> Save the library file --> Click Run


3.Recovery Scenario for Test Run Error:

Steps to follow to check if test does not run successfully then Test Run Error can be raised.

Trigger Event steps:

Resources Menu -->Recovery Scenario Manager -->New -->Next -->Select “Testrunerror Window” as Trigger event -->Next -->select any error o -->Next -->Next -->(Continue below mentioned steps)

Recovery Operations steps:

Select function call as Recovery Operation -->Next {Open Notepad -->Save empty file with .vbs extension} -->Browse the .vbs fie path -->Next -->Uncheck Add another Recovery Operation -->Next -->(Continue below mentioned steps)

Post-Recovery Test Run Option Steps:

Select Post-Recovery Test Run Option {Repeat current step and continue, Proceed to Next step, Proceed to Next Action, Proceed to next test iteration, Restart current test run, Stop the Test Run} -->Next >Enter Scenario Name >Next -->Select Option --> Finish >Save the scenario with “.qrs” -->Record required Recovery Operation {Click ok, Click Cancel} take the script into function -->Save the library file -->Click Run


4.Recovery Scenario for Application Crash:

Steps to follow to check application failure during Test Run.

Trigger Event steps:

Resources Menu --> Recovery Scenario Manager--> Click New--> Click Next -->Select Application Crash as Trigger event-->Next -->Select selected executable application-->Next --> (Continue below mentioned steps)

Recovery Operations and Post-Recovery Test Run Option Steps:

Select Recovery Operation {Keyboard, Mouse Operation,Close Application Process, function Call, Restart, Microsoft Windows} -->Next -->If you want to check Add another operation else uncheck-->Next -->Next -->Enter Scenario Name -->Next-->Select Option -->Finish -->Close -->Save the scenario with “.qrs”


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 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.

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, 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 error statements :

1. On Error Resume Next
2. On Error Go to 0
3. err.number
4. err.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 got to 0 statement disables error handling we have previiously 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 division
 
Function division() 
on error resume next
 
'divide by zero
z=40/0 
 
' Report the  error occured. You can see the error number and description in result summary
   If Err.number <> 0 then  
 
Reporter.ReportEvent micWarning,"Error Occured","Error number is  " &  err.number & " and description is : " &  err.description
 
 'disables error handling 
   on error goto 0 
 
   End if
 
End function