BASE I Recovery

Recovery means the ability of a test tool to react to unexpected situations in the test execution without aborting tests. Efficient recoveries usually require test object-specific adaptations. Recoveries can be executed on all operational layers of the business-based object model, i.e. on TestCase, TestAction and ParamAction layer.

Recovery settings can be specified via the start screen of Tosca Executor (see chapter "Run Classic tests with Tosca Executor").

As regards execution, the recovery is always structured the same way:

  1. At first a layer-specific recovery script is executed. Recovery scripts are VB script file, from a technical point of view. For further information on VB scripts see chapter "BASE I Keywords". If no specific script exists, a standard process is performed (see chapter "Typical actions of recovery scripts").

  2. Subsequently Tosca optionally tries to execute the test object (TestCase, TestAction and ParamAction) again.

  3. The recovery script and the optional re-execution of the test object is called recovery scenario.

    • After a successful execution of the recovery scenario, the test execution continues.

    • If it is not possible to recover successfully, the execution continues with an exception on the TestCase layer and processes layer-specific recovery scripts.

In case of Error 20000 error messages there will be no recovery (see chapter "Program errors").

Example: Exception on the ParamAction layer

  1. In this example, an exception appears when a logical control is steered. This exception leads to the execution of the recovery script on the ParamAction layer. (For an overview of typical actions see table "Control").

  2. According to the specified settings, the control is steered again.
    This setting is especially recommended for thin client applications, where the visualization of controls may be delayed due to heavy load on the server. In this case a repeated steering attempt will result in a correct test progress.

  3. The recovery action is logged.

  4. If the re-execution of the ParamAction was successful, the test execution continues. Otherwise, an error is raised (see chapter "BASE I Exception handling"), which leads to an recovery on the TestCase layer.

    The recovery on the TestAction layer is not started, because it cannot be successful with an insolvable ParamAction problem.

Schematic recovery process. Exception on ParamAction layer

Example: Exception on the TestAction layer

  1. In this example an exception appears when a logical control is steered. As a result, the recovery script is executed on the TestAction layer.

  2. The recovery action is logged.

  3. If the re-execution of TestAction was successful, the test execution continues. If an error is raised, the recovery is started on the TestCase layer.

Schematic recovery process. Exception on TestAction layer

Typical actions of recovery scripts

Layer

Verification error (layer 1)

Dialog error (layer 2)

Program error

TestCase

<no recovery>

The application is restarted and reset to its initial state.

Start the application and return to initial state.

TestAction

<no recovery>

1. A screenshot is made and saved.

2. A standard popup window is responded to if required.

Recovery attempt on the TestCase layer (no proper recovery)

ParamAction

<no recovery>

1. A screenshot is made and saved.

2. A standard popup window is responded to if required.

Recovery attempt on the TestCase layer (no proper recovery)

 

Recovery in the engine object model

  • RecoHandler is the central object. It is derived in some engines.

  • The test execution is processed by engine objects (see chapter "Executing business-based objects"). The engine object uses the ExecLib to find out, whether a recovery is needed or not. The next steps depend on the given recovery settings and the exception layer.

  • Empty recovery scripts for the following layers are part of the Tosca Base Engine: TestCase (REC_TC.vbs), TestAction (REC_TA.vbs) and ParamAction (REC_PA.vbs). These scripts allow the adjustment of an application-specific recovery, without having to derive a separate recovery handler.

Recovery object in engine object model

Technical process of recovery

The following illustrations show the technical process of recovery, beginning with the steering command execParamAction() based on kwdHandler. We assume that the control to be steered cannot be found, which means that connectToRepresentation() fails and an exception of layer 2 (dialog error) is raised:

Technical process of recovery, part 1

  1. connectToRepresentation() raises the exception.

  2. The kwdHandler has to check, whether a recovery is required or not by starting ExecLib.doRecover().

  3. ExecLib decides as follows:

    • getLastExceptionRaised … Request last exception

    • Compare exception layer of the latest exeception with currently active recovery settings

    • Find out if the maximum number of retries has already been exceeded.

The result is returned as True/False and starts the recovery if the result is True.

  1. The engine checks whether a special recovery script or a standard recovery shall be applied.

  2. If a special recovery script exists, it is executed.

The recovery script REC_PA.vbs is a VB script file, where the steering commands are entered. The use of VB script files for customizing controls is described in chapter "BASE I Keywords".

  1. If no special recovery script exists, the default recovery is executed. For an overview of default recoveries see chapter "Typical actions of recovery scripts".

Technical process of recovery, part 2