ecatt620

eCATT: extendedComputer Aided Test Tool

(BC-TWB-TST-ECA)

V1.04

Release 620

SAP Online Help 09/17/02

eCATT: extended Computer Aided Test Tool (BC-TWB-TST-ECA) 620 2

Copyright

Copyright 2002 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose withoutthe express permission of SAP AG. The information contained herein may be changed without priornotice.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registeredtrademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390,AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner,WebSphere, Netfinity, Tivoli, Informix and Informix Dynamic ServerTM are trademarks of IBMCorporation in USA and/or other countries.

ORACLE is a registered trademark of ORACLE Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame,MultiWin and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide WebConsortium, Massachusetts Institute of Technology.

JAVA is a registered trademark of Sun Microsystems, Inc.

JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license fortechnology invented and implemented by Netscape.

SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow,SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP, mySAP.com, and otherSAP products and services mentioned herein as well as their respective logos aretrademarks or registered trademarks of SAP AG in Germany and in several other countriesall over the world. MarketSet and Enterprise Buyer are jointly owned trademarks ofSAP Markets and Commerce One. All other product and service names mentioned are thetrademarks of their respective owners.



Icons

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Typographic Conventions

Type Style Description

Example text Words or characters that appear on the screen. These include fieldnames, screen titles, pushbuttons as well as menu names, paths andoptions.

Cross-references to other documentation.Example text Emphasized words or phrases in body text, titles of graphics and tables.

EXAMPLE TEXT Names of elements in the system. These include report names,program names, transaction codes, table names, and individual keywords of a programming language, when surrounded by body text, forexample, SELECT and INCLUDE.

Example text Screen output. This includes file and directory names and their paths,messages, source code, names of variables and parameters as well asnames of installation, upgrade and database tools.

EXAMPLE TEXT Keys on the keyboard, for example, function keys (such as F2) or theENTER key.

Example text Exact user entry. These are words or characters that you enter in thesystem exactly as they appear in the documentation.

Variable user entry. Pointed brackets indicate that you replace thesewords and characters with appropriate entries.



eCATT: extended Computer Aided Test Tool (BC-TWB-TST-ECA) ....................................................... 7

General Information.............................................................................................................................. 8

Preparing Systems and Computers for eCATT................................................................................ 9

Maintaining Table T000............................................................................................................... 10

Enabling Scripting at the Front End ............................................................................................ 11

Enabling Scripting at the Back End.............................................................................................12

eCATT Drivers ................................................................................................................................ 13

Test and Data Management ........................................................................................................... 14

Test Script Versions........................................................................................................................ 15

Running Tests from a Central Test System ................................................................................... 16

External Tools................................................................................................................................. 18

Authorizations ................................................................................................................................. 19

Using eCATT...................................................................................................................................... 20

Creating eCATT Objects ................................................................................................................ 21

Displaying or Changing eCATT Objects......................................................................................... 22

Deleting eCATT Objects................................................................................................................. 23

Renaming eCATT Objects.............................................................................................................. 24

Copying eCATT Objects................................................................................................................. 25

Uploading eCATT Objects.............................................................................................................. 26

Downloading eCATT Objects ......................................................................................................... 27

Downloading Referenced eCATT Objects.................................................................................. 28

Migration of CATT Test Cases ....................................................................................................... 29

Migrating CATT Test Cases to eCATT ....................................................................................... 30

Test Script Editor ............................................................................................................................ 31

Creating Test Scripts................................................................................................................... 32

Maintaining Attributes.................................................................................................................. 34

Using TCD (Record) to Record Transactions ............................................................................. 36

TCD Command Interface ........................................................................................................ 37

Screen Simulation ................................................................................................................... 40

Using SAPGUI (Record) to Record Transactions....................................................................... 42

Checking Initial States ............................................................................................................. 44

Re-Recording with SAPGUI Commands................................................................................. 46

Notes on the Playback of SAPGUI Commands ...................................................................... 47

SAPGUI Command Interface .................................................................................................. 48

Parameters.................................................................................................................................. 51

Special Variables..................................................................................................................... 52

eCATT Commands ..................................................................................................................... 54

* ............................................................................................................................................... 55

=............................................................................................................................................... 56



Examples for the Assignment Operator (=) ......................................................................... 57

ABAP ....................................................................................................................................... 59

CHETAB .................................................................................................................................. 60

CHEVAR.................................................................................................................................. 61

CLEAR..................................................................................................................................... 62

DO ........................................................................................................................................... 63

ELSE........................................................................................................................................ 64

ELSEIF .................................................................................................................................... 65

ENDABAP ............................................................................................................................... 66

ENDDO.................................................................................................................................... 67

ENDIF...................................................................................................................................... 68

ENDMESSAGE ....................................................................................................................... 69

EXIT......................................................................................................................................... 70

FUN ......................................................................................................................................... 72

GETTAB .................................................................................................................................. 73

IF.............................................................................................................................................. 74

LOG ......................................................................................................................................... 76

MESSAGE............................................................................................................................... 77

ON_LAST_MESSAGE_CHECK.............................................................................................. 79

REF.......................................................................................................................................... 80

REFCATT ................................................................................................................................ 81

REFEXT .................................................................................................................................. 82

REMOTECATT........................................................................................................................ 83

RESCON ................................................................................................................................. 84

RESTAB .................................................................................................................................. 85

SAPGUI ................................................................................................................................... 86

SENDEXT................................................................................................................................ 87

SETTAB................................................................................................................................... 88

TCD ......................................................................................................................................... 89

WAIT........................................................................................................................................ 90

WAIT_ON_DYNPRO............................................................................................................... 91

Using an External Tool with eCATT............................................................................................ 92

Creating Test Scripts with an External Tool ............................................................................ 93

Uploading External-Tool Scripts to eCATT ............................................................................. 94

Parameterization in an External Tool ...................................................................................... 95

Executing External Test Scripts in eCATT .............................................................................. 96

Test Configuration Editor ................................................................................................................ 97

Creating Test Configurations ...................................................................................................... 98

Creating Variants in Test Configurations .................................................................................... 99

Editing Variants ......................................................................................................................... 100

Test Data Editor............................................................................................................................ 102



Creating Test Data Containers ................................................................................................. 103

Creating Variants in Test Data Containers ............................................................................... 104

System Data Editor....................................................................................................................... 105

Creating System Data Containers ............................................................................................ 106

Executing Test Scripts .................................................................................................................. 107

Start Options ............................................................................................................................. 108

Logs .............................................................................................................................................. 110

Displaying and Printing Logs .................................................................................................... 111

Deleting Logs ............................................................................................................................ 112

Archiving Logs........................................................................................................................... 113

Using Logs ................................................................................................................................ 114

Notes and Recommendations.......................................................................................................... 119

Test Workbench............................................................................................................................ 120

Moving from CATT to eCATT ....................................................................................................... 121

eCATT Tutorial ............................................................................................................................. 122

Part 1 - Creating a Test Script .................................................................................................. 123

