eCATT Tutorial

Blogs

eCATT - An Introduction (PART I)Sapna Modi Business CardCompany: Larsen &Toubro Infotech Ltd.Posted on Apr. 10, 2006 08:59 PM in Application Server, Emerging Technologies

What Is eCATT?

eCATT is a SAP Testing Tool, which can be used to automate & test business

scenarios in R/3. One can create and execute the eCATT scripts based on

business processes mapped in R/3. These scripts can be then tested before go

live to Production server. If needed eCATT can be used in production server also

provided exact functionality of its usage should be known. After testing, eCATT

generates a detailed log depending on the processes executed. If the testing is

smooth with success mode, this means the business scenarios mapped in R/3

system are correct. And if the test results in error than one can analyze the

problems from the generated error log. Thus helps in analyzing the error.

What Are The Various Ways Of Doing Testing?

Testing can be done by various ways like Manually, using CATT etc.

Why To Use eCATT?

CATT will be no longer supported for the creation of new development. So those

using CATT are forced to update to use eCATT. Comparative to manual testing,

the following are advantages of using eCATT –

Due to automation, testing time is reduced to a large extent.

Due to automation, less manpower is required for testing. This helps financially.

Due to automation, manual errors are reduced to large extent. Hence results in

error free testing. This helps, as no further problems will occur while the usage

of R/3 system by end users and hence increases the efficiency.

Proved to be extremely useful in Rollout projects.

eCATT Prequisites:

Web Application Server (WAS) 6.20 or more.

SAPGUI 6.20 or more.

