eCATT TutorialIntroductionThis 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.PrerequisitesYou need a system based on SAP Web Application Server 6.40 or higher.Scripting has been enabled. SeePreparing Systems and Computers for eCATT.BackgroundWhen 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 ContainerIntroductionIn most practical test environments, eCATT resides on acentral test systemand 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 LandscapeFor this tutorial, your system landscape consists of a system containing the transactionEC_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.

PrerequisitesIn the eCATT system, you require an RFC destination for the system under test. Here we will call the RFC destinationTUTORIAL. This should be a type 3 connection. You can use transactionSM59to maintain RFC destinations. Make sure that you can log on to the system using the RFC destination.Procedure1.Start transactionSECATT.2.On the eCATT initial screen, select theSystem Dataradio button and enter a name for your new system data container in the field beside it. For this tutorial, we will refer to it asTUTORIAL_SDC. You may have to prefix the name (for example, withZ) if you are in a customer namespace.

3.Choose theCreate Objecticon as shown above. This will open the editor for the system data container.4.On theAttributestab, enter a title for the system data container for example,System Landscape for eCATT Tutorial.

5.Change to theSystem Datatab. You will see a default target system calledNONE. 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 useTARGET_1), and use the F4 help to enter the RFC destinationTUTORIAL.

8.ChooseEnter. TheInstance Descriptionfield will be filled automatically.9.Save your system data container.ResultYou 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 ScriptIntroductionIn 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.Procedure1.On the eCATT initial screen, select theTest Scriptradio button and enter a name for your new test script in the field beside it. Here, we will name itTUTORIAL_TS. Leave the remaining fields empty.

2.Choose theCreate Objecticon, as shown above, to open the editor for the test script.3.On theAttributestab, enter the following information:FieldEntry

TitleTesting Transaction EC_TUTORIAL_SAPGUI

ComponentBC-TWB-TST-ECA

System Data ContainerTUTORIAL_SDC

Leave theTarget Systemfield 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.TheStart Optionsare displayed.Accept the defaults but make sure thatLog Displayhas been selected.7.Chooseto 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.ResultYou 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 TransactionIntroductionYou will record the transactionEC_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 TransactionThe 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.PreparationMake sure that scripting is enabled on thefront endand that the profile parametersapgui/user_scriptingis set toTRUEinboth systems. In many systems, the default isFALSEand 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.ProcedureStarting the Recorder1.In the test script editor, choose thePatternfunction to display theInsert Statementdialog.

2.In the dialog, change the group toUI Control, chooseSAPGUI (Record)for the command, accept the interface name, and select the target systemTARGET_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 selectingAfter 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.ChooseStart RecordingorEnter.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 theRecord SAPGUI Commanddialog, 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 Transaction8.Expand theFlightstree and chooseNew Bookingfrom the context menu of a flight date.

9.On theCust. Detailstab, use the F4 help to enter a customer number.

10.Change to thePassengerstab. You will see some information already entered.

11.Enter the following information.FieldEntry

ClassFirst class

NameSmith

Form of addressMr

DOB10.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.ChooseSave.

13.Confirm the booking.14.The messageFlight was booked successfully. Booking number appears.

That is the end of the transaction.Ending the Recording15.Using the task bar, change to the session containing the test script.16.Select theClose Recorded GUIscheck box and then chooseEnd 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.ChooseSave.ResultYou 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 ScriptIntroductionWhen 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 theUI Controltab. 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.Procedure1.In the test script editor, choose.The start options appear.2.Change to theUI Controltab.3.Select theHighlight All Called GUI Elementscheckbox. 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 useEditFindand searchforBooking number).

Compare it to the number that you generated earlier. This is a new booking.

Dealing with MessagesUp 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.Procedure1.In the command editor, double click the command interface of the SAPGUI command that contains the message textFlight 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 theMessagenode, are the message type (S), message ID (ECDEMO), and the message number (024). The variable part of this message is recorded beside theParameter 1node. Youcannotparameterize 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 thePatternfunction 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.Chooseand enter the following:FieldEntry

MODE'R'

MSGTYP'S'

MSGID'ECDEMO'

