eCATT Tutorial

Introduction
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
Introduction
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. This
transaction is only in Web Application Server 6.40 systems. If you do not have access to a second Web AS 6.40,
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 a 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
Introduction
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.
Procedure
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

Leave the Target System field empty. We will not use this field in this tutorial.
4. 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.
5. Choose .
6. The Start Options are displayed.
Accept the defaults but make sure that Log Display has been selected.
7. 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.
8. 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
Introduction
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
8. Expand the Flights tree and choose New Booking from the context menu of a flight date.

9. On the Cust. Details tab, use the F4 help to enter a customer number.

10. Change to the Passengers tab. You will see some information already entered.

11. Enter the following information.
Field Entry
Class First class
Name Smith
Form of address Mr
DOB 10.10.1970

It is essential to change the data in a field during recording if you want to be able to parameterize that field later
when editing the test script.
12. Choose Save.

13. Confirm the booking.
14. The message Flight was booked successfully. Booking number <number> appears.

That is the end of the transaction.
Ending the Recording
15. Using the task bar, change to the session containing the test script.
16. 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.

17. 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
Introduction
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.

Dealing with Messages
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 MESSAGEENDMESSAGE block.
The simplest function of the MESSAGEENDMESSAGE 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 MESSAGEENDMESSAGE 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 1node. 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 MESSAGEENDMESSAGE 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 Entry
MODE 'R'
MSGTYP 'S'
MSGID 'ECDEMO'
MSGNR 024

You have defined a rule that requires a particular message to occur.
6. In the start options, change the error behavior to terminate when an error occurs.

7. Execute the script.
The log shows that the required message did not appear.

8. Go back to the test script and cut and paste the ENDMESSAGE command so that it is after the SAPGUI
commands.

9. Execute the test script. This time the log should be green.

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.
10. 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.
11. In the parameter list, create the export parameter E_BOOKINGNUMBER and the local variable V_MESSAGES. You
can use to toggle between display of parameters and command interfaces in the parameter list.

12. Save and execute the test script.

Result
You have captured a message and read the value from its variable part.

Making Your Script Ready for Data Input
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
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 real-world 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
Component Test Data for eCATT Tutorial
Title 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
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

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.
7. On the Configuration tab, enter the name of your test data container TUTORIAL_TDC and give it an alias TD1.

8. On the Variants tab, choose the Variant Maintenance Assistant .
9. 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.

10. Select the three variants that you want to add to the test configuration and choose Attach as Variant(s).
The new variants appear in the right pane.
11. 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.
12. 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.

Improving the SAPGUI Recording.
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.
2. 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.

3. Choose .
4. In the start options for the SAPGUI command, select Do Not Close Created Sessions.

5. 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.

6. 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.
7. Use the Pattern function to create the SAPGUI (Attach) command.

8. Select the recording granularity. As you are only going to enter a single GETGUI command, the granularity is
not important.
9. In the Select Sessions dialog, select the session to be recorded there should only be one displayed.

10. Choose Enter
The Recording Running dialog box appears.
11. Choose Insert GETGUI Command.
12. 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.
13. Expand the Get node until the value from the field is visible.
14. Select the Text checkbox.

15. Choose Insert and Exit.
16. In the Recording Running dialog box, select Close Recorded GUIs and then choose End Recording.
17. Open the command interface of the GETGUI command and double-click the Text node to display
the Value node for editing.

18. In the value field enter the parameter name V_CUSTOMER and create it as a local variable.

19. 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.

20. Execute the test script.

21. 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)
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
1. 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
2. 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.

3. Choose icon to start the transaction.
4. Use the F4 help to enter an airline and a flight number then choose Displ. Flights.

5. Select a flight and choose Create Booking.
6. Use the F4 help to choose a customer number.

7. Change to the Passengers tab and enter a name, title, and date of birth for the passenger.
8. Choose Save.
The success message appears with the booking number.

9. Leave the transaction by choosing the popup appears.

10. 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
11. 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
12. In the structure editor, expand the command interface to show the fields of the first screen.
13. Double-click the Fields node to display the fields for editing.

14. Replace the recorded values LH and 0400 in the VALINcolumn with the parameter
names I_AIRLINEand 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.
15. In the structure editor, expand the node for the second screen.

16. Double-click the field node to display the fields for editing.
17. 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.
18. 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.

19. 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.
20. 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, orC, if you want the parameterization to have the effect of setting, getting, or
checking a value.