R/3 4.6C or more. (Target system must have sufficient support package level

(Details available in SAP Note 519858) or SAP R/3 Enterprise Release 4.7.

SubscribePrintPermalinkShare

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/u/37984

http://www.addthis.com/bookmark.php?v=250&username=scnblogs

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3334


http://weblogs.sdn.sap.com/pub/q/weblogs_rss?x-ver=1.0&x-mimetype=application%2Frdf%2Bxml


http://weblogs.sdn.sap.com/pub/t/21


http://www.sdn.sap.com/irj/scn/bc?u=79NNCnlBWVE%3D



http://www.addthis.com/bookmark.php?v=250&username=xa-4beb58fc35fc4a1b

Before creating Test Scripts using eCATT, some system settings need to be done

–

Maintaining Table T000

o Start transaction SM31, Maintain Table Views.

o In the Table/View field, enter T000.

o Choose Maintain.

o In the Change View Clients, Overview screen, select the relevant client

and choose.

o In the Restrictions when starting CATT and eCATT field, select an entry

that allows eCATT.

Enabling Scripting at the front End. (Check whether SAP GUI Scripting

component is installed. There is an option for installing this component when

installing the SAP GUI.)

o On any screen, choose Customizing of local layout from the Standard

Toolbar.

o Choose Options.

o Choose the Scripting tab.

o Select Enable Scripting.

o Choose Apply.

Enabling Scripting on application server.

o Start transaction RZ11.

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

o Choose Display.

o In the Display Profile Parameter Attributes screen, choose Change value

from Application Toolbar.

o Enter TRUE in the New value field.

The R/3 users executing eCATT scripts should have RFC authorizations.

Features Available In eCATT:

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.

Integrated with Test Workbench, so allows proper management of scripts using

SCAT transaction.

Supports CATT migration to eCATT.

All eCATT Objects are Repository Objects. Therefore one can take advantage of

Standard SAP Transport Tools.

eCATT Objects can easily download & upload in XML with XSD format.

There can be several versions of Test Scripts, which allows different

implementations with different releases.

The separation of Test Scripts, Test Data & System Data allows for a

considerable degree of reuse.

Ways Of Doing Testing In eCATT:

eCATT enables to test all mySAP applications, including those running outside of

SAP GUI for Windows and SAP GUI for Java. There are four different drivers

available in eCATT for this testing purpose as follows –

Non-User Interface:

Suitable for testing backend R/3 specific modules like function modules &

BAPIs, Interfaces testing in mySAP environment, load testing.

TCD:

Suitable for testing transactions (especially who don’t involve activex

controls), load testing. Doesn’t require GUI for playback, so offers

maximum speed for testing.

SAPGUI Scripting:

Suitable for testing transactions, who involve activex controls. Requires

GUI for playback & hence very slow. Not suitable for load testing.

Interface To External Tools:

External products, which are certified against BC-eCATT Interface, can be

tested who run under GUIs (Other than SAP GUI for Windows & SAP GUI for

JAVA) using eCATT.

Transaction For Using eCATT:

Choose SAP menu-> Test->Test Workbench->CATT->Extended CATT.

Transaction code – SECATT.

Editors Available In eCATT From SECATT Transaction:

Test Configuration Editor:

Used to maintain Test Configuration object. Test Configuration data object

contains set of reference to a Test Script, System Data Container &

several Test Data Containers. It contains all the information necessary to

run an automatic test without further user interaction.

Test Script Editor:

Used to create & maintain Test Scripts. There are some recording

functions available in this editor. Test Script Editor has following areas:

Application Toolbar.

Information Area

Editor Tab –

Parameter List

Command Editor

Structure Editor

Attribute Tab

Test script data object contains an executable script & an interface for

data transfer.

Test Data Editor:

Used to create & maintain the Test Data Containers. Test Data Containers

are the data objects, which contain a set of parameters that can be

maintained independently of a test script. Parameters can be ABAP simple

types, structures, or tables.

System Data Editor:

Used to create & maintain the System Data Containers. System Data

Containers are the data objects, which identify instances of SAP systems.

They can be maintained independently of the test script like Test Data

Containers.

Sapna Modi is a Software Engineer.

http://weblogs.sdn.sap.com/pub/u/37984

Blogs

eCATT Scripts Creation – TCD Mode (PART II)Sapna Modi Business CardCompany: Larsen &Toubro Infotech Ltd.Posted on Apr. 10, 2006 09:00 PM in Emerging Technologies, Application Server

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 will be explained in detail. In the subsequent Parts, SAPGUI recording

mode of recording and other details of eCATT will be covered.

Steps Involved In Creation Of eCATT Test Scripts:

Test script is generally series of steps (transactions) involving a business

scenario. Identification of right transactions for this script, which prepares the

input data for the script and also covers the planned business scenario, should

be done.

Recording of test script by selecting proper recording mode.

Execution of test script immediately after recording without parameterization to

confirm the errorless recording.

Parameterization of the import, export & variable parameters.

Preparing variants using Test Data Container.

Linking Test Script (TS) & Test Data Container (TD) by Test Configuration (TC).

Execution of TS using TC for different Variants.

How To Identify Any Transaction For TCD Recording Mode:

If the transaction runs under SAP GUI for Windows or SAP GUI for Java, it can be

recorded by either TCD or SAP GUI mode.

If the transaction doesn’t have any activex controls then TCD recording mode

can be used.

If the transaction has activex controls and these controls are NOT mandatory for

the functionality of the transaction, then also TCD mode can be used as

recording mode.

Key Features Of TCD Recording Mode:

It is suitable for the transactions not having activex controls, so it doesn’t

require any GUI playback mode.















It is very fast.

It has its own built in screen simulation for standard screen elements. Hence

while execution, the controls are deactivated and the user’s actions are

simulated by reading the recorded data flow.

Steps For Recording Using TCD Mode:

Transaction SECATT.

Give the name of the Test Script (TS) in Test Script input box. The Version input

by default is with value 1.

In the Attributes ->General Data Tab, the value of the Component will be BC-

TWB-TST-ECA for eCATT.

In the test script editor, choose the Editor tab.

Choose Pattern button from the application toolbar.

The Insert Statement dialog box appears.

From the Command Dropdown List, choose TCD (Record).

In the Transaction field, enter the transaction code of the transaction that you

want to record, and choose Enter.

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

Accept the system-generated name or edit it.

If there is a system data container, you can enter the target system in the

Target System field.

Choose Enter.

The transaction starts recording.

Work through the transaction as normal.

When you leave the transaction, the system returns you to the script editor with

the Recording ended dialog box.

Choose Yes to transfer the data.

A TCD command and its associated Command Interface will be inserted in test

script editor of SECATT.

Execution of Recorded TCD script:

Once the recording of the transaction is done and the details of recording are

taken back to the test script editor, script can be executed.

First of all without parameterization the script should be executed to confirm the

errorless recording. At the runtime, a Start Options window appears. Give the

following values on this window –

o Error Behavior with value S No termination, continue with next script.

o System Data – Name of the system data container, which contains the

Target System.

o Target System – Name of the server on which the execution will happen.

o Select the Log Display check box.

o In TCD section of window, select N – Process in background, synchronous

local.

o Click on Execute button.

Transaction will start executing, which appears at the bottom.

If the recording is error free, then success log will appear. And if there is any

error in recording of the transaction and its replay then error log with details will

appear.

After the confirmation of error free recording, one can go ahead with

parameterization of the import, export & variables.

In SECATT transaction using Test Data (TD), variants can be prepared for the

recorded test script. In the Parameters tab, add all the parameters from the test

script. This will appear as ECATTDEFAULT in the Variants tab. Add multiple

variants, as per requirement in the Variants tab. Test Data is independent of

test script. Hence can be reused wherever required.

In SECATT transaction using Test Configuration (TC), the TD & TS can be linked

together on the Configuration tab. On the Variants tab, using Variant

Maintenance Assistant required variants values from TD could be linked to TC.

Finally the TC can be executed from SECATT directly by giving the required

variant name at runtime.

The TC is used in managing the scripts in plans/packages using SCAT

transaction.



Blogs

eCATT Scripts Creation - SAPGUI Mode (PART III)Sapna Modi Business CardCompany: Larsen &Toubro Infotech Ltd.Posted on Apr. 10, 2006 09:01 PM in Emerging Technologies, Application Server



recording is explained in detail. In the Part III, the creation of eCATT Scripts

using SAPGUI mode is explained in detail. In the subsequent Parts, Management

of eCATT scripts via Test Workbench and other details of eCATT will be covered.

Steps Involved In Creation Of eCATT Test Scripts:

Test script is generally series of steps (transactions) involving a business

scenario. Identification of right transactions for this script, which prepares the

input data for the script and also covers the planned business scenario, should

be done.

Recording of test script by selecting proper recording mode.

Execution of test script immediately after recording without parameterization to

confirm the errorless recording.

Parameterization of the import, export & variable parameters.

Preparing variants using Test Data Container.

Linking Test Script (TS) & Test Data Container (TD) by Test Configuration (TC).

Execution of TS using TC for different Variants.

How To Identify Any Transaction For SAPGUI Recording Mode:

If the transaction runs under SAP GUI for Windows or SAP GUI for Java, it can be

recorded by either TCD or SAP GUI mode.

If the transaction doesn’t have any activex controls then TCD recording mode

should be used. Here SAPGUI mode can also work.

If the transaction has activex controls and these controls ARE MANDATORY for

the functionality of the transaction, then only SAPGUI mode can be used as

recording mode.

Key Features Of SAPGUI Recording Mode:















It is suitable for the transactions having activex controls, so it requires GUI

playback mode.

It is slow comparative to TCD recording mode.

It is not suitable for load testing.

Steps For Recording Using SAPGUI Mode:

Transaction SECATT.

Give the name of the test script (TS) in Test Script input box. The Version input


In the Attributes ->General Data Tab, the value of the component will be BC-


In the Attributes ->General Data Tab, the values of the SystemDataContainer

should be given which contains all target systems with RFCs on which the script

will be either executed or recorded & in the TargetSystem the name of target

system (e.g. recording R/3 server) should be mentioned.

In the test script editor, choose the Editor tab.

From the Application Toolbar, click on Record Test Script (Ctrl+F5).

One window appears with title ‘Record SAP GUI Command’, select each check

box of the Automatic Generation section. Click On Start Recording button.

Login in to Target System from SAP Logon or either create a new session on

target system.

One window appears on the newly created session of target system as ‘Record

SAP GUI Command’. Click on Yes for recording.

One window with title ‘Recording Running’ will appear. In the section of Record

initial state for value check, select the Record with inactive checks radio button.

Below the radio buttons, one table control with the record/ types for GUI

elements is mentioned along with check boxes. Select all the check boxes.

Select the check box of Closed Recorded GUIs and click finally the Continue

(Enter) button. This recording window exists till recording ends. Lots of data of

initial state for the mentioned screen element types will be generated. So one

can be selective in selecting the checkboxes.

Recording can be started with the transaction working as normal on the newly

generated session.

Once the transaction is complete with the functionality, from the Recording

Running window, click on End Recording button. This will take the recorded

details of the transaction to SECATT transaction in the test script editor.

A SAPGUI command and its associated Command Interface will be inserted in

test script editor of SECATT.

Execution of Recorded SAPGUI script:

Once the recording of the transaction is done and the details of recording are

taken back to the test script editor, script can be executed.

First of all without parameterization the script should be executed to confirm the

errorless recording. At the runtime, a Start Options window appears. Give the

following values on this window:

o Error Behavior S No termination, continue with next script.


Target System.



o In SAPGUI section of window, select following options:

Procg Mode SAPGUI - S Synchronous GUI Control

Error Mode for SAPGUI - C Continue (Continue on Any Error)

Stop When - N Do Not Stop

Close GUIs - R Close Generated Sessions After REF


Transaction will start executing, by creating a new session. This requires GUI for

playback.



appear.

After the confirmation of error free recording, one can go ahead with

parameterization of the import, export & variables.





test script. Hence can be reused wherever required.





variant name at runtime.


transaction.



Blogs

eCATT Chaining, Parameterization, Creation Of Test Data,Test Configuration, System Data (PART IV)Sapna Modi Business CardCompany: Larsen &Toubro Infotech Ltd.Posted on Apr. 18, 2006 08:17 PM in Emerging Technologies, Application Server



recording is explained in detail. In Part III, SAPGUI recording mode of recording is

explained in detail. In Part IV chaining, parameterization, creation of Test

Configuration, Test Data Container, and System Data Container will be explained

in detail and in subsequent parts the management of eCATT Scripts via

Testworkbench & other details of eCATT will be covered.

What Are Parameters:

Parameters are export, import interfaces or local variables of a script. Parameter

name can be 30 char long. The first letter should be either an underscore or

character.

Their visibility within the script is same and outside it is of import parameter,

export parameter or local variable. The visibility can be set from the parameters

list.

ONLY local variables can be used in the inline ABAP block in the test script

editor. Import & Export parameters CANNOT be used in the inline ABAP block.

Import Parameters (IP): Import parameters are input values to the script. They

are passed to the script during execution. They are locally available and test

script version independent. Import parameters can hold default value also.















Export Parameters (EP): Export parameters are outcome of the test script

execution. The result value is passed into the export parameter when the test

returns from the test module. They are test script version independent.

Local Variables (LV): Local variables are used in test scripts for calculations, or

to receive export parameters from referred test cases or called function

modules. They are also used for passing values to and from inline ABAP blocks &

are version-dependent – that is, a local variable defined in one version is not

automatically defined in another version.

System fields can also be used in command editor. They are read-only and are

available from SYST structure.

There are special read-only eCATT variables, which can also be used in

command editor. e.g. &YEARB, &YEARA, &YEAR, &VARID, &USER, &TIME,

&SYSTEM, &SUBRC, &SCRIPTVERSION, &SCRIPTNAME, &SAPRL, &REFVERSION,

&REFNAME, &REFLEVEL, &OPSYS, &MSX, &MST, &MSN, &MSI, &MSG, &MS4,

&MS3, &MS2, &MS1, &M04, &M03, &M02, &M01, &LPC, &LOGID, &LANGUAGE,

&HOST, &EXCEPTION, &DBSYS, &DATE, &CLIENT etc.

The status of values, either fixed or parameterized or not define, are symbolized

as follows -

Why Parameterization Is Needed:

After recording of the transaction. Transaction can be checked without

parameterization for errorless recording. Once the successful recording is

confirmed, automation can be parameterized.

Due to parameterization, the recording becomes reusable. Different sets of data

can be passed via parameters and the recorded script can be used again and

again.

This is very similar to concept of Constants in Program (Without

parameterization) and using variables for those values (with parameterization).

If parameterization is not done than before next execution of automated script,

input data will be checked and changed at Test Script level. Due to this the

errorless recording time data will be disturbed.

Hence parameterization is necessary.

TCD Mode Parameterization:

If a transaction is recorded via TCD mode, then the screens can be simulated via

screen simulation. Screen simulation can be used to edit and parameterize the fields.

Screen simulation icon is present in the command interface of the TCD mode. Using

Screen simulation Import parameters, Export parameters, field check, and values in

the input field can be assigned. To delete the default values space characters (‘ ‘) can

be passed via screen simulation. For parameterization, if the field has any value, one

can clear it.

Fields having mode ‘S’ (Set) under each dynpro of the command interface contain

some value entered during the recording. This is the value one needs to parameterize

as Import Parameter so that with next run a new set of data will be passed to the

recording. And recording becomes reusable.

For parameterization, select the Dynpro whose fields need to be parameterized as

Import/Export parameter. Click on Screen Simulation icon of the command interface.

The system will prompt for the login of recording time target system. Give the login

details.

Defining Import Parameters:

After step 3, the screen simulation window will appear. Select the field value &

click on Insert Import Parameter (F6) icon from the application toolbar.

One Maintain field entry window appears for the selected field with its technical

name. Give the parameter name & default value in the Field contents there.

Press enter. The parameter will be inserted into the parameter list. Click on Back

(F3) button of the standard toolbar.

This way one can parameterize all the import values.

Defining Export Parameters:

The output results of the transaction are assigned to export parameters. Export

parameter are necessary for chaining of transactions wherein output of one

transaction becomes input for other transaction. Here export parameters can be

linked between the two transactions interacting.

Fields having ‘G’ (Get) as mode are assigned to export parameters. Last dynpro

in the dynpro list just before the MSG node in the command interface contains

the output messages and other outcomes. Export parameters can be assigned

for these values.

Follow step 3. After step 3, the screen simulation window will appear. Select the

field and click on the Read field value (Ctrl+Shift+F3) icon from the application

toolbar.

Read field value window appears. The field with the technical name appears

against which the Param. Name needs to be given. Give the name of the export

parameter. Click on enter. Automatically the name will be included in the

Parameters list. Click on Back (F3) button from the standard toolbar.

This way one can parameterize all the export values.

Defining Field Checks:

One can check whether the runtime value of a field is the expected value or not.

The check value can be a constant or a parameter value.

Follow step 3. After step 3, screen simulation window appears. Select the field. If

the field has already some value, clear the value of the field.

Click on the Check field (Ctrl+Shift+F2) icon from the application toolbar.

Maintain field check dialog box appears. Give the name of the variable in the

Param. Name. If it doesn’t exist, it will be created automatically as import

parameter in the parameter list. Give the value against this field. Click on enter.

Click on Back (F3) button from the standard toolbar.

SAPGUI Mode Parameterization:

Defining Import Parameters:

Import parameters are defined for the input values given during the recording of

the transaction. These values are present under the ProcessedScreen node of

the SAPGUI command interface for the given screen.

Double click on the command interface of SAPGUI command from the test script

editor from the left side. On right side the command interface will open. Under

the ProcessedScreen -> UserChangedState node select the State node of the

field, which needs to be parameterized. Double click on the field number. On the

rightmost section, assign the Import parameter to Value field.

Define this import parameter in the parameter list with the type of the field &

assign the default value.

This way multiple import parameters can be assigned & created.

Defining Export Parameters:

Export parameters are used to link transactions while chaining. i.e. Export

parameter of first transaction becomes the import parameter in chaining.

Export parameters are assigned to result of transaction. e.g. Material Created

out of MM01 transaction. So the results are captured from Message node under

the ProcessedScreen node using MESSAGE-ENDMESSAGE command.

Click on Pattern (Ctrl+F6) button from the application toolbar. From the

Command dropdown, select the MESSGAE MESSAGE …END MESSAGE option.

The Interface name is automatically populated by system. Click on enter.

The MESSAGE-ENDMESSAGE for interface MSG_1 will be inserted into the test

script editor. Place this block around the SAPGUI command from which the

export value will be captured. After that assign the respective message

parameter to the export parameter.

The message variable number can be confirmed from the command interface

from the right side.

Declare this export parameter in the parameter list.

This way multiple export parameters can be declared.

Passing Values To Subsequent Screen: In SAPGUI mode, value from one screen

can be passed to the subsequent screen. E.g. system generated value for an

input field on one screen can be passed to subsequent screen. This can be

achieved by assigning an Export Parameter to the required value. And then

passing this export parameter as input (import parameters) to subsequent

screens.

o Double click on interface from the SAPGUI command in which the

parameter to be captured exists, in test script editor. On the right side, the

command interface will open. Under the ProcessedScreen -> InitialState

node, the value will exist. Make sure that the Check, of the topmost

GuiElement branch under which the GuiElement exists which needs to

capture, is blank ‘ ‘ instead of ‘X’.

o Under the State node of the GuiElement, which is to be captured, double

click on the number, which appears in square braces. On the right side,

Name & Value will appear. There in Value, write the Export Parameter

name.

o Declare this export parameter in the parameter list. And it can be passed

further in same recording to subsequent screens as import parameter.

Chaining Of Scripts:

Test case is a series of steps (transactions) involving one business scenario.

Each step is automated and then linked together via chaining so as to complete

the business scenario.

Chaining mainly involves the linking of script by import & export parameters.

The export parameter, which is outcome of first transaction, is passed as import

parameter to second transaction and so on.

Create two test scripts, which are related in a way that output of one script

becomes input to other. E.g. VA01 output of sales order can be given as input to

VA02. Both the scripts should be parameterized as well.

For creating chaining of the scripts, create a new script. Transaction SECATT.

Click on Pattern (Ctrl+F6) button from the application toolbar.

One Insert Statement dialog box will appear. From the Command dropdown,

select REF command. In the Test Script, give the name of test script, which

needs to be linked. Press Enter. The Interface name will be automatically

populated. Press Enter.

The REF command will be inserted into the test script editor.

Double click on the Command Interface of the inserted REF statement in the test

script editor. On the right side the interface will open with the

Importing/Exporting nodes. These Importing and Exporting node have import

and export parameters, which were assigned while creation of that script.

Double click on Importing node. On the rightmost side, all the import

parameters appear under the Element column.

Declare all import parameters in the Parameter section above and assign then in

Value column below against the Import parameters.

Double click on Exporting node of the command interface. On the right side the

export parameters, which were created during the script creation are displayed.

Declare the variables and assign them to the export parameters.

Similar ways include other test scripts also using REF command. Assign the

import parameters and variables to the Importing as well as Exporting nodes

respectively.

The export of one test script will be assigned as import of the next script using

variables.

The import parameter of chained script is assigned to the respective Importing

node element.

This ways multiple transactions can be linked together in the final chained

script. The parameter list of this chained script contains only the import

parameters as well as the variables.

Click on Save (Ctrl+S) button from the standard toolbar. By giving the default

values in the import parameters, execute the script and ensure the correctness

of chaining. Once the successful execution of the chained script is confirmed, TD

and TC can be prepared.

Creation Of System Data Container (SD):

System data container contains the list of the target servers, which can be used

at the recording time and/or at execution time. Target systems with their RFCs

are mentioned in the SD.

Creation of RFC for target system:

RFC destination will be created for the target systems, which will be used as

recording time and/or execution time systems for eCATT scripts. Using SM59 on

source system (where eCATT scripts will be available), create a RFC destination

for R/3 system.

Give the necessary details like RFC Destination, Connection Type, Description.

In Logon/Security tab, recommended is to mention the Trusted system ‘No’. This

ensures that every time, login window will be prompted when target system is

referred via RFC. Hence secure. After RFC creation, the server can be added to

the SD list.

For SD creation, transaction SECATT.

In the System Data input field give the name of SD. Click on Create Object (F5)

icon from the application toolbar.

On the create screen, in the Attribs tab, give the Title (mandatory) for the SD.

Under the System Data tab, target system NONE is already present. Append a

new row by clicking Append row icon from the toolbar. In the Test System

column, give the name of the target server. By this name the target system will

be referred in eCATT. Under the RFC Destination column, select the respective

RFC for the target system. The Instance Description field is automatically filled

by system. Click on Save (Ctrl+S) icon from the standard toolbar.

This way multiple target systems can be added to the system data.

Creation Of Test Data Container (TD):

Test data containers are used for creation of variants. Variant values are also

maintained in TD. Variants created in TD are linked in Test Configuration. TD is

independent of test script. Hence once created can be used for multiple scripts.

Transaction SECATT.

In the Test Data input field, give the name of the test data. Click on Create

Object (F5) icon from the application toolbar.

On the create screen, under the Attributes -> General Data tab in the Header

Data section, give Title (Mandatory) and Component (Mandatory). Under the

Maintenance System, give the SystemData Container as well as Target System,

which is present in the SD.

Under the Parameters tab, click on Append Parameter icon and the new lines

will be appended in the parameter list. Add the lines to the required number of

parameters. Add the parameters. The parameters name & type must match to

that of the script to which the TD will be linked. Click on Save (Ctrl+S) button

from the standard toolbar.

To create variant, minimum one parameter should be present in parameter list.

Under the Variants tab, the column titles are Variant, Description & after that

the parameters from the parameters list. ECATTDEFAULT variant will be present

as default. This variant contains values from the Parameters under the

Parameters tab.

To add new variants, click on Append Variant icon. Give the details of new

variant with values. Add required number of variants this way. Click on Save

(Ctrl+S) button from the standard toolbar.

Creation Of Test Configuration (TC):

Test Configuration contains reference to one Test Script (TS), one System Data

container (SD) and can contain reference to multiple Test Data container (TD).

TC is used in scripts management using TestWorkbench in R/3 system.

One more Advantage of using TC is that for any given script, without changing

data at TS level, the script can be checked for different sets of data using

Variants of TC. In turn these variant values are captured from TD. Hence the

errorless recording time data is always maintained in TS. And the Last Changed

script attribute (Attributes tab -> Extras tab -> Administration Data) will contain

only the details of the person who has made changes to script and not to the

data.

For TC creation, transaction SECATT.

Give the name of TC in Test Configuration and click on Create Object (F5) icon

from the application toolbar.

On the create screen, give the Title (Mandatory) & Component (Mandatory).

Under the Configuration tab, give the System Data Container, which contains

the Target System. Also give the name of Test Script. Test Data and an Alias can

be added to Test Data section using Append Row icon. The Alias is an

alphanumeric name up to three characters. Multiple test data can be given if

required.

Variants can be added from Variants tab. The TC references the import part of

the data interface of the test script. Variants can be prepared either manually by

clicking the icons Append Variant/Insert Variants or from the wizard using test

data containers referenced in the Configuration tab.

o Manually Creating Variants:

In the Test Configuration editor under Variants tab, click on the Append

Variant icon. This will insert a new line for variant under ECATTDEFAULT.

In the Variants field, give the name of the variant. Under each parameter

either give value or leave the field blank. Click on Save (Ctrl+S) button

from the standard toolbar.

This way multiple variants can be directly added to Variants list.

o Variants from Test Data Containers:

Prerequisite for this option is that Test Data Containers should be

maintained under Configuration tab. To create variants from the

Test Data containers, click on the wizard icon (Variant Maintenance

Assistant) under the Variants tab.

The Variant Maintenance Assistant window appears. The left half of

the screen displays the variants belonging to a test data container.

The right half of the screen displays the variants belonging to the

test configuration. Scrolling between the multiple variants of Test

Data is available. Select the variant from the Test Data & click on

Attach as variant button. The variant will be copied to Test

Configuration side.

Only the parameters in the test data container that match those of

the test script are appended. The value in a field is determined by

the following syntax: <parameter name>(<alias>, <variant>)

where the parameter name, alias, and variant all refer to a test data

container.

Click on enter. Variant will be added to Variants list in TC. The links

will be present for the values of the parameters from TC to TD. Any

changes done at TD side will be referred dynamically in TC. This way

multiple variants can be created.

Linking single field of Test Data variant to Test Configuration

variant: Select a field belonging to a test data container. Select an

empty field belonging to the test configuration. Choose Link

individual field. The field belonging to the test configuration is filled.

The value in a field is determined by the following syntax:

<parameter name>(<alias>,<variant>) where the parameter

name, alias, and variant all refer to a test data container. Click on

enter. The field will be dynamically linked.

Linking multiple fields in Test Configuration column to a single field

of Test Data variant: Select a field belonging to a test data

container. Select a field belonging to the test configuration. Choose

Insert in column. All the empty fields in the column are filled. The

value in a field is determined by the following syntax: <parameter

name>(<alias>,<variant>) where the parameter name, alias, and

variant all refer to a test data container. Click on enter.

o Click on Save (Ctrl+S) icon from the standard toolbar. And Test

Configuration is now ready to execute or to link to TestWorkbench

depending on the variant selected.



Blogs

eCATT Scripts Management Via Test Workbench (PART V)Sapna Modi Business CardCompany: Larsen &Toubro Infotech Ltd.Posted on Apr. 13, 2006 08:18 PM in Emerging Technologies, Application Server




explained in detail. In Part IV, the parameterization, creation of Test

Configuration,Test Data Container, System Data Container are explained in

detail. In Part V, the management of eCATT Scripts via Testworkbench will be

explained. In the subsequent parts eCATT Logs & other details of eCATT will be

covered.

Why eCATT Scripts Management Is Required By Test Workbench By SCAT:

eCATT scripts can be very well executed via the transaction SECATT by which

the scripts are created. In SECATT, the script execution can happen at Test

Script (TS) level or Test Configuration (TC) level. At test script level execution,

the data may need to be changed depending on the behavior of transaction(s) in

the script. This change will override the default recording data of the script. If

the script recording is error free then change of the data at TS level is not

recommended. Hence execution of the script via TC is adapted. In TC, the data

is changed at variant level, which are picked from Test Data (TD) Container.

Changing data in TD doesn’t affect the default recoding time data i.e.

ECATTDEFAULT. Now even if the execution can happen via TC, then also

clubbing of TCs, which are related depending on a series of functionality or the

function module or location against which the test case is being executed, is not

possible via SECATT transaction.

Moreover one has to maintain the log IDs of the scripts being executed via

SECATT. As script executes multiple times, the logs are stored against that

script. So which log has generated during the final regression testing time is

difficult to make out.

Hence for the Regression Test, the requirement is that somewhere the log IDs

should be present along with the scripts, which are as a result of the test carried

out during final testing. These log IDs will be available for future use. So all the















requirements of grouping the scripts on some defined conditions, availability of

log IDs for future usage will be fulfilled by Test Workbench SCAT Transaction.

How Scripts Can Be Managed In Test Workbench:

Test cases can be managed in test workbench via Test Catalog, Test Plans &

Test Packages. Also with the Test Workbench test status can be analyzed. Test

status is in terms of traffic lights for eCATT logs.

Test Catalog - A Test Catalog is a set of test cases in a hierarchical hypertext

structure. To be able to use the test catalog to generate test plans, one must

put it in the SAP Application hierarchy. One can create test plans across several

test catalogs via the SAP application hierarchy. This procedure allows creating a

lot of small test catalogs, which are easier to maintain than one large test

catalog.

Test Plan - A test plan is a set of test cases, which must be tested, in a particular

period for a particular purpose. The relevant test cases can be divided among

several test catalogs.

Test Package - A test package is a person and period-oriented view of a test

plan. It contains all tests, which a tester is to perform in a specified period.

After a test, the tester sets the test case status, e.g. ‚Pass‘ or ‚Fail‘. one can get

an overview of the status of all test cases of a test plan with Status analyses.

Creation Of Test Catalogs:

Transaction SCAT or Tools->ABAP Workbench->Test->Test Workbench->Test

Organizer->Manage Test Catalog.

Click on menu Environment->Manage Test Catalog.

Click on Create (F5) icon from the application toolbar.

Test Catalog Information window appears.

Give the name of System Data and Target System in the eCATT section. System

Data container should contain the RFC for the Target System on which the script

will execute.

In Test Catalog Header Data section give Title. The title is the name of the

catalog by which it will be referred in the Test Plans.

In the Responsibility section, Name contains the logged in user name by default.

Click on Save (Ctrl+S) from the standard toolbar.

The Test Catalog is created. Now the Test Configurations need to be added to

this test catalog.

Select the Test Catalog created in step 8 and click on Change (F6) icon from the

application toolbar.

Under the Structure, name of test catalog will appear.

Select Test Catalog name and click on the button As Subnode (F5) from the

application toolbar.

Insert Nodes window appears. Here we are adding the Test Configurations to the

test catalog. So select the second radio button of Test Case. Give the value from

the dropdown list as E eCATT Test Configuration.

In the Test Case Key, click on F4 help. Select the Test Configurations from the

system. As the grouping of the scripts is on the basis of the location against

which the test is carried out, so all the scripts, which will be specific to this

particular location, should be selected.

In the Variant Selection, select the Special Variant radio button. Click on F4. Now

in the list shown by system will show only the common variant to all the select

Test Cases from step 13. If in case the scripts are selected which don’t have

common variant names then only the variants of first test case appears in the

list.

o Without Variants – Only with ECATTDEFAULT.

o All Variants Including Default Variant – All the variants including

ECATTDEFAULT variant.

o All Variants Excluding Default Variant – All the variants excluding

ECATTDEFAULT variant.

o Special Variants – Only for the selected variants from the list, which are

common to all the selected test cases.

Select the variant for the location against which testing is carried out and press

enter. All the selected scripts along with the variant name will appear under the

Test Catalog name.

Click on Save (Ctrl+S) button from the standard toolbar..

In order to use the test catalog in Test Plans, test catalog must be present in

SAP Application Hierarchy. To achieve this, click on button Library (Ctrl+F12)

from the application toolbar or click on GOTO menu -> Library.

Select path as follows => Test Organizer Library -> Application Components ->

BC -> BC-TWB Test Workbench -> BC-TWB-ORG Test Organizer -> BC-TWB-ORG-

CTL Test Catalog. With the Test Catalog selected, click on Nodes (Insert Nodes

F5) button from the application toolbar.

One small window of Create Link appears. Click on (Find) Test Catalog button.

Give the name of Test Catalog created in step 16 in the Description field. The

name will appear in the search help output window. Select the catalog and press

enter.

One Information popup appears ‘ The two structures are from different mySAP

components’. Press Enter. The catalog will be added under the Test Catalog

node.

Click on Save button from the standard toolbar. Now the catalog is present in

the application hierarchy.

This way multiple test catalogs can be prepared depending on some defined

conditions like different locations against which the testing will be carried out.

These test catalogs then can be used for the preparation of test plans.

Creation Of Test Plans:

Transaction SCAT.

Click on menu Environment->Manage Test Plans.

Click on the Create (F5) icon from the application toolbar.

Create Test Plan window appears. In the Template, select Application

Component Hierarchy. Under the Test Plan & Header Data section, give the Test

Plan Title. With the Test Plan Title, the plan will be referred. In the eCATT

section, give the name of System Data Container & Target system on which the

scripts will execute. Click on Enter.

The system will take to Crate Test Plan screen where the Test Organizer Library

is displayed. Here from this SAP Application Hierarchy, select the test catalog.

This test catalog is the one whose scripts will be pulled in the test plan and then

subsequently in test package of that plan. Scripts from multiple test catalogs

can be taken. Select path as follows => Test Organizer Library -> Application

Components -> BC -> BC-TWB Test Workbench -> BC-TWB-ORG Test Organizer -

> BC-TWB-ORG-CTL Test Catalog. Select the scripts from single or multiple Test

Catalogs as per the requirement.

Click on Generate (F8) button from the application toolbar. After the plan is

generated save it.

Test Plan is ready now. One can prepare the Packages from this plan by some

defined conditions like scripts of foreground execution, background execution or

different tester or different target systems at execution time.

Creation Of Test Package:

Select the test plan created in step 6 above. Click on Test Packages (Ctrl+F9)

button from the application toolbar.

Test Organizer – Test Package Management screen comes. Click on Create Test

Package button.

It will display all test catalogs under that test plan. Select the scripts from the

required test catalogs depending on the condition on which that package is

planned. After selecting the scripts, click on Generate (F8) button. The Create

Test Package window for title appears. Give the name of the package in the title.

By this name the package will be referred always. Click on Enter.

Once the package is prepared, select the package name and click on Status

button for refresh. Once the refresh is done, the right panel will show the

number of scripts against that package under the Error/No Result/Ok columns.

The package is also now ready. This way multiple packages can be prepared

which will involve all the scripts of the plan in totality.

Execution Of Test Cases Series Via Test Workbench:

Test Cases can be executed via different ways at different levels in test

workbench system. Test Cases can be executed at Test Catalogs level/Test Plan

level or even at Test Package level.

The scenario depicted here is by creating a pool of test cases in Test Catalogs.

Then from those test catalogs preparing Test Plans depending on some defined

conditions. From these plans again preparing Test Packages. And finally

executing these Test Packages which give the transparent picture of how the

testing was planned and carried out.

So transaction SCAT.

Click on menu Environment->Manage Test Plans.

Select the Test Plan, which needs to be executed.

Click on Test Packages (Ctrl+F9) button from the application toolbar.

Select the package. Before the execution, the status in traffic light for each of

the script will be untested.

For the mass execution of the complete package, select the package. Then click

on Automatic Test button from the application toolbar.

Test Case Selection window appears. If in case all the scripts need not to be

executed at a given time, then select the required once. By default all the

scripts under the package are selected for execution. Click on Enter.

One window with title ‘Start Options (eCATT Mass Start)’ will appear. Select the

following options –

o Error Behavior - S No termination, continue with next script.


Target System.



o Select the Status In TWB check box.

o In TCD section of window, select N – Process in background, synchronous

local.

o In SAPGUI section of window, select following options -

Procg Mode SAPGUI - S Synchronous GUI Control

Error Mode for SAPGUI - C Continue (Continue on Any Error)

Stop When - N Do Not Stop

Close GUIs - R Close Generated Sessions After REF


On execute button click on Start Options window, the system prompts for login

& password window of Target System. Give the login details and execution of

scripts will start in series.

Once the execution is completed, the logs are taken back to test workbench and

the status of traffic light will either change to green for success or red for error.



Blogs

eCATT Logs (PART VI)Sapna Modi Business CardCompany: Larsen &Toubro Infotech Ltd.Posted on Apr. 18, 2006 08:18 PM in Emerging Technologies, Application Server




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 will be explained in detail & in the

subsequent parts other details of eCATT will be covered.

What Are eCATT Logs:

eCATT Logs are generated every time a test script or test configuration is

executed either by SECATT or SCAT transaction.

The log is hierarchically structured according to the test script used, and

displayed as a structure with nodes. Each test script in turn may contain one or

many recorded transactions. This also includes any inline ABAP code or any

other eCATT commands if used.

Each of the eCATT log shows the execution status of each of the step executed

for the given test script along with necessary details like unique log ID, executed

variants details, Import/Export/Local parameters details, Target System details,

Source System details, Test Data container, time taken for each step of

automated steps as well as total execution time in seconds, execution mode like

With Interruption (Foreground for TCD & with user intervention for SAPGUI) or

Without Interruption (Background for TCD & without user intervention for

SAPGUI) etc.

Advantages Of eCATT Logs:

eCATT log stores all the steps of the test case along with lots of other useful

information about systems, variants etc.

These logs help in analysis of the business process. As all the system messages

are stored in the logs, which are generated during execution of the given script,

it becomes simple to analyze the result set.















The expiry date of logs can be changed. So they can be maintained for the

defined time frame. And hence the results of one regression testing can be used

as reference for next regression testing. This helps in rollout projects.

In case of errors, system prompts the relevant messages, which help in

understanding of the process that has gone wrong. After necessary corrections,

the script can be again executed and the new log will be generated. The

success, error or execution status is depicted by colors in logs. So it becomes

much more user friendly to analyze.

How To Look In eCATT Log From Log ID:

Transaction SECATT.

Click on Logs (Ctrl+F12) icon from the application toolbar.

Under the Log Selection section, in Currt. Procedure No. Input field give the log

ID.

Remove the values from the Starter & Start date input fields. They are not

necessary in this case, as Log ID is known. In case log ID is not known & one

wants to analyze all the logs generated on a particular date by a particular

tester then give these input fields. Other input fields include Test Configuration,

Test Script, Expiry date, which in this case are not mandatory. Different input

combinations can be made for eCATT logs depending on what kind of input is in

hand. In absence of eCATT Log ID, the combination of other input fields

becomes useful.

Click on Execute (F8) button.

eCATT Log with the Log ID in title appears in next window. By click on Expand All

Nodes (F5) button, all the nodes will be drilled down till end. And the detailed

view of log will be displayed.

How To Look Into eCATT Logs From Test Workbench:

With the assumption that test package is executed, logs from test package will

be analyzed here.

Transaction SCAT.

Menu Environment -> Manage Test Plan.

Give the name of test plan. Click on Status Analysis button from the application

toolbar.

The execution status of the package is in terms of traffic lights under the Status

column with description under Status Text column.

Click on the traffic light of the required test configuration. After click, Status

Maintenance window appears. This window contains Test Case details, Status of

execution etc. Click on Log (Shift+F1) button from the application toolbar.

Detailed eCATT Log is displayed against that test configuration with unique log

ID.

Analysis Of eCATT Logs:

Top Level Information: The first line of the log displays the log identification

number. Depending on the tests, other information is also displayed:

o The number of test configurations executed. (This information appears if

the execution happens from the test workbench via SCAT).

o The name of the test script or test configuration executed via SECATT.

o The version number of the test script.

o The execution mode i.e. With Interruption (Foreground for TCD & with user

intervention for SAPGUI) or Without Interruption (Background for TCD &

without user intervention for SAPGUI) .

After the top line following information is displayed in one line: System, Client,

User, Language, Release, ApplicationServer, Operating System, Database

System, Date of exeuction, Time of execution.

Script Details:

After the detailed systems information, the test script details like test script

name, version, description & execution time taken by the complete script is

displayed in seconds. The system Data Container as well as Test Data container

are also displayed. The status of execution of scripts is depicted by colors either

green background color for success or red background color for error.

Successful Script

Script in Error

Maintenance System:

If a test script has a maintenance system, the RFC destination is displayed and

the detailed component information is shown below it.

Comments, Duration, IF-ENDIF structure:

To display comments, duration time in seconds in the log, click on Settings…

(Shift+F7) icon from the application toolbar. Select the check boxes of Disp.

Duration, Display Comments. Press Enter.

The log with the comments, duration time will be displayed. If the IF-ENDIF

structure is executed, it is displayed with green color otherwise not.

Errors, Multiple Variants, Messages, Navigation:

o Error: If a script contains one or more errors, it is in error with background

red color. If a node is marked as containing an error, the node above it in

the hierarchy is also marked as containing an error with red color. Error

message is immediately displayed after that step and even after the script

details.

o Messages: Messages during the execution are displayed in the log under

messages node. Messages can also be seen in XML data.

o Multiple Variants: Script can be executed using multiple variants. The

variant names appear one after the other in the log.

o Navigation: By clicking on the hyperlinks from the log, one can navigate to

the test script, system data or test data etc. When a recorded transaction

uses a print function that sends a document to the spool, a message is

recorded in the log.

XML Data:

XML data is generated when testing function modules and transactions. To view

XML data, click the hyperlink name of the XML data in the log.

Here is an extract of XML-DATA-01 from the log shown above.

How To Change Expiry Dates/Deletion/Archiving Of eCATT Logs:

Transaction SECATT.

Click on Logs (Ctrl+F12) icon from the application toolbar.

Under the Log Selection section, in Currt. Procedure No. Input field give the log

IDs by clicking on the Multiple Selection button. Multiple Selections For Currt.

Procedure No. window appears. The entire log IDs should be given here. Click on

Execute (F8) button.

On the Log Selection window, the multiple selection button will show green

status for having multiple values of Log Ids. Click on Execute (F8) button.

Logs from the selection screen are displayed in the tabular format with the

details like status, start date, end date, starter, expiry date, test script, test

configuration etc.

Select all the logs by clicking on Select All icon on left top of the grid. Click on

Change Expiry Date (Ctrl+F8) button from the application toolbar.

Date change window appears. Set the required expiry dates to the logs. Click on

Enter. The Expiry date will change for the all the selected logs to this new value.

When the expiry date reaches for any log, the log is automatically deleted. If the

automatic deletion is not required, explicitly also the log can be deleted from

the menu Log Selection->Delete (Shift+F2).

Also the logs can be archived. Select the log from the list, from the menu Log

Selection -> Archiving On/Off (Ctrl+F7).

How To Find Database Tables For eCATT Logs:

Transaction SARA.

In the Object Name input field give value ECATT_LOG.

Click on Database Tables button from the application toolbar.

On the Tables & Archiving Objects window, in the Tables from which data is

archived section, tables are displayed for eCATT Log. These are the tables in

which the log is stored in the database. Select the All Tables radio button.



Blogs

eCATT Scripts Creation Non-User Interface Mode & Rename, Copy, Delete, Upload, Download eCATT Objects(PART VII)Sapna Modi Business CardCompany: Larsen &Toubro Infotech Ltd.Posted on Apr. 19, 2006 08:33 AM in Emerging Technologies, Application Server




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 are explained in detail.

In Part VII, creation of eCATT Scripts using Non-User Interface mode will be

explained along with the details of Copy, Rename, Delete, Upload and Download

of eCATT objects. In the subsequent Part, tips & l inks of eCATT will be covered.

Key Features Of Non-User Interface Recording Mode:

The non-user interface can be used for testing back-end R/3-specific modules,

such as function modules and BAPIs.

It should be the preferred driver for interface tests in the mySAP environment.

It is fast, efficient, and suitable for load testing.

Steps For Recording Using Non-User Interface Recording Mode:

Transaction SECATT.

Give the name of the Test Script(TS) in Test Script input box. The Version input


In the Attributes ->General Data Tab, the value of the component will be BC-


In the Attributes ->General Data Tab, the values of the SystemDataContainer

should be given which contains all target systems with RFCs on which the script

will be either executed or recorded & in the TargetSystem the name of target

system (e.g. recording R/3 server) should be mentioned.

Click on the Pattern (Ctrl+F6) button from the application toolbar.















From the Command dropdown, select FUN. In the Function Module give the

name of the function module/BAPI, which needs to be tested. Click on enter. The

Interface name will automatically appear (E.g. Here BAPI_MATERIAL_SAVEDATA

is used). Click on enter.

The FUN with the function module/BAPI name along with the command interface

will be inserted into command editor.

Double click on the Command Interface (e.g. BAPI_MATERIAL_SAVEDATA_1) from

this FUN syntax in the command editor. On the right side, the command

interface will open in a window. The command interface will have all the

IMPORT/EXPORT/TABLES/EXCEPTIONS parameter of the given function

module/BAPI.

Under the IMPORTING/EXPORTING/TABLES/EXCEPTIONS node, all the import

parameters, export parameters, tables & the exceptions belonging to that

function module/BAPI are present. These parameters can be parameterized.

If the function module or BAPIs are called in the ABAP Program then the way the

values are passed to those parameters, similar ways values will be passed here

in terms of Parameterization. The declaration of these parameters will happen at

the Parameter List as either Import/Export/variable.

The output message variables, like the other recording modes, can be captured

from the Exporting node.

All the parameters needed for the execution of the function module/BAPI will be

declared in parameter list and then parameterized.

In the current example, BAPI is used for Material create and saving this data.

Before this a unique material number is generated by system using another

BAPI. This is written in ABAP-ENDABAP block. After the number is generated, this

newly generated number is assigned to a variable. As import and export

parameters cannot be used in inline ABAP code. So the variable is used. This

variable is then passed as import parameter to BAPI, which is to be tested via

this recording.

Once the parameterization is done. The script is ready for execution. There is no

specific Start Options mode available for Non-User Interface mode at execution

time. It always executes in Background mode.



appear.

Analyze the generated log (weblog Part VI). Following is the log generated for

the example mentioned here. It shows Import, Export parameter along with the

execution mode and time taken for each of the individual step and complete

execution.

Inline ABAP code is also shown in the log. It shows the results also.

The function module/BAPI is also shown in log. The Importing/Exporting

parameters along with the message generated.

After the confirmation of error free recording, one can go ahead with the

preparation of TD, TC for the TS.





test script. Hence can be reused wherever required. (Weblog Part IV).




(Weblog Part IV).


variant name at runtime. (Weblog Part IV).


transaction. (Weblog Part V).

How To Copy, Rename & Delete eCATT Objects:

One can copy all the eCATT Object i.e. Test Configuration, Test Script with

Version, Test Data & System Data.

Transaction SECATT.

Click on Copy Object (Ctrl+F5) icon from the application toolbar.

Copy dialog box appears with the copy detail for the eCATT Object whose radio

button was selected on SECATT.

For Test Configuration copy, give the name of the new TC and click on Copy

button. The new test configuration will be ready.

Similar way, for Test Data and System Data, give the new names and click on

Copy button.

System Data Copy-

For copying Test Script, system gives one Version input field on Copy dialog box.

If this field is left blank then all the versions are copied to new name. Otherwise

only the specified version is copied.

Rename eCATT Object: Similar to copying the eCATT objects, renaming can be

done. On the application toolbar of SECATT transaction, click on Rename Object

(Ctrl+F6) icon from the application toolbar.

Depending on the eCATT object selected, the Rename dialog box will appear.

Give the new name and click on Rename button. The object will be renamed.

Similar ways all other eCATT objects can be renamed.

Deletion Of eCATT Objects: Similar to Copying & Renaming, all the eCATT

objects can be deleted. Click on Delete Object (Shift+F2) from the application

toolbar of SECATT transaction.

Confirmation Prompt dialog box will appear. Click on Yes for the deletion of

object.

There is no dependency on objects for deletion. Meaning deletion of TC won’t

affect the TD & TS inside it. In case of Test Scripts deletion, to delete specific

version mention it in the transaction. If the version field is left empty, all the

versions are deleted. Similar way all the other eCATT objects can be deleted.

How To Download eCATT Objects:

eCATT objects can be downloaded in XML & XSD format. These files can be

further uploaded to any system. Hence the reuse of objects and their transfer

amongst the R/3 system is facilitated. All the objects i.e. Test Script, Test

Configuration, Test Data & System data can be downloaded via SECATT

transaction. For a script to work successfully, the entire linked object should be

present along with it like System Data, Test Configuration & multiple Test Data

containers. This linking of objects can be known and the entire related object

could be downloaded in one shot.

Transaction SECATT.

Give the name of Test Configuration or Test Script or Test Data or System Data,

which needs to be downloaded.

Menu Goto -> Reference List.

One List Of Referenced Objects screen comes. Object Type & Object Name

automatically appears depending on the selected eCATT object on SECATT

screen.

Click on Execute (F8) button from the application toolbar. List of referenced

objects will appear.

Click on Download All Objects (F5).

All the objects from the referenced list will be downloaded at the path given in

the Browse For Folder dialog box. Click on Ok.

The files will be downloaded at the given destination in XML XSD format.

Downloading Individual eCATT Object: Individual objects can also be downloaded

instead of the complete reference list from transaction SECATT. Give the object

name and click on the Display (F7) icon from the application toolbar. From the

menu <eCATT Object>-> Download, the given object can be downloaded.

Similar way other eCATT objects can be individually downloaded.

How To Upload eCATT Objects:

eCATT objects i.e. Test Script, Test Data, Test Configuration as well as System

Data can be uploaded via SECATT transaction from the XML, XSD files. The

prerequisite is that both the XML & XSD files should be present in the same

folder.

Transaction SECATT.

Menu eCATT Object -> Upload.

Select Files For Upload dialog box appears. Select the file and click on Open

button.

Change eCATT objects to be uploaded window appear. Select the eCATT object,

give the target object name if not present & click on Enter. The object will be

uploaded and directly taken to SECATT window.

In case of Test Script, the Target Version (TV) number can be given.

This way multiple objects can be uploaded.

System Data Container Upload/Download:

When uploading or downloading system data containers for copying to another

system, the name of an RFC destination remains unchanged in the RFC

Destination field. However, in the new system, this name might not exist or

might be that of a different RFC destination. In this case, RFC destination needs

to be maintained.



Blogs

eCATT Tips Of Recording, Testing & Links (PART VIII)Sapna Modi Business CardCompany: Larsen &Toubro Infotech Ltd.Posted on Apr. 24, 2006 04:54 AM in Application Server, Emerging Technologies




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.

o 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.

o On the Expert tab, in the Controls section select the checkboxes of Show

keys in all dropdown lists & Sort items by keys.

o Transaction with dropdown without keys setting –

Transaction with dropdown keys settings –

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.

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.

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.

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.

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.

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).

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.

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.

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 -

