Information Technology Reference
In-Depth Information
not enough information to control the system under test. In this example all
controllable actions have been removed since no state satisfies condition (4), i.e.,
in every state a controllable action may be disabled. Such a system model is
restricted to monitoring the behavior of an implementation.
In the following section we discuss the test case extraction from the product
LTS.
6TtCeExon
From the resulting product LTS, which will be referred to as
test graph
in the
following, test cases that aim at detecting the mutation can be generated. Note
that in order to generate proper test cases, the labels in the test graph are
divided into two categories: (1) Observables (keyword
obs
) denote actions that
are observable by the tester, i.e., they denote outputs of the implementation
under test. (2) Controllables (keyword
ctr
) denote actions that are controllable
by the tester, i.e., they denote inputs of the implementation under test.
The resulting test cases must fulfill certain properties in order to form valid
ioco test cases. One characteristic is
controllability
, which means that a test case
must not contain choices between several controllables or between controllables
and observables. Furthermore, each final state of the test case has to be la-
beled with a verdict, which can be
pass
,
fail
,or
inconclusive
. Pass means that
the implementation has successfully passed the test case. Fail denotes that the
implementation does not conform to the specification. Fail verdicts may be ex-
pressed implicitly by defining that each unspecified behavior causes a fail verdict.
Inconclusive says that the implementation behaved correctly but that the goal
of the test case, the so-called
test purpose
, could not be reached. A test purpose
describes what shall be tested by the test case. In our case, the test purpose is
to pass so-called
unsafe states
. An unsafe state denotes the direct predecessor of
a fail state of the test graph, which indicates a mutation. If a fail state cannot
be reached any more, i.e., if its unsafe state has been passed and the fail state
has not been reached, then the fault injected into the mutant used for test case
generation could not be identified in the implementation by the test case. In
this case, the verdict has to be pass. Note that the verdicts of the test cases are
assigned during test case extraction. They are not specified by the pass and fail
states generated throughout the product calculation described in the previous
section.
There exists more than just one approach to extract test cases that detect the
injected fault from a given test graph. Describing all of them in detail would go
beyond the scope of this paper. Hence, in the following we will only outline sev-
eral of our ideas for selecting test cases from our test graph. Our first approach,
called
A1
in the following, is to unfold the test graph and subsequently select one
controllable test case for each unsafe state in the resulting tree. The extracted
test cases have a special structure. They consist of one main branch representing
the path to the unsafe state. All other branches not leading to the unsafe state
are cut right after one observation and terminated via an inconclusive verdict.
This is also illustrated by our example test case depicted in Figure 10 . This test
