Jon Maidstone

PM Group -
Design Tools

eCATT: Test Configurations and
Test Data Containers
A worked example

09. July 2003

............................................. 7 3...........................................................................3...............................................................................................................................................doc Page 2 ..........................1 Test Configuration........ 7 3.......................................................................................................2 Test Data Containers............ 10 C:\Jon\eCATT\Documents\TDC_Example_Paper.............................................. 3 2 How Does Data Get Into a Script? ...... 9 4 Conclusion ..................................................... 4 3..................................................................4 Executing the Configuration .......... 3 3 Introducing our Example................................................................................................................................................................................................ 6 3.eCATT: Test Configurations and Test Data Containers Contents 1 Introduction .................................1 The Variant Wizard .................................3 Assigning Data From Test Data Containers to a Configuration .......................................................................................... 5 3...........................................

if you are implementing Warehouse Management and want to test material movements. scripts can draw on data from more than one test data container. You can either enter variants manually. While this is fine for testing the script while you are developing it. This allows you to store logically-grouped data in separate test data containers and merge it with other data into a single test case in the form of a test configuration. but in separate objects called test data containers. Once you have assigned a script to a configuration. Normally. Exporting parameters are the values that a script returns to its caller when it has finished. where you want to try out various different sets of data to see whether they are valid or fail your script. using a worked example. within the same object. show you how to plan a strategy for managing test data. When the script is called directly from a test configuration. test data containers.eCATT: Test Configurations and Test Data Containers 1 Introduction One of the main features of eCATT (and CATT before it) is the relative ease with which you can compile complex data-driven tests. it is very likely that you will have to set up certain data before many of your actual test cases can be performed. In this article. you may assign a default value to each parameter. using the REF command or from a test configuration. the script will have a command interface that can be supplied with values in the same way that you might parameterize a TCD or a SAPGUI command. In the former case. • To set up data for subsequent tests: When you test an SAP System. 2 How Does Data Get Into a Script? Each test script may have importing and exporting parameters. The fact that the data is now separate makes it easier to reuse. you can use the Variants section of the test configuration editor to maintain sets of data with which the script will be executed. it did mean that the data that you had was not reusable with other scripts.doc Page 3 . Test data is now not stored in the eCATT test script. you could store test data alongside the test procedure – that is. Now you can actually test the material movement! In CATT. I want to show you the relationships between test scripts. In between these “black and white” values. eCATT uses test configurations as a vehicle for passing data to a test script. For example. and you may well have a second set of data that should always cause the application to fail. you have a large “gray” area. you will always have one set of data that will always cause the application to run successfully. running a test script several times with different sets of data. you need a warehouse with goods in it that you can move. The script is executed once for each set of data – or variant – that you enter. or use data from a test data container to populate them. it is thoroughly unsuitable for a “live” test run for the following reasons: • You can only assign one value at a time to each parameter in this way • Each time you wanted to change the parameter. In the design for eCATT. since data from a single container can be assigned to any number of eCATT scripts. and test configurations and. Importing parameters are the values that are passed to the script by its caller when it is called. Furthermore. you will typically have some control data. then posting some inbound goods to stock the warehouse. the importing parameters of the test script are exposed in the test configuration for you to assign one or more sets of values. known as variants (see figure 1). Although this had the advantage that you could execute the procedure quickly and easily. There are essentially two reasons why you might want to do this: • To test “borderline” values: When you test how a transaction behaves. C:\Jon\eCATT\Documents\TDC_Example_Paper. Within the script. This means setting up the warehouse and the required material masters. you would have to modify the script Consequently. A script may be called in one of two ways – either from another script. this was changed.

