Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Showing posts with label Recovery Scenario In QTP. Show all posts
Showing posts with label Recovery Scenario In QTP. Show all posts

Recovery Scenarios In QTP10.0


Recovery Scenarios Enhancements :

81. Recovery scenarios (RS) to run in a separate thread. Currently recovery scenarios run in the same thread as QTP. This causes recovery scenarios to be useless in case a Modal dialog blocks QTP.

82. Option to stop chaining in recovery scenarios. Currently if RS1 and RS2 both match the trigger criteria then both of the scenarios are executed. There is no way to specify that RS2 should not be executed if RS1 is executed.


83. Currently there is no way to enumerate recovery scenarios present in a File.


84. Recovery scenarios don’t work when they are associated at run-time.


85. Ability to test the RS trigger from the UI. This would help debug in debugging the issues when recovery scenario does not get fired

Post-Recovery Test Run Options Screen In QTP

Post-Recovery Test Run Options Screen In QTP


When you clear the Add another recovery operation check box in the Recovery Operations Screen and click Next, the Post-Recovery Test Run Options screen opens. Post-recovery test run options specify how to continue the run session after QuickTest has identified the event and performed all of the specified recovery operations.

QuickTest can perform one of the following run session options after it performs the recovery operations you defined:

  • Repeat current step and continue
  • The current step is the step that QuickTest was running when the recovery scenario was triggered. If you are using the On error activation option for recovery scenarios, the step that returns the error is often one or more steps later than the step that caused the trigger event to occur.
    Thus, in most cases, repeating the current step does not repeat the trigger event. For more information, see Enabling and Disabling Recovery Scenarios.

  • Proceed to next step
  • Skips the step that QuickTest was running when the recovery scenario was triggered. Keep in mind that skipping a step that performs operations on your application may cause subsequent steps to fail.

  • Proceed to next action or component iteration
  • Stops performing steps in the current action or component iteration and begins the next iteration from the beginning (or from the next action or component if no additional iterations of the current action or component are required).

  • Proceed to next test iteration
  • Stops performing steps in the current action or and begins the next QuickTest test or business process test iteration from the beginning (or stops running the test or component if no additional iterations of the test or component are required).

  • Restart current test run
  • Stops performing steps and re-runs the test or component from the beginning.

  • Stop the test run
  • Stops running the test or component.
    Note: If you chose Restart Microsoft Windows as a recovery operation, you can choose from only the last two test run options listed above.

Select a test run option and click Next to continue to the Name and Description Screen.


Trigger Event Handling in QTP

Select Trigger Event Screen In QTP Automation Testing


The Select Trigger Event screen enables you to define the event type that triggers the recovery scenario, and the way in which QuickTest recognizes the event. 


Select a type of trigger and click Next. The next screen displayed in the wizard depends on which of the following trigger types you select:

  • Pop-up window. QuickTest detects a pop-up window and identifies it according to the window title and textual content. For example, a message box may open during a run session, indicating that the printer is out of paper. QuickTest can detect this window and activate a defined recovery scenario to continue the run session.
  • Select this option and click Next to continue to the Specify Pop-up Window Conditions Screen.

  • Object state. QuickTest detects a specific test object state and identifies it according to its property values and the property values of all its ancestors. Note that an object is identified only by its property values, and not by its class.
  • For example, a specific button in a dialog box may be disabled when a specific process is open. QuickTest can detect the object property state of the button that occurs when this problematic process is open and activate a defined recovery scenario to close the process and continue the run session.
    Select this option and click Next to continue to the Select Object Screen.

  • Test run error. QuickTest detects a run error and identifies it by a failed return value from a method. For example, QuickTest may not be able to identify a menu item specified in the method argument, due to the fact that the menu item is not available at a specific point during the run session. QuickTest can detect this run error and activate a defined recovery scenario to continue the run session.
  • Select this option and click Next to continue to the Select Test Run Error Screen.

  • Application crash. QuickTest detects an application crash and identifies it according to a predefined list of applications. For example, a secondary application may crash when a certain step is performed in the run session. You want to be sure that the run session does not fail because of this crash, which may indicate a different problem with your application. QuickTest can detect this application crash and activate a defined recovery scenario to continue the run session.
  • Select this option and click Next to continue to the Recovery Operations Screen.
    Notes:

    • The set of recovery operations is performed for each occurrence of the trigger event criteria. For example, suppose you define a specific object state, and two objects match this state, the set of recovery operations is performed two times, once for each object that matches the specified state.

    • The recovery mechanism does not handle triggers that occur in the last step of a test or component. If you need to recover from an unexpected event or error that may occur in the last step of a test or component, you can do this by adding an extra step to the end of your test or component.