MSGNR024

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 parameterV_MESSAGES. (Instead ofE_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 parameterE_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 parameterE_BOOKINGNUMBERand the local variableV_MESSAGES. You can useto toggle between display of parameters and command interfaces in the parameter list.

12.Save and execute the test script.

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

Making Your Script Ready for Data InputWhen 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 ofdata for each test run.Procedure1.In the test script editor, use the search functionto find the nameSmiththat 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 toI_NAME(without inverted commas because it is a parameter name).

5.ChooseEnter.6.In theParameter Maintenancedialog, selectImportand chooseYes.

7.In a similar manner, replace Mr withI_TITLE, and 10.10.1970 withI_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.

ResultYou 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 SetsYou 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 noVisibilityfield that is, defining the parameters as import or export makes no sense here.Procedure1.On the eCATT initial screen, create a test data containerTUTORIAL_TDC.2.On theAttributestab, choose theGeneral Datatab and enter the following information:FieldEntry

ComponentTest Data for eCATT Tutorial

TitleBC-TWB-TST-ECA

3.On theParameterstab, create the parametersI_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 theVariantstab and create the following variants:VariantI_NAMEI_TITLEI_DOB

VARIANT_1JonesMr12.10.1961

VARIANT_2HarrisMrs13.10.1965

VARIANT_3SinghMiss14.10.1973

6.Save your test data container.ResultYou 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 byimportingthem from your test script (or any other script or data container with suitable parameters). Also, if the variants had been stored inexternal variants, you could have imported them, rather than entering the data manually.

Assembling Your Test ConfigurationAlthough 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.Procedure1.With your test script open in the test script editor, chooseUtilitiesTest ConfigurationCreate 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 theConfigurationtab. You see your test script and the system data container are already referenced.

5.Choose theVariantstab. 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:VariantI_DOBI_TITLEI_NAME

VARIANT_110.10.1971MrSmith

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 theConfigurationtab, enter the name of your test data containerTUTORIAL_TDCand give it an aliasTD1.

8.On theVariantstab, choose theVariant 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 chooseAttach 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 aVariantstab where you can select variants to be executed, override default data, and so. Do not make any changes just now.

ResultThe 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 theCustomer Detailssection, 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.Procedure1.Open the test scriptTUTORIAL_TSin 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 cansplitthe command first.

3.Choose.4.In the start options for the SAPGUI command, selectDo 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 thePatternfunction 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 theSelect Sessionsdialog, select the session to be recorded there should only be one displayed.

10.ChooseEnterTheRecording Runningdialog box appears.11.ChooseInsert GETGUI Command.12.Go to the other session and click on the field that you want to get the value of.

TheSelection of Properties and Methods to be Recordeddialog opens.13.Expand theGetnode until the value from the field is visible.14.Select theTextcheckbox.

15.ChooseInsert and Exit.16.In theRecording Runningdialog box, selectClose Recorded GUIsand then chooseEnd Recording.17.Open the command interface of the GETGUI command and double-click theTextnode to display theValuenode for editing.

18.In the value field enter the parameter nameV_CUSTOMERand create it as a local variable.

19.In the command editor, enterLOG ( 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 theGETGUInode.

ResultYou 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.Procedure1.Create a new test script using the following information:FieldEntry

TitleTesting Transaction EC_TUTORIAL_TCD

ComponentBC-TWB-TST-ECA

System Data ContainerTUTORIAL_SDC

Recording the Transaction2.Using thePatternfunction, chooseUI Control, TCD (Record). Choose the target systemTARGET_1. Enter the transaction codeEC_TUTORIAL_TCDand accept the automatically generated interface name.

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

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

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

9.Leave the transaction by choosingthe popup appears.

10.ChooseYes, 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 Transaction11.Execute the test script. choose the optionProcess in backgroundin 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, chooseProcess in Foreground. With this option, you can see interact with the transaction during execution.Parameterizing the Command Interface12.In the structure editor, expand the command interface to show the fields of the first screen.13.Double-click theFieldsnode to display the fields for editing.

14.Replace the recorded valuesLHand0400in theVALINcolumn with the parameter namesI_AIRLINEandI_FLIGHT_NUMBERrespectively. In the dialog box that appears after you chooseEnter, make the parameters input parameters.

A field modeSdenotes that the field will be set with the value in theVALINcolumn.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]toG(for get) and then enter the parameter nameV_CITY_FROMin theVALINcolumn. 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]toC( for check) and then enter the nameV_AIRPORT_FROMin theVALINcolumn. When you create the parameter make it a local variable and make sure the default value isFRA. 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.SummaryYou have seen that you can use TCD to record a transaction, and replay it in background mode for fast execution.You always use theVALINcolumn of the command interface to parameterize fields of the transaction. You need to make the field modeS,G, orC, if you want the parameterization to have the effect of setting, getting, or checking a value.