Lecture Notes in Computer Science 3472

15 Case Studies 453
Motivations for the Abstractions The test models of the SUTs described in the
literature are all abstractions of the SUTs. Note that the test model must be
an abstraction and a simplification of the SUT because if not one could validate
directly the SUT without spending extraordinary efforts to build and validate a
model. Generally the description techniques for modeling are independent of the
implementation languages of the SUTs. The models represent artifacts of the
the SUT symbolically in order to be more human readable and comprehensible.
The most important motivation is probably that models are specified to
support the validation process. Because the test models concentrate on the parts
or certain aspects of the SUT that are to be verified, they are simpler and
easier to understand than the whole complexity of the SUT. Hence they can be
managed intellectually, validated by reviews and maintained more easily. Even
formal methods like model checking or theorem proving are applicable to them
sometimes. In other words, we get the confidence more easily that the model
meets the requirements of the system and thus the model serves as an abstract
reference implementation of the SUT.
Another important motivation is a technical one: generally the test generators
suffer from the state explosion problem. In order to support efficient test case
generation the models have to be as simple i.e. as abstract as possible.
Yet another aspect is that in some cases the models should be platform independent,
i.e. independent from, respectively, the test framework, the simulation
environment or the implementation language of SUT. This is achieved by modeling
the SUT’s artifacts symbolically and by building an adaptor which translates
the abstract test cases to concrete ones (cf. Sec. 15.7.3). Hence the models can
be used to test several implementations realized on different platforms because
the model leaves unchanged and only the adaptor has to be adjusted. Clearly,
in this case, platform-specific issues cannot be tested.
Functional Abstraction The purpose of functional (or behavior) abstraction is
to concentrate on the “main” functionality of the SUT which has to be verified.
This leads to an omission of cumbersome details in the test model that are not in
the focus of the verification task. 2 By doing so the model often implements only
parts of the complete behavior determined in specification documents, i.e., the
model does not completely define the intended behavior of the SUT but models
significant aspects only. In addition, functional abstraction supports the modelbased
testing process: if the SUT’s functionality can be divided into independent
parts, one can build a separate model for each part in order to verify each
functionality separately. An obvious drawback is that only the modeled parts
of the specification can be tested and that special care must be taken to detect
feature interactions between different functionalities.
Examples for functional abstraction The case study described by Philipps and
Pretschner [PPS + 03] concentrates on testing the protocols between a smart card
2
This does not necessarily mean that special cases are omitted—if these have to be
tested, they have to be modeled.