Skip to Content
The Part I of eCATT Introduction gives the basic details about usage of eCATT & features involved. In Part II, the creation of eCATT scripts using TCD mode of recording is explained in detail. In the Part III, the creation of eCATT Scripts using SAPGUI mode is explained in detail. In Part IV chaining, parameterization, creation of Test Configuration, Test Data Container, and System Data Container are explained in detail. In Part V, the management of eCATT Scripts via Testworkbench is explained. In Part VI, the eCATT Logs is explained in detail. In Part VII, creation of eCATT Scripts using Non-User Interface mode is explained along with the details of Copy, Rename, Delete, Upload and Download of eCATT objects. In the Part VIII, tips & links of eCATT will be covered.
Tips To Be Followed Before or During Recording:
  • Test case is generally a series of transactions pertaining to one business scenario. Before recording of the script via eCATT, work with the script on R/3 system directly with a given set of valid data for the entire script. Execute the script manually directly on R/3 for at least 2-3 times with the same set of data. On 2nd time onwards, system may prompt some error messages, warning messages etc. Correct the data only for the error messages and let the warning messages & popup be as it is. This way the data is ready which gives all possible behavior of the transaction. Now record the script with this data. Recording will now include the extra popup, warning messages, which normally don’t come. Make these screens optional in SAPGUI mode. After recording, without parameterization check for the errorless recording by execution. If the recording is successful, then only go for parameterization otherwise do the corrections by rerecording if needed.
  • There can be some default settings for the parameters values on the user ID by which the recording is done. Make sure that before replaying those recorded eCATT scripts, the default user ID settings are done on the system on which the final execution will happen. Following such prerequisites in terms of user ID settings or some behavior of transaction of first run, in same session with some default data etc. always help in the successful execution of the scripts.
  • If the transaction to be recorded on R/3 involves dropdown list box, do the following setting before recording of that transaction. Due to following settings, the keys will be assigned to each item in the dropdown in sorted manner and recording will happen for these keys values. This helps in replaying the transaction successfully.
    • Log on to target R/3 system. On any transaction, click on Customizing Of Local Layout (Ctrl+F12) icon from the application toolbar. Select the Options -> Expert.
      image
    • On the Expert tab, in the Controls section select the checkboxes of Show keys in all dropdown lists & Sort items by keys.
      image
    • Transaction with dropdown without keys setting –
      image
      Transaction with dropdown keys settings –
      image
  • If the recording includes, adding some value to the table then don’t scroll up to blank line. Use directly the Create Item icon and then add the new values. Scrolling fails at the time of replay.
    image
  • If the recording includes searching some value from ALV grid and the value is known then don’t scroll and look for the value. Use the Search icon from the ALV toolbar for searching. Once the search item is found, then click on the item for further processing.
    image
  • It happens at times that the screen size reduces at the time of recording in width and height. In such scenario if the field to be captured during recording is present somewhere at the bottom, then don’t scroll. Use the TAB key till that field is reached. Due to Scroll functionality possibility of script failure becomes high.
  • It is not possible to capture the value from a dynamically generated list. If the recording includes a dynamically generated list and one value (which is not known until execution) from this list needs to pass to the subsequent step in recording then use foreground mode of recording for this dynamically generated list. Use WAIT XXX statement after its recording. During this WAIT XXX seconds, capture the value from the generated list manually and pass it to the next recording.