eCATT Weblog Links From SDN:

eCATT An Introduction (Part I)

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/3334

eCATT Scripts Creation - TCD Mode (Part II)


eCATT Scripts Creation - SAPGUI Mode (Part II)


eCATT Chaining, Parameterization, Creation Of Test Data, Test Configuration,

System Data (Part IV)


eCATT Scripts Management Via Test Workbench (Part V)


eCATT Logs (Part VI)


eCATT Scripts Creation Non User Interface Mode & Rename, Copy, Delete,

Upload & Download eCATT Objects:


eCATT - Creating A Test Case For WebDynpro:


eCATT Links From SAP Help:

Online SAP Help For eCATT:

http://help.sap.com/saphelp_nw04/helpdata/en/20/e81c3b84e65e7be10000000a

11402f/frameset.htm

TCD Parameterization:

http://help.sap.com/saphelp_erp2004/helpdata/en/b5/c5f60a2b5bc74f8ca0eef40

158806c/content.htm

TCD Command Interface:

http://help.sap.com/saphelp_erp2004/helpdata/en/82/fc193c66f5dc1ce1000000

0a11405a/frameset.htm

Setting Field Values Dynamically In TCD:

http://help.sap.com/saphelp_erp2004/helpdata/en/05/33384162316532e100000

00a1550b0/frameset.htm

