eCATT Tutorial
Use
This tutorial is intended for test developers new to eCATT. By the end, you should be able to use
eCATT to create reusable test cases for testing remote systems.
Prerequisites
You need a system based on SAP Web Application Server 6.40 or higher.
Scripting has been enabled. See Preparing Systems and Computers for eCATT.
Background
When you design an automated test, you need to answer the following questions:
1. What applications am I going to test?
2. What does my system landscape look like?
3. How can I best create an automated test for my applications?
4. What data do I need to feed into the tests?
5. How do I build executable test cases?
6. How can I organize my test cases?
The graphic below shows how the different eCATT objects fit into the test development process.
The first step is to define what you want to test within the scope of your project. Having done this,
you create a system data container in which you map out the system landscape for the project.
Without a system data container, you cannot write test scripts that access other systems. The third
step is to create the test scripts themselves.
You then need to consider the data that you will need to run the tests. The data should be arranged
in test data containers to allow the maximum degree of reuse and to eliminate as much redundancy
as possible. Finally, you assemble the test configurations from the other eCATT objects.
Test configurations can be assigned to test catalogs and test plans within the Test Workbench. The
configurations can then be assigned to individual users for testing. The Test Workbench is not part
of this tutorial.
Creating Your System Data
Container
Use
In most practical test environments, eCATT resides on a central test system and runs tests against
remote systems in the test landscape.
To access these remote systems, eCATT uses standard RFC destinations. However, these RFC
destinations are never referenced directly within a test script - that would minimize the reusability of
the test script. Instead, the RFC destinations are assigned to logical names in a system data
container, and it is these logical names that are used in the test script.
Your Test Landscape
For this tutorial, your system landscape consists of a system containing the
transaction EC_TUTORIAL_SAPGUI. If you do not have access to a second system containing this
transaction, simply use an RFC destination in the eCATT system that points to the eCATT system
itself.
Prerequisites
In the eCATT system, you require an RFC destination for the system under test. Here we will call the
RFC destination TUTORIAL. This should be an type 3 connection. You can use transaction SM59 to
maintain RFC destinations. Make sure that you can log on to the system using the RFC destination.
Procedure
1. Start transaction SECATT.
2. On the eCATT initial screen, select the System Data radio button and enter a name for your new
system data container in the field beside it. For this tutorial, we will refer to it as TUTORIAL_SDC.
You may have to prefix the name (for example, with Z) if you are in a customer namespace.
3. Choose the Create Object icon as shown above. This will open the editor for the system data
container.
4. On the Attributes tab, enter a title for the system data container - for example, System
Landscape for eCATT Tutorial.
5. Change to the System Data tab. You will see a default target system called NONE. However, you
are not going to use it in this tutorial.
6. Append a row for your new target system.
7. Enter a name for the target system (here we use TARGET_1), and use the F4 help to enter the RFC
destination TUTORIAL.
8. Choose Enter. The Instance Description field will be filled automatically.
9. Save your system data container.
Result
You have created your system data container. It does not do anything by itself - you will use it later
to enable your tests to run against the remote system defined in the RFC destination.
Creating Your Test Script
Use
In this section, you will create an empty test script and assign to it the system data container that you
created earlier. You will then execute the test script.
Activities
1. On the eCATT initial screen, select the Test Script radio button and enter a name for your new test
script in the field beside it. Here, we will name it TUTORIAL_TS. Leave the remaining fields empty.
2. Choose the Create Object icon, as shown above, to open the editor for the test script.
3. On the Attributes tab, enter the following information:
Field
Entry
Title
Testing Transaction EC_TUTORIAL_SAPGUI
Component
BC-TWB-TST-ECA
System Data Container TUTORIAL_SDC
4.
5. Leave the Target System field empty. We will not use this field in this tutorial.
6. Save your test script.
You are now able to execute the test script. Of course, since you have not recorded any transactions
or entered any script commands, you cannot expect to see much happening. However, it is worth
doing to see a successful execution before the script becomes more complicated.
7. Choose
.
The Start Options are displayed.
8. Accept the defaults but make sure that Log Display has been selected.
9. Choose
to execute the test script. The log will then be displayed and should look something like
the following:
The green icon beside the test script name indicates that the entire test script has been executed
without error.
10. Go back to the test script editor.
Result
You have a test script that you can edit to perform useful testing. The test script was executed in the
local system, so the system data container, though present, was not actually used. However, it the
next part of the tutorial, you will record a transaction that is in a remote system. For that, the system
data container will be necessary.
Recording the Transaction
Use
You will record the transaction EC_TUTORIAL_SAPGUI. This transaction has been written to
include the active use of controls, such as the tree control, and is therefore not suitable for recording
using the TCD command. The SAPGUI command is designed for just such a transaction. For
simplicity, you will record the complete transaction although this is not a restriction of the SAPGUI
command.
Normally, we recommend that you try out a transaction before recording it. You would then be able
to assess which command is the best to use. Additionally, you would also reduce the number of
false entries and thereby reduce the complexity of the resulting script. Here, just go ahead and
record the transaction. If you make too many errors, simply delete all the resulting commands and
try again (of course, eCATT offers more sophisticated ways of reworking a test script).
When you start the recording process, eCATT automatically opens a new session. You will therefore
have two sessions open - the original eCATT session, which provides you with various functions to
use during recording, and the session containing the transaction that you will record.
The Transaction
The transaction is based on the flight data model. You use the transaction to create a booking. The
generated booking number is displayed in a message and also in a field of an ALV grid.
Preparation
Make sure that scripting is enabled on the front end and that the profile
parameter sapgui/user_scripting is set to TRUE in both systems. In many systems, the
default is FALSE and automatically reverts to this value when the system is restarted.
Close all sessions except for the one with the eCATT test script editor. This is not for technical
reasons - you will be switching back and forward between the two sessions and it is easy to get
confused if you have more sessions open.
Procedure
Starting the Recorder
1. In the test script editor, choose the Pattern function to display the Insert Statement dialog.
2. In the dialog, change the group to UI Control, choose SAPGUI (Record) for the command, accept
the interface name, and select the target system TARGET_1.
The target systems that you can choose from are the same ones that are in the system data
container that is referenced in the attributes of the test script.
3. In the following dialog, specify the transaction ( EC_TUTORIAL_SAPGUI) that you want to record.
Additionally, select the check box that will automatically generate a new SAPGUI command after
every screen change (to do this, you must first deselect manual generation).
By selecting After Every Screen Change, you have chosen a particular recording granularity.
However, granularity does not directly affect how much information is recorded. At one extreme, all
the information can be recorded into one command with a large command interface, and at the other
extreme, you can have multiple SAPGUI commands, each with a small command interface. In
practice, the selection of the granularity at this stage is usually not critical because you can change it
in the script later.
4. Choose Start Recording or Enter.
5. A new session is automatically created. You can, and should, switch back and forward between the
two sessions using the taskbar as shown below. Try it now.
6. In the Record SAPGUI Command dialog, confirm that you want to record the new session.
7. In the session containing the test script, you will see a control panel similar to the following
screenshot. Leave the settings as they are for the moment.
In the second session, you see the transaction to be recorded.
The Transaction
1. Expand the Flights tree and choose New Booking from the context menu of a flight date.
2. On the Cust. Details tab, use the F4 help to enter a customer number.
3. Change to the Passengers tab. You will see some information already entered that you will
overwrite for this exercise.
Enter the following information.
Field
Value
Class
First class
Name
Smith
Form of adress Mr
Date of Birth
10.10.1972
Note
During recording, it is important to change the data in fields that you want to set parameters for later
in the test script.
Choose Save.
4. Confirm the booking.
5. The message Flight was booked successfully. Booking number
<number> appears.
That is the end of the transaction.
Ending the Recording
1. Using the task bar, change to the session containing the test script.
2. Select the Close Recorded GUIs check box and then choose End Recording.
The recorded session closes and you now see the SAPGUI commands in the command editor of the
test script editor. Above the command editor is the parameter list. You can use the button at the top
left of this section to toggle between the display of normal parameters and the command interfaces.
3. Choose Save.
Result
You have recorded a transaction in a remote system.
You have created a test script in the central test system, which can be executed repeatedly using
exactly the same values that you entered during recording.
Executing Your Test Script
Use
When you are developing test scripts, you often want to run them by themselves. You can do this
from the eCATT initial screen or from the test script editor. In practice, your test scripts are usually
executed as part of a test configuration - you will do this later in the tutorial.
When you start execution, you are presented with the start options. You can specify display options,
how eCATT reacts to errors, override default values, and so on. Some options are specific to
particular commands - for example, the TCD and SAPGUI commands. These are grouped on the UI
Control tab. You can even specify a different system data container. So long as the names of the
target systems are the same as those use in the test script, you can test a different system
landscape.
Procedure
1. In the test script editor, choose
.
The start options appear.
2. Change to the UI Control tab.
3. Select the Highlight All Called GUI Elements checkbox. This option is cosmetic but will help you
see which elements are being selected during replay. Leave the other default options as they are.
4. Choose
.
The test script executes and the log is displayed.
5. Check the log.
Find the booking number (you can use Edit Find and search for Booking number).
Compare it to the number that you generated earlier. This is a new booking.
Handling Messages
Use
Up to now, we have treated messages passively - if they arrive, they are recorded in the log.
However, eCATT offers better ways for processing messages. The main way is to use the
MESSAGE...ENDMESSAGE block.
The simplest function of the MESSAGE...ENDMESSAGE block is to collect all messages that occur
from commands enclosed between the MESSAGE and ENDMESSAGE commands. The MESSAGE
command also allows you to specify how eCATT reacts to particular categories of messages or even
to specific messages.
When you recorded the transaction EC_TUTORIAL_SAPGUI and made a successful booking, the
system delivered a success message. Each time that you execute that test script, you want to know
that that particular success message occurs. Therefore, you define a rule, in the command interface
of the MESSAGE command, which will cause the script to fail if the message does not occur.
In the first part of this exercise, you will create a MESSAGE...ENDMESSAGE block that encloses no
commands. Using the start options, you will cause the execution to terminate when the required
message does not appear. In the second part of the exercise, you will position the ENDMESSAGE
command so that the block contains the SAPGUI commands that you recorded earlier. Assuming
the transaction replays correctly, the required message will appear and the test script will pass.
Finally, you will write a few lines of code to extract the variable part of the message so that it is
available for possible further use.
Procedure
1. In the command editor, double-click the command interface of the SAPGUI command that contains
the message text Flight was booked successfully. If you were careful during the
recording, that will be the last SAPGUI command in your script.
The screenshot above shows the command interface displayed in the easy mode
. Beside
the Message node are the message type ( S), message ID ( ECDEMO), and the message number
( 024). The variable part of this message is recorded beside the Parameter 1 node.
You cannot parameterize the message parts of a SAPGUI command interface.
2. Add a few empty lines in the command editor before the SAPGUI commands. Place the cursor
before the existing commands.
3. Use the Pattern function to insert the MESSAGE...ENDMESSAGE block. Accept the default
interface name as shown.
4. Double click the command interface ( MSG_1) of the MESSAGE command. The command interface
is displayed in the structure editor to the right of the command editor.
5. Choose
and enter the following:
Field
Input
MODE
R
MSGTYP S
MSGID
ECDEMO
MSGNR
024
6.
7. You have defined a rule that requires a particular message to occur.
8. In the start options, change the error behavior to terminate when an error occurs.
9. Execute the script.
The log shows that the required message did not appear.
10. Go back to the test script and cut and paste the ENDMESSAGE command so that it is after the
SAPGUI commands.
11. Execute this test script. This time the log should show only green traffic lights.
As you can see, the required message has occurred. Depending on what you recorded, you may get
other messages. As we have not specified any rules to deal with them, they will be handled by
default rules.
12. Go back to the test script editor and add the following lines to the end of the script:
V_MESSAGES = E_MSG_1[1]-MIDX.
E_BOOKINGNUMBER = E_MSG_1[V_MESSAGES]-MSGV1.
LOG ( E_BOOKINGNUMBER ).
The field MIDX of the first row of the ENDMESSAGE command interface always contains the
number of messages captured in the ENDMESSAGE command. Here, you assign that value to a
parameter V_MESSAGES. (Instead of E_MSG_1[1]-MIDX, which was required in previous
releases, you can use the special parameter &TFILL).
The second statement assigns the first variable part of the last message to the
parameter E_BOOKINGNUMBER. For the sake of simplicity, we make the assumption that the
message is always the last one. More generally, you could loop through the command interface to
find the message that you are interested.
The third statement is just a convenient command to simply show the extracted value being used.
13. In the parameter list, create the export parameter E_BOOKINGNUMBER and the local
variable V_MESSAGES. You can use
interfaces in the parameter list.
14. Save and execute the test script.
to toggle between display of parameters and command
Result
You have captured a message and read the value from its variable part.
Making Your Script Ready for
Data Input
Use
When you define import or export parameters in a test script, the test script is no longer restricted to
being a standalone test but can be used as part of a more complex test. The main uses for import
parameters are:

Receiving data from other test scripts. You can reference one script in another.

Receiving data from test configurations.
In the tutorial so far, every time you made a new booking you used the same passenger details. By
changing the fixed values recorded in the test script to import parameters, you enable the test script
to use a different set of data for each test run.
Procedure
1. In the test script editor, use the search function
to find the name Smith that you record earlier.
The search result indicates which command interface to parameterize.
2. Open the command interface in the structure editor and expand tree as shown below.
3. Double-click the ' Smith' node so that the value appears for editing on the right.
4. Change the value to I_NAME (without inverted commas because it is a parameter name).
5. Choose Enter.
6. In the Parameter Maintenance dialog, select Import and choose Yes.
7. In a similar manner, replace ' Mr' with I_TITLE, and ' 10.10.1970' with I_DOB.
The parameters are automatically entered in the parameter list with the default values that you
recorded earlier. The values are without inverted commas, which is different to the treatment of fixed
values in the structure editor.
Result
You have created import parameters and assigned them default values. Each time the script is
executed, the defaults will be used unless other values are supplied.
Creating Reusable Test Data
Sets
Definition
You can to a limited extent enter data values directly into test script and, as you will see later, in test
configurations. However, that is not the sensible way to handle your data in most cases. With realworld testing, much of the data is identical in many different test cases. For example, currency
conversion values. What is more, when these values need to be changed, you would like to be able
to change them in one place and affect all the test cases. In eCATT, you achieve this by storing your
data in test data containers, and then referencing the test data from within test configurations.
Test data containers consist of parameters and variants. The parameters describe the interface of
the container and the variants store the data. You define the parameters in the same way that you
define the parameters in a test script with the difference that there is no Visibility field - that is,
defining the parameters as import or export makes no sense here.
Procedure
1. On the eCATT initial screen, create a test data container TUTORIAL_TDC.
2. On the Attributes tab, choose the General Data tab and enter the following information:
Field
Entry
Title
Test Data for eCATT Tutorial
Component BC-TWB-TST-ECA
3. On the Parameters tab, create the parameters I_NAME, I_TITLE, I_DOB. Accept the default
types.
4. We have chosen to use the same names as we used in the test script. This make it easier for us to
remember how they are intended to be used. You will see later that it can make the assignment of
data in test configurations easier. However, parameters need not have the same name as the
parameters in the test script to which the values will be assigned.
5. Change to the Variants tab and create the following variants:
Variant
I_NAME I_TITLE I_DOB
VARIANT_1 Jones
Mr
12.10.1961
VARIANT_2 Harris
Mrs
13.10.1965
VARIANT_3 Singh
Miss
14.10.1973
6. Save your test data container.
Result
You have created a test data container with several sets of data.
You created the parameters manually in order to emphasize that they are independent of any test
script. However, you could have created the parameters by importing them from your test script (or
any other script or data container with suitable parameters). Also, if the variants had been stored
in External Variants, you could have imported them, rather than entering the data manually.
Assembling Your Test
Configuration
Definition
Although you have executed a test script directly, the normal test case is represented by a test
configuration. The test configuration references other eCATT objects to combine them into a test
case. At the core of the test configuration is the test script. The importing parameters of the test
configuration are those of the test script.
Normally a system data container is referenced, which overrides the system data container in the
test script. Optionally one or more test data containers are referenced and, to these test data
containers, you make links from the variants in the test configuration.
Procedure
1. With your test script open in the test script editor, choose Utilities Test Configuration Create Test
Configuration. This is the quick way to create a test configuration.
2. In the dialog box, save the test configuration.
3. You are now in the test configuration editor.
4. Choose the Configuration tab. You see your test script and the system data container are already
referenced.
5. Choose the Variants tab. You will see a default variant with parameters and data from the
referenced test script.
6. Create a new variant and enter the following data:
Variant
I_DOB
I_TITLE I_NAME
VARIANT_1 10.10.1971 Mr.
Smith
7.
8. The problem with this manual method is that the values are part of the test configuration. As mention
above, the preferred method is to reference data in test data containers.
9. On the Configuration tab, enter the name of your test data container TUTORIAL_TDC and give it
an alias TD1.
10. On the Variants tab, choose the
.
11. You see two panes. On the left pane are the variants in the test data container, and on the right
pane are the variants in the test configuration.
12. Select the three variants that you want to add to the test configuration and choose Attach as
Variant(s).
13. The new variants appear in the right pane.
14. Choose
, then save your test configuration.
Observe how the test data from test data container is referenced not by the name of the test data
container but by the alias that you entered earlier.
15. Now execute your test configuration. In the start options you will see there is a Variants tab where
you can select variants to be executed, override default data, and so. Do not make any changes just
now.
Result
The test script is executed once for each set of data.
Use
Improving the SAPGUI
Recording
Use
You have recorded a transaction but now you decide that the recording is not exactly what you want.
You could simply delete the recorded commands and start again. However, you may have invested
considerable effort in recording and parameterizing the transaction and you do not want to lose what
you have already done.
What you can do is use the SAPGUI (Attach) option. You execute the test script until it reaches the
part where you want to add the new commands. There are several ways to make the execution stop
at the relevant part (for example, using breakpoints), but for this exercise, we will use a simple
method that is easier to demonstrate.
For this exercise, you will read the value of a screen field, of the Customer Details section, into a
parameter. During the original recording, you did not try to record the initial value of the field, nor did
you use the GETGUI command. Now you want to enter a GETGUI command in the middle of the
transaction.
Procedure
1. Open the test script TUTORIAL_TS in the test script editor.
Comment out the commands after the place where you want to enter the new command.
If you have used too coarse a granularity and the desired place is part way through a command, you
can split the command first.
2. Choose
.
3. In the start options for the SAPGUI command, select Do Not Close Created Sessions.
4. Choose
.
The transaction replays to the end of the script then stops. Both the eCATT session and the session
where the replay took place remain open.
5. In the eCATT session, go back to the test script editor and place the cursor where the new
command is to go - that is, after the last uncommented SAPGUI command.
6. Use the Pattern function to create the SAPGUI (Attach) command.
7. Select the recording granularity. As you are only going to enter a single GETGUI command, the
granularity is not important.
8. In the Select Sessions dialog, select the session to be recorded - there should only be one
displayed.
9. Choose Enter.
The Recording Running dialog box appears.
10. Choose Insert GETGUI Command.
11. Go to the other session and click on the field that you want to get the value of.
The Selection of Properties and Methods to be Recorded dialog opens.
12. Expand the Get node until the value from the field is visible.
13. Select the Text checkbox.
14. Choose Insert and Exit.
15. In the Recording Running dialog box, select Close Recorded GUIs and then choose End
Recording.
16. Open the command interface of the GETGUI command and double-click the Text node to display
the Value node for editing.
17. In the value field enter the parameter name V_CUSTOMER and create it as a local variable.
18. In the command editor, enter LOG ( V_CUSTOMER ). This is just to demonstrate that the value
read from the field is available for other commands to use. Uncomment all the commands.
19. Execute the test script.
20. Expand the log to view the GETGUI node.
Result
You have taken an existing recording and added a new command to it. You used a GETGUI
command to read the value of a field into a parameter.
Testing a Transaction Suitable for
TCD (Record)
Use
You can use the SAPGUI command to test the same transactions that the TCD command can test.
So why learn to use a second command? For those transactions that TCD can test, it is much more
efficient to use TCD than SAPGUI (perhaps fifty times faster), which can make a considerable
difference to the execution time, especially when the transaction is called repeatedly.
Procedure
Create a new test script using the following information:
Field
Entry
Title
Testing Transaction EC_TUTORIAL_TCD
Component
BC-TWB-TST-ECA
System Data Container TUTORIAL_SDC
Recording the Transaction
1. Using the Pattern function, choose UI Control, TCD (Record). Choose the target
system TARGET_1. Enter the transaction code EC_TUTORIAL_TCD and accept the automatically
generated interface name.
2. Choose icon
to start the transaction.
3. Use the F4 help to enter an airline and a flight number then choose Displ. Flights.
4. Select a flight and choose Create Booking.
5. Use the F4 help to choose a customer number.
6. Change to the Passengers tab and enter a name, title, and date of birth for the passenger.
7. Choose Save.
The success message appears with the booking number.
8. Leave the transaction by choosing Exit. The following popup appears.
9. Choose Yes, then save your script.
Look at the command interface of the TCD command.
Here, you can see the screens of the transaction listed under the DYNPRO node.
Executing the Transaction
Execute the test script. Choose the option Process in background in the TCD start options. Notice
how much faster it executes than the similar transaction that you recorded earlier with SAPGUI
command. Execute the test script again. This time, choose Process in Foreground. With this
option, you can see interact with the transaction during execution.
Parameterizing the Command Interface
1. In the structure editor, expand the command interface to show the fields of the first screen.
2. Double-click the Fields node to display the fields for editing.
3. Replace the recorded values 'LH' and 0400 in the VALIN column with the parameter
names I_AIRLINE and I_FLIGHT_NUMBER respectively. In the dialog box that appears after you
choose Enter, make the parameters input parameters.
A field mode 'S' denotes that the field will be set with the value in the VALIN column.
4. In the structure editor, expand the node for the second screen.
5. Double-click the field node to display the fields for editing.
6. Change the mode of field [5] to 'G' (for get) and then enter the parameter
name V_CITY_FROM in the VALIN column. When you run the test script, the actual value will be
read into the parameter and be available for use elsewhere in the script.
7. Change the mode of field [6] to 'C' ( for check) and then enter the name V_AIRPORT_FROM in
the VALIN column. When you create the parameter make it a local variable and make sure the
default value is FRA. When you execute the script, the actual value will be checked against the value
of the parameter. If the values are different, the script will fail. You can try this later either by
changing the value of the parameter or by entering an airline that does not fly from the airport.
8. In the command editor, enter LOG ( V_CITY_FROM ).
This is only to demonstrate that the value read from the TCD command interface is available in the
parameter for use by another command.
9. Save and execute the test script.
Summary
You have seen that you can use TCD to record a transaction, and replay it in background mode for
fast execution.
You always use the VALIN column of the command interface to parameterize fields of the
transaction. You need to make the field mode 'S', 'G', or 'C', if you want the parameterization to
have the effect of setting, getting, or checking a value.
eCATT Command Reference
Use
An eCATT script consists of individual eCATT commands.
Each command begins with a command word and ends with a period. Comments (*) and
assignments (=) are exceptions to this rule.
You can have several commands on the same line. Comments (*), assignments (=), and inline
ABAP are exceptions to this rule.
We recommend using the Pattern function to insert commands. In the following table, those
commands that can be inserted using the Pattern function have the groups under which they
can be found noted. There is also a group called ALL COMMANDS.
Command Set
Command
Pattern Function Group
*
Protocol
=
Parameters
&ST30_POST_WAIT_ASYNC
This is not actually a command but a parameter that, like
a command, can be set in the script test.
The parameter is used in performance tests for test
scenarios containing asynchronous parts.
ABAP
Program Control
APPEND
Parameters
BCSET
Customizing
BREAK
Script Control
CALLMETHOD
ABAP Objects
Command
Pattern Function Group
CALLSTATIC
ABAP Objects, Checks
CHEATTR
ABAP Objects, Checks
CHEGUI
UI Control, Checks
CHESTATIC
ABAP Objects, Checks
CHETAB
Database, Checks
CHEVAR
Parameters
CLEAR
Parameters
CREATEOBJ
ABAP Objects
DELETE
Parameters
DELSTORE
Protocol
DO
Script Control
ELSE
Script Control
ELSEIF
Script Control
ENDABAP
Program Control
ENDDO
Script Control
ENDIF
Script Control
ENDMESSAGE
Script Control
ESF
Enterprise Services
EXIT
Script Control
FUN
Program Control
GETATTR
ABAP Objects
Command
Pattern Function Group
GETGUI
UI Control
GETLEN
Parameters
GETSTATIC
ABAP Objects
GETTAB
Database
IF
Script Control
INSERT
Parameters
LOG
Protocol
LOGMSG
Protocol
LOGTEXT
Protocol
LOOP
Parameters, Script Control
MESSAGE
Script Control
ON_LAST_MESSAGE_CHECK
PERF
Script Control
REF
Test Script References
REFCATT
Test Script References
REFEXT
Test Script References
REMOTECATT
Test Script References
RESCON
Program Control
RESTAB
Database, Customizing
RETRIEVE
Protocol
SAPGUI
UI Control
Command
Pattern Function Group
SENDEXT
Test Script References
SETATTR
ABAP Objects
SETSTATIC
ABAP Objects
SETTAB
Database, Customizing
SETVALID
checks
STORE
Protocol
TCD
UI Control
VALIDATE
checks
WAIT
Script Control
WAIT_ON_DYNPRO
WEBDYNPRO
UI Control
WEBSERVICE
Enterprise Services
WSPROXY
Enterprise Services
https://help.sap.com/docs/SAP_NETWEAVER_731_BW_ABAP/c6663103e6ad47dcb8bb830d85137077/4
96f79aa2c293b5be10000000a42189b.html?version=7.31.25&locale=en-US