Lecture Notes in Computer Science 3472

450 Wolfgang Prenninger, Mohammad El-Ramly, and Marc Horstmann
existing tools are used, there is not much freedom in selecting a test case generation
method, as the study is then constrained by the methods supported by
the tool. All the methods used employ some search algorithm(s). The output of
a test case generation algorithm is a suite of abstract test cases that still need to
be instantiated as described in the next section. In the following we elaborate on
the different methods used for test case generation in the case studies reviewed.
We focus on the methods and tools not covered in Sec. 14.2.
In [SA99], the authors used their own system prototype for test generation.
The prototype enumerates all the possible paths on the FSM (i.e. the test model)
of the SUT of a given finite length. Despite the small size of the FSMs extracted
in this case study, it is infeasible to enumerate all possible state transition paths
from the initial state due to the presence of loops. Each generated path is an
abstract test case, consisting of a sequence of processor instructions with different
events at different stages. In this study, two types of abstract test cases were
generated: snapshot and temporal test cases. In a snapshot test case the exact
timing of events is considered, while in a temporal test case, only the order of
events matters.
Abstract Test Case Generation Using TGV As indicated in [CJRZ01] and
[KVZ98], TGV was used for abstract test case generation in these two studies.
TGV outputs a test case DAG (Directed Acyclic Graph). The paths of this
DAG represent possible system runs of the SUT. Detailed discussion of TGV is
in Sec. 14.2.10.
Abstract Test Case Generation Using GOTCHA In [DBG01] and [FHP02], the
process of test generation is automated by GOTCHA [HN99], which explores the
state space described by the input GDL model. The test engineer has several
alternative test generation strategies, including performing breadth-first search
and coverage-directed search, from each of the start states. Coverage-directed
search involves giving priority to exploring states that lead to new coverage tasks.
Coverage is a measure of the completeness of a test suite, i.e., the percentage
of a program exercised by the test suite. This will typically involve collecting
information about which parts of a program are actually executed when running
the test suite in order to identify which branches of the conditional statements
have been taken. The most basic level of test coverage is code coverage testing
and the most methodical is path coverage testing. A coverage task is a task
specified in the test specification that the test suite must satisfy. This is done
by including in the test suite a set of test cases that satisfy the task. Coveragedirected
search aims to find paths through the FSM model that satisfy each
coverage task. To do so, GOTCHA starts by constructing a search tree that
explores the entire state space. This is done by traversing all the reachable
states of the FSM model. After enumerating the entire reachable state space, a
random coverage task is chosen from those that have not yet been covered or
proved to be uncoverable. A test case is generated by constructing an execution
path to the coverage task (state in this case) then continuing on to a final state.
At the point when the recommended test length is exceeded or a final state is