SAPGUI Command Interface:

http://help.sap.com/saphelp_erp2004/helpdata/en/bc/6d7290f64c11489f2c9b03

458ef53f/frameset.htm

Execution Start Options:

http://help.sap.com/saphelp_erp2004/helpdata/en/bc/6d7290f64c11489f2c9b03

458ef53f/frameset.htm

http://help.sap.com/saphelp_erp2004/helpdata/en/bc/6d7290f64c11489f2c9b03458ef53f/frameset.htm




http://help.sap.com/saphelp_erp2004/helpdata/en/05/33384162316532e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_erp2004/helpdata/en/05/33384162316532e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_erp2004/helpdata/en/82/fc193c66f5dc1ce10000000a11405a/frameset.htm

http://help.sap.com/saphelp_erp2004/helpdata/en/82/fc193c66f5dc1ce10000000a11405a/frameset.htm

http://help.sap.com/saphelp_erp2004/helpdata/en/b5/c5f60a2b5bc74f8ca0eef40158806c/content.htm

http://help.sap.com/saphelp_erp2004/helpdata/en/b5/c5f60a2b5bc74f8ca0eef40158806c/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/20/e81c3b84e65e7be10000000a11402f/frameset.htm

http://help.sap.com/saphelp_nw04/helpdata/en/20/e81c3b84e65e7be10000000a11402f/frameset.htm









