Lecture Notes in Computer Science 3472

15 Case Studies 441
Test Model Since the term test model is not part of the glossary it will be
introduced here. We call the abstract formal behavior model of the SUT, which
is used in conjunction with the test specification to derive test cases, a test
model (also abstract test model or sometimes if the context is defined only
model). In principle there are two ways for deriving test models. The first is to
benefit from an existing model, whether it is a formal specification or a system
development model of the SUT. For example, usually in the case studies that
involve a hardware SUT, a design model is available that is then abstracted to
build a test model. The abstraction becomes necessary due to constraints given
by the test case generator and the potential available test model traces, which
have to be limited. The second way is to build the test model manually, based on
information from the natural language specification of the SUT. For both cases
a validation of the test model has to be assured. Sec. 15.4 illustrates both ways
in more detail.
Test Specification Besides a test model, a test specification is necessary in order
to direct the test case generation. It has two aims, first to define formally what
will be tested and second to restrict the amount of resulting test cases. The test
specification defines which of the potential available test model traces will form
the test suite. Based on a test purpose, which can exist in different degrees of
formalization, the test specification has to be in an operational state in order to
use it in conjunction with the test model as input for the test case generator.
The type of test specification for the considered case studies can be categorized
into functional, structural or stochastic specifications (cf. also Chapter 11):
• Functional specifications represent a set of environment behaviors or use
cases in order to constrain the behavior of the test model to certain functionalities.
• Structural specifications can be applied to decomposed components, where
different coverage criteria starting from simple statement coverage up to path
coverage are available.
• Stochastic specifications select test cases by random or by a probability
distribution and have been observed to be also useful in some fields, e.g. in
partition testing [Nta98].
Test Case Generation Once the test model and test specification are defined,
test case generation can be started which results in a test suite. A test case is
generated by constructing an execution path of the test model which complies
also to the restrictions of the test specification. This process continues until all
specified test cases are found.
Test Case Instantiation In order to concentrate on the essential aspects of the
SUT to be verified and to handle, in a lot of cases, the state explosion problem
of the considered SUTs, the test models have to be on an abstract level. Thus
the generated test cases/test suites are also at this abstraction level. Before the
execution of these test cases, a concretization of the previously done abstractions