ECATT VSDK 3.0. SAP AG 2005, Title of Presentation / Speaker Name / 2 Target Group and Prerequisites Target Group Implementation and integration teams.

eCATT

VSDK 3.0

SAP AG 2005, Title of Presentation / Speaker Name / 2

Target Group and Prerequisites

Target Group Implementation and integration teams

Quality managers supervising in-house development

Prerequisites Experience of software testing

An understanding of the architecture of the SAP Web Application Server (as provided in course SAPTEC)


Course Goals

In this course, you will learn What and when you need to test in the SAP Solution Lifecycle

The advantages of eCATT for testing SAP systems compared with other automated test tools

How to set up your system environment for testing with eCATT

How to create test cases to test various different kinds of SAP applications

How to create executable tests, and how these can be managed using the SAP Test Workbench

How to migrate CATT objects to eCATT


Contents

Unit 1Getting Ready to Test

Unit 2Getting Ready to Test with

eCATT

Unit 3eCATT Scripts and the

Script Editor

Unit 4Non-UI Testing

Unit 5Testing Transactions - I

Unit 6Testing Transactions - II

Unit 7Testing Transactions - III

Unit 8Building Executable Tests

Unit 9Advanced Topics

Unit 1: Getting Ready to Test


Unit Objectives

In this unit, you will learn: When you need to test in your SAP environment

The advantages and disadvantages of manual and automated testing

Decision criteria for selecting an automated test tool

What can be tested using SAP eCATT


Occasions for Testing

New SAP installations

Addition and integration of new components

In-house developments Functional Tests

Integration tests with other components

Upgrades – regression testing

Application of Legal Change Packages


Manual or Automated Testing

Manual Testing Requires a group of testers who must

Have lab space to work inBe trainedBe released from their other duties (internal) or “bought-in” (external)

Is time-consuming Offers little potential for reuse of test resources But does have the advantage that manual testers spot errors and issues

that are beyond the scope of the test plan

Automated Testing Requires fewer people and resources Execution takes less time Parameterization of fields allows replay with any number of different

sets of values Offers considerable possibilities for reusing test scripts Makes it easier to reproduce errors that occur during testing


The Economics of Testing

Automated testing requires good planning and modeling

Learning to use a new test tool takes time

An automated test script will only give you maximum ROI if it is reusable

A switch to automated testing requires investment and commitment

Not every test scenario has to be automated If it doesn't have to be repeatable, it doesn't necessarily have to be

automated

Automation is a means to an end, not an end in itself. If it is taking too long to automate the last 5% of your test scenario, consider running that part manually!


Choosing an Automated Test Tool – External Tools

Classic automated test tools can test an SAP System by driving the SAP GUI...

Automated Test Tool

ScriptSAPGUI Window

Fro

nten

dB

ackend

... But treat the SAPGUI Window as a standalone desktop application: Generally not aware of the multiple tier solution

No access to what is happening on the application server or the database


Choosing an Automated Test Tool – SAP CATT

CATT – Computer Aided Test Tool

Available from Release 3.0

Advantages Shipped free with SAP Basis System

Most effective testing method for SAP transactions

Disadvantages Control technology not fully supported

No support for tabular parameters of function modules

Only limited support for distributed system environments

Only limited support for external applications


Choosing an Automated Test Tool - SAP eCATT

The Extended Computer Aided Test Tool (eCATT) is the successor to SAP‘s CATT.

Its design aims were to Enable as many SAP transactions as possible to be tested

automatically

Provide a simplified concept for testing in a complex system landscape

Allow reuse of test data by storing it in separate container objects

Leverage the benefits of the existing CATT

eCATT is available with Release 6.20 of the SAP Web Application Server

With it, you can remotely test any mySAP.com solution that is running R/3 Basis Release 4.6C or higher (see note 519858 for details of required support packages)


What Applications Can Be Tested Using eCATT?

Transactions in SAP GUI for Windows

