Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 5

eCATT building blocks

17 min

Listen to this lesson

0:00 / 6:28

If you join an SAP program that has been live for a decade, there is a good chance you inherit automated tests built with eCATT, the extended Computer Aided Test Tool that SAP ships inside the ABAP application server. You start it with transaction SECATT (or from the SAP menu under Test, Test Workbench, Test Tools). Before you can judge such a library, you need to read it, and eCATT is easy to read once you know its four object types.

Four objects, one test

SAP's eCATT documentation explains that rather than one object defining every aspect of a test, eCATT has four separate object types. Three are building blocks; the fourth combines them into an executable test case.

Test configurationThe executable test: one test script plus one system data container plus test data (variants). Assigned to test catalogs and plans; produces a log.
Test scriptThe steps: driver commands (TCD, SAPGUI, FUN, WEBDYNPRO, WEBSERVICE...), parameters, checks and inline ABAP.
Test data containerReusable parameters and variants, for example customers, materials and quantities, separated from the script.
System data containerThe landscape: logical target systems mapped to RFC or HTTP destinations.
The four eCATT object types. The test configuration is what actually runs.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-205

System data containers

A system data container maps out the system landscape for a test project. It lists logical target systems, each pointing to an RFC destination or HTTP destination; a target called NONE exists by default. Scripts refer to the logical target, not to a real system, so the same script can run against EQ1 today and CMQ tomorrow by changing the container. SAP's overview is explicit that without a system data container you cannot write test scripts that access other systems.

Scripts name a logical target; the system data container decides which real system it reaches, so moving from EQ1 to CMQ is a container change.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-205

Test scripts and drivers

The test script holds the steps. eCATT offers different drivers (commands), each for a technology, and you can mix them in one script. SAP's documentation describes the main ones and when to use them:

DriverUse forNotes from SAP's documentation
FUNFunction modules and BAPIs (no UI)Preferred for interface tests; fast, efficient, suitable for load testing
TCDClassic transactions without controlsBuilt-in screen simulation; no GUI needed for playback; suitable for load testing
SAPGUITransactions with controls (GUI scripting)Needs a GUI for playback; not suitable for load testing; GETGUI/CHEGUI read and check values
WEBDYNPROWeb Dynpro ABAP or Java applicationsRecording and a simulator for parameterizing UI elements
WEBSERVICEWeb servicesNeeds an ABAP proxy class, which can be generated from a WSDL
External tool interfaceUIs eCATT does not cover itself, such as SAP GUI for HTMLRequires a third-party tool certified against the BC-eCATT interface
eCATT drivers. The driver mix is the first clue to how fragile a library will be.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-205

Test data containers and variants

A test data container holds parameters and variants that many scripts can reuse: a set of customers, materials and quantities, for example. A test configuration references one or more containers (each with a short alias of up to three characters) and defines variants, so one script can run many data combinations. At execution, the start options let you run internal variants or external variants from a file, and a generic filter (such as TEST*) picks which variants run.

One test configuration runs one script many times: once per selected variant, internal or from an external file.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-205

Prerequisites you will meet

  • The client must allow eCATT: in table T000 (maintained via SM31), the field for restrictions when starting CATT and eCATT must permit it.
  • SAPGUI-driver scripts need GUI scripting enabled on the application server (profile parameter sapgui/user_scripting, set in RZ11) and at the front end.
  • Every execution writes a hierarchical log that gives pass or fail and a detailed, permanent record of the run.

What would you do?

Priya opens a test configuration for the order-to-cash flow and sees the system data container points its single target at an RFC destination to EQ1. After the conversion, the script must test CMQ. What is the right change?

Key points
  • eCATT runs in the ABAP stack; start it with SECATT.
  • Four object types: test script, test data container, system data container, and the test configuration that combines them.
  • System data containers map logical targets to RFC or HTTP destinations, so scripts are landscape-independent.
  • Drivers: FUN for function modules, TCD for classic transactions, SAPGUI for controls, plus Web Dynpro, web service and external tools.
  • Prerequisites include client settings in T000 and GUI scripting for SAPGUI scripts.

Check your understanding · not graded

Lesson check

  1. 1. Which eCATT object combines a script, a system data container and test data into an executable test?

  2. 2. What does an eCATT system data container hold?

  3. 3. Which eCATT driver does SAP describe as preferred for interface tests of function modules and BAPIs?

  4. 4. What must be enabled on the application server for SAPGUI-driver scripts?