eCATT Links From SAP Service Marketplace:

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

eCATT Details On Service Marketplace:

https://websmp204.sap-ag.de/~form/sapnet?

_FRAME=CONTAINER&_OBJECT=011000358700003012112003E

eCATT Frequently Asked Questions:

https://websmp104.sap-ag.de/~sapidb/011000358700003021722003E#availabl

esince

eCATT Security Guide:

https://websmp204.sap-ag.de/~form/sapnet?

_FRAME=CONTAINER&_OBJECT=011000358700003043282003E

Useful eCATT Links From SDN Forum:

How To Find eCATT Version:

https://www.sdn.sap.com/irj/sdn/thread?

forumID=117&threadID=133916&messageID=1501467

eCATT Error - ‘Error In Control Details:



eCATT Error – ‘Control Data Obsolete’ Details:



Testing Custom Report Output Using eCATT:



eCATT - Problem With ME21/MIRO/MIGO:



eCATT Error – Screens Smaller When Replayed & Caused Error:



eCATT - Executing Several Variants At Once:



eCATT – Creating Summary Report Based On Logs:



https://www.sdn.sap.com/irj/sdn/thread?forumID=117&threadID=111915&messageID=1250664
















https://websmp204.sap-ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700003043282003E


https://websmp104.sap-ag.de/~sapidb/011000358700003021722003E#availablesince