Transactions in SAP GUI for Java

Web-based Transactions

Desktop-based transactions

Function Modules and BAPIs

. . . Using Built-In eCATT Means

. . . Using eCATT Together With a Certified External Tool


What Does Testing an Application Mean?

Recording the application so that it can be replayed

Parameterizing the application

to allow it to be replayed with varying values

Setting checks on the application to make the test

react to different circumstances

Making thetest reusable


What Systems Can Be Tested Using eCATT?

You require at least one SAP Web Application Server 6.20 to operate as a test server

From this central test system, you can test any other system that is running the component SAP_BASIS with Release 4.6 Support Package 32 or higher

Web AS 6.20

eCATT

R/3

CRM

APO


Unit Summary

In this unit, you have learned Some of the issues you have to consider in deciding a test strategy

The functional test tools that are available from SAP

The scope of eCATTThe applications that you can test with itThe system landscape in which you can test

Unit 2: Getting Ready to Test With eCATT


Unit Objectives

In this unit, you will learn: How a finished eCATT test case is put together

The different object types used in eCATT

How to set up a system for use with eCATT

Some of the security aspects that you need to consider


A Finished Example

TestInstructions

SystemLandscape Description

Data todrive the

test

Test Configuration

ResultsArchive


The Different Object Types

Test ScriptThe set of commands that forms the test

Test Data ContainerReusable sets of data that can be used to run tests

System Data ContainerA list of systems that are addressed during the

execution of a test script

Test ConfigurationA test script, combined with data from one or more test data containers,

plus a system data container that describes the correct system landscape


Constructing an Automated Test Series

What applications am I going to test?

What does my system landscape look like?

How can I best create an automated test for my applications?

What data do I need to drive the tests?

How can I organize my test cases?

1

2 3

4 5

System data

container

Test

script

Test data

container

Test Workbench


Setting Up the System

Support Package Levels Each system in which you want to test must have at least the following

support package level4.6C: Support Package 324.6D: Support Package 216.10: Support Package 17

Client Settings In each client in which you want to test, you must ensure that the

CATT/eCATT flag is set to allow tests to run

GUI Scripting In order to use the new GUI Scripting functions, the following settings

have to be made:Profile parameter sapgui/user_scripting must be set to TRUESAP GUI must be Version 6.20 with patch level =>18 and GUI Scripting

installed


Mapping the System Landscape

R/3CRM APO

Business Process

Web AS 6.20

eCATT

1. Test CRM transaction2. Check table entries

in R/33. Run transaction in R/34. Call function module

in APO

RFC


Defining RFC Destinations

Source System Target System

RFC Destination

Client: 100Lang: ENUser: testerPwd: letmein

Target Transaction

Direct but unsafe

Client: 100Lang: ENUser: <current>

RFC Destination

Target Transaction

Safe but cannot run unattended


Function of System Data Containers

CommandWith

LogicalTarget

Test Script

Target System

System Data Container

Target < -- > RFC Dest.

The logical target describes the function of the system – for example R/3. The system data container maps the logical name to a particular RFC destination.


Creating a System Data Container

SAP Web AS 6.20

System undertest

Relationship described by RFC destination XYZ

System Data Container

Target system RFC Destination. . . . . .

R3 XYZ


Advantages of System Data Containers

Consistency One container can serve a whole project

The RFC destinations can contain the client, language, and user name for the logon – eliminates sources of errors

Access to SM59 and the authorization to create system data containers can be restricted to project leads

Reuse Using logical system names in a script means that the execution

environment of the script can be changed by switching system data containers. Changes in the script coding are not required.


Unit Summary

In this unit, you have learned The different object types with which you work in eCATT

How these object types support you in the various stages of planning an automated test project

How to set up a system to enable eCATT

How to define secure RFC destinations

How to create a system data container

Unit 3: eCATT Scripts and the Script Editor


Unit Objectives

In this unit you will learn: The structure of an eCATT script

The essential features of the eCATT script editor

The main aspects of the eCATT scripting language

How to work with parameters


Design Considerations for a Script

Definite Goal

Before you write your script, work out exactly what you want it to do

Reusability

Try to create small self-contained script modules. This will make them more easily reusable.


Structure of a Script

Test Script

Attributes

Commands

Parameters

Importing ExportingLocal variables


Script Attributes

Administrativedata about thescript

Search terms:Can be used in Infosystem

Attaches systemdata container toscript, allowingaccess to othersystems


The Script Editor

CommandEditor

StructureEditor

Parameter List


Simple Parameters

Creation

Use

I_IMPORT = 'LH'.

CHEVAR ( I_IMPORT <> 'UA' ).

. . .


Structured Parameters

Use

I_STRUCTURE-CARRID = 'LH'.

I_ITAB[2]-CONNID = '0400'.

GETLEN ( I_ITAB, VAR ).


Script Language

Recording and playback of applications

Conditions

Loops

Checks

Calculations

Reading table valuesSimulation of

Customizing settings

Blocks of ABAP coding


Commands for Recording Applications

Recording and playback of applications

FUN calls a function module

TCD allows you to recordand replay SAP

transactions

SAPGUI allows you to record sequencesof screens containing

controls

An interface allows youto integrate test tools

from third-party vendorswith SAP eCATT


Choosing the Right Driver

Is the applicationa function module

or BAPI?

Yes

Use FUN

No Does the application run under SAP GUI for

Windows or Java?

NoUseext. tool

Yes

Does the application use controls?

No UseTCD

Yes

Are the controlsessential within the transaction?

No

Yes

Use SAPGUI

No single driverprovides the best solution for every application


Special Variables

&SZBRC - Return code

&TIME - Current time

&DATE – Current date

&YEAR – Current year

&YEARA – Next year

&YEARB – Last year

&LPC – Loop counter

&MSX – Number of messages returned by a transaction

&USER – User name

&CLIENT – Current client


Pattern Function

The Pattern function is similar to the statement pattern in the ABAP Editor. It allows you to build individual eCATT commands.

A command consists of: The command keyword

Argument (the target object)

Interface (parameters that need to be passed)

Target system


Command Interface

Most eCATT commands have a command interface, which corresponds to: The interface of a function module (for FUN)

The screen and field structure of a transaction (for TCD)

A list of user interactions (for SAPGUI)

The importing and exporting parameters of a referenced script

Command interfaces are stored in XML format in the local system, even if the object that they describe only exists in a remote system.


Unit Summary

In this unit, you have learned The various areas of the eCATT Test Script Editor

The features of the eCATT script language

How to create eCATT parameters

How to use the pattern function in the eCATT Script Editor

Which driver to use for various kinds of applications

Unit 4: Non-UI Testing

Function Modules and BAPIsTable Operations Inline ABAP


Unit Objectives

In this unit you will learn: How to test function modules and BAPIs

How to read from and test against the database

How to use blocks of ABAP coding to enhance your test scripts




or BAPI?

Yes

Use FUN


Non-UI Testing: Function Modules

FunctionModule

Unit Test

FunctionModule

FunctionModule

FunctionModule

Whole Backend Process

FunctionModule

Transaction

Utility Within a Script

Transaction


Testing Function Modules

FUN ( <function module>, <interface>, [<target>] ).

Command Interface

Importing

Exporting

Changing

Tables

Exceptions

Function Module


Parameterizing the Interface

or

INTERFACE-IMPORTING-PARAMETERNAME = value.

INTERFACE-IMPORTING-STRUCTURE-FIELDNAME = value.

INTERFACE-TABLES-TABLE[idx]-FIELDNAME = value.


Trapping Exceptions

DATA_INCOMPLETE CREATE_FAILED

Exceptions

Interface

DATA_INCOMPLETE CREATE_FAILED

Exceptions

Interface


Table Operations

Test Script Database

Application Table

Customizing Table

GETTAB ( TAB, INTF, [DEST] ).

CHETAB ( TAB, INTF, [DEST] ).

SETTAB ( TAB, INTF, [DEST] ).

RESTAB ( TAB, [DEST] ).


Using Inline ABAP

ABAP.* Any ABAP Coding that is allowed in a subroutine* may appear hereENDABAP.

ParametersName Description Value I/E/V Ref Type

V_TAB SFLIGHT-table <INITIAL> V SFLIGHT[]

ABAP.SELECT * FROM sflight INTO TABLE v_tab WHERE carrid = ‘LH’ AND connid = ‘0400’.ENDABAP.

Expecting a result set of more than one line.No corresponding function module available.“Once-off” query


Unit Summary

In this unit you have learned: How to test function modules and BAPIs

How to read from and test against the database

How to use blocks of ABAP coding to enhance your test scripts

Unit 5: Testing Transactions - I

Testing conventional transactions using the TCD command


Unit Objectives

In this unit you will learn: What transactions are suitable for testing using the TCD command

How to record a transaction using the TCD command

How to set input fields, read output fields, and perform fields checks with the TCD command




or BAPI?


Windows or Java?

Yes


No UseTCD

Yes


No


Characteristics of the TCD Command

The TCD command is the recording technique that was used to test transactions in CATT

It is based on the Batch Input Interface

It allows you to record a transaction, parameterize its input fields, and read or set checks against its output fields


Background: The Batch Input Interface

Background: Data-consistency checks in SAP transactionsare often implemented within the coding of the screen flow logic (Process After Input)

Batch Input is a technique originally developed for data transferfrom legacy systems into an R/3 System that processes transactions in the background

CATT used this technique for unattended transaction testing. It is a very efficient testing method, and has consequently been retained in eCATT


The TCD Command

TCD ( transaction, interface, [sys] )

Same system

Different system


How TCD Really Works - Recording

ENTER

FIELD VALUE

VBAK-AUART AFVBAK-VKORG 1000. . .BDC_OKCODE ENT2

FIELD VALUE

KUAGV-KUNNR 1280VBAP-MATNR P-103. . .BDC_OKCODE SICH


How TCD Really Works - Replay

No SAP GUI session

FIELD VALUE

. . .BDC_OKCODE

FIELD VALUE

KUAGV-KUNNR 1280VBAP-MATNR P-103. . .BDC_OKCODE SICH

VBAK-AUART AFVBAK-VKORG 1000

Field values

ENT2Function code


The Command Interface

Transaction

Screen

Screen

Field

Field

Field

Field

Field


Parameterizing Input Fields

Double-click

Field name Value

You can replace the recorded values with either literals or variables


Reading and Checking Output Fields

To...

Read a value

Check a value

MODE must be...

'G'

'C'

Field name in VALIN column

Will contain value from output fieldat the end of the transaction

Contains the value that must be present in the screen field at runtime


Message Handling

Location of message(program and screen)

Message attributes(type, ID, number)

Message variables(up to four)

Full text of message(in logon language)

MSGInternal Table

Number of messages&MSX

TCD

Command Interface


Reading Message Contents

Addressing the Last Message

<interface>-MSG[&MSX]-<component>

Looping Through All Messages

DO &MSX.<interface>-MSG[&LPC]-<component>ENDDO.


Testing Messages

ON_LAST_MESSAGE_CHECK ( 031 ).

TCD ( EC_TUTORIAL_TCD, EC_TUTORIAL_TCD_1 ).

ON_LAST_MESSAGE_CHECK ( * ).

TCD ( EC_TUTORIAL_TCD, EC_TUTORIAL_TCD_1 ).

Require that a particular message is sent

Tolerate all messages


Troubleshooting the TCD Command


Unit Summary

In this unit you have learned: What transactions are suitable for testing using the TCD command

How to record a transaction using the TCD command

How to set input fields, read output fields, and perform fields checks with the TCD command

Unit 6: Testing Transactions - II

Testing control-based transactions using the SAPGUI command


Unit Objectives

In this unit, you will learn: Why the TCD driver is not suitable for testing all transaction types

How GUI Scripting works

How to use the eCATT SAPGUI command to record a transaction

How to set input fields, read output fields, and perform field checks in a SAPGUI recording




or BAPI?


Windows or Java?

Yes


Yes


Yes

Use SAPGUI


Why TCD Cannot Test Everything

SAP GUI Window

Fro

nte

nd

Ba

cke

nd

TCD

Recorder

Application

Logic

ControlALV

Tree

Calendar

OCX control underWindows

Bean under Java

Action leads tolocal processing

in SAP GUI

Action leads toevent handler

on application server

New recordingcomponent

eCATT


Introducing GUI Scripting

Scripting host in GUI

(Requires SAP GUI 6.20)

eCATT at backend


Recording the SAPGUI Command – Procedure

1. Select SAPGUI(Record)

2. Set the scripting granularity


Recording the SAPGUI Command - Procedure

3. Confirm that you want to record

4. Pick the relevant initial states to record


Scripting Granularity

Action

Action

Action

Action

Action

Action

Action

Session

Action

Action

Action

Action

Action

Action

Action

Transaction

Action

Action

Action

Action

Action

Action

Action

Screen

S

S

T

T: New Transaction S: New Screen


Making Sense of the Command Interface - 1

One ProcessedScreen node per screen

UserChangedState describes the user actions on the screen


Parameterizing an Input Value

Field name

Double-click

Enter parameter name in this field


Recording the SAPGUI Command – Initial State


Active and Inactive Checks

Active Checks Record the initial states of the selected screen element types

On replay, check that the values in the fields correspond to the recorded initial states

Inactive Checks Record the initial states of the selected screen element types so that

they can be placed into script parameters and used in the rest of the script


Making Sense of the Command Interface - 2

One InitialState node per processed screen

Are checks active?

Field name

Field value during recording


Retrieving an Output Value

Double-click

Enter parameter

name inthis field


Activating and Deactivating Field Checks


Message Handling – MESSAGE

Stipulate that certain messages must/must not occur in order for the script to be a success

Find out what messages occurredduring a particular block of SAPGUI commands


Message Handling - ENDMESSAGE

MIDX MODE MSGTYP MSGID MSGNR MSGV1 MSGV2 MSGV3 MSGV4

<n> F E ECDEMO 003 LH 0400

2 A E ECDEMO 021

3 A S XY 100

E_MSG_1

E_MSG_1[1]-MIDX contains the total number of messages in the table


Creating Rules in the MESSAGE Statement

Rule = What to do + Message qualification

What to do

R: RequireE: ExpectA: AllowF: Fail

Mode

ExitContinue processingor jump directly to ENDMESSAGE?

Message qualification

Any combination of

MessageType

MessageClass

MessageNumber


Some Sample Message Rules

“Tolerate all error messages”

Mode Exit MSGTYP ID Number

'A' 'E'

“Fail script and jump to ENDMESSAGE on error message ZJM 001”

Mode Exit MSGTYP ID Number

'F' 'X' 'E' 'ZJM' '001'


Default Message Handling Rules

User-defined Rules

AllowSuccessInformation messagesWarning

Fail and ExitErrorTermination messagesDump


Message Processing

NewMessage

Process accordingto rule

Look up in user-defined

rules

Process accordingto rule

Look up in defaultrules

Discard


The SAPGUI Command Interface 4

System Information


Activating and Deactivating Screens

Active = ‘X’: Screen activeActive = ‘ ’: Screen inactiveActive = ‘O’: Screen optional

Screen 1 Screen 2 Screen 3

“Join” OK?


Troubleshooting in the SAPGUI Command

Set automation queue behavior

Run commands with stops at various granularity levels

Close GUI sessions or leave them open for inspection


Unit Summary

In this unit, you learned: Why the TCD driver is not suitable for testing all transaction types

How GUI Scripting works

How to use the eCATT SAPGUI command to record a transaction

How to set input fields, read output fields, and perform field checks in a SAPGUI recording

How to activate and inactivate screens in a script, and the things that you have to consider when doing so

Unit 7: Testing Transactions - III

Testing Web- and Desktop-based Applications Using an External Tool


Unit Objectives

In this unit, you will learn: When to use TCD and SAPGUI, and when you have to use an external

tool

Why SAP chose to work with external tools

The advantages of the external tool integration

How the integration works




or BAPI?


Windows or Java?

NoUseext. tool


Configuring The System for an External Tool

Run function module SET_EXTERNAL_TOOLin test mode

Run programECATT_GENERATE_ET_USERto generate service user

Regenerate authorizations in role SAP_ECET


External Tool Integration - Architecture

eCATT

Scriptwith

Attributes

Application Server Database

Scripts storedin SAP database

Frontend

External Tool

Physicalscriptcommands

ApplicationUnderTest


Using Compuware TestPartner to Record a Script

Recording

VBA Functionality

Checks

Parameterization


Passing Arguments To and From TestPartner – Argument Container

TestPartner

Script

Argument Container

eCATT


Passing Arguments To and From TestPartner – Script Coding

Name Type Direction ...

I_Name String IMPORT ...

E_Value String IMPORT ...

Argument Container

Script: VBA Coding

Sub Main ()

Dim ImportParam As String, ExportParam As String

ImportParam = GetEcattArg("I_NAME")

. . .

SetEcattArg "E_VALUE", ExportParam

End Sub


Uploading Scripts

Script name and version

Administrative settings

Projects for upload


Calling External Scripts

REFEXT ( SCRIPT, INTERFACE, VERSION ).


Unit Summary

In this unit, you have learned: When to use TCD and SAPGUI, and when you have to use an external

tool

Why SAP chose to work with external tools

The advantages of the external tool integration

How the integration works

Unit 8: Building Executable Tests

Calling Other Test ObjectsTest Configurations and Test Data ContainersThe Test Workbench


Unit Objectives

In this unit, you will learn: How you can modularize tests at script level

The difference between a test script and a test configuration

How to create test configurations

How to manage test data


Modularization at Script Level

There are two reasons for modularization: To split up parts of a process into separate eCATT scripts to increase

the possibility of reusing them

To allow the integration of non-eCATT objects, that isExternal scripts Existing CATT procedures


REF

Scripts can call other scripts:

REF ( SCRIPT, INTERFACE, [TARGET]).

REF

REF

REF

REF

Create Order

ATP Check

Manufacturing

Billing


REFCATT

From eCATT, you can call CATT procedures residing in the same system:

REFCATT ( CATT, INTERFACE, [TARGET] ).

REFCATT ( CATT, INT, TGT ).

CATTProcedure

TGT


REMOTECATT

You can also call CATT procedures that reside in a remote system:

REMOTECATT ( CATT, INTERFACE, TARGET ).

REFCATT ( CATT, INT, TGT ).

CATTProcedure

inTGT

EXE


Test Configuration

Importing Parameters

Script

Command <interface>, <target>.Command <interface>, <target>.Command <interface>, <target>.Command <interface>, <target>.

System mapping

System data container

Data - Variants


Manual Variants

Quick entry for a few variants

Cut and paste possible from delimited text file (Excel)

Variants bound to a single configuration – not reusable


Reusing Test Data: Test Data Containers

Importing Parameters

Script

Command <interface>, <target>.Command <interface>, <target>.Command <interface>, <target>.Command <interface>, <target>.

System mapping

System data container

VariantsTest data container

Test data container


Test Data Container

Parameters

Name Value Ref System ABAP Type Length

Airline LH S_CARR_ID

Date D 8

Variants

Variant Description Airline Date

Var1 Data AA 01.04.2002

Var2 Data LH 01.04.2002


Managing Test Data 1

Test Script

Parameters

P1

P2P3

Test Data Container

Parameters

P1

P2P3



Test Script

Parameters

P1

P2P3

Test Script

Parameters

P1

P4P5

Test Script

Parameters

P2

P5P6

Test Data Container

Parameters P1, P2, P3, P4, P5, P6



Test Script

20 Parameters

Test Script

15 Parameters

Test Script

24 Parameters

Test Data Container

ParameterGroup 1

Test Data Container

ParameterGroup 2

Test Data Container

ParameterGroup n. . .


Variant Wizard

Test Data Container Configuration Variants

Variants Variants

Start variant wizard


Managing Test Data - Example

I_CARRID I_CONNID I_FLDATE I_FARE I_CURR I_TYPE I_MAX_E I_MAX_B...

LH 0400 20030101 600 EUR 747 250 40

LH 0400 20030102 750 EUR 747 250 40

LH 0400 20030103 600 EUR 747 250 40

QF 0006 20030101 1500 AUD 747 250 40

QF 0006 20030102 1850 AUD 747 250 40


Managing Test Data - Example

Test Data Container

AIRCRAFT

Test Configuration

Maximize reuse

Minimize redundancy

Data for a particulartest case

Test Data Container

AIRLINES


Modularization at Test Organizer Level

Test Catalog

Test Plan

Test Configuration

Test Configuration

User

Test Package


Unit Summary

In this unit, you have learned: How you can modularize tests at script level

The difference between a test script and a test configuration

How to create test configurations

How to manage test data

Unit 9: Advanced Topics

Versioning of ScriptsMigrating CATT Procedures


Unit Objectives

In this unit, you will learn Why script versioning is necessary

How to create different versions of a script

How the system picks the correct version of a script for execution

How to migrate CATT procedures to eCATT


Versioning

For different implementations of the same test (for example, transaction with / without controls), you can create different versions of the same script.


How Versioning Works

Test Configuration

Script EC_DEMO

Sys. Data EC_DEMOSYSTEMS

Target Sys. R3

Version 1: SAP_APPL 46C

Version 2: SAP_APPL 470

R/3Rel. 4.6C

Release? 4.6C

Version 1: SAP_APPL 46C


Specifying the Validity of a Version

Target System


Backup Versions

Version 1

SAP_BASIS 610

Version 2

SAP_BASIS 620

Version 3

SAP_BASIS 620

Version 2

SAP_BASIS 620

Backup


Test System

eCATT

Migration Function

Migration

Target System

‘X’

CATT Module

CATT Module

New eCATT ScriptNew eCATT ScriptWith target system X


Migrating Variants

Target System

‘X’

CATT Module

Variants

Test System

New eCATT Scriptwith target system X

Test Configuration

Target System X

Variants

Script


Recursive Migration

Target System

‘X’

CATT Module

REF…REF…

CATTModule

CATTModule

Test System


REF…

REF…

New eCATT Script



Unit Summary

In this unit, you have learned Why script versioning is necessary

How to create different versions of a script

How the system picks the correct version of a script for execution

How to migrate CATT procedures to eCATT


Course Summary

In this course, you have learned What and when you need to test in the SAP Solution Lifecycle

The advantages of eCATT for testing SAP systems compared with other automated test tools

How to set up your system environment for testing with eCATT

How to create test cases to test various different kinds of SAP applications

How to create executable tests, and how these can be managed using the SAP Test Workbench

How to migrate CATT objects to eCATT

ECATT VSDK 3.0. SAP AG 2005, Title of Presentation / Speaker Name / 2 Target Group and Prerequisites Target Group Implementation and integration teams.

Documents

sap ag

sap test workbench

sap ecatt slide

testing sap systems

sap gui

testing slide

sap environment

test plan automated