Part 2 - Executing a Test Script ................................................................................................ 125

Part 3 - Chaining a Series of Transactions ............................................................................... 129

Part 4 - Loops, Conditions, and Inline ABAP ............................................................................ 132

Part 5 - Using System Data ...................................................................................................... 136

Part 6 - Test Data Containers ................................................................................................... 140

Part 7 - Using Test Configurations and Variants ...................................................................... 142

Part 8 - Versions ....................................................................................................................... 145



eCATT: extended Computer Aided Test Tool (BC-TWB-TST-ECA)PurposeUse extended Computer Aided Test Tool (eCATT) to create and execute functional tests for softwarebased on R/3 technology. The primary aim is the automatic testing of SAP business processes. Eachtest generates a detailed log that documents the test process and results.

eCATT enables automatic testing in SAP GUI for Windows and SAP GUI for Java. In order to offer acomplete test solution that covers other GUIs, eCATT has interfaces to third party tools.

Implementation ConsiderationsTest cases usually make R/3 System database changes. Therefore, you should not normally run themin productive systems.

In general, do not use eCATT to manipulate data in a productive system: eCATT is a testtool. Only use eCATT in a productive system if you know exactly what will happen.

IntegrationeCATT can be used with the Test Workbench. You can migrate test cases from Computer Aided TestTool (CATT) to take advantage of the better features of eCATT.

FeaturesYou can:

Test transactions and reports

Test remote systems

Check authorizations (user profiles)

Test database updates

Set up customizing tables

Test the effect of changes to customizing settings

Perform load testing

Check system messages

Call BAPIs and function modules

ConstraintseCATT runs in a system based on SAP Web Application Server 6.20 or higher.

TutorialYou can find a step by step introduction to eCATT in the eCATT Tutorial [Page 122].



General InformationThis section contains general information about eCATT.



Preparing Systems and Computers for eCATTFor up-to-date information see SAP Note 519858.

Here is a checklist for preparing to use eCATT:

Maintain table T000 [Page 10] to allow eCATT to be used in the relevant clients.

Patch the systems. For information about which support packages to use, see SAP Note 519858.

Check that the users have the appropriate authorizations.

Install the latest 6.20 SAP GUI for Windows with the SAP GUI Scripting component.

Enable scripting if required. This needs to be done at both the back end [Page 12] and front end[Page 11].

Install certified external tools on the local machine of the user. Use the SET_EXTERNAL_TOOLfunction module to make the required entries in the customizing table ECCUST_ET.

Create RFC destinations (transaction SM59) for target systems.



Maintaining Table T000Procedure1. Start transaction SM31.

2. In the Table/View field, enter T000.

3. Choose Maintain.

4. In the Change View Clients: Overview screen, select the relevant client and choose .

5. In the Restrictions when Starting eCATT field, select an entry that allows eCATT.

6. Choose .



Enabling Scripting at the Front EndPrerequisitesThe SAP GUI Scripting component is installed.

ProcedureOn any screen, choose Customizing of local layout.

Choose Options....

Choose the Scripting tab.

Select Enable Scripting.

Choose Apply.

ExampleThe following screenshot shows the recommended settings.



Enabling Scripting at the Back EndProcedure1. Start transaction RZ11.

2. On the Maintain Profile Parameters screen, enter sapgui/user_scripting.

3. Choose Display.

4. In the Display Profile Parameter Attributes screen, choose Change value.

5. Enter TRUE in the New value field.

6. Choose .



eCATT DriverseCATT enables you test all mySAP applications, including those running outside of SAP GUI forWindows and SAP GUI for Java. To cover all the test possibilities, eCATT has four different drivers,each specialized for a particular task. You can use several drivers in the same test script. You choosethe most appropriate drivers for the application under test.

Non-User InterfaceThe non-user interface is for testing back-end R/3-specific modules, such as function modules andBAPIs. It should be the preferred driver for interface tests in the mySAP environment. It is fast,efficient, and suitable for load testing.

TCDUse TCD for testing transactions, especially those that do not use controls.

TCD has the following advantages:

It has a built in screen simulation for standard screen elements.

No GUI is required for playback.

It is suitable for load testing.

The TCD command has the same limitations as the CATT function of the same name. The flow of datato and from controls, as well as screen input values, are recorded. When the test script runs, thecontrols are deactivated and the user's actions are simulated by reading the recorded data flows.

GUI ScriptingUse GUI scripting for testing applications that use controls in SAP GUI for Windows and SAP GUI forJava.

It requires GUIs for playback and is not suitable for load testing.

Interface to External ToolsIf you have the appropriate supported tools from third parties, you can test applications that run underGUIs other than SAP GUI for Windows and SAP GUI for Java.

These products should be certified against the BC-eCATT interface [Page 18].



Test and Data ManagementeCATT ObjectsTest ConfigurationThis data object contains a set of references to a test script, a system data container, and possiblyseveral test data containers. A test configuration contains all the information necessary to run anautomatic test without further user interaction.

The separation of test script, test data, and system data allows for a considerable degree of reuse.

Test ScriptThis data object consists of an executable script and an interface for data transfer.

Test Data ContainerThis data object contains a set of parameters that can be maintained independently of a test script.Parameters can be ABAP simple types, structures, or tables.

System Data ContainerThis data object identifies instances of SAP systems. It can be maintained independently of the testscript.

Having the system data as an independent object allows test scripts to be efficiently redirected whenthe system landscape changes.

Central Test SystemAll the actions executed by eCATT can take place from a single designated system. This system alsostores all the data. This makes the administration and execution of tests easier.

Versions and VariantsA test script can have several versions [Page 15]. This allows different implementations for differentreleases. Test data containers and test configurations can have variants. Variants are different sets ofdata.

Transport and DownloadAll eCATT objects are Repository objects. Therefore, you can take advantage of the standard SAPtransport tools.

Naming ConventionThere is no naming convention for eCATT objects. A name is an alphanumeric string up to 30characters long. A name is not case-sensitive.



Test Script VersionsYou can create versions of test scripts. This allows you to use the same script to test a particularbusiness function, even if the implementation of this function in the system changes from release torelease (for example, from a transaction in SAP GUI for Windows to a web application).

eCATT automatically finds the appropriate version of a test script for the system under test (throughthe test configuration).There is only one eCATT object for a test script, irrespective of how manyversions exist in other words, there is only one object in the object directory.

Creating different versions of a script is suitable for scripts with similar functionality but differingimplementations for different validity areas. You should not use versions for scripts with differentimplementations in the same validity area.

Certain attributes and parameters should be identical for all versions of a test script otherwise, therewould problems with calling the interface when using the REF command. However, new versions of atest script can extend the interface. Even parameters such as complex structures or tables can beextended.



Running Tests from a Central Test SystemIntroductionSeveral different systems might be involved in a business process that you want to test. Consider asimple scenario:

1. A purchase order is entered on the first system.

2. The order is passed to a second system where production is scheduled.

3. The second system passes information to a third system where a table is updated.

You want to test the transactions and check the table update.

