BASE I Specific technologies

The steering requirements of test targets differ significantly depending on the technology, with which the GUI of the test target was created. Thus the base engine does not contain its own application steering. The actual application steering is conducted by specific engines (adaptors) and included in the engine environment.

From a technical point of view a specific engine is a VB-OCX. Generally a specific engine comprises two groups:

  • Specific objects for steering screens and controls

  • Specific objects for scanning definition screen and control data (for the extension of the wizard)

Specific technologies and the layers of engine ObjectModels

The central element of the integration of specific engines is the ObjectServer in the base engine. It creates the requested objects by using class names (using CreateObject and not New). Thereby it is possible that specific engines may pass on their replacement of engine classes (because the specific replacements are instantiated by the ObjectServer).

Business-based layer and specific engines

Technology-specific derivations of TestSet, TestCase, TestAction or ParamAction are not needed. Thus the creation of these objects is not carried out with the ObjectServer.

Definition layer and specific engines

The definition layer is not derived in most adaptors. Derivations happen for example in the HOST engine (HOSTMap, HOSTFieldDef), where in some cases additional Row/Column information is needed to mark logical screens and controls.

Representation layer and specific engines

The representation layer of the engine ObjectModel is always derived in the specific engines: In practice, derivations of the PARep base class are generated for each control type to cover the steering requirements.

Derivation of PARep for the example SAP engine

Consideration of specific derivations – ObjectMappings.dat

Specific requirements need to be recognized in the instantiation request by the Engine.ObjectServer. They have to be listed in the file ObjectMappings.dat.

The position of this file is specified under Engine->Class Mapping Path in the engine Settings dialog (see chapter "Settings - Engine").

The file has an INI structure, which is organized according to the engines. In the following chapters the entries in ObjectMappings.dat are described.

Registration on the layer of specific engines

The category settings for specific engines are specified in an own section in the file ObjectMappings.dat.

Syntax:

[<ENGINE NAME>]

Example - HTML:

[HTML]
controlDefClassName=HTMLEngine.clsHTMLControlDef
objectMapClassName=HTMLEngine.clsHTMLObjectMap
 
handlerClassName=HTMLEngine.HTMLKWDHandler
recoveryClassName=HTMLEngine.clsHTMLReco
 
taRepresentationClassName=HTMLEngine.HTMLBrowser

Excerpt from ObjectMappings.dat

The following keys are identified. If keys are left out in a section, the Engine-ObjectServer uses the base classes.

  • controlDefClassName

    Class name of the replacement of ControlDef. This class will later contain the definition information of the control layer.

  • objectMapClassName

    Class name of the replacement of GuiMap. This class will later contain the definition information of the screen layer.

  • handlerClassName

    Class name of the handler for keywords that has to be used. This is the replacement of the kwdHandler (see chapter "Executing business-based objects").

  • recoveryClassName

    Class name of the Recovery handler that has to be used (see chapter "Technical process of recovery").

  • taRepresentationClassName

    Class name of the TestAction representation class that has to be used.

The process is described in the following illustration:

Process of identifying the suitable class name

  • If a TestAction has to be executed, loadDefinition() (see chapter "Executing business-based objects") and afterwards ObjectServer.loadMap() is loaded to read the definition data. In the tag <GuiMap> the ObjectMap file contains the central information, which specific engine shall be used for steering (in Illustration "Process of identifying the suitable class name" is the name of the engine HTML) in the form of the attribute ScreenType.

  • Subsequently, the screenType is passed on to the ObjectServer for each instantiation request, to enable the identification of the class names in the right section.

Registration on the layer of individual control types

In further sections the class names for the different control types are listed. The names of the sections to be used are read while the definition objects are loaded from the ObjectMappings.dat. They are part of the attribute TypeInfo of the <Control> tag.

ObjectMappings.dat

  • paRepresentationClassName

    describes the class names of the representation class (of the PARep replacement).

  • omTranslationName

    specifies the logical type identifier, which shall be used for the export of business-based test cases from Tosca Commander™ to a Word document.

[HTMLComboBox]
paRepresentationClassName=HTMLEngine.HTMLComboBox
omTranslationName=ComboBox

Selection of a specific engine for the screen analysis – WizardMappings.dat

To include a specific engine in the work with the Wizard, it has to be registered under WizardMappings.dat.

The position of this file is specified under Wizard->Class Mapping Path in the Tosca Commander™Settings dialog (see chapter "Settings - Engine").

WizardMappings.dat

The section name indicates, how the wizard identifies that a specific engine shall be used. The following types of identification are possible:

  • Process name (exe-Name)

    Name of the process, which the screen is assigned to. The recognition, that the process name has to be used for identification, happens by the file extension.EXE.

  • Class name

    Class name of the main window, which contains the screen. The recognition, that the class name has to be used for identification, happens by the prefix Class

    Example:[Class=Centura*]

For the specification of class names Wildcards may be used.

Optionally, several sections can refer to the same engine specification

Example: SAP is identified by SAPLOGON.EXE or SAPLGPAD.EXE. Thus two sections are created.

  • EnginePrefix

    is used as a prefix for the naming of newly created ObjectMaps.

  • EngineName

    is displayed in the Wizard header as part of the caption.

  • UserControlRepresentationClassName

    is the class name of the specific control, which shall be used for reading the control information from the screen to be analyzed.

If one of these entries is missing, the complete section is not loaded. (Entries, which are commented out, are not considered).

[SAPLOGON.EXE]
EnginePrefix=SAP
EngineName=SAPEngine
UserControlRepresentationClassName=SAPEngine.SAPDetailsPage

If you extend the file Wizardmappings.dat, please make sure that the setting Log Level is set to Code Debug, so that the information can be written to the log file. The path to the log file can be specified via the setting Path to Logfile Directory.

Comments

To comment out entries in Wizardmappings.dat, please add a semicolon ; to the beginning of the line to be commented out.

Selection of a specific engine for the steering – WinClassMappings.dat

This file can be modified only after consulting the Tricentis Support.