Beginners Guide To Ecatt

eCATT
VSDK 3.0
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)
SAP AG 2005, Title of Presentation / Speaker Name / #
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 1 Getting Ready to Test
Unit 5 Testing Transactions - I

Unit 6 Testing Transactions - II
Unit 2 Getting Ready to Test with eCATT
Unit 7 Testing Transactions - III
Unit 3 eCATT Scripts and the Script Editor
Unit 8 Building Executable Tests Unit 9 Advanced Topics
Unit 4 Non-UI Testing
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 in Be trained Be 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 Frontend SAPGUI Window
Script
... 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
Backend
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 SAPs 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? . . . Using Built-In eCATT Means
Transactions in SAP GUI for Windows
Transactions in SAP GUI for Java
Function Modules and BAPIs
. . . Using eCATT Together With a Certified External Tool
Web-based Transactions
Desktop-based transactions
What Does Testing an Application Mean?
Making the test reusable
Setting checks on the application to make the test react to different circumstances
Parameterizing the application to allow it to be replayed with varying values
Recording the application so that it can be replayed
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
R/3
eCATT
CRM
Web AS 6.20
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 eCATT

The The
applications that you can test with it system landscape in which you can test
Unit 2: Getting Ready to Test With eCATT

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
Test Configuration
System Landscape Description
Test Instructions
Data to drive the test
Archive
Results
The Different Object Types
Test Script
The set of commands that forms the test
System Data Container

A list of systems that are addressed during the execution of a test script
Test Data Container

Reusable sets of data that can be used to run tests
Test Configuration
A 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?
System data container Test data container
1 2
4 3
Test script
5
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 level
4.6C: 4.6D: 6.10:
Support Package 32 Support Package 21 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 SAP
parameter sapgui/user_scripting must be set to TRUE
GUI must be Version 6.20 with patch level =>18 and GUI Scripting installed
Mapping the System Landscape
1. 2. eCATT 3. 4.
Web AS 6.20
Test CRM transaction Check table entries in R/3 Run transaction in R/3 Call function module in APO
RFC
CRM
R/3
APO
Business Process
Defining RFC Destinations
Source System
RFC Destination Client: Lang: User: Pwd: 100 EN tester letmein
Target System
Direct but unsafe
Target Transaction
Safe but cannot run unattended

RFC Destination
Client: 100 Lang: EN User: <current> Target Transaction
Function of System Data Containers
Test Script System Data Container Command With Logical Target Target System
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 under test
Relationship described by RFC destination XYZ
Target system
. . .
RFC Destination XYZ
. . .
R3
System Data Container

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.

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
Parameters Importing
Exporting
Local variables
Commands
Script Attributes
Administrative data about the script
Search terms: Can be used in Infosystem
Attaches system data container to script, allowing access to other systems

The Script Editor
Parameter List
Command Editor
Structure Editor
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
Checks
Loops
Calculations
Simulation of Customizing settings
Reading table values
Blocks of ABAP coding
Commands for Recording Applications
Recording and playback of applications
FUN calls a function module TCD allows you to record and replay SAP transactions SAPGUI allows you to record sequences of screens containing controls
An interface allows you to integrate test tools from third-party vendors with SAP eCATT
Choosing the Right Driver
Is the application a function module or BAPI?
No
Does the application run under SAP GUI for Windows or Java?
No
Use ext. tool
Yes
Yes Does the application use controls?
Use FUN
No
Use TCD
No
Yes
No single driver provides the best solution for every application

Are the controls essential within the transaction? Yes
Use SAPGUI
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.

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 BAPIs Table Operations Inline ABAP

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
Yes
Use FUN
Non-UI Testing: Function Modules
Unit Test Function Module
Whole Backend Process Function Module
Utility Within a Script
Transaction
Function Module
Function Module
Function Module
Transaction
Testing Function Modules
FUN ( <function module>, <interface>, [<target>] ).
Command Interface
Importing
Exporting Changing
Tables
Function Module
Exceptions
Parameterizing the Interface
or
INTERFACE-IMPORTING-PARAMETERNAME = value. INTERFACE-IMPORTING-STRUCTURE-FIELDNAME = value. INTERFACE-TABLES-TABLE[idx]-FIELDNAME = value.
Trapping Exceptions
Interface
Exceptions DATA_INCOMPLETE CREATE_FAILED
Interface
Exceptions
DATA_INCOMPLETE CREATE_FAILED
Table Operations
Test Script
GETTAB ( TAB, INTF, [DEST] ). CHETAB ( TAB, INTF, [DEST] ). SETTAB ( TAB, INTF, [DEST] ). RESTAB ( TAB, [DEST] ).
Database
Application Table
Customizing Table
Using Inline ABAP

ABAP. * Any ABAP Coding that is allowed in a subroutine * may appear here ENDABAP.
Parameters Name Description

V_TAB SFLIGHT-table
Value <INITIAL>
I/E/V V
Ref Type 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

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
No
No
Use TCD
No
Yes Are the controls essential within the transaction?
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 transactions are often implemented within the coding of the screen flow logic (Process After Input)
Batch Input is a technique originally developed for data transfer from 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 VBAK-AUART VBAK-VKORG . . . BDC_OKCODE
VALUE AF 1000 ENT2
FIELD KUAGV-KUNNR VBAP-MATNR . . . BDC_OKCODE
VALUE 1280 P-103 SICH
How TCD Really Works - Replay
No SAP GUI session
Field values FIELD VBAK-AUART VBAK-VKORG . . . BDC_OKCODE VALUE AF 1000 ENT2 Function code FIELD KUAGV-KUNNR VBAP-MATNR . . . BDC_OKCODE VALUE 1280 P-103 SICH
The Command Interface
Transaction
Screen Field Field Field Screen
Field
Field
Parameterizing Input Fields You can replace the recorded values with either literals or variables
Field name Double-click Value
Reading and Checking Output Fields

To... Field name in VALIN column Will contain value from output field at the end of the transaction Contains the value that must be present in the screen field at runtime
MODE must be...
Read a value
'G' 'C'
Check a value
Message Handling
TCD Command Interface
Location of message
(program and screen)
Message attributes
MSG
Internal Table
(type, ID, number)
Message variables
(up to four)
Number of messages &MSX
Full text of message

(in logon language)
Reading Message Contents
Addressing the Last Message <interface>-MSG[&MSX]-<component>
Looping Through All Messages DO &MSX. <interface>-MSG[&LPC]-<component> ENDDO.

Testing Messages
Require that a particular message is sent ON_LAST_MESSAGE_CHECK ( 031 ). TCD ( EC_TUTORIAL_TCD, EC_TUTORIAL_TCD_1 ).
Tolerate all messages ON_LAST_MESSAGE_CHECK ( * ). TCD ( EC_TUTORIAL_TCD, EC_TUTORIAL_TCD_1 ).
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

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
No
Yes Are the controls essential within the transaction? Yes
Use SAPGUI
Why TCD Cannot Test Everything SAP GUI Window Control

ALV Tree Calendar New recording component OCX control under Windows Bean under Java Action leads to local processing in SAP GUI
Frontend
Backend
TCD Recorder
eCATT Application Logic
Action leads to event handler on application server
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 Action Action Action
Action
Action
S
Action Action Action S Action Action Transaction T: New Transaction
Action
Action Action Screen S: New Screen
Action
Session
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
Enter parameter name in this field
Double-click
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 in this 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 occurred during a particular block of SAPGUI commands
Message Handling - ENDMESSAGE
MIDX <n> 2 3
MODE F A A
MSGTYP E E S
MSGID ECDEMO ECDEMO XY
MSGNR 003 021 100
MSGV1 LH
MSGV2 0400
MSGV3
MSGV4
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: E: A: F: Require Expect Allow Fail
Message qualification
Message Type Message Class
Mode
Any combination of Continue processing or jump directly to ENDMESSAGE?
Exit
Message Number
Some Sample Message Rules Tolerate all error messages
Mode 'A'
Exit
MSGTYP 'E'
ID
Number
Fail script and jump to ENDMESSAGE on error message ZJM 001
Mode 'F'
Exit 'X'
MSGTYP 'E'
ID Number 'ZJM' '001'
Default Message Handling Rules
User-defined Rules
Allow
Success Information messages Warning
Fail and Exit
Error Termination messages Dump
Message Processing
Look up in user-defined rules New Message
Look up in default rules
Discard
Process according to rule

Process according to rule
The SAPGUI Command Interface 4
System Information
Activating and Deactivating Screens
Active = X: Screen active Active = : Screen inactive Active = 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

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
No
No
Use ext. tool
Configuring The System for an External Tool
Run function module SET_EXTERNAL_TOOL in test mode
Run program ECATT_GENERATE_ET_USER to generate service user
Regenerate authorizations in role SAP_ECET

External Tool Integration - Architecture

Application Server Database
eCATT
Script with Attributes
Scripts stored in SAP database
Frontend
Physical script commands
Application Under Test
External Tool
Using Compuware TestPartner to Record a Script
Checks
VBA Functionality
Parameterization
Recording
Passing Arguments To and From TestPartner Argument Container
eCATT
Argument Container
Script TestPartner
Passing Arguments To and From TestPartner Script Coding

Argument Container
Name I_Name E_Value

Sub Main ()
Type String String
Direction IMPORT IMPORT
... ... ...
Dim ImportParam As String, ExportParam As String ImportParam = GetEcattArg("I_NAME") . . .
SetEcattArg "E_VALUE", ExportParam

End Sub Script: VBA Coding
Uploading Scripts
Projects for upload
Script name and version
Administrative settings
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 Objects Test Configurations and Test Data Containers The Test Workbench

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 is External scripts Existing CATT procedures
REF Scripts can call other scripts: REF ( SCRIPT, INTERFACE, [TARGET]).
Create Order
REF REF REF REF

Manufacturing ATP Check
Billing
REFCATT From eCATT, you can call CATT procedures residing in the same system: REFCATT ( CATT, INTERFACE, [TARGET] ).
REFCATT ( CATT, INT, TGT ).
CATT Procedure
TGT
REMOTECATT You can also call CATT procedures that reside in a remote system: REMOTECATT ( CATT, INTERFACE, TARGET ).
REFCATT ( CATT, INT, TGT ).
CATT Procedure in TGT

EXE
Test Configuration
Data - Variants
Importing Parameters
Command Command Command Command
<interface>, <interface>, <interface>, <interface>,
<target>. <target>. <target>. <target>.
System mapping
Script
System data container
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
Variants
Test data container
Test data container
Importing Parameters
Command Command Command Command
<interface>, <interface>, <interface>, <interface>,
<target>. <target>. <target>. <target>.
System mapping
Script
System data container
Test Data Container
Parameters
Name Value Airline LH Date Ref System S_CARR_ID ABAP Type Length D 8
Variants
Variant Var1 Var2 Description Data Data Airline AA LH Date 01.04.2002 01.04.2002
Managing Test Data 1
Test Script
Parameters P1 P2 P3
Test Data Container

Parameters P1 P2 P3
Test Script
Parameters P1 P2 P3
Test Script
Parameters P1 P4 P5
Test Script
Parameters P2 P5 P6
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

Parameter Group 1
Test Data Container

Parameter Group 2
Test Data Container
...
Parameter Group n
Variant Wizard
Start variant wizard
Test Data Container

Variants
Configuration Variants
Variants
Managing Test Data - Example
I_CARRID I_CONNID I_FLDATE I_FARE I_CURR I_TYPE I_MAX_E I_MAX_B... LH LH LH QF QF 0400 0400 0400 0006 0006 20030101 20030102 20030103 20030101 20030102 600 750 600 1500 1850 EUR EUR EUR AUD AUD 747 747 747 747 747 250 250 250 250 250 40 40 40 40 40
Managing Test Data - Example
Test Data Container AIRLINES
Test Configuration
Maximize reuse
Minimize redundancy Test Data Container AIRCRAFT
Data for a particular test case
Modularization at Test Organizer Level
Test Catalog
Test Plan
User
Test Package
Test Configuration
Test Configuration
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 Scripts Migrating 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 Sys. Data Target Sys.
Version 1: SAP_APPL 46C
EC_DEMO EC_DEMOSYSTEMS
Version 2: SAP_APPL 470
R3
Release?
4.6C
R/3
Rel. 4.6C
Specifying the Validity of a Version
Target System
Backup Versions
Version 1
SAP_BASIS 610
Version 2
SAP_BASIS Backup 620
Version 3
SAP_BASIS 620
Migration
Test System
CATT Module
Target System X
CATT Module
eCATT Migration Function
New NeweCATT eCATTScript Script

With target system X
Migrating Variants
Test System
New eCATT Script
with target system X
Target System X
CATT Module
Script Target System X
Variants
Variants Test Configuration

Recursive Migration
Test System
New eCATT Script
Target System X
CATT Module REF REF
REF REF
New eCATT Script New eCATT Script

CATT Module
CATT Module

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

Beginners Guide To Ecatt

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Beginners Guide To Ecatt

Uploaded by

Copyright:

Available Formats

eCATT

Target Group and Prerequisites Target Group

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

Course Goals In this course, you will learn

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

Unit 1 Getting Ready to Test

Unit 5 Testing Transactions - I

Unit 2 Getting Ready to Test with eCATT

Unit 7 Testing Transactions - III

Unit 3 eCATT Scripts and the Script Editor

Unit 8 Building Executable Tests Unit 9 Advanced Topics

Unit 4 Non-UI Testing

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

Unit 1: Getting Ready to Test

Unit Objectives In this unit, you will learn:

Decision criteria for selecting an automated test tool

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

Upgrades regression testing

Application of Legal Change Packages

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

Manual or Automated Testing Manual Testing

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

... But treat the SAPGUI Window as a standalone desktop application:

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

Leverage the benefits of the existing CATT

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

Transactions in SAP GUI for Java

Function Modules and BAPIs

. . . Using eCATT Together With a Certified External Tool

What Does Testing an Application Mean?

Making the test reusable

Recording the application so that it can be replayed

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

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

Unit Summary In this unit, you have learned

The scope of eCATT

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

Unit 2: Getting Ready to Test With eCATT

Unit Objectives In this unit, you will learn:

How to set up a system for use with eCATT

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

System Landscape Description

Data to drive the test

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

The Different Object Types

System Data Container

Test Data Container

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

Setting Up the System Support Package Levels

Support Package 32 Support Package 21 Support Package 17

parameter sapgui/user_scripting must be set to TRUE

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

Mapping the System Landscape

Defining RFC Destinations

Direct but unsafe

Safe but cannot run unattended

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

Function of System Data Containers

Target < -- > RFC Dest.

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

Creating a System Data Container

SAP Web AS 6.20

System under test