eCATT enables you to create and manage the tests in a single system, and execute the appropriatetests against the various target systems.

System RequirementsThe central test system must be based on Release 6.20 of the Web Application Server or later.

The target systems must be based on SAP Basis Release 4.6 or later. A patch containing essentialeCATT functions must have been applied to each of the target systems.

LocationThe central test system contains:

eCATT

Repository of eCATT objects (test script, test data containers, system data containers, and testconfigurations)

Logs

RFC destinations for the target systems

The applications under test reside on the target systems. The central test system can also be a targetsystem.

Specifying Target SystemsIn a test script, the RFC destinations are not specified directly. You specify the RFC destinations in asystem data container, where you assign them to target systems. You create the names of the targetsystems yourself, and it is these name that you use in the test script.

In a system data container, you could have:

Target System RFC DestinationMY_TARGET_SYSTEM_1 RFC_DESTINATION_1

MY_TARGET_SYSTEM_2 RFC_DESTINATION_2


In a test script, you could have:TCD ( , , MY_TARGET_SYSTEM_1 ).TCD (, , MY_TARGET_SYSTEM_2 )CHETAB ( , , MY_TARGET_SYSTEM_3 ).

The advantage of this separation of test script and RFC destinations is that you can change the targetsystems without having to change the test script. You can simply assign a different system datacontainer, containing a different set of RFC destinations, to the test script. You can do this in a testconfiguration.



Continuing the example, a second system data container could have:

Target System RFC DestinationMY_TARGET_SYSTEM_1 RFC_DESTINATION_4





External ToolsUseeCATT itself covers the automatic testing in SAP GUI for Windows. For other GUIs and externalapplications, eCATT provides an interface for external tools. You can also use external tools for testingin SAP GUI for Windows and SAP GUI for Java.

You record an external script into its own eCATT test script. This test script can then be called fromanother eCATT test script.

In order to create, edit, or execute external tests, the corresponding test tool must be installed on thesame front-end machine as the SAP GUI in which you are working.

Test scripts that are created with an external tool are stored in the SAP database. All test scripts,whether generated by eCATT itself or with external tools:

have the same object type

are integrated with the SAP Change and Transport System

are stored in the same location.

External Tools Usable with eCATTFor information about certified external tools, refer to the SAP Partner and Product Directory atwww.sap.com/partners/search.asp

RestrictionsExternal tools are not part of the SAP installation.

CompatibilityA test script recorded with one version of an external tool may not be compatible with a differentversion of that tool.

An eCATT test script will always be compatible with eCATT.



AuthorizationsDocumentationAuthorizations and security are covered more fully in the eCATT Security Guide, which can be foundin SAPNet.

Access to the eCATT Test SystemAccess to the eCATT test system should be strictly controlled.

In the eCATT test system, there may be RFC destinations in which the user and passwordare fully specified.

Authorizations Required at Design TimeYou need:

Developer rights (S_DEVELOP with relevant activities) in the eCATT test system.

RFC rights (S_RFC) in the eCATT test system.

The relevant authorizations in the target systems.

Authorizations Required at RuntimeYou need:

A profile containing S_DEVELOP authorization with activity 16 (Execute) and 03 (Display) in theeCATT test system.

RFC rights (S_RFC) in the eCATT test system.

A profile containing S_DEVELOP authorization with activity 16 (Execute) in the target systems.

The relevant authorizations in the target systems.

Security and the SAPGUI CommandThe following are some of the security features:

The administrator can switch GUI Scripting on or off for a particular application server.

In addition to the server settings, GUI Scripting requires certain components to be installed on thefront end. If GUI Scripting is enabled, the user can enable or disable scripting at the front end.Here, you have the option to be notified whenever a script attaches to the SAP GUI or a scriptopens a connection. eCATT itself never opens a new connection.

eCATT GUI Scripting does not use Windows Scripting Host.

The SAPGUI command never records logon screens.

Target SystemsWhen you record GUI actions in a target system, the security settings of the target system apply.When you replay a SAPGUI command, the security settings of the eCATT system apply.



Using eCATTCalling eCATTGo to the initial screen by one of the following:

Choose SAP menu Test Test Workbench CATT Extended CATT.

Use transaction code SECATT.

The EditorsFrom the initial screen, you can go to the appropriate editor for each type of eCATT object. The editorsare:

Test configuration editor [Page 97]

Test script editor [Page 31]

Test data editor [Page 102]

System data editor [Page 105]



Creating eCATT ObjectsYou can create the following eCATT objects:

Test configurations [Page 98]

Test scripts [Page 32]

Test data containers [Page 103]

System data containers [Page 106]



Displaying or Changing eCATT ObjectsUseYou can display or change the following eCATT objects:

Test configurations

Test scripts

Test data containers

System data containers

Procedure1. On the Extended Computer Aided Test Tool: Initial Screen screen, select the type of eCATT

object.

2. Enter the name of the eCATT object in the appropriate field.

3. If the eCATT object is a test script, either enter the version in the Version field or leave the fieldempty. If you leave the field empty and more than one version exists, you will be offered a list ofversions to choose from.

4. Choose to display, or to change, the eCATT object.

The appropriate editor opens.



Deleting eCATT ObjectsUseYou can delete the following eCATT objects:

Test configurations

Test scripts




object.


3. If the eCATT object is a test script and you want to delete one version, enter the version in theVersion field. If you want to delete all versions, clear the Version field.

4. Choose .

A dialog box appears.

5. Choose Yes.



Renaming eCATT ObjectsUseYou can rename the following eCATT objects:

Test configurations

Test scripts




object.


3. Choose .


4. Enter the new name.

5. If the eCATT object is a test script and you want to rename one version, enter the appropriateversions in the Version fields. If you want to rename all the versions, leave the Version fieldsempty.

6. Choose Enter.

If a new eCATT object has been created, you will be prompted to save.



Copying eCATT ObjectsUseYou can copy the following eCATT objects:

Test configurations

Test scripts




object.


3. Choose .


4. Enter the new name.

5. If the eCATT object is a test script and you want to copy one version, enter the appropriateversions in the Version fields. If you want to copy all the versions, leave the Version fields empty.

6. Choose Enter.

If a new eCATT object has been created, you will be prompted to save.



Uploading eCATT ObjectsUseAn eCATT object can be stored as an XML file (you download [Page 27] eCATT objects from withintheir respective editors). This enables you to transfer eCATT objects between R/3 systems simply.You can upload the following eCATT objects:

Test configurations

Test scripts



When you upload a test configuration or test script, eCATT objects that it references are notautomatically uploaded. You need to specifically upload these objects.

System Data ContainersWhen uploading or downloading system data containers for copying to another system, the name ofan RFC destination remains unchanged in the RFC Destination field. However, in the new system, thisname might not exist or might be that of a different RFC destination. In this case, you need to maintainthe RFC destination.

Procedure1. On the Extended Computer Aided Test Tool: Initial Screen screen, choose eCATT Object

Upload.


2. Choose the folder where the files are located.

3. Select the file or files, then choose Open.


