recovery scenario

7/29/2019 Recovery Scenario

1/14

Error Handling & Recovery ScenarioRecovery 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


2/14

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)


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)




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.


Resources Menu -->Recovery Scenario Manager -->New -->Next -->Select Testrunerror

Window as Trigger event -->Next -->select any error o -->Next -->Next -->(Continue below

mentioned 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 RecoveryOperation -->Next -->(Continue below mentioned steps)


3/14




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.


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 :


4/14

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 dividecall division

Function division()onerrorresumenext

'divide by zero

z=40/0

' Report the error occured. You can see the error number anddescription in result summary

If Err.number 0 then

Reporter.ReportEvent micWarning,"Error Occured","Error numberis " & err.number & " and description is : " &err.description

'disables error handling

onerrorgoto 0

Endif

Endfunction

What are Recovery 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 RecoveryScenarios.

Next question arises,


5/14

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 Users 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 objects 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

QTP Recovery Scenario Function Call

Recovery Scenarios

Automated tests are created mainly to be run unattended, and this raises a few concerns for automation

developers. Assume a situation where you initiated your test-suite while leaving your office to be run over-night.

However, because of unforeseen errors, your test stops at a point and disrupts your results. This is what brings us to

creating Recovery Scenarios in QTP. For demonstration, a Test Run Error for item in list or menu not found is used.

This article discusses a way of creating a Recovery Scenario for an instance where an item in the list item or menu is

not found.


6/14

In this example, we will define a Function Call and use that Function Call to handle the error. The default syntax for

the Recovery Scenario Function is:

Function fnRecovery(Object, Method, Arguments, retVal)

'Error Handling Code

EndFunction

Explanation of each argument tofnRecoveryis given below:

Object as Object: The object of the current step.

Method as String: The method of the current step.

Arguments as Array: The actual method's arguments.

Result as Integer: The actual method's result.

To handle this scenario, we will use the function below:

Function Recovery_ListItemIsNotFound(Object, Method, Arguments, retVal)

Dim sAllItems, arrAllItems, intItem

WithObject

'Retrieve all items from the Listbox

sAllItems = .GetROProperty("all items")

'Split 'all items' using a delimiter ";" into an array

arrAllItems = Split(sAllItems, ";")

'Select a random number

intItem = RandomNumber.Value(LBound(arrAllItems), UBound(arrAllItems))

.Select"#" & intItem

Reporter.ReportEvent micInfo, "ListItemIsNotFound", "Item: " & .GetROProperty("value")

EndWith

EndFunction


7/14

Recovery_ListItemIsNotFound, as the same suggests, executes the Recovery Operation if the list item that we

supplied to our target WebList does not exist. This is quite common in Web applications, and Items in a WebList can

change depending upon the input(s) provided.

To start, Click Resources -> Recovery Scenario Manager. You should see a window like this:

Recovery Scenario Wizard

In the window, click the following button:

Doing so will invoke the Recovery Scenario Wizard:
http://relevantcodes.com/Articles/RecoveryScenario1/OpenRSButton.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/RecoveryScenarioWizard.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/OpenRSButton.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/RecoveryScenarioWizard.PNG


8/14

Recovery Scenario Wizard - Welcome

When the window above opens:

1. Click Next

2. Select Test Run Erroras the Trigger Event

3. Click Next
http://relevantcodes.com/Articles/RecoveryScenario1/1TriggerEvent.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/WelcomeWizard.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/1TriggerEvent.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/WelcomeWizard.PNG


9/14

4. Select Test Run Error: Item in list or menu not found in the Error Listbox

5. Click Next twice and navigate to Recovery Operation
http://relevantcodes.com/Articles/RecoveryScenario1/3DefineRecoveryOperation.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/2SelectTestRunError.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/3DefineRecoveryOperation.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/2SelectTestRunError.PNG


10/14

6. Select Function Call and Click Next

7. Select a library which will store our Recovery Function.

8. Select Define New Function and in the TextArea, paste the function Recovery_ListItemIsNotFound
http://relevantcodes.com/Articles/RecoveryScenario1/5SelectFunctionLibrary.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/4SelectFunctionCall.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/5SelectFunctionLibrary.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/4SelectFunctionCall.PNG


11/14

Define New Function

9. Click Next

10. Make sure Add Another Recovery Scenario Checkbox is not selected and click Next again.
http://relevantcodes.com/Articles/RecoveryScenario1/6RecoveryOperationComplete.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/DefineNewFunction.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/6RecoveryOperationComplete.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/DefineNewFunction.PNG


12/14

11. Under Post-Recovery Test Run Options, select proceed to next step.

12. Give your scenario a name and Click Next

13. And finally, Check the following option:Add Scenario to current testand Click Finish. Save Changes before

closing.

We will use the WebList below to select a value that does not exist in it; so, lets write a code to select Rational

Robot. If you view the items present in the listbox, you will notice that Rational Robot indeed doesnt exist, but our

Recovery Scenario will handle the error when we select it. Instead, it will select a random value from the list.

Browser("title:=.*Recovery Scenario.*").Page("micclass:=Page")_

.WebList("name:=testTools").Select"Rational Robot"
http://relevantcodes.com/Articles/RecoveryScenario1/8RecoveryScenarioName.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/7ProceedToNextStep.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/8RecoveryScenarioName.PNGhttp://relevantcodes.com/Articles/RecoveryScenario1/7ProceedToNextStep.PNG


13/14

MsgBox "Item Selected: " & Browser("title:=.*Recovery Scenario.*").Page("micclass:=Page")_

.WebList("name:=testTools").GetROProperty("value")

When the code above executes, you will notice that, instead of throwing a Test Run Error, a random value from the

list box was selected. You will know that the Recovery Scenario was triggered and ran successfully when you view

the Test Results:

Recovery Scenario Executed

There are plenty of other scenarios as well, and I will try to cover some of the important ones. If you have any

suggestions, or a scenario that you would like me to cover first, please use the comments section of this post to

share your ideas/thoughts with me. Thanks! :)