When To Use Recovery Scenarios

Deciding When to Use Recovery Scenarios


Recovery scenarios are intended for use only with events that you cannot predict in advance, or for events that you cannot otherwise synchronize with a specific step in your test. For example, you could define a recovery scenario to handle printer errors. Then if a printer error occurs during a run session, the recovery scenario could instruct QuickTest to click the default button in the Printer Error message box.

You would use a recovery scenario in this example because you cannot handle this type of error directly in your test. This is because you cannot know at what point the network will return the printer error. Even if you try to handle this event by adding an If statement in your test immediately after a step that sends a file to the printer, your test may progress several steps before the network returns the actual printer error.

If you can predict that a certain event may happen at a specific point in your test, it is highly recommended to handle that event directly within your test by adding steps such as If statements or optional steps, rather than depending on a recovery scenario. For example, if you know that an Overwrite File message box may open when a Save button is clicked during a run session, you can handle this event with an If statement that clicks OK if the message box opens or by adding an optional step that clicks OK in the message box.

Handling an event directly within your test enables you to handle errors more specifically than recovery scenarios, which by nature are designed to handle a more generic set of unpredictable events. It also enables you to control the timing of the corrective operation with minimal resource usage and maximum performance. By default, recovery scenario operations are activated only after a step returns an error. This can potentially occur several steps after the step that originally caused the error. The alternative, checking for trigger events after every step, may slow performance. For this reason, it is best to handle predictable errors directly in your test.

For more information on optional steps, see Using Optional Steps. For more information on inserting programming statements such as If statements, see Adding Steps Containing Programming Logic.

Defining and Using Recovery Scenarios In QTP

About Defining and Using Recovery Scenarios


Unexpected events, errors, and application crashes during a run session can disrupt your run session and distort results. This is a problem particularly when tests run unattended—the test pauses until you perform the operation needed to recover. To handle situations such as these, QuickTest enables you to create recovery scenarios and associate them with specific tests. Recovery scenarios activate specific recovery operations when trigger events occur. For information on when to use recovery scenarios, see Deciding When to Use Recovery Scenarios.

The Recovery Scenario Manager provides a wizard that guides you through the process of defining a recovery scenario, which includes a definition of an unexpected event and the operations necessary to recover the run session. For example, you can instruct QuickTest to detect a Printer out of paper message and recover the run session by clicking the OK button to close the message and continue the test.

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 QuickTest run error.
  • Recovery Operations. The operations to perform to enable QuickTest 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 QuickTest should proceed after the recovery operations have been performed, and from which point in the test QuickTest 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. A recovery scenario file is a logical collection of recovery scenarios, grouped according to your own specific requirements.

To instruct QuickTest to perform a recovery scenario during a run session, you must first associate the recovery scenario with that test. A test can have any number of recovery scenarios associated with it. You can prioritize the scenarios associated with your test to ensure that trigger events are recognized and handled in the required order. For more information, see Adding Recovery Scenarios to Your Test.

When you run a test for which you have defined recovery scenarios and an error occurs, QuickTest looks for the defined trigger events that caused the error. If a trigger event has occurred, QuickTest performs the corresponding recovery and post-recovery operations.

You can also control and activate your recovery scenarios during the run session by inserting Recovery statements into your test. For more information, see Programmatically Controlling the Recovery Mechanism.

Note: If you select On error in the Activate recovery scenarios box in the Recovery pane of the Test Settings dialog box, the recovery mechanism does not handle triggers that occur in the last step of a test. If you chose this option and need to recover from an unexpected event or error that may occur in the last step of a test, you can do this by adding an extra step to the end of your test.