4. In the relevant Target object field, enter a name for the eCATT object.

5. If the eCATT object is a test script, you can enter a version number in the Target Version field.

6. Choose .

7. Choose .



Downloading eCATT ObjectsUseYou can store an eCATT object as an XML file. The file can be uploaded [Page 26] to eCATT. Thisenables you to transfer eCATT objects between R/3 systems simply. You can download the followingeCATT objects:

Test configurations

Test scripts



When you download a test configuration or test script from within its editor, eCATT objects that itreferences are not automatically downloaded. You need to specifically download these objects.

To download all referenced objects together with the referencing object, see Downloading ReferencedeCATT Objects [Page 28].

System Data ContainersWhen uploading or downloading system data containers for copying to another system, the name ofan RFC destination remains unchanged in the RFC Destination field. However, in the new system, thisname might not exist or might be that of a different RFC destination. In this case, you need to maintainthe RFC destination.


object.


3. If the eCATT object is a test script, enter the version in the Version field.

4. Choose .

The appropriate editor opens.

5. Choose Download.


6. Select the folder in which you want to store the file, and choose OK.

ResultAn XML file is created in the folder that you selected.



Downloading Referenced eCATT ObjectsUseA test configuration references a test script, a system data container, and possibly several test datacontainers. A test script can reference a system data container and other test scripts. You candownload all these referenced objects together, at the same time as the referencing object.

Procedure1. On the Extended Computer Aided Test Tool: Initial Screen screen, choose Goto Reference

List.

2. In the Object Type field, select the type of the eCATT object that references the other objects.

3. In the Object Name field, enter the name of the eCATT object that references the other objects.

4. If the eCATT object is a test script, enter the version number in the Version field.

5. Choose .

A list of all the referenced objects is displayed.

6. Choose .


7. Select the folder in which you want to store the files, and choose OK.

ResultThe selected object and all the objects that it references are downloaded.



Migration of CATT Test CasesYou can migrate CATT test cases to eCATT test scripts of the same name. The eCATT test scripts arenew objects and the original CATT test cases remain as they were.

During migration, eCATT does the following:

Writes a comment in the test script, with information about the source of the test case.

Copies all the attributes of the test case to the test script.

Copies the documentation in the test case to the test script.

Replaces the ampersand ( & ) at the beginning of CATT parameters and local variables with theunderscore ( _ ) at the beginning of eCATT parameters. The ampersand ( & ) at the beginning ofstandard parameters is not affected.

Replaces CATT functions with the appropriate eCATT commands.

Writes comment lines into the test script where changes to the script need to be done manually.

VariantsVariants are an integral part of many CATT test cases, whereas in eCATT the variants are separatefrom the test scripts.

eCATT can migrate a test case into a test script and create a test configuration of the same name. Thetest configuration contains the variants. Alternatively, you can choose to only create the test script. Inthis case there are no variants.

VersionsYou can migrate a test case, from different releases of the SAP System, into one test script of multipleversions.

Migration of Test Cases Containing the REF FunctionCATT test cases can use the REF function to call test modules, which can call other test modules.

If you use recursive REF migration, all the test modules are migrated into individual eCATT testscripts, which are referenced using the REF command.

If you do not use recursive REF migration, only the test case is migrated. The test modules arereferenced by the REFCATT or REMOTECATT commands as appropriate.



Migrating CATT Test Cases to eCATTUseYou can create new eCATT test scripts and test configurations from CATT test cases.

Procedure1. On the Extended Computer Aided Test Tool: Initial Screen screen, choose eCATT Object Catt

Migration


2. If the test case is in another system, enter the appropriate information in the System DataContainer and Source System fields.

3. Choose Test Cases.

A dialog box appears in which you can search for test cases.

4. Select the test cases that you want, and choose .

A new row appears in the CATT Migration dialog box for each of the selected test cases. Youcannot change the name of the target object.

5. If you want to create a test configuration as well as a test script, select Create Test Configuration.

6. If you want to use recursive REF migration, select Recursive REF Migration.

7. In the Target Version field, enter a version number for the test script. If the script already exists,enter a version number that is not in use.

8. In the Target Package field, enter a package name for the test script. Leave the field empty for thetest script to be saved as a local object. If the test script exists already, you must assign the newversion to the same package.

9. Choose .

10. Choose .

The test scripts are created and saved.

11. If there is a or a in the Status field of a test script, double-click the icon to get moreinformation about the error or warning.

12. Display the test script in the test script editor.

If manual changes are needed to complete the migration, these will be noted in the commandeditor.



Test Script EditorUseYou use the test script editor to create and maintain test scripts. You can use the recording functions,or directly input eCATT commands into the command editor.

The test script editor has the following areas:

Application Toolbar

Information Area

Editor tab

Parameter List

Command Editor

Structure Editor

Attribute tab

Command Editor

Structure Editor

Parameter List

Information Area

Application Toolbar

Parameter ListThe parameter list contains the parameters and the command interfaces. You can toggle between thedisplay of parameters and command interfaces by choosing .

When you make changes in the parameter list, you can refresh the list by choosing . This not onlyrefreshes the display, but also re-reads the definition of the ABAP Dictionary reference (from the targetsystem if specified) of each parameter and recreates the structure of structured parameters. Values ina structured parameter are retained in fields of the same name in the recreated structure.

Values of simple parameters are displayed and edited in the parameter list.

When defining structured parameters in the parameter list, you assign ABAP Dictionary references inthe Parameter Reference field. For example, if you want to reference SPFLI and enter:

SPFLI, the parameter is a structure

SPFLI[], the parameter is a table

You can display the values of a selected command interface or structured parameter by choosing .The values are displayed in the structure editor, where they can be edited.

In the parameter list, you define the visibility of parameters. This determines whether a parameter istreated as an export parameter (E), an import parameter (I), or a local variable (V).

Command EditorThe command editor is a basic text editor. Here, you enter eCATT commands:

by using Pattern in the application toolbar

from the keyboard

by copy and paste

from a file

You can use to save the contents of the command editor to a local file. Local files can be edited instandard text editors such as Notepad.

When you use to load commands from a local file, it overwrites everything in the command editor.

You can display a command interface in the structure editor by double-clicking the name of acommand interface. If the command interface does not yet exist it is also entered in the parameter list.



You can use to check the syntax in the command editor. If you have entered a statementcontaining a command interface that does not yet exist, the command interface is automaticallyentered in the parameter list.

Structure EditorYou use the structure editor to display and edit a structure. A structure can be a command interface ora structured parameter.

Displaying Structures in the Structure EditorWhen you first open the script editor, the structure editor is not visible. To display a structure, double-click it in the parameter list or command editor. As an alternative, you can select the structure in theparameter list, and choose . The structure editor then displays the selected structure.

The left-hand side displays the selected structure as an hierarchical tree. You can click on the nodesto expand or collapse the tree.

Assigning ValuesYou maintain the values of a structure in the right-hand side of the structure editor. To display fields ofa structure for editing, double-click the corresponding elements in the tree. The selected elements aredisplayed in the right-hand side of the structure editor.

