ISO/IEC JTC1/SC29/WG12
Multimedia and Hypermedia information coding Expert Group (MHEG)
|
Multimedia and Hypermedia information coding |
| Date: | November 1997 |
| Source: | MHEG Support Centre: Guillaume Audeon (CRIL ENGENIERE)
Andreas Kraft (GMD FOKUS) |
| Title: | Proposal for the description of single test cases |
| Status: | For discussion |
| Requested Action: | |
| Distribution: | MHEG Members and Mail list reflector http://www.demon.co.uk/tcasey/wg12 |
The notation used to specify the test cases is the following:
| Identifier | Provides a reference for test case for further reference, e.g. rect01 |
| Purpose | Provides a purpose and short description for the test case. |
| PICS Item(s) | List of items of the Protocol Implementation Conformance Statement (PICS) which have to be defined for this test case, if applicable.
This list references all the capabilities that the engine must implement for this test case to be selected for execution. |
| Description | Provides a detailed description of the test case. |
| Features | Lists all MHEG features that are tested, i.e. classes, attribute, elementary actions, events and behaviours. An additional list might indicate MHEG-5 features that are used by the referenced MHEG-5 application but that are not tested by this test case. |
| Objects | List of the relevant MHEG Application and Scene objects for the test case. A naming scheme should be defined which is independend of a domain.
Additionally, the content data might also be referenced herein. |
| Pre-Requisites | List of test cases and PICS that must have been tested successfully in order to run this test case. If one of these listed prerequiste test cases fails this test case cannot be performed. |
| This section describes the external (perceptible) part of the test case, i.e. what shall the operator observe and what control shall he perform to assess the test if performed correctly.
The scenario is described using a scripting language like event mechanism which is described in contribution MHEG 97/1058. It might also been possible to use screenshots to give the operator of the tests a hint for what should be seen on the screen. However, screenshots should not been used for accurate comparisons and shall not be considered as a formal specification of the expected result. | |
| External events | This part lists a sequence of possible user input or other external events which should be applied during the run of the test case. |
| Initial state | What is the initial state of the engine after the test cases is load into the engine under test. |
| Finit state | What is the state of the engine at the end of the test case. |
The objective of the test case selection step is to select the test cases that are appropriate by taking into account the capabilities implemented by the engine under test. The capabilities of the engine under test are stated by PICS selections which are given by the supplier of the engine. A test case is selected only if all the related engine's capabilities are stated as supported by the supplied PICS.
The test case selection process therefore consists mainly in taking account test cases that are related to the capabilities stated as supported by the given PICS. For example, if the PICS states that the EntryField class is supported by its engine , all test cases which relates to the EntryField class can be selected as appropriate to test this engine.
The test cases ----> PICS relation is expressed in the test case notation by the „PICS Item(s)" list of the Identification section (see above).
It is likely that some test cases rely on other to be executed correctly. A test case might fail with or without impact on the rest of the test cases. Therefore, a test case might require that a previous test case is successfully passed in order to be eecuted itself. The relations between test cases is expressed in the test case notation in the „Pre-Requisite" section.