Test Data Container and Test Configuration

Create a test data container. Use this test data container and the test script that you have created in a previous task to create a test configuration. Then run the test configuration.

1. Create a test data container with the name ZECATT_TDC_##, where ## is your group number. Give the test data container a self-explanatory title and assign it to the BC component. Use the same parameter that you used in your test script. As a variant, import a file (your instructor will give you the details). You might not be able to use the GUI on the frontend in the training room to do so. Your instructor will give you more details about this.

2. Create a test configuration with the name ZECATT_CONFIG_##, where

## is your group number. Give the test configuration a self-explanatory title and assign it to the BC component. As the system data container (SDC), either choose an SDC that you have created or an SDC specified by your instructor. Use the eCATT objects you have created as the test script and test data container. Choose a few variants from your test data container so they can be executed in the test configuration (not, however, the ECATTDEFAULT variant). Finally, run the test configuration and check the log that is generated.

Solution 7: Executing an eCATT Test Script

Task 1: Create and Execute a Simple eCATT Test Script (FUN Command)

Create an eCATT test script that reads the contents of a table on your local system.

Then run the test script and check the log created.

1. Create an eCATT test script called ZECATT_##, where ## is your group number. Give the test script a self-explanatory title and assign the test script to the component BC.

a) Start transaction SECATT (Extended Computer Aided Test Tool, menu path Tools → ABAP Workbench → Test → Test Workbench → Test Tools → Extended CATT). On the initial screen of this transaction, select the Test Script radio button, and enter the name of your test script in the associated input field. Then choose Create Object (F5). On the next screen, under Attributes → General Data, enter a self-explanatory title for the test script in the Title field, and in the Component field, select the component BC.

2. Switch to the test script editor and write an eCATT script that records the function module RFC_READ_TABLE on your system, where table T000 is to be read. Here, the import parameter QUERY_TABLE = TABNAME should be transferred to the function module. Save your test script as a Local Object.

a) Switch to the Editor tab page. You are now in the test script editor. The simplest way to record a function module is to choose Pattern in the application toolbar. On the following screen, in the Group field, choose the Program Control entry and in the Command field, the FUN entry.

In the Function Module field, enter the name RFC_READ_TABLE for the function module to be executed and choose Continue. The system now proposes an interface. Confirm the name of this interface by choosing Continue again.

b) Open the structure editor by double-clicking the name of the command interface generated automatically (for example, RFC_READ_TABLE_1). In the structure editor, open the path IMPORTING → QUERY_TABLE and double-click QUERY_TABLE.

In the Value field on the right-hand side of the structure editor, enter the name of the parameter specified in the task (TABNAME) and press Enter. On the popup that is then displayed, choose Import and confirm your entries with Yes. In the parameter editor, enter the value T000 for the TABNAME parameter in the Value field, since this table is to be read. Finally, save the script and, on the following screen, Create Object Directory Entry, choose Local Object.

3. Run your test script and check the results of the test script using the log created.

a) Choose Execute Test Script from the application toolbar. On the following screen, accept the predefined values and choose Execute. The result log of the test is then displayed. You can open the tree structure here to display detailed information about the individual steps.

Task 2: Optional: Extend the Test Script to Include Cross-System Testing and SAP GUI Command

Extend your test script from the previous task to include the recording and running of an SAP transaction on a remote target system and the recording and running of a transaction that uses controls on your own system.

1. Add an additional eCATT command to your test script so that a user master record is changed on a remote system. Use a system data container and a user on the remote system to do this. Your instructor will give you the details.

Save your test script, execute it, and check the result of the execution.

a) Enter the test system editor for your test script. Go to the Attributes tab page. In the area General Data → Maintenance System, enter the name of the system data container that your instructor gives you and save your entry. By double-clicking the name of the system data container, you can check which target system relates to a remote SAP system. Then switch back again and choose the Editor tab page. In the command editor, position your cursor at the start of a new line.

b) The simplest way to record an SAP transaction in a remote SAP system is to choose Pattern in the application toolbar. In the Group field on the following screen, choose the UI Control entry, and in the Command field, the TCD (Record) entry. In the Transaction field, enter the name SU01for the transaction to be executed and choose Continue. The system now proposes an interface. Do not change the default value.

In the Target System field, choose the remote target system from the system data container using the F4 help. Then confirm your selection by choosing Continue. The transaction SU01 then starts on the remote system. On the initial screen of transaction SU01, enter the user that your instructor specifies and choose Change. On the Address tab page, you can now make a suitable entry in the Function field (such as Course Participant). Then save your data for transaction SU01, choose Back, and confirm on the next screen that you want to transfer the data. Save your test script again, and then choose Execute Test Script. On the following screen, accept the predefined values and choose Execute. The result log of the test is then displayed. You can open the tree structure here to display detailed information about the individual steps. You can, for example, branch to the data entered on the individual screens.

Continued on next page

2. Extend your eCATT test script. In the SAP Easy Access menu of your local system, choose Tools → ABAP Workbench → Overview → Object Navigator (SE80) and display the program RSPFPAR. To do this, you may have to use the SAP GUI installed on your SAP system (instead of the SAP GUI in your training room). In the hierarchy tree of transaction SE80, branch to RSPFPAR → Subroutines → READ_ACTUAL_PAR_VALUES after selecting the program, and display the relevant report by double-clicking the program name. End the recording of the transaction and save the eCATT script.

Execute the test script and display the log.

a) First use transaction RZ11 to check in another session whether the SAP system allows the execution of scripting commands. To do this, on the initial screen of transaction RZ11, enter the parameter name sapgui/user_scripting, choose Display, and, if necessary, change (using the Change Value pushbutton) the value of this parameter to TRUE (uppercase letters are required). Select Switch on all servers and choose Save. Then log off with your user and log back on again so that the changes take effect.