Values can be initial, fixed, or parameterized. This is indicated in the tree by the following symbols.

Symbols used

Symbol Meaning

The value has been parameterized.

No value has been assigned.

A fixed value has been assigned.

You can use the screen simulation to help parameterize transactions. To go to the screen simulation,select the screen that you want to maintain and choose .

Downloading Test ScriptsYou can download [Page 27] a test script as an XML file.

Creating Test ScriptsUseTo create a new test script or a new version of an existing test script.

Procedure1. On the Extended Computer Aided Test Tool: Initial Screen screen, select Test Script.

2. In the Test Script field, enter a name for the script. It must be an alphanumeric string of up to 30characters (underscores are permitted and it is not case-sensitive).

3. In Version field of the script, either enter an integer of up to 8 figures or leave the field empty. Ifyou leave this field empty and the script:

a. does not already exist, the version will automatically be set to 1.

b. exists already, you will be offered the next version number higher than the highest existingversion number.



4. Choose .

The test script editor appears.

5. Choose the Attribute tab and enter the required information.

6. Choose the Editor tab.

7. Enter eCATT commands in the command editor, and parameters in the parameter list.

8. Choose , to check the script syntax.

9. Choose .

When you save the script for the first time, a dialog box prompts you to assign it to a package.



Maintaining AttributesUseThe test case attributes contain organizational and technical information. Many of the attributes areoptional. Attributes can be used as test case selection criteria.

General Data Header Data

Title (required field). A short description of the test script.

Package (required field). You assign the test script to a package when you save the test scriptfor the first time.

Person Responsible. The creator of the test case is automatically entered in this field. You canchange the entry for example, if the creator is not the person responsible for this test case.

Component (required field). SAP application hierarchy component name.

Search Terms. These can be used to find the test script.

Maintenance System

System Data Container. Enter the name of a system data container. This will be used as thedefault system data container when the test script is executed.

Target System. If you have specified a system data container, you can also specify a targetsystem. This is the default target system for eCATT commands for which a target system hasnot been specified.

Versioning DataThis data is used by eCATT to determine which version is to be executed when the test script isreferenced by a test configuration or a REF command. eCATT inspects the target system at replaytime and stores the software component, release, and patch level of the target system in the log. Itthen compares the target system data with all the versioning data of the test script and selects theversion that matches.

Software Components. For example, SAP_BASIS.

You can list several software components. However, only one is used to determine whichversion is to be executed. If you list several software components, use to specify the onethat is to be used.

The software components are identical in all versions of the script.

Releases. You can specify the releases (for example, 620) and patch levels for which the testscript is valid.

You need not specify the patch level.

If you specify a particular combination of release and patch in one version, that combinationcannot be specified in another version. Backup versions are the exception to this rule.

In one version only, you can enter an asterisk (*) in the Release field. This version will be usedif no other version has release data that matches that of the target system.

Backup. To exclude a version from the version search, select Backup. This prevents the versionfrom being executed by a test configuration or REF command. It can only be executed from thetest script editor.

Extra Planning Data. You can enter an estimate of the time needed for the test and also assign a

priority.



Administrative Data. This is automatically entered.

RestrictionsOn this tab, you can document the restrictions on where and how the test script is used. You can enterinformation in the following categories:

Technical Information

Dependencies

Use as



Using TCD (Record) to Record TransactionsUseYou use TCD (Record) to record all the entries and functions in transactions.

To help decide between using TCD (Record) or SAPGUI (Record), see eCATT Drivers [Page 13].

Procedure1. In the test script editor, choose the Editor tab.

2. Choose Pattern.

The Insert Statement dialog box appears.

3. From the Command dropdown list, choose TCD (record).

4. In the Transaction field, enter the transaction code of the transaction that you want to record, andchoose .

In the Interface field, a system-generated name appears.

5. Accept the system-generated name or edit it.

6. If there is a system data container, you can enter the target system in the Target System field.

7. Choose .

The transaction starts.

8. Work through the transaction as normal.

When you leave the transaction, the system returns you to the script editor with the Recordingended dialog box.

9. Choose Yes to transfer the data.

ResultA TCD command and its associated command interface is inserted in the test script. The test scriptcan be executed as is. Alternatively, you can parameterize it, enhance it with other eCATT functions,and so.



TCD Command InterfaceField Description

TCODE Transaction code.

MODE Processing mode. Possible values: A, N, E, X,or Y. See Start Options.

BINPT Batch input mode. Set by X.

WAIT Wait factor. This simulates the time required fora user to enter a character. It is only usedwhen in processing mode N. Unit is 0.1second. For example, a value of 5 simulates0.5 seconds for each character.

Screen ModesScreen modes before execution are visible in the structure editor. Screen modes after execution arevisible in the XML data in the log.

Screen Modes Before ExecutionDynpro Mode Meaning

D Inactive.

X Active.

Screen Modes After ExecutionDynpro Mode Meaning

D Inactive.

K Skipped. It was dynamically deactivated.

0 Not executed.

1 Finished. There were no field checks to do.

2 Finished. All field checks are correct.

3 Finished. Some field checks are not correct.

4 Finished. Some field checks were not done.

Field ModesField modes before execution are visible in the structure editor. Field modes after execution are visiblein the XML data in the log.

Field Modes Before ExecutionField Mode Meaning

C Check.

G Get

S Set

I Input

O Output.



Field Modes After ExecutionField Mode Meaning

Z Field check was skipped dynamically.

5 Check was correct

6 Check was not correct.

7 Field was not checked.

G Get returned.

8 Get did not return.

S Set was performed.

P Set was not performed. It was preventeddynamically.

Messages

Do not use the structure editor to parameterize messages.

All messages sent by a transaction are stored in an internal table called MSG. You can view themessages in the log.

MSG has the following fields:

Field Description

TCODE Transaction code from which the message wassent.

DYNAME Program name.

DYNUMB Screen number.

MSGTYP Message type.

MSGSPRA Message language.

MSGID Message class.

MSGNR Message number.

MSGV1 First variable part of message.

MSGV2 Second variable part of message.

MSGV3 Third variable part of message.

MSGV4 Fourth variable part of message.

ENV Monitoring activities for batch input.

FLDNAME The full text of the message.

To pass messages to parameters in the test script, use the script editor and the following syntax: = -MSG[]-.

The number of messages sent by the transaction is contained in the eCATT variable &MSX.

You can access all the messages from a transaction.DO &MSX.

LOG ( -MSG[&LPC]-FLDNAME ).



ENDDO.



Screen SimulationUseIf a transaction has been recorded using TCD (Record), you can display the screens of the transactionin the screen simulation. You can use the screen simulation to edit and parameterize fields. If you dothis, the appropriate entries are made automatically in the parameter list and the structure editor.

Assigning Values to FieldsIf a field was set in the Menu Painter to be ready for input, it is also ready for input in the screensimulation. This is the case even if the transaction dynamically set the field otherwise.

