The test case attributes contain organizational and technical information. Many of the attributes are optional. Attributes can be used as test case selection criteria.
· Header Data
Ў Title (required field). A short description of the test script.
Ў Package (required field). You assign the test script to a package when you save the test script for the first time.
Ў Person Responsible (required field). The creator of the test case is automatically entered in this field. You can change the entry – for example, if the creator is not the person responsible for this test case.
Ў Component (required field). SAP application hierarchy component name.
· Search Terms. These can be used to find the test script.
· Maintenance System
Ў System Data Container. Enter the name of a system data container. This will be used as the default system data container when the test script is executed.
Ў Target System. If you have specified a system data container, you can also specify a target system. This is the default target system for eCATT commands for which a target system has not been specified. This system is accessed during script development for recording, and for execution within the eCATT script development environment. If no maintenance system is specified, the development system (NONE) itself is used. The maintenance system is not relevant to the execution of test configurations.
This data is used by eCATT to determine which version is to be executed when the test script is referenced by a test configuration or a REF command. eCATT inspects the target system at replay time and stores the software component, release, and patch level of the target system in the log. It then compares the target system data with all the versioning data of the test script and selects the version that matches.
You can also change the versioning data using Version Management , which is the recommended way because you can see the versioning data for all the versions of a script simultaneously.
· Software Components. For example, SAP_BASIS. You can list several software components. If you use the F4 help, you can select the actual software components from the local system or the maintenance (Target) system.
· Releases. You can specify the releases (for example, 620) and patch levels for which the test script is valid. If you use the F4 help, you can select the actual values from the local system or the maintenance (Target) system.
Ў You need not specify the patch level.
Ў If you specify a particular combination of software component, release, and patch in one version, that combination cannot be specified in another version. Backup versions are the exception to this rule.
Ў In one version only, you can enter an asterisk (*) in the Release field. This version will be used if no other version has release data that matches that of the target system.
Ў If you enter R(for required) in the Relevance field of a row, then the validity of the version is always determined by the entries in the row. Alternatively, you can enter O(for optional). This is useful for specifying several combinations, only one of which need exist in the target system for the version to be valid.
· Backup. To exclude a version from the version search, select Backup. This prevents the version from being executed by a test configuration or REF command. It can only be executed from the test script editor.
· Planning Data. You can enter an estimate of the time needed for the test and also assign a priority.
· Administrative Data. This is automatically entered.
On this tab, you can document the restrictions on where and how the test script is used. Most of the entries here have no effect on the execution of a test script but the following do:
· Status: only active scripts are included in automatic tests.
· Command BCSET in Script Allowed: the BCSET command will only be executed if this is selected.