All about Recovery Scenarios using QTP

While executing scripts, we usually encounter unexpected & unpredictable events &errors, which results into application crashing during a run session causing total

disruption of the run session and distortion of results. Such problems are quite frequent

especially when the tests are made to run unattended. In such a case the test process

halts until the user perform some desired recovery operation.

Recovery scenarios are useful when it is difficult to predict at which step the errors can come or when we are

confident that the error will not come in the QTP script, whereas it can be anywhere outside the QTP Script. For

illustration; Pop-up message of "out of paper", as caused by the printer device driver. "On error resume next"

is preferred when we sure that the error is expected one and wish to perform some other actions.

In order to handle such situations QTP comes to our rescue by creating recovery scenarios and associates them

with the particular tests. What does a Recovery Scenarios do is to activate a specific recovery operation when a

trigger events takes place. Most simple example of a typical unexpected & unpredictable events & errors is like

Incompatible Media in portable Drive.

The Recovery Scenario Manager presents a structured wizard which helps us in defining

the recovery scenario, like detailed definition of the unexpected event and the operations

required to recover from the exception during the run session.

Advantages of Recovery Scenario Manager: Recovery Scenario Manager can be used to

handle several known errors occurring at runtime. Following four events available in the

recovery scenario manager are extremely helpful

1) Application Crash: This event is useful in handling crashed applications at runtime.
http://www.softwaretestinggenius.com/articals.php?mode=details&qry=153&parent=112http://www.softwaretestinggenius.com/articals.php?mode=details&qry=153&parent=112http://relevantcodes.com/Articles/RecoveryScenario1/ScenarioExecuted.PNGhttp://www.softwaretestinggenius.com/articals.php?mode=details&qry=153&parent=112


14/14

2) Pop Up Window: This event is useful in managing various unwanted application

windows, which get built-up at runtime.

3) Test Run Error: This event is useful in handling VBScript statement errors at

runtime.

4) Object State: This event is useful in handling object related errors at runtime.

Elements of Recovery Scenario: Steps to handle the exceptions are

1) Trigger Event: Is an unexpected event like appearance of a Pop-up window, object

state, test run error causing application crash or interruption in our running session.

2) Recovery Steps: Constitutes a series of steps required to be performed to enable

QTP to proceed further with the process of test after some trigger event has interrupted

the run session. Examples of a recovery operation can be 1) A keyboard or mouse

Operation like a Click over the "OK" button in the Pop-up window 2) Close Application

Process 3) Function Call 4) Restarting the OS etc.

3) Post-Recovery Test Run: Are a set of instructions designed to be provided to QTP

on proceeding further with the test after some recovery operation has been carried out.

Examples of Post Recovery actions can be repeating the complete test from the

beginning or some steps may be skipped altogether & continuing with the remaining

steps in the test.

QTP & Recovery Scenarios:

All Recovery scenarios get saved & logically grouped in recovery scenario files. Grouping

of various recovery scenarios in recovery scenario file can be managed according the

user requirements. Recovery scenario files carry a typical extension of .rs.

In order to instruct QTP to carry out a recovery scenario during a particular test run, we

firstly associate it with the particular test. There is no limitation to any fixed number of

recovery scenarios associated with a test. Order of execution of various recovery

scenarios associated with a test can easily be prioritized, thereby the trigger events get

recognized and handled in the desired sequence.

Whenever any error comes during the execution of a test having many recovery

scenarios associated with it; QTP intelligently hunts for the defined trigger event which

had caused the particular error. After detecting the trigger event, QTP automatically

performs the desired recovery steps and post-recovery test runs etc.

Recovery statements can be inserted in the tests to comfortably control and activate the

recovery scenarios during the test run.

Cons of Recovery Scenarios:

Although Recovery Scenarios are users friendly on one hand; they tend to slow down the

speed of the Test Run. Presence of a few such recovery scenarios would reduce the

speed of Test Run significantly. This can become irritant to the testers, who can prefer

the approach of using VBScript On Error/Goto 0 far more useful for catching & handling

small errors.

recovery scenario

Documents