To ensure that only values are entered in these fields, you should put values in all relevantfields when recording a transaction.

1. Enter values in the required fields.

Space characters (to delete field default values) can be passed by entering twoapostrophes ( ' ' ).

2. Choose .

Inserting Import Parameters1. If the field has a value assigned already, clear the field.

2. Select the field and choose .


3. In the Param. Name field, enter a name for the parameter. If this parameter does not exist, it isautomatically created.

4. In the Field contents field, enter a default value.

5. Choose .

6. Choose .

Inserting Export Parameters1. If the field has a value assigned already, clear the field.



3. In the Param. Name field, enter a name for the parameter. If this parameter does not exist, it isautomatically created.

4. Choose .

5. Choose .



The parameter is filled at the end of the transaction. You cannot use it in the sametransaction as an import value for a subsequent screen.

Define Field CheckYou can check whether the runtime value of a field is the expected value. The check value can be aconstant or a parameter.

1. If the field has a value assigned already, clear the field.


3. A dialog box appears.

4. Define the check by one of the following:

a. In the Param. Name field, enter a name for the parameter. If this parameter does not exist, it isautomatically created as an import parameter.

b. In the Field contents field, enter a default value.

5. Choose .

6. Choose .



Using SAPGUI (Record) to Record TransactionsUseUse SAPGUI (Record) to record transactions that contain controls.

During the course of recording, one or more SAPGUI commands are created in which changes to thestate of the screen elements are recorded. You can choose to have these created automatically ateach token change, screen change, transaction change, or session. You can also at any point duringthe recording choose Enter SAPGUI Command to generate a SAPGUI command manually.

PrerequisitesSAPGUI 6.20 must be installed on the same machine that the test script is running on.

Scripting support has been installed and is active.

Procedure1. In the test script editor, choose Pattern.

The Insert Statement dialog box appears.

2. From the Command dropdown list, choose SAPGUI(Record).

A system-generated name appears in the Interface field. If a maintenance system is specifiedon the Attributes tab, a system-generated name appears in the Target System field.

3. Accept or edit the system-generated names.

4. Choose .

The Record SAP GUI Command dialog box appears. In this box you can set the recordingmode. You can change the mode while recording.

5. Select one of the following recording modes:

a. Manual. A SAPGUI command is only generated when Enter SAPGUI Command is chosen.

b. At each dialog step. Every communication between front end and backend creates a separateSAPGUI command.

c. At each screen change. Each screen change creates a separate SAPGUI command.

d. For each transaction. Each transaction change creates a separate SAPGUI command.

e. For each session. The data for each session is recorded in a separate SAPGUI command.

6. Choose Start Recording.

A new session is automatically started. A new Record SAP GUI Command dialog box appearsin the first session.

7. Choose Yes.

The Recording Running... dialog box appears. It will remain available during the recording.You can change the settings at any time during the recording.

a. You can change the recording mode and confirm the change by choosing Change RecordingMode.

b. You can generate a new SAPGUI command by choosing Enter SAPGUI Command.

c. You can record the initial state of selected types of screen elements. This can generate a lotof data, so be selective about what and when you record.

8. In the second session, start the transaction.

9. Work through the transaction as normal.

10. In the first session, choose End Recording.



The SAPGUI commands and their corresponding command interfaces are entered in the testscript.



Checking Initial StatesYou can choose to record the initial states of selected types of screen elements. The RecordingRunning ... dialog box is always available during recording. The part of the dialog box relevant tochecking initial values is shown below.

If either Record with Active Checks or Record with Inactive Checks is selected, the initial states of theselected screen elements are recorded.

With Record with Active Checks the check flags are set. With Record with Inactive Checks the checkflags are not set. Irrespective of which option you choose, you can later manually change the status ofthe flags in the structure editor.

At any time you can change the settings in Recording Running ... popup. This allows you to optimizethe amount of data recorded. For example, if you are only interested in the contents of input/outputfields on the final screen of a transaction, you can record only these. For the changes to take effect,you should choose Activate mode for initial states.

ExampleAn example of a command interface taken from a recording of transaction SE37 (Function Builder) isshown below.



Under the InitialState node, you can see that the flag in each Check node, down to and including thescreen element, is set. If any of these were not set, the check would not be made when the script isexecuted.

The name of the screen field (RS38L-NAME) is from the ABAP Dictionary.

The value against which the actual value during replay will be checked is that of the CheckValue node.This is by default the recorded value. However, you can parameterize it or replace it with another fixedvalue.



Re-Recording with SAPGUI CommandsUseWhen you have recorded a transaction and there are errors, you can use this procedure to re-record asection of the transaction.

Procedure1. In session 1, open the test script for editing.

2. Execute the test script and examine the log to identify the last SAPGUI command before thesection containing the errors.

3. Go back to the test script editor and comment out all the commands after the end of the error-freesection.

4. Choose .

5. Start a new session (session 2).

6. In session 2, start transaction SECATT.

7. In session 1, set the cursor after the last error free SAPGUI command and choose .

8. In the Record SAPGUI Command dialog box, set the granularity of the recording and choose StartRecording.

9. In session 2, enter the name of the test script and choose .

10. In the Close GUIs field of the Start Options dialog box, select Do Not Close Generated Sessions,then choose .

A new session starts automatically (session 3).

11. Wait until the execution in session 2 is finished.

12. In session 1, in the Record SAPGUI Command dialog box, choose Yes to record the new session.

The Recording Running dialog box appears.

13. In session 3, work through the transaction.

14. In session 1, choose End Recording.

The new SAPGUI commands are now in the test script.

15. In session 1, choose .

16. The connection and session IDs in the newly recorded command interfaces must be identical tothose in the preceding SAPGUI command. If necessary edit the new command interfaces.



Notes on the Playback of SAPGUI CommandsSAPGUI commands can be placed in a MESSAGEENDMESSAGE block. If an error that wouldnormally cause a termination occurs, depending on the start options the execution jumps to theENDMESSAGE command and continues from there.

You can define checks in InitialState nodes. For a check to occur, the complete path to the element tobe checked must have the Check attributes set (with 'X').The InitialState node has a get function. An element in an InitialState node is always supplied with thevalue that appears during playback. If you enter a parameter in the appropriate Value field, thatparameter will be supplied with the actual value.

Values in the UserChangedState node can be supplied with fixed values or parameters.

Message popups that appear during runtime but not during recording, are automatically closed so thatthey do not invalidate the test script.



SAPGUI Command InterfaceThis example illustrates the main features of the SAPGUI command interface.

Header Data

If the ResetGUI contains 'X', the transaction specified in ProcessedScreen[1] will be started anew.Where several transactions have been recorded, set the ResetGUI flag in the first SAPGUI commandfollowing each change of transaction.

ConnectionID and SessionID uniquely identify the sessions during replay. When everything should runin the one session, all the SAPGUI command interfaces must have the same SessionID andConnectionID.

SystemInfo is only for logging purposes. It is overwritten during replay.

ProcessedScreen Node

Active.

If the flag is not set, ProcessedScreen will not be executed.

