Unit 5: Testing Transactions - IITesting control-based
transactions using the SAPGUI command
SAP AG 2003, PDECAT 2003/2, JM/ *
Unit ObjectivesIn this unit, you will learn:Why the TCD driver
is not suitable for testing all transaction typesHow GUI Scripting
worksHow to use the eCATT SAPGUI command to record a transactionHow
to set input fields, read output fields, and perform field checks
in a SAPGUI recording
SAP AG 2003, PDECAT 2003/2, JM/ *
Choosing the Right DriverIs the application a function module or
BAPI?
SAP AG 2003, PDECAT 2003/2, JM/ *
Why TCD Cannot Test EverythingSAP GUI
WindowFrontendBackendTCDRecorderApplicationLogicNew recording
componenteCATT
SAP AG 2003, PDECAT 2003/2, JM/ *
Introducing GUI ScriptingScripting host in GUI(Requires SAP GUI
6.20)eCATT at backend
SAP AG 2003, PDECAT 2003/2, JM/ *
Recording the SAPGUI Command Procedure2. Set the scripting
granularity
SAP AG 2003, PDECAT 2003/2, JM/ *
Recording the SAPGUI Command - Procedure
SAP AG 2003, PDECAT 2003/2, JM/ *
Scripting Granularity
SAP AG 2003, PDECAT 2003/2, JM/ *
Making Sense of the Command Interface - 1One ProcessedScreen
node per screen UserChangedState describes the user actions on the
screen
SAP AG 2003, PDECAT 2003/2, JM/ *
Parameterizing an Input ValueField nameDouble-clickEnter
parameter name in this field
SAP AG 2003, PDECAT 2003/2, JM/ *
Recording the SAPGUI Command Initial State
SAP AG 2003, PDECAT 2003/2, JM/ *
Active and Inactive ChecksActive ChecksRecord the initial states
of the selected screen element typesOn replay, check that the
values in the fields correspond to the recorded initial
statesInactive ChecksRecord 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
SAP AG 2003, PDECAT 2003/2, JM/ *
Making Sense of the Command Interface - 2One InitialState node
per processed screenAre checks active?Field nameField value during
recording
SAP AG 2003, PDECAT 2003/2, JM/ *
Retrieving an Output ValueDouble-clickEnter parameter name in
this field
SAP AG 2003, PDECAT 2003/2, JM/ *
Activating and Deactivating Field Checks
SAP AG 2003, PDECAT 2003/2, JM/ *
Message Handling MESSAGE
SAP AG 2003, PDECAT 2003/2, JM/ *
Message Handling - ENDMESSAGEMIDX MODE MSGTYP MSGID MSGNR MSGV1
MSGV2 MSGV3 MSGV4 FEECDEMO 003 LH 0400 2 AEECDEMO 021 3 AS XY 100
E_MSG_1E_MSG_1[1]-MIDX contains the total number of messages in the
table
SAP AG 2003, PDECAT 2003/2, JM/ *
Creating Rules in the MESSAGE Statement
SAP AG 2003, PDECAT 2003/2, JM/ *
Some Sample Message RulesTolerate all error messagesMode Exit
MSGTYPIDNumber'A' 'E'Fail script and jump to ENDMESSAGE on error
message ZJM 001Mode Exit MSGTYP IDNumber'F' 'X' 'E' 'ZJM' '001'
SAP AG 2003, PDECAT 2003/2, JM/ *
Default Message Handling RulesAllowSuccessInformation
messagesWarningFail and ExitErrorTermination messagesDump
SAP AG 2003, PDECAT 2003/2, JM/ *
Message ProcessingNewMessage
SAP AG 2003, PDECAT 2003/2, JM/ *
The SAPGUI Command Interface 4System Information
SAP AG 2003, PDECAT 2003/2, JM/ *
Activating and Deactivating ScreensActive = X: Screen
activeActive = : Screen inactive Active = O: Screen optional
SAP AG 2003, PDECAT 2003/2, JM/ *
Troubleshooting in the SAPGUI CommandSet automation queue
behaviorRun commands with stops at various granularity levelsClose
GUI sessions or leave them open for inspection
SAP AG 2003, PDECAT 2003/2, JM/ *
Unit SummaryIn this unit, you learned:Why the TCD driver is not
suitable for testing all transaction typesHow GUI Scripting
worksHow to use the eCATT SAPGUI command to record a transactionHow
to set input fields, read output fields, and perform field checks
in a SAPGUI recordingHow to activate and inactivate screens in a
script, and the things that you have to consider when doing so
eCATT: New Features in Release 6.40
SAP AG 2003, PDECAT 2003/2, JM/ *
Major New Features At-A-GlanceWeb Dynpro TestingABAP Objects
FrameworkBC Set IntegrationExternal VariantsScript Debugger
SAP AG 2003, PDECAT 2003/2, JM/ *
Other New FeaturesWhere-Used ListIntegration into SE80Extended
Syntax Check
SAP AG 2003, PDECAT 2003/2, JM/ *
Major Improvements to Existing Features Improved SAPGUI
HandlingVersioning EnhancementsUsability Improvements
SAP AG 2003, PDECAT 2003/2, JM/ *
WebDynpro Recording an ApplicationUse the Pattern
Functionhttp://p12345:50000/webdynpro/dispatcher/local/Welcome/WelcomeApplicationFor
name-value pairs in URL:?name1=value1&name2=value2
SAP AG 2003, PDECAT 2003/2, JM/ *
RFC DestinationsApplication URLhttp://://Use the HTTP
Destination field in the system data container
SAP AG 2003, PDECAT 2003/2, JM/ *
Parameterizing Fields Read values under SCREEN nodes Check
values under SCREEN nodes Set values under:DATACHANGES nodesACTIONS
nodes Getting and checking can be done using the context menu or
simulator
SAP AG 2003, PDECAT 2003/2, JM/ *
The Command Interface
SAP AG 2003, PDECAT 2003/2, JM/ *
Simulation and ReplaySAP GUI 6.40 required for:simulator
foreground replayStart OptionsBackgroundForegroundParallel display
of recorded and actual screensError mode starts and background and
only changes to foreground in case of error
SAP AG 2003, PDECAT 2003/2, JM/ *
ABAP ObjectsNew Commands in Release 6.40For Public Static
MembersCALLSTATIC ( , , ).GETSTATIC ( , , ). SETSTATIC ( , , ).
CHESTATIC ( , , ). For Public Instance MembersCREATEOBJ ( ,
).CALLMETHOD ( , , ). GETATTR ( , , ).SETATTR ( , , ).CHEATTR ( , ,
).
SAP AG 2003, PDECAT 2003/2, JM/ *
External VariantsThe contents of a test data container or test
configuration can be downloaded as a text file (XML format also
planned)External data can be uploaded from external files into test
data containers or test configurationsIt is also possible for a
test configuration or test data container not to contain any
internal variants, but to point to a text or XML file on the
frontend, from which the variants are read dynamically at
runtime
SAP AG 2003, PDECAT 2003/2, JM/ *
External Variants Upload Test ConfigurationUpload
variantsTextFileExecute
SAP AG 2003, PDECAT 2003/2, JM/ *
External Variants Dynamic LoadingTest ConfigurationUpload
variantsTextFileExecute
SAP AG 2003, PDECAT 2003/2, JM/ *
Integrating BC Sets With Test Scripts In Release 6.40, eCATT
allows you to integrate BC Sets. The following BC Set activities
are allowed:ActivateSimulate ActivationCompare BC Set contents with
currently-active Customizing settingsCheck that a BC Set exists in
a particular system
SAP AG 2003, PDECAT 2003/2, JM/ *
Integrating BC Sets and eCATT - Architecture
SAP AG 2003, PDECAT 2003/2, JM/ *
The eCATT BCSET CommandChange RequestsWorkbench Request
Customizing RequestVariablesVariable parameters from the BC
Setdefinition
SAP AG 2003, PDECAT 2003/2, JM/ *
Script Debugger Based on the Log Structure
SAP AG 2003, PDECAT 2003/2, JM/ *
Script-Wide SearchA script-wide search function (Ctrl + F)
SAP AG 2003, PDECAT 2003/2, JM/ *
Where-Used List - SearchYou can use the where-used list function
for any eCATT object. The search can include any or all of the
eCATT object types in which the required object can be used
SAP AG 2003, PDECAT 2003/2, JM/ *
Where-Used List Hit ListFrom the hit list, you can navigate to
any listed object
SAP AG 2003, PDECAT 2003/2, JM/ *
SE80 IntegrationThere are two new views within the Object
Navigator:The Object Navigator shows you the test objects that
belong to a particular packageThe Test Repository shows you the
test objects that belong to a particular application component
SAP AG 2003, PDECAT 2003/2, JM/ *
Extended Syntax CheckCheck the syntax of your inline ABAP using
the Extended Syntax Check
SAP AG 2003, PDECAT 2003/2, JM/ *
Extended MESSAGE HandlingMESSAGE command handling now applies
not only to the SAPGUI command, but also to TCD, FUN, and inline
ABAPThe MESSAGE command can also interpret messages that are output
by the application log
SAP AG 2003, PDECAT 2003/2, JM/ *
Versioning EnhancementsA new graphical tool for managing the
validity of all script versions centrallyChoose Utilities ->
Version Management -> Display | Change from transaction
SECATTFeatures: Overview of all versions of a script Maintain
validitySet Backup flag Simulation of version determination on the
basis of a given target system
SAP AG 2003, PDECAT 2003/2, JM/ *
Versioning Enhancements
SAP AG 2003, PDECAT 2003/2, JM/ *
Usability Improvements 1Automatic parameter creation When you
enter an undeclared parameter name in a command interface, eCATT
asks you if you want it to be created Advanced drag and drop
featuresParameters from parameter list into command
interfacesCommand interface into editor in properly-resolved
formCopying of parameters and/or command interfaces Edit ->
Parameter/Command Interfaces-> ImportFrom one script to
anotherFrom a script to a test data containerFrom a test data
container to a script
SAP AG 2003, PDECAT 2003/2, JM/ *
Usability Improvements - 2Automatic Test Configuration Creation
Utilities -> Test Configuration -> CreateCreates a new
configuration based on the current script and system data
containerEdit Command Right mouse-click on a command, choose
EditAllows you to change arguments of a commandThe options that are
available depend on the command Simplified Views in Structure
Editor icon in the structure editor toolbar Reduced views of
certain command interfaces to aid usability
SAP AG 2003, PDECAT 2003/2, JM/ *
GUI Scripting New Security FeaturesAs well as the profile
parameter sapgui/user_scripting, the following two parameters
provide more refined access
control:sapgui/user_scripting_disable_recordingIf this parameter is
set to TRUE, scripts can be replayed against the system in
question, but recording is not
allowedsapgui/user_scripting_set_readonlyIf this parameter is set
to TRUE, scripts can only contain read-only operationsSAPGUI 6.40
or 6.20 patch 42+ is required
SAP AG 2003, PDECAT 2003/2, JM/ *
Improved SAPGUI Handling InitialState Replaced In Release 6.40,
it is no longer necessary to record the Initial States of elements
in order to access output values of fields for retrieval or
checkingNote: Initial State recording and processing is still
possible to ensure the compatibility of scripts recorded in Release
6.20
SAP AG 2003, PDECAT 2003/2, JM/ *
GETGUI and CHEGUI - Capturing
SAP AG 2003, PDECAT 2003/2, JM/ *
GETGUI and CHEGUI ParameterizingDouble-clickEnter
parameternameCHEGUI allows you to perform a check against a certain
value as well as retrieving the actual value in the field at
runtime
SAP AG 2003, PDECAT 2003/2, JM/ *
Improved SAPGUI Handling - SAPGUI (Attach) When recording with
SAPGUI, it is no longer necessary to open a new window each time
you want to recordInstead, you can attach to a window that is
already open by choosing the SAPGUI (Attach) option in the command
pattern dialog box
SAP AG 2003, PDECAT 2003/2, JM/ *
Improved SAPGUI Handling SAPGUI (Attach) You will be presented
with a list of all open sessions belonging to systems on which GUI
Scripting is enabled
SAP AG 2003, PDECAT 2003/2, JM/ *
Improved SAPGUI Handling Split and JoinYou can split a SAPGUI
command into a number of commands of finer granularityIt is also
possible to join multiple SAPGUI commands in a single commandeCATT
generates new command(s) and comments out the original
SAP AG 2003, PDECAT 2003/2, JM/ *
Copyright 2003 SAP AG. Alle Rechte vorbehaltenWeitergabe und
Vervielfltigung dieser Publikation oder von Teilen daraus sind, zu
welchem Zweck und in welcher Form auch immer, ohne die ausdrckliche
schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser
Publikation enthaltene Informationen knnen ohne vorherige
Ankndigung gendert werden.Die von SAP AG oder deren Vertriebsfirmen
angebotenen Softwareprodukte knnen Softwarekomponenten auch anderer
Softwarehersteller enthalten.Microsoft, WINDOWS, NT, EXCEL, Word,
PowerPoint und SQL Server sind eingetragene Marken der Microsoft
Corporation.IBM, DB2, DB2 Universal Database, OS/2, Parallel
Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries,
pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere,
Netfinity, Tivoli, Informix und Informix Dynamic ServerTM sind
Marken der IBM Corporation in den USA und/oder anderen
Lndern.ORACLE ist eine eingetragene Marke der ORACLE
Corporation.UNIX, X/Open, OSF/1 und Motif sind eingetragene Marken
der Open Group.Citrix, das Citrix-Logo, ICA, Program Neighborhood,
MetaFrame, WinFrame, VideoFrame, MultiWin und andere hier erwhnte
Namen von Citrix-Produkten sind Marken von Citrix Systems,
Inc.HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken
des W3C, World Wide Web Consortium, Massachusetts Institute of
Technology. JAVA ist eine eingetragene Marke der Sun Microsystems,
Inc. JAVASCRIPT ist eine eingetragene Marke der Sun Microsystems,
Inc., verwendet unter der Lizenz der von Netscape entwickelten und
implementierten Technologie. MarketSet und Enterprise Buyer sind
gemeinsame Marken von SAP AG und Commerce One.SAP, SAP Logo, R/2,
R/3, mySAP, mySAP.com und weitere im Text erwhnte SAP-Produkte und
-Dienst-leistungen sowie die entsprechenden Logos sind Marken oder
eingetragene Marken der SAP AG in Deutschland und anderen Lndern
weltweit. Alle anderen Namen von Produkten und Dienstleistungen
sind Marken der jeweiligen Firmen.
Version 2003/219/3/2003A finished test case the test case that a
user will see in their worklist in the SAP Test Workbench consists
ofA set of instructions that describe the test caseOne or more sets
of data with which the test case will be executedA description of
the system landscape in which the test is to be performed. The
result of each test run is a log. The log contains detailed
information about the test environment (system including technical
platform information and release, user, time and date) and the
commands that were executed during the test. You can also see the
data that was fed into the test case, and the results that it
returned. Logs can be either archived or deleted using periodic
background jobs.On the next slide, you will see the different eCATT
object types corresponding to the different elements of a test
case. A test script is the set of commands that describes a test.
Typically, this will include a recording of one or more
transactions with the associated checks and calculations required
to evaluate the results. In order to address different systems, you
need a description of the system landscape. This is contained in a
system data container. Each entry in a system data container
describes one target system.Unlike CATT, eCATT separates test
instructions from test data. The test instructions are contained in
a test script. Test data is stored in test data containers. By
separating the test data from any particular test case in this way,
it should be easier to reuse data in a variety of test cases. None
of the objects test script, system data container, or test data
container is executable from the Test Workbench. A complete
automated test case requires a combination of one test script to
provide the instructions, one system data container to describe the
relevant system landscape, and one or more sets of data (variants)
with which to execute the test. This combination is called a test
configuration. The variants that are used may be entered manually
or may be drawn from one or more test data containers.
The first step towards an automated test is to map the system
landscape in which you will be working. There are two main
considerations here:The applications that you want to test are
generally not present in your central test system, so you must test
remotely.The business process that you want to test may extend
across system boundaries, so you need to be able to test in several
different remote systems. In order to test remotely, you use Remote
Function Call (RFC). However, in an eCATT test script, you do not
address target systems directly using an RFC destination. Instead,
you assign a logical system name to each system in your landscape,
and it is this name that you use in the test script. Resolving the
logical name, as used in the script, into an RFC destination that
identifies a particular system is the task of a system data
container. The RFC destinations that you use in eCATT are normal
R/3 -> R/3 destinations that you define in transaction SM59. In
each RFC destination, you can specify not only the location of the
system that you want to address, but also the user credentials that
will be used to log onto that system. The logon to the remote
system can only take place unattended if the logon data is complete
(client, user, and password). Storing passwords in RFC destination
definitions is, however, not to be recommended. If you do not store
a password, the logon data is incomplete, and a logon screen will
be displayed when time your test case tries to enter that system.
Consequently, the test case can no longer run unattended.The way
around this problem is to establish a trusted/trusting relationship
between systems, in which the target system trusts calls that are
made by the central test system. This eliminates the need to store
a password within the destination definition but ensures that the
logon can still run unattended.For details of how to set up a
trusted/trusting RFC relationship, refer to SAP Note 128447.The
task of a system data container is to map the logical names that
are used in a script to a particular RFC destination that specifies
the system, client, and user that the test case is to access.You
can assign the logical names yourself. As a rule, they should
reflect the function of a system and should not relate to a
particular release or system name they should remain relevant
beyond the lifetime of a particular release or system.Consider the
following example: Your R/3 System has Release 4.6C and has the
System ID P01. Possible logical names for this system might
be:R3R3_46CR3_P01P01_46CNow consider the situation after an upgrade
to R/3 Enterprise: Your system no longer runs under Release 4.6C
and may have moved so that the system is no longer called P01. Any
logical name that refers to either the release or the system name
is therefore obsolete: In our example, only R3 is still relevant.To
create a system data container, start transaction SECATT, select
the System data container radio button, enter a name for your
system data container, and choose Create. On the next screen, you
must maintain various attributes for the system data container in
particular, it must have a title, an application component, and a
package.On the System data tab, you will see that the default
system NONE is already present. This refers to the default RFC
destination NONE, allowing you to refer to the current system at
any time. To add a new system to the container, choose the Create
icon. eCATT appends a new row to the table. In it, you must specify
a logical name for your system and, in the third column, assign an
RFC destination that already exists (you can use possible values
help to display all relevant RFC destinations). In the second
column, you may enter a description of the system.Repeat the
previous step for each system in your system landscape.System data
containers help you to achieve greater consistency in your test
activities. You can create a single system data container for a
test project (or subproject). Since the RFC destinations behind the
logical destinations contain a full set of logon credentials, you
can be sure that your test developers and testers are using the
correct systems, clients, and users.System data containers also
improve the stability of your scripts. In a script, you only ever
refer to a particular target system by its logical name, which
remains constant. The actual system to which that logical name
points is dependent on the current system data container. Thus you
can execute a script against a completely different system
landscape simply by linking it with a different system data
container, and you never have to change the script coding.Although
it is impossible to make general rules about how to write the
perfect script, there are two guidelines to consider:Have a
definite goal! Before you start writing the script, make sure that
you know exactly what you want it to do. Aim for reusability! There
is little point in packing an entire order-to-cash scenario into a
single script, because it contains many parts that you might be
able to reuse in other test scenarios. You should therefore aim for
smaller test scripts it is very easy to create one "master script"
at the end that does nothing other than call a series of smaller
scripts. In terms of its structure, a test script is similar to a
function module. It contains various attributes, an interface in
the form of importing and exporting parameters, and the commands
that actually form the test. Scripts may also contain local
(private) variables for use within the coding. When you create a
script, you must first maintain certain attributes.The following
attributes are mandatory: Title, package, person responsible,
application component. The maintenance system attributes are
important. It is here that you can assign a system data container
to your script. You can then address any of the systems listed in
the system data container from your script. In addition, you can
make any one system from this system data container the default
target system by entering its logical name in the target system
field. On the Versioning Data tab, you can specify the validity of
the current version of your script. You will learn more about
versioning in Unit 9.The Restrictions tab contains optional
documentary attributes. You can, for example, specify that the test
script applies to a particular locale or platform. Note, however,
that these attributes are not evaluated by eCATT when you run a
script. You can only use them as useful search terms.
The script editor has three areas the command editor, where you
enter the script coding, the parameter list, where you can create
importing and exporting parameters, as well as local variables for
your script, and the structure editor, where you can edit any
structured parameters within the script. A structured parameter can
be A structureAn internal tableA command interface (interface of an
eCATT command)You create parameters in the parameter editor section
of the script editor. Each parameter must have a name, a type, and
be defined as an Importing parameter, an Exporting parameter, or a
local Variable.Parameters can have any data type except for String
and XString. The default data type is C with length 128. You can
also type a parameter with reference to an ABAP Dictionary type
(either simple or structured).Parameters may also have a default
value, which you enter in the Value field. In the command editor,
you work with parameters in the same way as you would work with
variables in any programming language you can use them freely in
assignments and logical expressions as shown above.As well as
elementary parameters, you can also create structured parameters
that is, structures or internal tables. To create a structured
parameter, the reference type must be a structure in the ABAP
Dictionary.To create an internal table parameter, the reference
type must be either an internal table type in the ABAP Dictionary
or a structure type followed by opened and closed square brackets,
for example SPFLI[].To address a component of a structure, you use
the same notation as in ABAP, that is -.To address a particular
component of an internal table, you use the notation [index]-.The
eCATT command GETLEN allows you to find out the number of entries
in an internal table. Its syntax is GETLEN ( TABLE, VARIABLE ).
which places the number of lines in table TABLE into the field
VARIABLE.If you assign whole structures using the form struc2 =
struc1, the assignment uses MOVE-CORRESPONDING logic.eCATT has its
own scripting language. It is similar to ABAP, but nevertheless a
different language. It allows you to record and replay
applications, perform checks, and use various common programming
control structures. There are four different ways of testing
applications. Each of them is appropriate for a particular kind of
application that you might want to test. It is important to
remember that no single way is suitable for testing everything. For
this reason, you should always take care to pick the correct driver
before you start to record your script.On the next page, you will
learn how to pick the correct driver for a test. You can use the
graphic to help you choose the right driver to test a particular
application. When it comes to testing applications using the TCD
and SAPGUI drivers, you should bear in mind that the TCD command is
the most efficient in terms of runtime, because it runs in the
background with no SAPGUI window attached. The SAPGUI command has
the overhead of having to instantiate the SAP GUI window.
Consequently, it should only be used for transactions where TCD
cannot be used. eCATT has a range of special variables, similar to
the sy- fields in ABAP. A full list is available in the eCATT
documentation. You can also use sy- fields in eCATT scripts. Note,
however, that sy- fields always relate to the local system, and
that special eCATT variables always relate to the target system.
So, for example, if you are logged onto the test system as user
SMITH, but the RFC destination that connects to the target system
logs on as TESTER, sy-uname will have the value SMITH, but
&USER will have the value TESTER. The pattern function allows
you to create eCATT commands quickly and easily. The first step is
to pick a command. Once you have done that, you must supply the
argument for example, the function module you want to call or the
transaction you want to record. Next, the system proposes the name
for the command interface. You can accept the default, or change it
if you like. Finally, you specify a target system. You can use any
system that is defined in the current system data container. If
there is no system data container attached to the script, you can
only execute the command locally. Command interfaces represent the
input/output interface of the command to which they belong. They
are always displayed in tree form in the structure editor. To open
a particular command interface in the structure editor,
double-click its name either in the parameter list or in the eCATT
command in which it is used. You can assign literals or variables
to parameters in the command interface. Literals must be enclosed
in single quotes. If you use variables, you must remember to
declare them as script parameters in the parameter list. There are
various situations in which you might need to test function
modules:As a unit test, where you test a single function moduleAs a
backend process, where you test a string of function modules that
make up a whole process, passing the results of one module onto the
nextAs utilities within a script, for example, to retrieve data
from the database that you want to use in transactions, or to
perform a complex plausibility check for which you know that a
function module already exists. In the graphic, you can see the
syntax of the FUN command. The FUN command interface is split into
the same sections as you find in the definition of the function
module itself Importing, Exporting, Changing, Tables, and
Exceptions. To pass a value to the function module, assign the
relevant literal or variable to the correct parameter in the
command interface. Do the same thing to receive an exporting
parameter into a script parameter. As well as assigning parameter
values using the structure editor, you can also address parameters
programatically within the script editor. This is particularly
useful if, for example, you need to assign values dynamically.The
syntax for addressing components within a command interface is
shown above. It is similar to the ABAP syntax for addressing
complex structures. Note that if you are working with internal
tables, you must specify the relevant table index in square
brackets.Sometimes, the aim of a test will be to make a function
module trigger an error. In such a case, you will want the test
case to be marked as successful if an exception is triggered.
eCATT, however, normally handles function module exceptions as
errors and, as shown in the top half of the graphic, will mark the
test case red in the log. To define an exception as successful, you
must assign it the value X in the command interface. If the
exception then occurs, the script will not fail. Defining an
exception as successful does not mean that the script will fail if
the exception does not occur. If you want this to happen, you must
query the special eCATT variable &EXCEPTION yourself in the
script. For example, in the above example, you would write CHEVAR (
&EXCEPTION = DATA_INCOMPLETE). The GETTAB and CHETAB commands
allow you to read and check single database table entries. Each has
a command interface with the structure of the table line. In the
structure editor, key fields are marked with (K).In both commands,
you enter values in the command interface that should be used to
make the database selection. If the GETTAB statement finds a
corresponding row in the database table, it places the contents of
that row into the command interface. Note that if you do not
specify the full table key, the single record returned by GETTAB
may not be the only one that matches your key specification. If you
want to retrieve multiple lines from the database, consider using a
function module or writing a SELECT statement in an Inline ABAP
block.The CHETAB command searches for a table entry matching the
key (plus any other non-key fields) that you specified. If it finds
one, the command is marked as successful. If it does not find a
corresponding table entry, the statement fails, and with it, the
script. Note that you must assign values to all key fields in the
CHETAB command. If one or more key fields are not relevant to your
query, assign them the value *. The SETTAB and RESTAB commands
allow you to simulate changes to Customizing settings within a
script. You can only use them on tables that are defined as
Customizing tables in the ABAP Dictionary. SETTAB makes temporary
changes to a Customizing table. With RESTAB, you can roll back
these changes at the end of the script. Do not use SETTAB for
extensive Customizing modifications. Business Configuration Sets
are far better suited to this task.There are cases where the eCATT
scripting language may be insufficient for your needs. For example,
you cannotTest classes and methodsRead multiple lines from the
database in a single commandFor cases such as these, you can use
blocks of ABAP coding in your script. Each block is introduced with
the keyword ABAP and ends with ENDABAP.Inside each block, you can
use any ABAP coding that is valid in the default target system of
your script. Technically the blocks are compiled into FORM
routines. This means:You cannot define your own FORM routines
within an ABAP blockAny data objects that you declare using the
DATA statement are not visible beyond the end of the block. Within
an ABAP block, only the local variables of the script are visible.
Consequently, if you want to use an importing or exporting
parameter of the script in an ABAP block, you must first assign it
to a local variable. To record a transaction that does not contain
controls, use the TCD command. It is easiest to insert the command
by choosing the TCD (Record) entry from the dropdown list box. You
will then be prompted to enter a transaction code. From this, the
system generates a proposal for the command interface name. You may
also specify a target system (as long as you have entered a system
data container in the script attributes). Once you have filled out
the arguments in the statement pattern, eCATT starts the
transaction, and you can work through it normally. The system
records all of your entries. When you leave the transaction,
control passes back to eCATT, and you will be asked whether you
want to use the data you have just recorded. Choose yes.If you now
double-click the name of the command interface in either the
parameter list or the command editor, the structure of the
transaction will appear in the structure editor. From here, you can
assign parameters to individual screen fields. The TCD command is
based on the batch input technique. When you record a transaction,
the recorder is triggered each time you choose a function (such as
pressing Enter, choosing a menu entry, clicking a pushbutton, and
so on). At this point, it collects all of the field contents from
the screen and stores them in a table, along with the function code
of the function you chose. TCD commands are replayed without the
transaction having any contact with a SAP GUI instance. The batch
input system is able to replay transactions using just the field
contents and function codes. While this provides quick playback for
scripts containing TCD commands, it makes TCD unsuitable for
transactions that make extensive use of controls, since controls,
in order to behave properly, must be alive at the frontend both
during both recording and playback. The command interface of a TCD
command divides the transaction into screens, and the screens into
fields. Each screen may be either active or inactive. Fields are
identified by a name. This is the same name as appears under the
Field description for batch input when you display the technical
information about a screen field ( F1 followed by the Technical
Information icon). The input and output fields on screens can be
parameterized. To assign a value to an input field, open the field
list of the relevant screen by double-clicking the "Field Mode Name
Valin" row beneath the screen number in the tree display. The field
list opens to the right of the tree. Find the field that you want
to set and ensure that its mode is set to 'S' (set value). Enter
the new value (either a literal or a variable) in the VALIN
column.With the TCD command, there are two options for
parameterizing output fields you can either place the value from an
output field into a variable in your script, or you can check the
value against a predefined check value.To read a value, you must
set the Mode of the field in question to 'G' (Get value). Then
enter the name of a parameter in the VALIN column. At runtime,
eCATT will place the value from the screen field into the script
parameter.To check a value, you must set the Mode of the field to
'C' (Check value).Then enter either a literal check value or the
name of a parameter containing the required check value. At
runtime, the screen field will be checked against the value that
you specified. If the values do not match, the script will fail.
All of the messages sent by a transaction are stored within the
command interface in an internal table called MSG. MSG has the
following fields: TCODE transaction code from which the message was
sent DYNAME program nameDYNUMB screen numberMSGTYP message type
MSGSPRA language of the messageMSGID message classMSGNR message
numberMSGV1 MSGV4 variables (optional) that replace placeholders in
the messageENV not used (batch input-specific)FLDNAME the text of
the message in fullThe number of messages sent by the transaction
is contained in the eCATT system variable &MSX.Using &MSX,
you can find any given message. To retrieve the last message, you
address MSG with index &MSX. The precise syntax is -MSG[
&MSX ]-. To loop through messages, you can use &MSX as the
count for a DO statement. The following example shows how you could
use a loop to check whether a particular message appeared during
the transaction: DO &MSX.IF ( command_interface-MSG[ &LPC
]-MSGID = message_class AND command_interface-MSG[ &LPC ]-MSGNR
= message_number ).* Do something. ENDIF.ENDDO.The
ON_LAST_MESSAGE_CHECK command allows you to specify before a TCD
command the number of a message that must occur during that
command.In the first example above, the message with number 031
must be sent by the subsequent TCD command, otherwise the script
will fail. To tolerate all messages (including errors), use the
command ON_LAST_MESSAGE_CHECK ( * ). This allows you to implement
your own message analysis after the TCD command. Note that this
command will be superseded in Release 6.40 by a new rule-based
message handling mechanism. This has already been implemented for
the SAPGUI command, and you will learn about it in the next unit.By
default, the TCD command runs in the background. Consequently, you
do not see anything between clicking the Execute button and the
appearance of the log. The start options of the TCD command allow
you to troubleshoot it by running it in the foreground (mode A). In
this mode, the transaction is played back screen-by-screen so that
you can analyze the various field contents and establish where
things are going wrong. Another useful troubleshooting mode is mode
E. In this mode, the transaction is played back in the background,
but switches to foreground processing if an error occurs.The TCD
command and batch input interface only work for applications that
are programmed using "classic" SAP dialog programming that is,
where the transaction is controlled exclusively by using Process
After Input (PAI) and Process Before Output (PBO).New transactions,
or transactions that were redesigned in the EnjoySAP initiative
(Release 4.6B), frequently use the SAP Control Framework to
implement part of their user interface. Examples of Control
Framework controls are the SAP List Viewer, SAP Tree Control, SAP
HTML Viewer, SAP TextEdit Control, and so on. One of the principal
characteristics of these controls is that their features and
functions are implemented locally within the SAP GUI. Further
functions are implemented by the application using the control in
the form of event handler methods. Functions that are implemented
in these ways do not form part of the standard PAI/PBO logic, and
therefore cannot be recorded by the TCD recorder.The only way to
enable these applications to be tested was to implement a new
testing driver at the frontend as part of the SAP GUI that works by
intercepting the actions that a user performs on a screen,
regardless of whether those actions belong to a conventional screen
element like a pushbutton or an input field, or to a control such
as the SAP List Viewer.
The SAPGUI driver in eCATT is based on the GUI Scripting
function in Release 6.20 of the SAP GUI. GUI Scripting allows you
to create scripts that automate the SAP GUI in much the same way
that macros allow you to automate Office applications. GUI
Scripting is a standalone feature of the SAP GUI that you can also
use independently of eCATT. For full details and a range of
documents on the subject of GUI Scripting, use the search function
on the SAP Service Marketplace (http://service.sap.com) to search
for the term "SAP GUI Scripting".A scripting host within the SAP
GUI intercepts the actions that you make on a screen. If you are
using GUI Scripting on its own, the actions are translated into VB
Script or Java Script. If you are working with eCATT, the actions
are transferred to eCATT, where you can see them as the command
interface of the SAPGUI command.The procedure for recording the
SAPGUI command is slightly more complex than when you record a
transaction using TCD. A TCD command always contains a single
transaction, and all of the input and output is recorded. With
SAPGUI, both the granularity of the recording and the amount of
data to be included is variable, and you have to specify this at
the beginning of each recording. This page and the next are
intended to give you a general overview of the recording procedure.
We will return to each step in more detail later on. To start a
SAPGUI recording, use the Pattern function and select the command
SAPGUI (Record). The next thing that you have to do is to specify
how you want the recorded data to be arranged in your script.After
you have set the granularity of your recording, eCATT opens a new
window of your chosen target system and asks you if you want to
record in it. Choose Yes at this point. You now have to specify the
kinds of user interface elements for which you want to record the
initial state. Recording the initial state allows you to extract
the contents of output fields. Having done that, you are ready to
record.
As we have already seen, a TCD command has a defined structure
based on the fact that TCD can only ever record a single
transaction. That transaction is broken down into screens, and each
screen contains fields. Because the SAPGUI command works at
frontend level, it only recognizes actions. One consequence of this
is that, unlike the TCD command, you can use the SAPGUI command to
record a part of a transaction or, indeed, several transactions. It
also means that there is no predefined granularity as is the case
with the TCD command. The first thing that you have to do when you
start recording a SAPGUI command is to define the level at which
you want the system to generate new commands. This can be at
various levels:Session level, which means that all of the actions
performed in a SAPGUI window (and that could encompass several
transactions) are combined into a single SAPGUI command.Transaction
level, in which the system generates a new SAPGUI command for each
new transactionScreen level, where a new SAPGUI command is
generated each time there is a screen change during recordingUser
interaction level, where a new SAPGUI command is generated each
time the token is exchanged between frontend and backend.In
deciding on a granularity level, you must take into account the
size of the generated command interfaces. If you record at session
level, for example, you will have a single command with a huge
command interface. If you record at user interaction level, the
command interfaces will be smaller, but you will have a large
number of commands. Generally speaking, it is easier to work with
command interfaces that are not too big. Screen level is often a
good level at which to work. Every SAPGUI command interface
contains details of the actions that you performed on that
particular screen. The command interface is split up into
ProcessedScreen nodes one for each screen within that particular
command interface. Below the ProcessedScreen node is a section
called UserChangedState. This section contains a list of the
actions that you performed on the screen during recording. It is
here that you can parameterize fields, as you will see on the next
page.Each GUI element with which you interacted during recording
has its own GuiElement node under the UserChangedState node. A blue
arrow pointing towards an attribute name in the State node denotes
a set parameter.To parameterize the value of a field, find the
relevant field and double-click the Text attribute. In the grid
that appears, enter the name of a variable against the Value
element.Do not change the Name field.You can only set values of
fields with which you interacted during recording. No other fields
are recorded.The methods of controls are denoted by a pair of
square brackets [ ] (not shown in the example above). Underneath
the method node are the individual parameters, which you can also
parameterize. Within the UserChangedState section of a command
interface, you can only set values. Furthermore, to set the value
of a field, you must have changed the value of the field during the
recording. You cannot retrieve the values of output fields. This is
the task of the InitialState section, which you will learn about on
the following pages. By default, the SAPGUI command only records
the actions that you perform in an application. This means that
only the entries that you make in fields, and not the field
contents that are displayed in output fields, are recorded.To
access the contents of output fields, you must record their initial
state. You do this by setting the appropriate options in the dialog
box shown in the graphic above.Since recording initial states
increases the volume of data transferred from the frontend to
eCATT, you can restrict the initial state recordings to certain
types of user interface element for example, input/output
fields.Once you have selected the initial states that you want to
record and decided whether to record with active or inactive
checks, choose "Activate mode for initial states". This
communicates your selection to the frontend. You can now start
recording in the new window that eCATT opened.
When you record initial states, you can choose whether to record
them with active checks or inactive checks. If you choose active
checks, the field contents at runtime will be compared with the
field contents that were present during recording. If they do not
correspond, an error will occur. If you choose inactive checks, all
of the necessary information to perform a check is recorded, but
the check is deactivated. The options in this dialog box activate
or deactivate checks for the whole of your recording. Later, when
you edit the command interfaces, you can activate and deactivate
checks for individual fields.
The InitialState node gives information about the contents of
screen elements at the beginning of each ProcessedScreen node.If
checks are active, the value of a particular GUI element during
playback will be compared with its value during recording. You can
parameterize the check values.A check will only be performed if the
Check option is set along the whole path of the tree from the top
of the InitialState node down to the element in question. A blue
arrow pointing away from an attribute name in the State node
denotes a get parameter.To retrieve the value of a field from the
SAPGUI interface, find the relevant field in the InitialState
section of the interface, and double-click the Text attribute. In
the grid that appears, enter the name of a value against the Value
element.Do not change the Name field.In the InitialState section of
the SAPGUI command interface, you have the opportunity to enable or
disable field checks. For a check to be active, all of the Check
attributes between the top of the current ProcessedScreen and the
element that you want to check must be set to 'X'. An important
part of testing an application can be to analyze the messages that
occur when the application is replayed. The SAPGUI command supports
you in this in two ways, allowing you to:Specify rules as to what
messages are allowed, which are prohibited, and which should be
toleratedAnalyze the messages that actually occurred during script
playback, along with their contents. To work with messages that are
sent during the course of SAPGUI commands, you enclose the SAPGUI
commands between the eCATT commands MESSAGE and ENDMESSAGE. Both
have a command interface:The MESSAGE command interface contains
rule definitionsThe ENDMESSAGE command interface contains a list of
messages that occurred during replay. The command interface of the
ENDMESSAGE command is similar to the MSG table in the command
interface of the TCD command it contains a list of the messages
that have been sent since the opening MESSAGE command.The MIDX
field contains the index of the current message, except in the
first row of the table, where it contains the total number of
messages contained in the table. You can access details of the
individual messages using the following fields:MSGTYP Message
typeMSGID Message classMSGNR Message numberMSGV1 MSGV4 Variable
parts of the messageThe ENDMESSAGE command interface always
contains details of the messages sent during the application,
regardless of whether you specified any rules in the MESSAGE
statement. In the MESSAGE statement, you define rules for message
processing. There are two aspects to each rule the mode and the
object.There are four possible modes:Require The message or
messages that you specify in the object must occur for the script
to succeedExpect At least one of the messages specified in one of
any number of rules defined with this mode must occur for the
script to succeedAllow Messages specified in the object will be
toleratedFail The message or messages specified in the object must
not occur. If they do, the script will fail. In addition to the
mode, there is a parameter Exit. This specifies what should happen
if an incoming message satisfies the rule:Exit = ' ': Carry on
processing as normalExit = 'X': Jump directly to the ENDMESSAGE
command. The object of a message can be any combination of message
type (S, I, W, E, A, X), message class, and message number. Above
are some sample message rules. The first is very general,
specifying that all error messages (only the type is specified no
message ID or number) are to be allowed. The second rule is far
more specific its mode is to fail the script and exit if error
message ZJM 001 occurs. The order in which you define rules is
crucial. As soon as eCATT has successfully applied a rule to an
incoming message, no further messages will be processed. In the
case of the rules above, it would mean that the first rule would
always overshadow the second, because message ZJM 001, when sent as
an error message, will satisfy the first rule and consequently be
allowed. If you define rules that conflict (as is the case here),
the more specific rule must come before the more generic rule. As
well as rules that you define, there is also a set of default rules
in the MESSAGE command: Success, information, and warning messages
are allowedError, termination, and type X messages cause the script
to failThe default rules are always processed after your own
user-defined rules. Consequently, if you create a rule of your own
that conflicts with a default rule (for example, you choose to
allow certain error messages), your rule will take precedence over
the default rule. When a new message arrives, eCATT first checks it
against your rules. If a rule is satisfied, the script continues
according to the rule definition and no further rules are
processed. If none of your rules are satisfied, the default rules
are processed. Again if a rule is satisfied, the script continues
according to the rule definition and, once again, no further rules
are processed. Since your rules are processed before the default
rules, any rule that you define that conflicts with a default rule
will take precedence. Since no further rules are processed once a
particular rule is satisfied, you must pay particular attention to
the sequence in which you define your rules. The more specific the
rule, the higher it should be in your list. Generic rules, such as
allow all error messages, should come near the bottom of the list.
The system information part of the command interface contains three
important nodes the ConnectionId and SessionId, and the ResetGUI
option. The ConnectionId and SessionId nodes determine the window
in which the command will be replayed. Essentially, the precise
values in these fields do not matter, but what is important is that
all SAPGUI commands that you want to replay in a single window must
have the same ConnectionId and SessionId. SAPGUI commands will only
replay properly if each successive command starts at exactly the
same point at which the last command stopped. Everything that you
record in a single attempt will, of course, fulfill this condition.
However, if you record a script in sections for example, a
transaction at a time it may be that your starting point for a new
section does not match the end point of the previous SAPGUI
command. If this is the case, you can use the ResetGUI option. If
you set ResetGUI to X, eCATT performs the equivalent of /n before
starting the transaction in the next ProcessedScreen section of the
command interface. Do not use ResetGUI within a transaction. You
can activate or deactivate individual ProcessedScreen nodes within
SAPGUI commands. The Active node can take the following values: X:
The screen is active and will be processed : The screen is inactive
and will not be processedO: The screen is optional. It will be
processed if it appears, but ignored if it does not.When you
deactivate screens, you must be aware that subsequent screens may
depend on information from that screen. There are various start
options that you can set to help you troubleshoot problems that
occur with the SAPGUI command.Processing mode: This allows you to
disable the automation queue, a helpful diagnostic tool if a
control is causing errors.Error Mode: This specifies whether the
SAPGUI command should terminate or continue when an error occurs.
Stop When: This option allows you to run a SAPGUI command with
stops at various levels of granularity. For example, you can stop
before each screen is processed. The granularity levels available
range from transaction down to individual method call. You can also
stop before each SAPGUI command, regardless of the granularity at
which it is recorded.Close GUIs: This option allows you to specify
whether eCATT should automatically close generated GUI sessions at
the end of a script (the default setting) or whether they should be
left open. This would allow you to inspect the state of the
application at the end of the script.
Before you can use an external tool with eCATT, you must perform
the following configuration steps:Declare the external tool to
eCATT by running the function module SET_EXTERNAL_TOOL using the
test mode in transaction SE37. If you execute the function module
without entering any field values, the default values will be used.
These default values set up the system to work with Compuware
TestPartner.Run program ECATT_GENERATE_ET_USER from transaction
SE38. This generates a service user that the external tool requires
in order to communicate with eCATT.Regenerate the authorizations in
role SAP_ECET. To do this, start transaction PFCG and open role
SAP_ECET in change mode. On the Authorizations tab, choose Change
authorization data. On the next screen, place the cursor on the
role name and choose Authorizations -> Generate. When you create
a script in eCATT, you can specify on the initial screen that the
script should be created using an external tool. Scripts that you
create in this way are the same as any other eCATT script they are
Repository objects, can be called from other scripts, and so on.
However, within eCATT itself, you can only maintain the attributes
of the script. To create or edit the script, you must start the
external tool (by choosing the Script function from the script
editor).Once the external tool has started, you can use it as
normal to record and edit a script. When you have finished, you
upload the external script to eCATT, where it is stored in the SAP
database.There are four steps to creating a script using Compuware
TestPartner:Record the applicationParameterize the input/output
fields of the applicationAdd any necessary VBA coding to the script
Implement any necessary checks for your test caseTestPartner
scripts do not possess importing and exporting parameters. To pass
data between eCATT and a TestPartner script, you use an
intermediate object called an argument container. The argument
container allows you to define importing and exporting parameters
for a TestPartner script. You do this in TestPartner under the menu
entry Tools -> SAP eCATT ->Argument Container.The importing
and exporting parameters that you define in the argument container
form the interface of the script. When you call the TestPartner
script from within eCATT, you have the opportunity to fill them
with values.Once you have defined importing and exporting
parameters in the argument container, you can use them in your
TestPartner script. To use an importing parameter from the argument
container, you must assign it to a variable in your script using
the following function:GetEcattArg( Name as String) As StringTo
return an exporting parameter from a script variable to the
argument container, use the function SetEcattArg Name as String,
Value as StringWhen you have finished recording, editing, and
testing your script, you can upload it to eCATT.Choose Tools ->
SAP eCATT -> Save BLOB -> Save and Goto eCATT. In the dialog
box that appears, select the projects that you want to upload. The
entire contents of the project or projects that you select are
stored within the script that you created in eCATT. Since this
means that one eCATT script can contain several TestPartner
scripts, you must select a primary project and primary script that
is, the script that will actually be executed when you call the
external script from within eCATT.Choose Save to upload the
resources to eCATT.To call an external script from another eCATT
script, you use the command REFEXT.In the REFEXT command, you
specify the name of the script and its version. The command
interface of the REFEXT command contains the importing and
exporting parameters of the external script as you created them in
the argument container within TestPartner.Tip: if you cannot access
a screen element in the simulator, try the command interface.
