Mastering eCATT: An In-depth Guide to SAP’s Extended Computer Aided Test Tool

SAP Extended Computer Aided Test Tool (eCATT) is a built-in graphical interface testing tool for SAP system, allowing to test an entire business process. The software has an ABAP script editor and allows to test modules that are supposed to be recorded and parameterized. Each test generates a detailed log that documents the test process and results.

eCATT enables automatic testing in SAP GUI for Windows and SAP GUI for Java. In order to offer a complete test solution that covers other GUIs, eCATT has interfaces to third party tools.

An SAP Web Application Server is needed to execute eCATT. The essential elements of a test case include test scripts, a system data container with the relevant RFC connections, and a test data container with test variants. Finally, in the test configuration, the three mentioned elements are encapsulated into a coherent test case.

The graphic below summarizes the development process and illustrates the role played by the different eCATT objects.

^{Process steps}

1. Define what you want to test within the scope of your project and make sure that the test system and the systems to be tested are prepared for use with eCATT.
2. Create a system data container in which you map out the system landscape for the project. Without a system data container, you cannot write test scripts that access other systems.
3. Create the test scripts themselves.
4. Consider the data that you will need to run the tests and arrange it in test data containers to allow the maximum degree of reuse and to eliminate as much redundancy as possible.
5. Assemble the test configurations from the other eCATT objects.
6. Test configurations can be assigned to test catalogs and test plans within the Test Workbench. The configurations can then be assigned to individual users for testing.
   An executed test configuration outputs its results in the form of a log. The log provides not only a message about the successful or failed execution of the full test, but also a permanent and detailed record of the test.

The graphic below shows how the various eCATT objects work together.

The test script defines the actions to be executed. The system data container provides the system mapping that determines the systems affected by the commands. The system data container of the test configuration overrides all other system data containers.

^{Transaction for using eCATT}

- Choose SAP menu-> Test -> Test Workbench -> CATT -> Extended CATT
- Transaction code -SECATT

^{Editors Available In eCATT From SECATT Transaction}

• Test Configuration Editor:

Used to maintain Test Configuration object. Test Configuration data object contains set of reference to a Test Script, System Data Container & several Test Data Containers. It contains all the information necessary to run an automatic test without further user interaction.

• Test Script Editor:

Used to create & maintain Test Scripts. There are some recording functions available in this editor. Test Script Editor has following areas:

• Application Toolbar
• Information Area
• Editor Tab:
  - Parameter List
  - Command Editor
  - Structure Editor
• Attribute Tab

Test script data object contains an executable script and an interface for data transfer.

• Test Data Editor:

Used to create & maintain the Test Data Containers. Test Data Containers are the data objects, which contain a set of parameters that can be maintained independently of a test script. Parameters can be ABAP simple types, structures, or tables.

• System Data Editor:

Used to create & maintain the System Data Containers. System Data Containers are data objects that identify instances of SAP systems. They can be maintained independently of the test script like Test Data Containers.

^{The first step in creating a test case is creating a test script}

Test script consists of three principal parts:

• Its attributes
• script commands
• parameters – only parameters that are expected to take values at runtime should be defined

The test script has mandatory attributes (title, package, person responsible, and application component) as well as attributes containing administrative information. Two important attributes are the maintenance system and the versioning information. System data container needs to be assigned in the maintenance attributes to enable the test script to address the system landscape during development.

A test script can exist in several versions and the validity of a test script for testing a given system is determined by the versioning information.

The import and export parameters define the interface of the test script so that values can be passed to and from the script. It’s also possible to create local variables that are only used within the test script.

The commands describe the test. Typically, a script contains one or more recorded transactions with the associated checks and calculations but it need not to do so. For example, it could contain just some useful functionality that can be referenced from another script, or it could contain a series of references to other scripts to build a more complex test out of reusable units.

^{The second step in creating a test case is creating a test data container}

In eCATT, the bulk of the test data is normally stored separate from the test scripts in test data containers. The main reasons for this are reusability and maintainability. Test data containers and a test script are brought together in test configuration to create an executable test case.

The Parts of a Test Data Container

Data containers consist of parameters and variants. The parameters describe the interface of the container and the variants store the data. You define the parameters in the same way that you define the parameters in a test script with the difference that there is no visibility field ­- that is, defining the parameters as import or export makes no sense here. If a parameter is structured, you can display and edit in the structure editor.

Each variant contains a field for each parameter. If no value has been entered in a field, the value specified in the ECATTDEFAULT is the value of the field.

After creation of Test Data Container, the parameters  in the test script are assigned to the Input values/output values .

^{The last step in creating a test case is creating the test configuration}

Although test scripts can be executed alone inside the eCATT development environment, this is normally only done during test development or troubleshooting. Test scripts can, and often do, contain default test data.

However, a complete test case is represented by a test configuration, and it is test configurations that can be executed from the Test Workbench.

The graphic below shows the main components of a test configuration. As with other eCATT objects, the test configuration has mandatory attributes (title, package, person responsible, and application component) as well as attributes containing administrative information. At the core of the test configuration is the test script. Each test configuration references exactly one test script and the default variant is defined by the import parameters of the test script.

The test script defines the importing parameters that make up the variants. The test data containers provide the bulk of the test data. The names of parameters defined in the test data containers do not need to be the same as those in the test configuration, although it can be convenient to arrange it so. There is considerable flexibility in building up variants. In one variant, you can link to fields in several different test data containers, manually enter values in other fields, and leave yet other fields empty to be filled with the default values.

You also have the option of assigning start profile test run parameters to test configuration variants. These parameters are transferred once, globally for the whole test run, irrespective of whether you start a single test configuration or an entire test package with multiple test configurations. These parameters can also be provided with other runtime values before the test package or test configuration is executed.

^{Executing test configuration}

Each execution generates a detailed log that documents the test process and results. The log is hierarchically structured according to the test script used, and is displayed as a structure with nodes.

If execution has been interrupted (for example, using the eCATT debugger or execution control), this is clearly marked at the highest level in the log.

‍