If 'X', ProcessedScreen will be executed.



If 'O', ProcessedScreen will only be executed if the screen actually appears.Transaction contains the transaction code.

Program contains the program name.

ScreenNumber contains the screen number.

InitialState contains the recorded initial states of the GUI elements.

Message contains the recorded messages.

UserChangedState contains the changes, made by the user, to the state of the GUI elements.

UserChangedState Node

If you want a field to be available for parameterization in the command interface, you must edit itduring recording.

Message Node



If AsPopup contains 'X', the message is a popup.Messages can be handled by enclosing SAPGUI commands in an MESSAGEENDMESSAGE block.

InitialState Node

The complete hierarchy of GUI elements down to the element to be checked is shown in theInitialState node. At each level there is a Check node where you can turn on ('X' ) or off the checks forall underlying GUI elements.

You can parameterize CheckValue.

In the log, the actual value of the GUI element appears beside the Value node.



ParametersParameters are a test scripts import and export interfaces, and also the local variables. Within a testscript, the parameters behave in a similar manner.

VisibilityThe visibility determines whether a parameter is an import parameter, an export parameter, or a localvariable. You set the visibility in the parameter list.

Local variables can be used inside inline ABAP blocks. Import and export parameters cannot be usedinside inline ABAP blocks.

Import parametersImport parameter values are passed when a test script is called, and are available locally in the testscript. They can have default values which are used if no other value is passed in the call.

Import parameters are version-independent that is, if you create a parameter in one version, it existsin all versions. This is important because it ensures a consistent interface for the test script.

Export parametersYou can assign the test script result to an export parameter, which can be passed to a variable in thecalling test procedure when you return from a test module.

Export parameters are version-independent that is, if you create a parameter in one version, it existsin all versions. This is important because it ensures a consistent interface for the test script.

Local variablesLocal variables are used in test cases for calculations, or to receive export parameters from referredtest cases or called function modules. They are also used for passing values to and from inline ABAPblocks.

Local variables are version-dependent that is, a local variable defined in one version is notautomatically defined in another version. For example, a parameter with a given name might bedefined as type C in one version, type I in a second version , and not exist at all in a third version.

Naming conventionNames are alphanumeric strings up to 30 characters long. The first character must be a letter or anunderscore.



Special VariablesSystem FieldsThe system fields contain system information. They are read-only. You can use any of the ABAPsystem fields in the command editor. The names of the system fields are in the ABAP Dictionarystructure SYST.

LOG ( SY-UZEIT ).

eCATT VariableeCATT variables are read-only.

You can use eCATT variables in the command editor.

LOG ( &TIME ).

You can use eCATT variables in the parameter list as default values for simple input parameters.

General Variables

Variable Description&CLIENT Logon client.

&DBSYS Database system of the target system.

&GUITYPE Current GUI type. The possible values are:WINGUI, JAVAGUI, and HTMLGUI.

&HOST Target on which the script was executed.

&LANGUAGE Logon language.

&OPSYS Operating system of the target system.

&SAPRL Basis release of the target system.

&SYSTEM Target system.

&USER User name.

Test Script Variables

Variable Description&EXCEPTION Exception of a function module called by the

FUN command.

&LOGID Log number.

&LPC Current value of the loop count in anDO...ENDDO loop.

&REFLEVEL Nesting level of a referenced test script.

&REFNAME Name of a referenced test script.

&REFVERSION Version of a referenced test script.

&SCRIPTNAME Name of the test script.

&SCRIPTVERSION Version of the test script.



&SUBRC System field SY-SUBRC.

&VARID Variant name.

Date and Time Variables

Variable Description&TIME Current time in the format HHMMSS.

&DATE Current date in the format YYYYMMDD.

&YEAR Current year in the format YYYY.

&YEARB Previous year in the format YYYY.

&YEARA Next year in the format YYYY.

Message Variables

Variable Description&M01 First variable text from the last message after a

TCD command.

&M02 Second variable text from the last messageafter a TCD command.

&M03 Third variable text from the last message aftera TCD command.

&M04 Fourth variable text from the last message aftera TCD command.

&MSG The last message after the TCD or FUNeCATT commands.

&MS1 First variable text from the last message.

&MS2 Second variable text from the last message.

&MS3 Third variable text from the last message.

&MS4 Fourth variable text from the last message.

&MST The message type of the last message.

&MSI The message ID of the last message.

&MSN The message number of the last message.

&MSX The number of messages.

You can access all the messages from a transaction.DO &MSX.

LOG ( -MSG[&LPC]-FLDNAME ).ENDDO.



eCATT CommandsAn 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.

You can have several commands on the same line. Comments (*), assignments (=), and inline ABAPare exceptions to this rule.

Command Set* [Page 55]

= [Page 56]

ABAP [Page 59]

CHETAB [Page 60]

CHEVAR [Page 61]

CLEAR [Page 62]

DO [Page 63]

ELSE

ELSEIF

ENDABAP

ENDDO

ENDIF

ENDMESSAGE

EXIT [Page 70]

FUN [Page 72]

GETTAB [Page 73]

IF [Page 74]

LOG [Page 76]

MESSAGE [Page 77]

ON_LAST_MESSAGE_CHECK [Page 79]

REF [Page 80]

REFCATT [Page 81]

REFEXT [Page 82]

REMOTECATT [Page 83]

RESTAB [Page 85]

SAPGUI [Page 86]

SENDEXT [Page 87]

SETTAB [Page 85]

TCD [Page 89]

WAIT [Page 90]

WAIT_ON_DYNPRO [Page 91]



*UseAn asterisk designates a comment line. The asterisk must be the first character on the line. In thescript editor, a comment line is colored blue.

Example* This is a comment line

* This is not a comment line



=UseExpressions = .

The assignment operator assigns the result of the expression on the right to the parameter on the left.

The expression can contain the arithmetic operators or the concatenation symbol:

Operator Description

+ addition

- subtraction

* multiplication

/ division

& concatenation

You can use parentheses to specify the order in which the components of an expression areevaluated.

You can specify the offset and length for character strings. The offset and length can be specified withvariables: = +().

Assigning Structured ParametersComplete structures can be assigned: = .

Complete tables can be assigned: = .

A table row can be assigned: = [].

An individual field of a table can be assigned: = []-.



Examples for the Assignment Operator (=)Simple ArithmeticI1 = 2.

I2 = 3 * ( I1 + 1 ) / ( I1 - 1 ).

Result: I2 has the value 9.

Character StringsC1 = abcd.

C2 = efgh.

C3 = C1 & C2.

C4 = C3+2(4).

Result: C4 has the value ' cdef '.

DatesSome calculations involving dates are not valid.

Dates are represented by parameters of type D, which have the format yyyymmdd (years, months,days).

A number of days can be represented by parameters of type I, P, N, or C (with numeric content).

Valid calculationsDate shifted by a number of days:DATE2 = DATE1 - NUMBER1.

20010823 - 10 gives 20010813DATE2 = DATE1 + NUMBER1.

20010823 + 10 gives 20010902

