Expand +



eCATT — The New Test Tool for Your E-Business Solution

by Jonathan Maidstone | SAPinsider

July 1, 2002

by Jonathan Maidstone, SAP AG SAPinsider - 2002 (Volume 3), July (Issue 3)

One thing that probably all SAP projects have in common is that they have to be tested. Whether you’re working on a big-bang implementation for a multinational company, applying the latest legal changes to mySAP HR in a single country, performing a regression test for a release upgrade, or rolling out a major in-house development, you need to ensure that the changeover in your production system will be as smooth as possible.

Essentially, there are two ways to test software. You can either assemble a group of living, breathing human beings and make them work through test plans, or you can try to automate the test process as far as possible. For usability testing, your team of human testers is irreplaceable, of course. But for functional testing (e.g., checking that business process transactions are functioning properly once you apply Customizing settings), automated testing provides numerous benefits: your test scripts can be run over and over again — and without demoralizing a human tester! Most test tools will also collate test results automatically, giving the test administrator a real-time overview of the state of play — what has been tested, and with what degree of success.

There are various tools for automated testing available on the market, many of which can be used to test SAP applications. However, these tools all work by harnessing the SAP GUI — recording the user’s entries when you create the test script, and playing them back at runtime. As such, these tools have no access to what is happening within the SAP application server during the test. This means that while it is possible to follow a transaction, or sequence of transactions, from start to successful (or unsuccessful) finish, there are only limited opportunities to check things along the way — like the value of a particular screen field, or even whether certain data has been written to the database successfully!

The Evolution from CATT to eCATT

The tool in the best position to cover the entire transaction has been SAP’s own test tool, the Computer Aided Test Tool (CATT), available since R/3 Release 3.0 as part of the Basis system. With CATT, you could take a look inside the applications and check various elements, such as variables, messages, and table contents. You could also simulate changes to Customizing settings without having to make them hard and fast in your system, allowing you to create very elaborate tests before resetting your original Customizing settings with a single command.

In recent R/3 releases, however, CATT has been unable to test certain features that have become standard in the SAP landscape. For example, the controls technology for developing more powerful, user-friendly interfaces introduced in Release 4.6 uses techniques that are incompatible with CATT testing. Increasingly, too, business processes reach across system boundaries. Sales orders entered in a CRM system may be relayed to an R/3 system, which in turn communicates with an APO system before the production planning is finally fixed. While it is possible to test such business processes with CATT, managing test cases in various systems could be difficult as the number of test cases and different systems starts to increase.

In view of these limitations, Release 6.20 of the SAP Web Application Server (Web AS) contains a new test tool to assist SAP customers working in Release 4.6C and up: the Extended Computer Aided Test Tool or eCATT.

The main features of eCATT are:

  • Improved test support for distributed systems

  • Test support for controls technology

  • A new and improved user interfacen Support for external testing tools and applications

  • A new management concept for test data

Let’s look at each of these five points in a little more detail.

Improved Test Support for Distributed Systems

In CATT, remote execution of test procedures was possible, but not always particularly convenient. The most frequently used solution was to store the test procedures remotely in the target systems and to call them from a central script, which led to the problem of keeping track of all of those scripts across various systems!

Figure 1 compares that approach to eCATT’s new process for remote script execution. All test scripts are created and maintained in a designated system, but they can be executed in any system running Release 4.6 or higher that is accessible using RFC. A separate eCATT object, called a system data container, contains a list of all of the target destinations that a script needs to address.

Figure 1 Comparison of Script Management Techniques in CATT and eCatt

Test Support for Controls Technology

One of the major problems of using CATT to test R/3 4.6C systems has been the lack of adequate support for controls.1 The reason for this lies in the nature of the controls themselves and the existing CATT architecture. At runtime, CATT procedures are executed wholly on the application server, that is, with no associated SAP GUI instance. However, for controls to function correctly, they must be instantiated at the frontend within a running SAP GUI. Consequently, CATT is unable to record or play back control data adequately.

In eCATT, this has been remedied by the new SAPGUI command, which uses a new scripting engine within the SAP GUI to record a user’s on-screen actions. This recorded data is stored in a test script and can be parameterized and replayed in much the same way as a conventional transaction call, thus opening up many more SAP applications to automated testing.

New, Improved User Interface

While SAP has been extending the scope of eCATT to include transactions that use controls, the development team has also made extensive use of the same technology to create a new user interface for eCATT. Compared with the CATT user interface, it is now easier to use and more compact — as Figure 2 shows, you can now edit your script commands and parameters all on the same screen.

Figure 2 eCATT Script Editor

A structure editor also allows you to display and edit structured parameters, such as internal tables for function modules, the structure of screens and fields within a transaction, or ABAP Dictionary structures.

Integration with Third-Party Testing Tools

eCATT contains a new interface allowing vendors of third-party test tools to integrate their tools with the eCATT environment. This integration allows you to use eCATT in conjunction with an external tool to test applications that cannot otherwise be tested using “pure” eCATT means, such as any applications with user interfaces written in HTML, Swing, Visual Basic, and so on. Scripts created using the external tool can be stored centrally in the SAP database, transported through your test landscape using the SAP Change and Transport System, and called from any eCATT script.

New Management Concept for Test Data

In CATT, the data that you used for a test was stored together with the test procedure itself in the form of a variant. This meant that test data couldn’t be reused — but how many test procedures do you have that first require you to create the same sets of master data? Probably a lot.

In eCATT, this concept has been changed, and data is now stored separately from test scripts in special objects called test data containers. The advantage of using separate data containers is that the data becomes available to any script that needs it.

To create an executable test (shown back in Figure 1), you use an object called a test configuration, which is the combination of a test script, a test data container, and a system data container (the list of target systems that will be addressed by that script).


eCATT is available with the SAP Web Application Server Release 6.20. Patches will also be available for previous releases from Release 4.6C onward to enable you to use the SAP Web AS 6.20 as a central test system, from which you can run tests in other systems.

As you can see in Figure 3, only the central test system requires Release 6.20. So, long before you upgrade your other solutions to a release based on Web AS 6.20, you could use a standalone SAP Web AS to take advantage of the new features offered by eCATT.

Figure 3 Using the SAP Web AS 6.20 as a Central System to Test Existing Solutions

For more information on getting started with eCATT, consult the documentation for Release 6.20 of the Web Application Server under

Migrating Existing CATT Procedures

An important consideration for many customers who have invested a lot of time and money in building up CATT tests is Can I migrate from CATT to eCATT? The answer is a resounding Yes!

In addition to the new features described here, eCATT also includes a migration tool that converts CATT test procedures into eCATT test scripts. Much of the conversion is automatic, although there are certain conventional CATT techniques (such as dynamic changes to RFC destinations during a procedure) that will have to be manually adjusted after the conversion.

1For more information on controls technology in R/3 4.6B and up, see the book Controls Technology, available from SAP at See also the June 2000 issue of SAP Insider in the Article Archives, and the article “SAP Controls Programming Essentials — What Every ABAP Developer Now Needs to Know” in the November/December 2001 issue of SAP Professional Journal (

A graduate in modern languages from the University of Bristol (UK), Jonathan Maidstone joined SAP in Walldorf in 1996 and worked as a translator for the ABAP Workbench and ABAP language groups until late 1999. Following a spell as a technical writer for the SAP Control Framework and DCOM Connector groups, he is now part of the product management group for Business Programming Frameworks, with particular responsibility for eCATT rollout. Jonathan can be reached at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!