b) Check whether your SAP GUI supports the execution of GUI scripting.

To do this, Enable Scripting must be selected under Customize Local Layout → Options... → Scripting.

Hint: Depending on the version of SAP GUI the menu path might be Customize Local Layout → Options... → Accessibility

& Scripting → Scripting instead.

c) Switch back to the test script editor for your test script. In the command editor, position the cursor at the start of a new line. The simplest way to record an SAP transaction that uses controls is to choose Pattern in the application toolbar. Now choose in the Group = UI Control and command = SAPGUI (Record). The entry in the Interface field ([GENERATED]) is generated automatically. Choose NONE as a target system using the F4 Help, since this command is to be executed on your local system. Now choose Continue. On the next screen, ensure that the Manual Generation checkbox is not set and that all four checkboxes are selected in the Automatic Generation area. You enter SESSION_MANAGERin the Start Recording with Transaction field, since recording is to start in the SAP Easy Access Menu. Ensure that the indicator is set in the ResetGUI = 'X' in First Created SAPGUI Command field. Choose Start Recording. If necessary, confirm the saplogon message by choosing OK. In future, always confirm these messages with OK. In the Record SAP GUI Command window, check the entry in the Message Server field (and, if necessary, change it to

your own host, twdfxxxx.wdf.sap.corp), choose Yes, and then switch to your new session (you may have to confirm more dialog boxes by choosing OK).

d) In the new session you have created, choose Tools → ABAP Workbench

→ Overview → Object Navigator in the SAP Easy Access menu and start the Object Navigator by double-clicking. In the Object Navigator, select the Program with the name RSPFPAR in the Repository Browser (even if Program or RSPFPAR are already predefined, choose these options again with the Enter key). In the folder structure that appears, choose Subroutines → READ_ACTUAL_PAR_VALUES and display the coding of the subroutine by double-clicking it. Select any section of text within the coding using the mouse.

e) Now switch to the Recording running... screen, select the Close Recorded GUIs field, and choose Stop Recording. Confirm a dialog box again if necessary. Save your test script again, and then choose Execute Test Script. On the following screen, accept the predefined values and choose Execute. If necessary, reconfirm the message that a script wants to connect to your SAP GUI (in future always confirm this message with OK). The test script is then run and the system displays the result log for the test. You can open the tree structure here to display detailed information about the individual steps. You can, for example, branch to the data entered on the individual screens.

Task 3: Test Data Container and Test Configuration

Create a test data container. Use this test data container and the test script that you have created in a previous task to create a test configuration. Then run the test configuration.

1. Create a test data container with the name ZECATT_TDC_##, where ## is your group number. Give the test data container a self-explanatory title and assign it to the BC component. Use the same parameter that you used in

Continued on next page

your test script. As a variant, import a file (your instructor will give you the details). You might not be able to use the GUI on the frontend in the training room to do so. Your instructor will give you more details about this.

a) Start the SAP GUI (you might have to start the SAP GUI from the operating-system level of your SAP system – with the RDP client, for example).

On the initial screen for transaction SECATT, now create a test data container (Test Data field) with the name ZECATT_TDC_##, where ##

is your group number. In the General Data area of the Attributes tab page, enter a descriptive title and BC as the component.

b) Go to the Parameters tab page. Choose the path Edit → Import Parameters and select the eCATT script that you have created (ZECATT_##). Select the row with the parameter TABNAME and choose the pushbutton with the arrow pointing to the right. Now choose Copy. Go to the Variants tab page and choose Edit → Variants → Upload. Navigate to the TXT file specified by your instructor (to do this, you may have had to start the GUI at the operating-system level of your training system) and transfer this file. If necessary, confirm that existing variants are to be deleted before the upload and finally save the test data container as a local object.

2. Create a test configuration with the name ZECATT_CONFIG_##, where

## is your group number. Give the test configuration a self-explanatory title and assign it to the BC component. As the system data container (SDC), either choose an SDC that you have created or an SDC specified by your instructor. Use the eCATT objects you have created as the test script and test data container. Choose a few variants from your test data

container so they can be executed in the test configuration (not, however, the ECATTDEFAULT variant). Finally, run the test configuration and check the log that is generated.

a) In the initial screen for transaction SECATT, now create a Test

Configuration with the name ZECATT_CONFIG_##, where ## is your group number. On the Attributes tab page (General Data area), enter a descriptive title and the value BC in the Component field.

b) On the Configuration tab page, choose either a system data container (SDC ZECATT_SDC_##) that you have created or the SDC specified by your instructor. As the test script, select the test script you have created. In the Test Data area, insert a row with the alias ADM and the object name of the test data container you created (ZECATT_TDC_##).

c) On the Variants tab page, choose the Variants Maintenance Assistant (pushbutton with the magic wand). On the left-hand side of the following screen, select all the variants and choose Attach as Variant

→ Back. Now save your test configuration as a local object.

d) Now run the test configuration you have defined. To do so, select your test configuration on the initial screen for transaction SECATT and choose Execute. Go to the Variants tab page and select a few variants in the lower part of the screen in the Execute column (always deselect the ECATTDEFAULT variant). Finally, choose Execute. Now confirm the additional dialog boxes if required by choosing OK.

e) Open the tree structure of the log that was generated after the transaction was executed. The number of times that the test script was run should be equal to the number of variants selected. If you open the (sub)log of one or more test script calls in the FUN → IMPORT... → IMPORTING... area, you can see which variable value was transferred from the test data container to the script (and therefore the function module). The related results are displayed in the FUN... → EXPORT ...

→ TABLES → DATA... → DATA[n].