When you are new at eCatt, a brief overall description can be useful. Catt stands for Computer Aided Test Tool is the tool to automate test scripts in SAP. In effect, a sequence of system-processing steps are recorded and can be executed at a later stage to test the effect of a development or customizing change.
The e in eCatt stands for "Extended", ergo: the more adult version of Catt. If you are dealing with a serious project and you want to ensure the knowledge required for testing is not required till the year 2050, working with computer aided test tools is a winner-formulea.
This article describes how eCatt hangs together, in a nutshell of course...
eCatt test scripts are composed of test scripts, system settings (landscape settings), variants (data to be assigned to a test script) and test configurations (where all components are linked together). From the development system an eCatt can be run on any system that is set up as part of the eCatt landscape. Thus triggered from the development system, scripts can perform a variety of actions on the test or QA system.
What you should do and not do when implementing eCatt scripts
- Do use "master scripts" and "sub scripts" - to avoid drowning in scripting steps
- Don't change the building blocks (test scripts) that are used elsewhere. Check out the "where used" list (article "Where is your script used") first !
Would you like to dine with us ? Come have a look at The Menu™. Today's special: the seCatt transaction...
System data
...is an overview of SAP systems (& clients) for which eCatt can be used. Once this is set up, the next step is setting up the...
Test data container
...which holds the definition of variables or parameters used in your eCatt, along with their values as variants, of which several can be set up. One of these variants are used in a...
The most commonly used statements in eCatt, with a short explanation: For a full list of available statements, go to the editor on a Test script and select button "Pattern". F4 on the "Command" field will list all available commands. Last time I checked this was: REF, REFCATT, TCD, SAPGUI, FUN, GETTAB, SETTAB, CHETAB, RESTAB, SETVAR, CHEVAR, LOG, DO..ENDDO, IF..ELSEIF..ELSE..ENDIF, EXIT, IF .. ELSE .. ENDIF and ABAP..ENDABAP
To get a where used list on test scripts available, here's what you can do... From the menu of transaction SECATTchoose Goto => Use of command. As the command choose "REF" and as Object in command fill in the test script you would like to see the where used list for. The use of your script in other test scripts as well as test confirurations is listed. Check out the other where-used options (commands) as well.
This article lists the main guidelines for setting up your eCatt scripts. Topics you are bound to experience for yourself, high level and detailed, with a short explanation of how and why. First of all, there should be a clear understanding of how scripts are best set up. The best way to work is differentiate in high-level scripts or master scripts and detailed step scripts. The detailed steps can be executed as seperate blocks, reusable in several master scripts. So: a script can call (reference) a script can call a script (up to about 6 or 7 levels). It's thus not very difficult to turn an eCatt script into a very complex monster....
The following guidelines should help you develop healthy eCatt scripts:
Whenever workflow has been implemented on your system, setting up eCatt processing can be quite a challenge. Here's how it can be done. Workflow work items can be executed in different ways. The user inbox is of course the most common one, but working through this inbox when setting up your eCatt session is quite impossible. An alternative would be transaction SWIA - "Execute work item as Administrator". This transaction allows you to enter a work item ID (which can be obtained via selection) which should produce a single-line result report. An even "closer to reality" approach would be using transaction SWI1 - "Work item selection" which would allow execution not as Administrator (like trx SWIA) but as regular user.
When an eCatt script requires actions to be performed on e.g. a Purchase Order which is normally created via an inbound Idoc - why not make eCatt create your example PO... This article describes the approach of using inbound Idoc processing to produce your test data. Before the Idoc can be set up, main data should be gathered from import parameters. The example creates a Purchase Order in the following steps: