Beginners Guide To Ecatt

eCATT
Presented by Dawn Burns Last Modified 5/8/2012 for Microsofts ERP Systems
Original Presentation was found on SAP Marketplace. This has been modified for MS internal documentation and includes MS standards/guidelines
Target Group and Prerequisites Target Group

EAS Testing Team
Prerequisites
Experience of software testing An understanding of the architecture of the SAP
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 create test cases to test various different kinds of SAP applications How we can integrate test cases from MTM and SAP. Identify the future direction of eCATTs (Solution Manager SOLMAN)
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 SOLMAN
Unit 4 Non-UI Testing
Unit 1: Getting Ready to Test
Unit Objectives In this unit, you will learn:

What is the test 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
Testing Environment Life cycle of an eCATT (current environment)

Transport Execute in MSU Transport Execute in MST
Build in MS1
NOTE: After MSS refresh of the MSU/MST environments, the eCATTs will need to be reapplied to these test environments. To transport the items to the MSU environment, a PM can simply reapply them. To have them reapplied to the MST environment, a member of the ASM team can reapply them. All items that should be transported must be in a Package. The package we will use for eCATTs will be Z_QA_TESTING.
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 Load Runner Use load runner for Stress test scripts QTP scripts Ideal for creating scenarios that extend beyond the SAP testing limits. For example, a non SAP R/3 system. Visual Studio scripts Used for testing web service transactions. eCATTs Extended Computer Aided Testing Tool Ideal for internal SAP test scenarios unit test, intra SAP end-to-end scenarios, SAP security, etc.
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 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
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 Defaults to Current environment
Test Instructions
Data to drive the test
Note: eCATT logs that are created in the MSU/MST system will be stored on the transparent tables ECLOG*. These tables will remain untouched by the MSS system refresh.
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
Summarized SAP Definitions:

Test Script Test scripts is a persistent data object that executes the test. This executable script has an interface that will transfer data at the time of the test scripts execution. Test Configuration
Test configuration is also a persistent data object. It references the test script. It can point to several test data containers (meta sample data) and a system data container (system where the script will be executed). The test data import parameters for the test script interface are stored in this object.
Logs The execution of a test configuration or the test script is recorded in a start activity log. System data container A system data container is also a persistent data object. It has a set of parameters that will identify SAP system instances. These can be maintained independently from the test script. The system data container contains the physical connection to one or more SAP instances. These connections are identified by logical indicators, called the target systems.
Constructing an Automated Test Series What applications am I going to test? Map out the transaction/screens/fields you plan on using Identify field values that you want Are these a constant Are these variables
Will you import ,export or have a local variable?
How can I best create an automated test for my applications? Branch from one script together or a self contained script
How can I organize my test cases?
Things to remember as you create your automated scripts As you record your automated scripts keep the following in mind
Dont use tab on your keyboard, click on the field you wish to enter data into. Only select the screens/fields you wish to pick up in your recording. Enter in the field values, dont select F4 to pick the value off the list as this is just additional overhead. Try to enter in values into a field and not wait for popup screens to appear. Example, if you are creating a customer master record using transaction XD01, enter in the tax jurisdiction value for US customers and not wait for Vertex to display the popup. This can cause issues if you are wanting to run the test script in background mode later. If there is a field that will automatically generate a number value for you, like customer master number or personnel number, set the field value to in the parameter field value. If you dont do this the system will not generate a new number.

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
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: VSTF reference Number Attaches system data and target System not Used outside of SOLMAN
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. NOTE: SAPGUI only runs In foreground mode.
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
&M01 to &M04 Message parameter 1, 2, 3 or 4

&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
Interface (parameters that need to be passed) NOTE: Once the Command line value changes, the additional fields in The popup box may change as the boxes are dependent on the command.
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. This means that the script lives in the system in which you exit the script from. Currently that would be in the MS1, MSU or MST environment. Later this would be in the SOLMAN system once the test team is using SOLMAN.

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

To find this option, go to transaction SECATT: 1. Select the radio button for test script. 2. Give the script a name: Z_TEST. 3. Select Create icon. 4. Enter in a short name for the script, associate this to a module. 5. Now select the pattern pushbutton. 6. Select All commands from the commands field. 7. Now you will see FUN for the next option. 8. Enter in the name of the function module 9. Enter in an interface name or just use the SAP default 10. Now hit enter. 11. Fun command now in the editor (lower left hand quadrant of the screen) manipulate the values in the interface by selecting the interface in the editor
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

Example of the Editor Command as seen in the Test Script screen
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
Exceptions can be checked and you can highlight them for the eCATT logs. This is helpful for trouble shooting issues
Interface
Exceptions DATA_INCOMPLETE CREATE_FAILED
Interface
Exceptions
DATA_INCOMPLETE CREATE_FAILED
Table Operations
Samples of some other commands that are available in the Pattern button in the eCATT test script. These all relate to databases.
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
If you wish to run the eCATT in background mode, use TCD record option. This is especially helpful if you are calling the eCATT through a web service or if the eCATT is running as part of a batch job.
TCD record is the option most like the LSMW recording tool.
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 eCATT 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
TCD recordings use a technique for unattended transaction testing. It is a very efficient testing method
The TCD Command
TCD ( transaction, interface, [sys] )
Same 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
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
S means we have set the value, I means the value is inferred, O means the values is an output.
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
Recording the SAPGUI Command Procedure

From within the Test Script pattern option: SAPGUI Record under all commands.
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
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
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
Unit 7: Testing Transactions - III
Misc. other items
eCATT Roles
Old role was called YSCATTSTST and this is being replaced by the new roles as of May 2012: There will be two roles one for the administrator and one for the user. The Administrator role should only be given to Test FTEs who will write/create/modify eCATT scripts/test configuration and this replaced the YSCATTSTST role. The user/tester role will be given to anyone who requests it. This role will only allow people to maintain test configuration (start with a Y*) and display the test scripts. The new role names:
ZMS:IT_TEST Composite
ZMS:IT_TESTLEAD
Add-On
ZZZ_ECATT_ADMIN ZZZ_ECATT_USER
Single Single
eCATT Roles Broken Down on the SECATT Transaction Breakdown of authorizations
Naming convention Reusable Scripts Preamble for Reusable Scripts: ZR_ (This would mean that the test script and the test configuration would start with a ZR_*.
Individuals with just the test role, would be able to create a YR_* test configuration option. Best Practice: Test Configuration should match the name of the test script)
For T-Codes ZR_TCODE_Functionality For Ex. T-Code = VA01, VA02, VA03 and so on. Names: ZR_VA01_CR
Functionality Description Create Change Display Delete Execute Trigger Search
Code CR CH DIS DEL EXE TRI SER
Naming convention ABAP Query for Tables Preamble for Reusable Scripts: ZR_TableName_Read_data
(This would mean that the test script and the test configuration would start with a ZR_*. Individuals with just the test role, would be able to create a YR_* test configuration option. Best Practice: Test Configuration should match the name of the test script)
ZR_TableName_Read_data
Ex. ZR_VBAK_READ_DATA
Naming convention Scripts with Edit Views Preamble for Reusable Scripts: ZR_TableName_Read_data
For scripts to Edit Views

ZR_Transaction_ViewName_Functionality Ex : ZR_SM30_V_TVKO_DIS
Naming convention Scripts to read tables using SE16 Preamble for Reusable Scripts: ZR_TableName_Read_data
For scripts to Read Tables using SE16

