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