SAPGUI & TCD Recording Modes:
  • Error messages can be recorded and replayed by Only SAPGUI recording mode and NOT by TCD mode.
  • Warning messages are automatically handled by TCD mode but in SAPGUI recording mode they need to be handled if they require user intervention for further processing. (E.g. Pressing and enter key will enable all the fields after warning message)
  • Screens can be made Optional for execution in SAPGUI mode. This optional screen will be handled automatically at runtime even if not in the screens flow. But in TCD screens can’t be made optional which may or may not occur during execution. Rather in TCD screens can be made active or deactivated in the cases where depending on some input values, the recording can be reused. The screens sequence should be known well in advance in TCD for making any screen active or not.
  • Only local variables from the eCATT Parameters can be used in Inline ABAP code. Import and Export parameter are not allowed.
  • Passing values to subsequent screens at runtime is only possible in SAPGUI and not in TCD mode.
  • SAPGUI Confirm Popup:
    In order to avoid the following popup for SAPGUI recording, option is available in R/3 System.
    image
    Click on the icon with tool tip Customizing Of Local Layout (Alt+F12) in the standard toolbar on any transaction of R/3 system. Select the Options menu.
    image
    From the Options -> Scripting, uncheck the check box of Notify when a script attaches to a running GUI. Click on Apply -> Ok. The popup won’t appear onwards.
    image
  • Making SAPGUI Screen Optional:
    It is possible in SAPGUI recording mode to make screens optional.
    Double click on the screen or message popup, which needed to make optional on the left side in the command editor. On right side, the interface will open. Under the ProcessedScreen node, first option is Active ‘X’.

    Change Active ‘X’ to ‘O’.

    ‘X’ – Active (Compulsory will execute)
    ‘O’ – Optional (will execute only when it will be in execution flow).
    image

eCATT Commands:
  • An eCATT script consists of individual eCATT commands. Each command begins with a command word and ends with a period. Comments (*) and assignments (=) are exceptions to this rule.
  • There can be several commands on the same line. Comments (*), assignments (=), and inline ABAP are exceptions to this rule.
  • E.g. of eCATT Commands are –
    *, =, ABAP, CHETAB, CHEVAR, CLEAR, DO, ELSE, ELSEIF, ENDABAP, ENDDO, ENDIF, ENDMESSAGE, EXIT, FUN, GETTAB, IF, LOG, MESSAGE, ON_LAST_MESSAGE_CHECK, REF, REFCATT, REFEXT, REMOTECATT, RESTAB, SAPGUI, SENDEXT, SETTAB, TCD, WAIT, WAIT_ON_DYNPRO
  • There are examples involving these eCATT commands, which can be found from the menu Goto-> Use Of Command.
    image
  • On the next screen eCATT – Search Of eCATT Commands in Test Script, in the Command input field, give the name of the eCATT Command from the F4 help.
    image
    And click on Execute (F8) button from the application toolbar. List of examples will be in the output.
Key Points Can Be Followed For Successful Testing Via eCATT:
  • Analysis of transactions with different behaviors for different sets of data. Finally selecting the set of data, which gives maximum possible messages/popup for the given transaction.
  • Automation along with the verification before final regression on Quality Server.
  • Preparation of variant files with details having comments on each value, which helps in preparation of data for the scripts before execution.
  • Analyzing the behavior of transactions for the background/ foreground execution mode. Accordingly preparation of packages for background & foreground execution.
  • Preparing the prerequisites for the regression as a whole considering the user ID settings. Also the transaction settings for those user IDs.
  • Maintaining the results in scorecard with log IDs for each location the scripts being tested during regression on Quality. This helps for future reference of script results. Scorecard can be something like as follows –
    image
eCATT Weblog Links From SDN:
eCATT Links From SAP Help:
eCATT Links From SAP Service Marketplace:

For accessing site from SAP Service Marketplace, user ID & Password is required.

Useful eCATT Links From SDN Forum:
To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

  1. Abdul Hakim
    Hi Sapna.Your weblog is very very informative.Keep up your good work..Well is it necessary for an ABAP Developers like me to know e-catt in detail…..

    Cheers,
    Abdul Hakim

    (0) 
  2. Anonymous
    thanks alot Sapna,

    This blog is very informative and i learned a lot from this examples, do you have any information on ECATT with Webdynproabap, if so can u share it with us.

    (0) 
      1. Anonymous
        Hi Peter,

        Thanks for the info.if some one searching for wda-ecatt testing must visit that page.

        regards,
        sathish

        (0) 
  3. Steven De Coninck
    Sapna,
    first of all, thx for the great blog.

    i have a question for you, hope you have an idea how to solve this.
    for a project we would like to create this:
    in a certain ecatt-script-variant we want to have for example user A (with password) and user B (with password).

    while executing the script, we want to connect to a system for example with user A, create a PO and then connect to the same system with user B and release that PO.

    do you know if this (working with different users) is possible in some way in Ecatt? and how we should establish this?

    please let me know via mail: deconincksteven@hotmail.com

    thx for your help!
    hope i can do anything in return!
    regards
    Steven from Belgium

    (0) 

Leave a Reply