ZR_SE16_TableName_Read
Naming convention Scripts to call Function Modules ZR_FUN_Functionanl_Module_name ( Truncated , in Description Complete Function Module Name can come in Description of eCATT)
Naming convention Scripts to call a report ZR_SE38_Reportname_Functionality (Truncated Report Name Complete Report Name Can Come in Description)
Naming convention Scenario Scripts Preamble for Scenario Scripts: ZS_ ZS_ PROJECTNAME_FUNCTIONALITY Then in the eCATT script, you will list the VSTF requirement numbers into the search term fields.
Naming convention Scenario Scripts for Unit Testing Preamble for Scenario Scripts: ZU_ Naming Convention for function Module Unit Testing ZU_VSTF_FUN_FUNCTIONMODULENAME_Functionality (Truncated Name of Function Module) Naming Convention function Class Unit Testing ZU_VSTF_CLASSNAME _Functionality (Truncated Name of Class Complete Name will come in Description)
(This would mean that the test script and the test configuration would start with a ZR_*. Individuals with just the test role, would be able to create a YR_* test configuration option.)
Note: These unit testing scripts will be focused around function module/RFC or ABAP Classes which are under development using these scripts they can do ongoing regression activity for their own use, further these script can be used to do performance testing if required.
REF Scripts can call other scripts: REF ( SCRIPT, INTERFACE, [TARGET]).
Create Order
REF REF REF REF

Manufacturing ATP Check
Billing
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) Gotcha make sure if you do this, that you get all records, sometimes I lose my second record, so I have to do this two times to get everything
Variants bound to a single configuration not reusable

If you want a variant for a specific item, like a regression test, then want another variant for SIT testing, create two separate variants that will link to the same test script. Otherwise, make one script then description will indicate BPRT vs. SIT and only run those variants associated to the test you want to perform SIT vs. BPRT.
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
Variant Wizard
Start variant wizard
Test Data Container

Variants
Configuration Variants
Variants
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
How to create test cases to test various different kinds of SAP applications
Microsoft Naming conventions for eCATT Test Scripts and Test Configuration What roles you will need in the Microsoft System for eCATTs
Unit 8: SOLMAN
Future State
Future state for eCATT storage
MSU
SMP SOLMAN production system MST

eCATTs MPU To create an eCATT, we will log into SOLMAN, go to transaction SECATT and create the eCATT against the SAP ERP system like MSU, MST, MPU, MPT, etc. eCATTs will be stored in SOLMAN, logs will be retained in SOLMAN, but the scripts will be run against the ERP systems like MSU, MST, etc.
MPT
Additional information on eCATTs
Helpful Sites:
http://help.sap.com/saphelp_nw70/helpdata/en/20/e81c3b84e65e7be10000000a11402 f/frameset.htm http://www.scribd.com/doc/58850884/52994887-What-Is-eCATT
For SOLMAN
https://websmp105.sapag.de/~form/sapnet?_SHORTKEY=01100035870000744547&_SCENARIO=011000358 70000000202& - NOTE: You will need an OSS id for this site.
Thank you
Thank you all for your time and attendance. A sincere thank you to the V-team members who have been involved in helping me trouble shoot MTM/VSTF/SOLMAN integration touch points: Ankur Srivastava, Bhavesh Jain, Radhika Daram, Mark Fitzloff, Hari Babu Sridharala, Andy Van Inwegen, and Jeff Steinhaus Special thanks to Bhavesh Jain for his assistance in the eCATT naming standards, Aron Stern (basis) and Casey OMara (VSTF) for working with us on trying to integrate MTM and SAP.

Beginners Guide To Ecatt

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Beginners Guide To Ecatt

Enviado por

Direitos autorais:

Formatos disponíveis

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 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 / #

Testing Environment Life cycle of an eCATT (current environment)

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

Manual or Automated Testing Manual Testing

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

Release 4.6C or higher

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 / #

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 Defaults to Current environment

Data to drive the test

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

The Different Object Types

System Data Container

Test Data Container

Summarized SAP Definitions:

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

How can I organize my test cases?

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

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

Unit Summary In this unit, you have learned

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

Unit 3: eCATT Scripts and the Script Editor

Unit Objectives In this unit you will learn:

The main aspects of the eCATT scripting language

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

Design Considerations for a Script

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

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

Administrative data about the script

The Script Editor

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

Simple Parameters Creation

Use I_IMPORT = 'LH'. CHEVAR ( I_IMPORT <> 'UA' ). . . .

Use I_STRUCTURE-CARRID = 'LH'.

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

Recording and playback of applications

Simulation of Customizing settings

Reading table values

Blocks of ABAP coding