https://websmp104.sap-ag.de/~sapidb/011000358700003021722003E#availablesince



eCATT Error -GUI Recording Not Working With VA01 (RE) Return:



eCATT – Which Dynpro Of Recording Corresponds To Which Screen Of

Transaction:



eCATT – Running eCATT Scripts In Batch:



eCATT – SAP’s Best Practice For eCATT:



eCATT – Updating Automatic Execution Result In Solution Manager:



eCATT – Testing eCATT Scripts In Multiple System:



eCATT – Meaning Of Transactions Containing Controls (SAPGUI):



eCATT – Workflow Testing By eCATT:



eCATT – SAPGUI Mode – Making Screen Optional:



eCATT – Parameterize The Input Date As System Date:



eCATT – Impact Of Solution Manager Version Upgrade On eCATT:



eCATT Error - Problem In Recording ME5J/ME53N:



eCATT – Security Testing Via eCATT:



eCATT Error: Problems Due To Changed Configuration & Master Data:































New To eCATT:



eCATT – Uploading Data From Excel:



eCATT – SAPGUI Recording Queries:



eCATT Error – Testing Webdynpro Logon Error:



eCATT – TCD Mode – Dynamically Assigning Parameter Value –



eCATT - Difference Between CATT & eCATT:



eCATT - RFC Functions In eCATT:



eCATT Error – eCATT Not Supported In SAPGUI For JAVA:



eCATT – Log Export RFC Function Module:























Blogs

eCATT : Creating a Test Case for a Web Dynpro ApplicationSumeet Kaul Business CardCompany: HCL Technologies LtdPosted on Feb. 14, 2006 07:07 AM in ABAP, SAP NetWeaver Platform

In my previous Welogs on eCATT , I discussed topics starting from "Introduction to

eCATT" to "Executing a Test Case using eCATT ". This Weblog will go a step further

and discuss how to create a Test Case for a Web DynPro Application. This is one of

the major features of eCATT that allows users to test business processes that cross

system boundaries.

The scenario for Test is as follows :

Scenario

The goal is to create a Test Case for a Web Dynpro Application that is on java Stack .

The application is for Purchase Order Creation.

The application will be tested for different set of data .

The url is : http://<server>:<port>/webdynpro/dispatcher/local/PO/CreatePO

Procedure:

The first step towards creating a Test Case for a Web Dynpro Application is to create a

RFC destination in SAP .

Tcode : SM59

RFC Destination : WEBDYNPRO2 , Type : G

Target Host : <server>

Service : <port>










http://www.sdn.sap.com/irj/scn/bc?u=DLyq2CGRS5I%3D





