首页 > Linux操作系统 > Linux操作系统 > Deciding When to Use Recovery Scenarios

Deciding When to Use Recovery Scenarios

原创 Linux操作系统 作者:ipqiaojj 时间:2009-03-17 10:57:32 0 删除 编辑

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 component. 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 component. 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 a user-defined function immediately after a step that sends a file to the printer, your component 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 component, it is highly recommended to handle that event directly within your component by adding steps such as If statements in user-defined functions, 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 in a user-defined function that clicks OK if the message box opens.

Handling an event directly within your component 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 component. 

来自 “ ITPUB博客 ” ,链接:,如需转载,请注明出处,否则将追究法律责任。



  • 博文量
  • 访问量