ECATTs – The Basics Part 1.

by | Mar 12, 2009 | Enterprise Project Management, NetWeaver

This will be the first in a series of blogs that will hopefully introduce you to eCATTs  and explain the various important eCATT objects and how to use them. In this first blog I will cover:

  1. What is an eCATT?.
  2. Pre-requisites and settings required before using eCATTs.
  3. Introduce the four important eCATT objects – Test Configuration, Test Data Container, System Data Container and Test Script.

1. What is an eCATT?

The extended Computer Aided Test Tool (eCATT) is a tool that allows users to create and execute functional tests for the majority of applications running on SAP Gui for Windows and SAP Gui for JAVA. Similar to most other automated testing tools eCATTs function by recording the application or process being tested and then allows you to parameterize the data being used. You then have the ability to take this parameterized data and create data sets to test various scenarios.  Furthermore, because eCATTs are embedded within the SAP application server, they have access to other interfaces such as Function Modules, BAPIs, and the SAP database and the ABAP runtime so that users can now write ABAP routines within their test scripts. Existing test cases from the older CATT tool can be migrated to take advantages of the better features provided by eCATTs. eCATT is also now integrated with the Object Navigator SE80. The transaction to run eCATTs is “SECATT”.

With eCATT You can:

  • Test transactions, reports, and scenarios
  • Call BAPIs and function modules
  • Test remote systems
  • Check authorizations (user profiles)
  • Test updates (database, applications, GUI)
  • Test the effect of changes to customizing settings
  • Check system messages

2. Pre-requisites and settings required before using eCATTs.

There are a few basic pre-requisite steps you must first take before you will be able to record and execute a recorded eCATT Script in your system. Further detail on these steps can be found in note 519858 & 480149

Pre-requisites:

  • eCATT can test systems based on release 4.6C or higher, however they will only run on systems using SAP Web Application Server 6.20 or higher.

Required Settings:

Please note: you may or may not have access to these settings and may have to contact your Netweaver Administrator to make these necessary changes.

  • Enable ECATTs for the client:
      1. Start transaction SM31.
      2. Enter table T000 and choose Maintain. You will be warned that the table is client-independent – ignore this warning.
      3. Double-click the relevant client in the list.  Under Restrictions, choose the setting that allows CATT/eCATT in that client. For full information, refer to the eCATT Security Guide, available from http://service.sap.com/eCATT.

 

  • Enable Front-End Scripting:
      1. Ensure the SAP GUI Scripting component is installed. There is an option for installing this component when installing the SAP GUI.
      2. On any screen, choose Customizing of local layout.
      3. Choose Options….
      4. Choose the Scripting tab.
      5. Select Enable Scripting.

    1. Apply

 

  • Enable Back-End Scripting:
      1. Execute transaction RZ11.
      2. On the Maintain Profile Parameters screen, enter sapgui/user_scripting.

      1. Choose Display.
      2. In the Display Profile Parameter Attributes screen, choose Change value.
      3. Enter TRUE in the “New value” field.

    1. Choose Save

3. ECATT Objects:

There are four main eCATT objects as shown in the screenshot below. They are:

  1. System data container
  2. Test script
  3. Test data container
  4. Test configuration container

The System Data Container can be considered as a central repository which tracks all the environments where you can have the eCatt scripts execute. For eg, you may need eCatt scripts to run in your sandbox or Dev or QA environments, as such all these systems would need to be maintained as part of a system data container. It can be maintained independently of the test script.  Having it as an independent object allows for test scripts to be efficiently redirected as and when the system landscape changes.  Without a System Data container you cannot write test scripts that access other systems.

The Test Script consists of an executable script and an interface for data transfer. The test script editor has the following areas:

  1. Application Toolbar
  2. Information Area
  3. Editor tab
    1. Parameter List
    2. Command Editor
    3. Structure Editor
  4. Attribute tab

In my next eCATT Blog I will explain these test script areas in greater detail.

The Test data container contains one or more sets of parameters that can be maintained independently of the test script. Parameters can be ABAP simple types, structures, or tables. The main reasons it is maintained separately are for reusability and maintainability. Test data containers and a test script are brought together in test configuration to create an executable test case. The simplest use of a test data container would be to create a separate one for each test script. However, there is no reusability in such a scenario.  A more effective way would be to create a single test data container for a group of logically connected Test Scripts.  By storing all of the scripts possible test data in one container, it becomes easier to keep the test data consistent and also maintenance of the test data is from one place. This type of situation is outlined in the image below.

The Test Configuration Container is used to maintain the test configurations object. To execute a script with one or more sets of data, we use a test configuration. A test configuration contains a reference to a test script, system data container and references to one or more test data containers. An executed test configuration produces its results in the form of a log which provides complete information as to whether a test was a pass or a fail.