which I recorded in a test script using the TCD command. The example is based on a transaction. Exporting Fig. It has two screens: Fig. The transaction is based on the flight data model used in ABAP training. Exporting params. 1: Passing parameters to a script in a REF command (top) or from a test configuration (bottom) 3 Introducing our Example I want to use an example to illustrate how we can build a test configuration.eCATT: Test Configurations and Test Data Containers eCATT Script eCATT Script Importing params. Importing Parameters Variant 1 Variant 2 Commands Variant 3 Variant n Exporting params. n eCATT Script Log Test Configuration repetitions Importing params.doc Page 4 . X_1). and can be used to add a new flight to the booking system. 2: First screen of demonstration transaction C:\Jon\eCATT\Documents\TDC_Example_Paper. Importing params. Command Interface Exporting params. REF (X.

Second screen of demonstration transaction The transaction requires you to supply certain information.doc Page 5 . You will also notice that there is already a variant in place – the default variant. In my test script. to which we assign the test script. I parameterized the fields of the transaction so that each field is filled from an importing parameter of the script. the parameters correspond to those of the script (see table above). and the parameter names on the right: Airline I_AIRLINE Flight Number I_FLIGHT_NUMBER Date I_DATE Airfare I_PRICE Local Currency I_CURR Plane Type I_PLANE_TYPE Max Capacity Econ I_CAP_ECON Max Capacity Business I_CAP_BUS Max Capacity First I_CAP_FIRST 3. we need to create a test configuration. the test configuration has the following set of parameters that needs to be filled: Fig 4: Parameters of a test configuration As you can see. Once we have done that. This consists of whatever default values have been C:\Jon\eCATT\Documents\TDC_Example_Paper.1 Test Configuration In order to create an executable test case in which we can pass several sets of values to the transaction.eCATT: Test Configurations and Test Data Containers Fig 3. The table below shows the field names on the left.

a set of variants might look like this: NAME I_AIRLINE I_FLIGHT I_DATE I_PRICE I_CURR I_PLANE_TYPE I_CAP_E I_CAP_B I_CAP_F 1 LH 400 31.2002 500 EUR 747-400 250 50 15 3 LH 400 02. For example. where the various combinations are maintained in the separate object on the left – a test data container .doc Page 6 . and a set of variants – the data that is managed in the container.2002 495 EUR 747-400 250 50 15 5 QF 005 01.10. C:\Jon\eCATT\Documents\TDC_Example_Paper.and are linked by reference into the corresponding fields of the test configuration: I_AIRLINE I_FLIGHT I_AIRLINE I_FLIGHT.eCATT: Test Configurations and Test Data Containers maintained for the various importing parameters of the script. the most striking of which is the redundancy of so much of the data – the combination LH 400 appears four times. and the plane type 747-400 (along with the capacity of the aircraft) five times.2002 1050 AUD 747-400 250 50 15 There are two comments that we can make about this table already.08. it would be best if the data could be stored separately from any particular test configuration to allow it to be reused by other configurations and scripts that require the same data. Later you will see how to control whether this variant is actually executed or not. So we can now start to assign the data with which we want to execute the test case. in which you can state in which cases that particular data can be used. The second thing that may have occurred to you is the way in which much of the data falls into two distinct groups – the airline code and flight number on the one hand. 3. Test data containers are not release-specific. QF 005 twice.09. each variant has a description. . We would then have something like this. and the aircraft type and its capacity in each of the three classes on the other.2002 500 EUR A340 200 20 0 2 LH 400 01.2002 1000 AUD 747-400 250 50 15 6 QF 005 02.09. Furthermore.10. AA 0017 LH 0400 LH 0400 LH 0400 QF 0005 LH 0400 QF 0005 UA 0945 QF 0005 Test Data Container Test Configuration Fig 5: Using test data containers to reduce redundancy A test data container has a set of parameters – in this case I_AIRLINE and I_FLIGHT.09.2 Test Data Containers A more efficient way of managing this data would surely be to maintain the flight number or aircraft type data separately and link it into the relevant fields of the test configuration. However. .2002 650 EUR 747-400 250 50 15 4 LH 400 03.

1 The Variant Wizard You start the variant wizard from the Variants tab of a test configuration using the wand icon (see fig. you must specify the script that is to be executed. Fig 6: Assigning test data containers to a test configuration Here. Assuming. the two test data containers ZECATTWS_FLIGHTS (containing airline and flight number) and ZECATTWS_AIRCRAFT (containing aircraft details) have been assigned to the script. business. that we have created two test data containers for our scenario – one containing the airline and flight number. and can be assigned using the Variant Wizard. the other containing the aircraft type and the numbers of seats in first. On the right-hand side. It consists of two areas.doc Page 7 . the sets of data that will actually be executed in the configuration). Note that it is also possible not to specify a test data container at all. once you leave the variant wizard.3 Assigning Data From Test Data Containers to a Configuration When you create a new test configuration. just double-click its name in the test configuration editor. Each must have at least a name and a type. you can see the variants currently assigned to the test configuration (that is. You may also specify a system data container.3. In this area.eCATT: Test Configurations and Test Data Containers The parameters of a test data container work in a similar fashion to the parameters of a script. we now need a way of using those data in our test configuration. 3. but to supply any required data by hand. you can only add data to the variants by adopting values from one of the test data containers. Within this area. which tells eCATT the system landscape in which it is to execute the test. On the left-hand side. However. you can see the contents of one test data container. The variant wizard allows you to C:\Jon\eCATT\Documents\TDC_Example_Paper. That data is now available to the configuration. you can use the buttons at the bottom of the dialog box to scroll through the various test data containers assigned to the test configuration. 3. therefore. 8). Hint: To look at the definition of a test script or test data container. and economy class. and you may specify one or more test data containers to be used as data sources for the configuration. you can fill in any gaps manually.

Note that all of these actions only fill fields that are still initial. Your first step will usually be to add a set of variants to the configuration from one of your test data containers: Fig 7: The variant wizard You can do this by dragging a variant from the left-hand side of the screen to the right-hand side. or column. C:\Jon\eCATT\Documents\TDC_Example_Paper. On the right-hand side. Once you have the next variant. variant. only fields with identical names to parameters in the test data container will be filled. Note that you may use the same variant more than once. • Clear the values in a particular cell. To switch to another container. you can merge its fields with the variants you have already created on the right-hand side of the screen by selecting one of the variants in the test data container (by single-clicking it) then selecting a variant on the right-hand side and choosing Add to Variant. Having picked out variants from your first test data container.eCATT: Test Configurations and Test Data Containers • Add a new variant to the configuration • Add fields from a variant in a test data container (left-hand side) to an existing variant in the configuration (right-hand side) • Place the value of a single field from a variant in a test data container (left-hand side) in a single field of an existing variant in the configuration (right-hand side) • Place the value of a single field from a variant in a test data container (left-hand side) into a particular field of all existing variants in the configuration (right-hand side).doc Page 8 . you can unite data that you have stored in any number of different test data containers. you will probably need to fill in gaps by using variants from further test data containers. In this way. use the scroll buttons in the bottom left-hand corner of the variant wizard.

Within the script. • Continue with next variant: The current variant is terminated. are affected by it. Remember again that this operation only works on cells that are currently empty. choose Insert Field in Column instead. to use the same value in every variant – useful. the value in the configuration will change with it. you can also create variants manually within the test configuration editor. If you want to replace values.eCATT: Test Configurations and Test Data Containers Remember that this operation only fills fields that are currently empty. it might be possible to continue processing the current variant despite the error. 3.4 Executing the Configuration When you execute a test configuration. then single-click the target field on the right-hand side. you will see something like this: Fig 8: Test configuration with references from test data containers Notice that the fields do not contain values. In other cases. Sometimes an error will be so severe that not just the variant in which it occurred. but eCATT continues processing the variant in which it occurred. Now choose Link Individual Field. processing resumes with the next variant • Continue with next test configuration: The current test configuration is terminated. but certain options apply specially to test configurations. you must first clear the existing values by selecting the relevant cells and clicking the trash can icon. LH*: All variants whose names start with LH are executed. but a reference to the source of the data. This is a genuine reference – in other words. for example. To add the single value to the entire column in the configuration (that is. C:\Jon\eCATT\Documents\TDC_Example_Paper. you can fill out manually any fields in any variants that you have not filled from a test data container. On returning to the test configuration editor by choosing Continue in the bottom right-hand corner of the variant wizard. but also subsequent variants. any default value maintained for the parameter will be applied. for fields like Company Code or Sales Organization). You can also determine how the configuration should behave if it encounters an error.doc Page 9 . In particular. single-click the field in the test data container display (left-hand side). you can specify which variants will be executed in one of three ways: • Leave the Variant field blank in the start options: All variants. are executed. including ECATTDEFAULT. These are similar to the execution options in the script editor. As well as using the variant wizard to construct your variants. it will be sent to the eCATT script as such. for example. • Enter a pattern. if you change the value within the test data container. processing resumes with the next test configuration (this option is only applicable to mass starts in the Test Workbench) • Continue with next script command: The error is logged. You can therefore choose between the following start options for a test configuration: • Terminate start process: The configuration stops processing immediately. If you want to transfer the value of a single field from a test data container to a variant in the configuration. you have various start options. Equally. If you leave a field blank. • Enter * in the Variant field: All variants except ECATTDEFAULT are executed.

increasing the potential for reusing this data and. through this reuse. This clean division is more than just nice-to-have in terms of the aesthetics of software design. Since test data containers are extensible. reducing the amount of effort required to create consistent automated test cases across the whole scope of a particular test project. it also makes it easier to separate the tasks of creating test scripts and assembling test cases.eCATT: Test Configurations and Test Data Containers 4 Conclusion Test configurations allow you to create powerful data-driven test cases while keeping the data separate from the test scripts themselves. C:\Jon\eCATT\Documents\TDC_Example_Paper. Furthermore.doc Page 10 . you can even reuse them across several releases by adding additional parameters and sets of data as required. the addition of test data containers to the testing environment allows you to separate your test data even from a particular test configuration.