Difference in days between two dates:NUMBER1 = DATE1 - DATE2.

20010813 - 20000618 gives 421

If DATE2 is greater than DATE1, NUMBER1 is negative if type I, P, or C, but positive if type N.

TimesSome calculations involving times are not valid.

Times are represented by parameters of type T, which have the format hhmmss (hours, minutes,seconds).

A number of seconds can be represented by parameters of type I, P, N, or C (with numeric content).

Valid calculationsTime shifted by a number of seconds:TIME2 = TIME1 - NUMBER1.

235930 - 31 gives 235859TIME2 = TIME1 + NUMBER1.

235930 + 31 gives 000001

Difference in seconds between two times:



NUMBER1 = TIME1 - TIME2.

104050 - 103030 gives 620

If TIME2 is greater than TIME1, TIME3 is negative if type I, P, or C, but positive if type N.



ABAPUseABAP.

The ABAP command introduces a block of ABAP statements. The block must end with ENDABAP.ABAP statements within an ABAP...ENDABAP block are called inline ABAP. Only ABAP statementsare permitted within the block. No other statements are permitted on the same line as this command.

You can reference local variables from within an ABAP...ENDABAP block. If you want to pass valuesfrom inline ABAP to import or export parameters, do it through local variables.

You can have more than one inline ABAP block in a test script. Data declared in one inline ABAPblock are not visible in the other inline ABAP blocks.

The inline ABAP is executed in the system to which the test script is allocated at runtime.

The contents of an inline ABAP block are not checked by the eCATT syntax checker.

ExampleIn this example, inline ABAP is used to read a record from a table and assign a value to an eCATT-defined parameter (CARRIER_ID).ABAP.

TABLES spfli.

DATA wa_spfli TYPE spfli.

SELECT SINGLE * FROM spfli INTO wa_spfli.

CARRIER_ID = wa_spfli-carrid.

ENDABAP.

LOG ( CARRIER_ID ).



CHETABUseCHETAB ( , ).CHETAB ( , , ).

The CHETAB command compares field values in a database table with values that you specify in thecommand interface (the command interface has the same structure as the table). You can use it tocheck:

Database updates after transactions

Whether a particular table entry exists

Customizing table entries

You specify the values of the fields in the command interface. You are not restricted to using the keyfields. You do not have to specify the complete key. However, you should not leave a key field empty:enter an asterisk in each key field for which you do not assign a value.

If no record that satisfies the search criteria is found, an error message is entered in the log.

If one or more records are found, the check is entered in the log as successful.

You can specify which system the database table is in. If you specify a target system, the test script orthe test configuration must have an appropriate system data container.

Procedure1. In the command editor, enter CHETAB ( , ).

2. Double-click .

The command interface appears in the structure editor.

3. In the structure editor, enter the values that you want to check. Make sure that each of the keyfields is filled with a value, parameter, or an asterisk.



CHEVARUseCHEVAR ( ).

The CHEVAR command checks the value of a simple parameter against another simple parameter orfixed value.

If the check is not successful, an error message is entered in the log.

The allowed comparison operators are:

Operator Meaning= equal to

not equal to

< less than

greater than

>= greater than or equal to

You can construct complex logical expressions using the following operators:

Operator MeaningAND Boolean AND

OR Boolean OR

NOT Boolean NOT

NOT takes priority over AND. AND takes priority over OR. However, you can use parentheses tospecify the processing sequence.

ExampleCHEVAR ( a = 0 ).



CLEARUseCLEAR ( ).

This function clears the contents of the parameter that is, it initializes the given field or fields. can be a:

Simple parameter

Field of a structured parameterCLEAR ( - ).

Complete structureCLEAR ( ).

Complete table rowCLEAR ( [] ).

Complete tableCLEAR ( ).



DOUseDO .

This command starts a loop. defines the number times the loop will be executed and canhave a value of up to 9999. The loop must end with an ENDDO command.DO .

ENDDO.

must be either fixed numerical value or a parameter with a numerical content.

You can use EXIT [Page 70] to conditionally terminate the loop. The exit condition is checked in eachloop iteration. If the condition is satisfied, the loop is immediately ended and the statement afterENDDO is executed.

DO loops can be nested.

ExampleDO 5.

Counter = Counter + 1.

EXIT ( Counter = 3 ).REF ( XYZ , XYZ_1 ).ENDDO.



ELSEUseELSE.

This command can only be used within an IF...ENDIF block. See IF [Page 74].



ELSEIFUseELSEIF ( ).

This command can only be used within an IF...ENDIF block. See IF [Page 74].



ENDABAPUseENDABAP.

This command terminates an ABAP...ENDABAP block. No other statements are permitted on thesame line as this command. See ABAP [Page 59].



ENDDOUseENDDO.

This function terminates a DO...ENDDO block. See DO [Page 63].



ENDIFUseENDIF.

This command terminates an IF...ENDIF block. See IF [Page 74].



ENDMESSAGEUseENDMESSAGE ( ).

This command terminates a MESSAGEENDMESSAGE block. See MESSAGE [Page 77].

The total number of messages generated in a MESSAGE...ENDMESSAGE block can be found in theMIDX field of the first line of the command interface. For example, to log the total number ofmessages, use LOG ( [1]-MIDX ).



EXITUseEXIT ( ).

You can use this command to conditionally exit a DO loop or a test case.

If the EXIT condition is not satisfied, the next statement is executed. If the condition is satisfied:

Inside a DO...ENDDO loop, the next statement after the ENDDO is executed.

Inside a test case that has been called by the REF command, the next statement after the REFstatement, in the calling test case, is executed.

In a test case itself, the test case is ended.

ConditionsTo formulate conditions, you can use logical expressions containing the following operators:

Operator Meaning= equal to

not equal to

< less than

greater than

>= greater than or equal to

AND Boolean AND

OR Boolean OR

NOT Boolean NOT

Simple conditions have the form:

You can combine several logical expressions into a single logical expression. If the single logicalexpression is true:

Only if all of the component expressions are true, link the expressions with AND.

If at least one of the component expressions is true, link the expressions with OR.

To negate the result of a logical expression, you can precede it with the NOT operator.

NOT takes priority over AND. AND takes priority over OR. However, you can use parentheses tospecify the processing sequence.

Leave a space before and after a parenthesis.

ExampleEXIT ( NOT ( A < B AND A > D ) ).



FUNUseFUN ( , ).FUN ( , , ).

The FUN command executes a function module.

The values for EXPORTING, IMPORTING, TABLES, CHANGING, and EXCEPTIONS, are passed bymeans of the command interface.

If a function module raises an exception, the name of the exception is logged.

Normally, a function module raising an exception is marked in the log as having an error. To preventthis, enter 'X' in the exception's Value field.

Procedure1. In the command editor, enter FUN ( , ).

2. Double-click .

The command interface appears in the structure editor.

3. In the structure editor, enter the appropriate values in the fields. These values can be parametersor fixed values.

NotesUI-oriented value conversions (such a

ecatt620

Documents