In eCATT, the bulk of the test data is normally stored separate from the test scripts in test data containers. The main reasons for this are reusability and maintainability. Test data containers and a test script are brought together in test configuration to create an executable test case.
The simplest use of test data containers is to create a separate one for each test script. However, this does not provide you with many of the advantages of reuse. A more effective way to manage test data is to create a single test data container for a whole application or sub-application (as shown in the upper part of the graphic below). By storing all of the test data in one container, you would find it easier to keep it consistent. In contrast to using a single test data container for all parameters, you can distribute the parameters over several test data containers (shown in the lower part of the graphic). For example, if you have a large number of scripts, each with many parameters, you may find that using a single test data container is no longer a practical option. In this case, you could split the parameters into logical groups, each in its own test data container.
This later approach can be illustrated by the example below, where the raw data for a transaction based on the flight data model is shown in the table. You can see that much of the data falls into two logical groups (airline and aircraft) and many of the fields have identical values.
By separating the aircraft data and the airline data into different test data containers, you can then conveniently reuse them when a test script calls for data of the appropriate sort. Additionally, by condensing the data so that particular combinations occur only once, (for example, LH 400) you only have to change the combination in on place, to affect all tests that reference it.
As with other eCATT objects, the test data container has mandatory attributes (title, package, person responsible, and application component) as well as attributes containing administrative information. 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. If a parameter is structured, you can display and edit in the structure editor.
Each variant contains a field for each parameter. If no value has been entered in a field, the value specified in the ECATTDEFAULT is the value of the field.