Now , create a System data Container assigning HTTP RFC destination created above .

Tcode : SECATT

After creation of Test Data Container , Create Test Script . ( the creation of the same

has been discussed at length in my previous weblogs )

In pattern option under UI control Group select WEBDYNPRO command .

Entering System data Container and Target System .

The Application in our case is “/webdynpro/dispatcher/local/PO/CreatePO”

Recording starts . The application starts in the browser .

Entering appropriate Header Info in the fields .

Adding item details .

Creating Purchase Order .

The PO is created in SAP and the PO number is reflected in top right corner .

Now , click “Stop Recording” Option .

Below we can see a WEBDYNPRO command is created for each page of application.

Now Parameterize the Input values

Creating Test Data Container .

2 Variants for are created . The Company code data is different in both cases .

For Test Variant 1 : Company Code is 1000.

For Test Variant 2 : Company Code is 3000.

Now Creating Test Configuration and attaching Test Data Container .

Executing Test Configuration .

Examining Log we see that :

PO can be created with var1 ( Company Code :1000 )

PO cannot be created with var2 ( Company Code :3000 )

Thus we were able to successfully Create a Test Case for a "Web Dynpro

Application" deployed on Java Stack using eCATT.

Sumeet Kaul is presently working for HCL Technologies Ltd, as a NetWeaver

Consultant.


Documents

eCATT Tutorial