Lecture Notes in Computer Science 3472

15 Case Studies 449
rion. Stochastic test specifications can be equally distributed, e.g. every second
test case of a randomly generated set will be chosen, or non-equally distributed
following a certain distribution function, cf. also Sec. 11.2.
Formalisms used for test specifications In most of the considered case studies,
the formalism used for the test specification and the formalism for the test model
are identical. Here, we brief the list of formal notations used in the case studies.
• Conference Protocol [BFdV + 99]: Since in this case study only stochastic
test specifications are used where a random number generator selects the
test cases, a special additional formalism is not necessary, but configuration
parameters concerning input and output gates or the random number
generator have to be defined.
• Smart Cards - CEPS [CJRZ01]: Test model and test specification are expressed
in the Input/Output Symbolic Transition System (IOSTS) formalism.
• SDU of ST100 DSP [DBG01]: Here first the MµALT (Modeling micro-
Architecture Language for Traversal) language is used. A coverage model
is basically determined by adding special attributes to interesting signals or
variables. These test constraints restrict the way targeted states are reached.
Second, the test generation tool GOTCHA (Generator of Test Cases for
Hardware Architecture) is used for generating test cases as execution paths
to the state coverage task and continuing to a final state.
• POSIX/Java [FHP02]: GOTCHA and its definition language (GDL) are used
to describe a set of coverage criteria and test constraints to form the test
specification. As in [DBG01], GOTCHA is also used for test case generation.
• PowerPC [FKL99]: A tool named Comet which is developed at IBM is used.
The definition of the coverage model is written in SQL.
• Cache Coherency Protocol [KVZ98]: In this case study different formalisms
for test model and test specification are used. LOTOS is used for the test
model. Automata in Aldebaran format are used for the test specification.
Both are inputs for the test case generator TGV.
• Smart Cards - WIM [PPS + 03]: The CASE tool AutoFocus is used where
graphical description techniques that are loosely related to the notations of
UML-RT form the test model and test specification. For test case generation,
the test model and the test specification are automatically translated to CLP
(constraint logic programming).
• Microprocessors [SA99]: FSMs where interesting control states and interesting
events as state associative control signals are specified, from the test
specification. The formalism used therefore is not mentioned.
15.6 Abstract Test Case Generation
This section covers the different methods used for test case generation in the
case studies reviewed in this chapter, assuming that a test model of the SUT
and a formal description of the test specification are available. Clearly, whenever