Lecture Notes in Computer Science 3472

15 Case Studies 457
level. In the test model, an operation and its operands are conveniently symbolized
by a string (a name). With this kind of model, the behavior of the smart
cannot be tested directly if it receives byte string which are for example one byte
too short or too long, respectively. It is up to the test engineer to decide whether
to cope with such illegal input at the level of the model, or at the level of the
driver component.
Intense data abstraction can lead to information loss that cannot be coped
with for test case generation. For example the smart card model developed by
Philipps and Pretschner [PPS + 03] abstracts completely from file contents, and
symbolizes files and operations on them without any implementation in the
model. Hence the contents of the files and their evolution over runtime could
not be tested with this model. Only static properties like file length could be
verified.
It is hard to detect feature interaction if functional abstraction is applied
to build separate test models for testing distinct functionalities. For instance,
Farchi et al. [FHP02] use separate models to test different operations of the
POSIX standard. These models help to verify the correct functioning of these
operations in a stand-alone manner, but do not help to verify the behavior of
the whole SUT where these operations are used in combination. In other words
unmeant behavior (bad feature interaction) of the SUT caused by combination
of operations which were verified separately cannot detected by this approach.
Finally, problems can arise if temporal abstraction is intensively used in the
test model. Obviously, in the domain of distributed real time systems a rigorous
use of temporal abstraction can prohibit the detection of faults which stems
from the sensitive interleaved timing behavior of the separate components. As a
counterexample, Dushina et al. [DBG01] explicitly do not use temporal abstraction
in their test model. In order to trace generated test cases and to check the
expected performance a clock cycle in the test model corresponds exactly to a
clock cycle in the real processor design.
15.7.2 Structure of Test Cases
A test case generated from the abstract test model and a test specification
contains inputs for the SUT and expected outputs and observable states from
the SUT. In the literature we find the different kinds of structuring a test case
as follows:
Test case is a trace In most model-based testing approaches an abstract test
case is a trace of the abstract test model. The test generator computes them
according to the test specification. In the approach described by Philipps and
Pretschner [PPS + 03] it is trace of input and output signals, in other approaches
[SA99, FKL99, DBG01, FHP02] it is a trace of the model’s FSM containing
actual states of input, output and internal variables. Overall, the trace describes
inputs/stimuli for the SUT and expected outputs or observable states of the
SUT for the verdict definition. Roughly, one abstract test case corresponds to
one concrete system run of the SUT.