Lecture Notes in Computer Science 3472

12 Technology of Test-Case Generation 347
– Calculate the identification traces and the postamble after the “critical
invocation”: The identification trace consists of one or more operations
to be executed in order to observe the behavior of the system after the
critical step. The postamble trace is a sequence of operations that resets
the state machine to the initial state from where new test cases can be
again searched for.
It is then possible to concatenate the preamble trace with the critical invocation
traces with the identification traces. The remaining symbolic parts
of the traces are finally fully instantiated in order to generate real test case
scripts that can be applied to a concrete implementation of the application.
While trying to discriminate the verification techniques used in this framework
we can identify clearly the usage of symbolic execution, but also of theorem
proving since a logic programming language (i.e. a theorem prover )isusedto
calculate the boundary states.
The second example on model-based test case generation we will discuss is
presented by Pretschner et al. in [PPS + 03]. This approach also relies on a CLP
tool to symbolically execute the abstract specification of the system. The application’s
state space is then searched for symbolic traces that can be instantiated
to form interesting test cases.
The specification model used in this case in the one used by the AUTOFO-
CUS CASE tool - inspired from UML-RT (UML for Real-Time systems), especially
directed towards the development of embedded systems. In this paradigm
the system’s structure is defined as a network of components. Each of the bottom
level component’s behavior is described by a state machine. Composition of the
bottom level state machines generates higher level state machines and so on until
the full system’s state machine is reached. As in the previous example, states
are defined by state variables and the transitions are possible via commands (or
operations) that are issued to the system.
Before describing how the test cases are generated, it is useful to mention that
the authors of the approach consider different kinds of coverage of the execution
state space. In [PPS + 03] they describe three different coverage classes:
• Functional coverage: this sort of coverage implies generating test cases that
exercise precise execution scenarios given in the specification. Both positive
as well as negative test cases are interesting to validate the system;
• Structural coverage: structural criteria implies for example issuing sequences
of commands that selectively test critical components of the system. Another
example is the coverage of states that may be considered dangerous or unsafe;
• Stochastic coverage: using this approach random traces are generated through
the execution state space of the application. Despite the search not being
directed, this sort of coverage may still produce relevant test cases.