Test Case Design Based on Z and the Classification-Tree Method*
Harbhajan Singh, Mirko Conrad, Sadegh Sadeghipour
Daimler-Benz AG, Systems Technology Research (F3S/K)
Alt-Moabit 96a, D- 10559 Berlin, Germany
e-mail: { singh Iconradlsadegh} @DBresearch-berlin.de
Abstract
Software testing often consumes up to 50 percent of the
overall software costs. A large amount of time and money
within the test process is spent due to incomplete, inconsis-
tent or ambiguos informal specijications of the test objects.
A more formal approach to the early phases of software de-
velopment can reduce the error rate drastically and, in ad-
dition, can signijicantly improve the central testing activi-
ties like test case design and test evaluation.
This paper presents an approach for generating test
cases from formal specijications written in Z by combin-
ing the classijication-tree method f o r partition testing with
the disjunctive normal form approach. Firstly, a classijica-
tion tree describing high level test cases is constructed from
the formal specijication of the test object. Then the high
level test cases are further rejined by generating a disjunc-
tive normal form for them. The rejined test cases obtained
this way cover all specijied aspects of the system explicitely
and also contain all information necessary to evaluate the
test results. The proposed combination of the classijication-
tree method with the disjunctive normalform approach pre-
serves advantages of both methods, overcomes most of their
limitations, and can be supported by tools.
1. Introduction
An objective of software testing is to find errors in the
test object by executing it with selected test data. Test-
ing is the primary method through which the producer of
software and the user or customer gain confidence that the
software will work as intended or specified. A thorough
test which does not find errors can provide increased justifi-
cation for confidence in the correctness of the test object
[6, 81. Testing, especially in projects concerning safety-
critical systems, consumes up to 50% of the overall costs
*This work was partially supported by the German Federal Ministry
of Educauon, Science, Research and Technology (ESPRESS project 01 IS
509 A)
81
0-8186-8002-4/97 $10.00 0 1997 IEEE
for software. Therefore, a cost-effective test process is de-
cisive in industrial competition.
A systematic test of a test object on the basis of its spec-
ification (black-box test) starts with the design of relevant
test cases. A test case describes a certain input situation
to be tested by comprising a set of input data. That is, it
abstracts from concrete test data and defines them, only in
so far as it is required for the intended test. During test
data generation concrete test data are defined for the test
cases. Determining the expected results for these test data
constitutes expected results prediction. Output values are
determined by running the test object with the test data dur-
ing test execution. Test evaluation eventually comprises the
comparison between actual and expected values [6].
Especially in the area of safety-critical systems, the use
of formal methods for the development of software is highly
recommended by standards and legal requirements. These
methods promise high product confidence because the pre-
cision of specifications written in a formal specification lan-
guage forces specifiers to express requirements and design
decisions in a clear and unambiguos manner. However, a
post-developmental validation through testing is indispens-
able, and the use of formal methods can improve the soft-
ware test. The formal specification of the test object forms
the basis for a systematic design of test cases, test data gen-
eration, and test evaluation. Since it contains all the infor-
mation necessary for the central test activities, these steps
can be highly automated.
Observing that the test process can profit by using formal
specifications and that test case design is the most important
prerequisite for a thorough software test, there have been
quite a few attempts [ 1, 12, 171 in the recent past to gener-
ate test cases on the basis of formal specifications written
in the specification language Z. The methods used in these
papers are based on partition testing [15]. Some authors
[9] have compared this method with random testing and
doubted its usefulness. Based on a quantitative model for
computing the fault detection probability of a given strat-
egy, they have shown that partition testing is not worse than
random testing, provided some conditions concerning the
structure of the partitioning are fulfilled. This would not
justify the overhead of partitioning and of keeping track of
which subdomains have been tested or not. However, fur-
ther analyses of the relationship between partition and ran-
dom testing have shown that partition testing can be much
better than random testing, again according to the quanti-
tative model mentioned above, if the subdomain definitions
are fault-based [20, 21. This means that the effectiveness of
a particular partition testing strategy depends on how well
that strategy groups together the failure-causing inputs. We
believe that regardless of any quantitative model for confi-
dence in the software, a solid basis for such a confidence can
only be provided if all the requirements have been checked
systematically. This cannot be achieved by random testing
or a pure fault-based partitioning. Furthermore, a test strat-
egy based on random testing only could be catastrophic for
safety-critical systems because there is no guarantee that the
input data relevant for safety-critical aspects are actually se-
lected. This point is also true for a test which is only based
on failure-causing inputs.
Concerning the above considerations, we took partition
testing as the basis of our approach to the systematic de-
termination and description of test cases for a test object
based on its formal specification written in Z. Any imple-
mented operation, whose specification is given by a Z op-
eration schema, can be considered to be a test object. The
approach uses the classification-tree method (CTM) [6] and
the idea of partitioning the input domain by using a trans-
formation into a disjunctive normal form (DNF) [5,4].
The following section describes the original approaches,
the classification-tree method, and the disjunctive normal
form approach, and motivates their combination. In sec-
tion 3, the chosen concept for test case design is explained
and applied to this example on the basis of its Z specifi-
cation. The main steps of this concept are summarized in
section 3.1. Section 4 characterizes the envisaged tool sup-
port based on the existing classification-tree editor (CTE).
Finally, section 5 summarizes the report and gives an out-
look to future work.
2. Combining the Classification-Tree Method
with the DNF Approach
2.1. The Classification-Tree Method
The classification-tree method [6] is a special approach
to (black-box) partition testing partly by using and improv-
ing ideas from the category-partition method [15]. It has
been used successfully in various application fields of the
Daimler-Benz Group. In the classification-tree method, the
input domain of a test object is analysed on the basis of its
functional specification with respect to various aspects con-
sidered to be relevant for the test. For each aspect, disjoint
82
and complete classifications are formed. Classes resulting
from these classifications may be further classified itera-
tively. The stepwise partition of the input domain by means
of classifications is represented graphically in the form of
a tree. Subsequently, test cases are formed by combining
classes of different classifications. This is done by using
the tree as the head of a combination table in which test
cases are selected appropriately.
The use of the classification-tree method will be ex-
plained by giving an example. The test object is a simpli-
fied part of the discrete control logic of a speed and distance
control system (SpeDi) for individual vehicles. SpeDi is an
adaptive cruise control system which supports the driver of
the controlled car by maintaining the desired speed of the
controlled car and a safe distance between the controlled
and a preceding car [ 141.
Figure 1. Speed and distance control system
(SpeDi): Fanning the road (left) and cruise
control switch.(right)
The road in front of the vehicle is fanned by infrared
beams in search of vehicles ahead as shown in Figure 1. As
long as no vehicle is detected, SpeDi provides an ordinary
speed control function, i.e. driving at the speed set by the
driver. If a vehicle is detected in front, the system automat-
ically switches to the distance control mode. It forces the
controlled vehicle to drive at the same speed as the preced-
ing vehicle at a safe distance. As long as the distance be-
tween the two vehicles is uncritical, the behaviour of SpeDi
in the distance control mode is the same as in the speed con-
trol mode. SpeDi is controlled by the cruise control switch
(Figure 1) located near the steering wheel. The driver can
define the current speed as the desired speed either through
the Set+ or Ser- command. With each subsequent use of
Set+ or Set-, the desired speed is incremented or decre-
mented, respectively, by a fixed amount. Off switches the
system off, and Resume retrieves the last desired speed.
A possible classification tree for generating test cases on
the basis of this informal specification is shown in Figure 2.
The root of this tree is the complete input domain of the
control software corresponding to the above specification.
The possible inputs for this software are data regarding a
vehicle in front and the control switch. Appropriate classi-
fication aspects in this case are, for example, the position of
the control switch and the presence of a vehicle ahead. The
classification based on the aspect “control switch?’ leads
to a partition of the input domain into sub-domains where
this switch has one of the positions Set+, Set-, Resume, or
Of. The classification based on “vehicle in front?’ results
in two classes - one with no vehicle ahead and the other
with a vehicle ahead. The class with a vehicle ahead can
be further classified under the aspect “distance between two
vehicles critical?’.
yes no
Test case
1
2
3 Applying these rules to a schema predicate leads to
4
Figure 2. A classification tree for SpeDi
In the combination table associated with the classifica-
tion tree, each row represents a test case. Some possible
test cases are shown as examples. The first test case (rep-
resented by the first row of the combination table), for in-
stance, describes the test in which a vehicle is in front of the
controlled vehicle, the distance between the two vehicles is
critical, and the control switch is in position Set+.
2.2. The D N F Approach
The disjunctive normal form approach is widely used [5,
4, 19, 1 1, 131 for generating test cases on the basis of formal
specifications. A disjunctive normal form of a predicate is a
disjunction of the conjunctions of the different components
of the predicate. In the following, the disjunctive normal
form approach will be illustrated when it is applied to Z
specifications. Thereby, it will be assumed that the reader
is familiar with the Z notation and its usual conventions for
the specification of sequential systems [ 161.
Let S denote the operational specification schema of the
test object which is the basis for the test case design. The
basic idea is to split S into a smaller set of sub-schemas
(SI, S 2 : .. .) whose disjunction is equivalent to the original
schema:
s 2 s , v s 2 v ... v s , v ... VS,.
These individual sub-schemas are the different test cases in
this approach. Each such test case may contain a number of
medicates which are coniugated. For examole. the test case
83
Si may look like this:
SI = [Signarure I Pil A Pi2 A . . . A Pi,].
h
The splitting of the original specification schema into its
disjunctive normal form can be carried out by transforming
its predicates by using a suitable rewriting system as des-
cribed in the following.
The main task in the disjunctive normal form approach
is to choose a suitable, i.e., a terminating and confluent,
rewriting system for performing required transformations
automatically. In such a rewriting system [4], the follow-
ing three groups of rules can be distinguished:
The first group consists of rules transforming Z expres-
sions, which are not in the syntax of regular predicate
logic, into formulas in regular predicate logic, e.g.:
E = if P then F1 else Fz t
( P A E = F1) V ( - P A E = F z ) .
The second group consists of rules distributing quanti-
fiers with respect to logical connectors, e.g.:
V x : A P A Q k (Vx : A P ) A ( V x : A a Q),
-(Vx:A.P) t 3x:A.-P.
formulas which can be handled in propositional logic.
T h i s means that each quantified formula can be con-
sidered to be a proposition.
The rules in the third group of the rewriting system
transform propositional logic formulas into a disjunc-
tive normal form. Such rules are, e.g.:
P+Q b ~ P V ( P A Q ) ,
P- Q k (PAQ)V(-PA-Q),
P A ( Q V R ) b (P A Q ) V ( P A R ) .
As a result of such transformations of the schema predi-
cates, the specification schema contains disjunctions of the
conjunctions of the schema predicates. The splitting of this
schema into its disjunctive sub-schemas is carried out by
simply using a Z calculus rule, according to which predi-
cate operators can be converted into schema operators. The
schema S, for example,
S [SigiznfureI ( P I V Pz V . . . V P, V . . . V fn)A Rest]
can be split as S e SI V Sa V . . . V SI V . . . V S,,, where
S, [Signature 1 P , A Rest]. Here each SI represents a
DNF test case.
2.3. Discussion
The classification-tree method is well suited for tool sup-
port since it decomposes the test case design process into
several steps which can be supported individually, allowing
the tool to guide the user appropriately. It offers a natu-
ral way of using semantic information during test case de-
sign through a suitable choice of classification aspects and
classes. Furthermore, it makes use of a graphical notation
which is well suited for visualization in a modem graphical
user interface. It can, however, happen that the test cases
obtained with the classification-tree method are not detailed
enough for the uniformity hypothesis [3] to be applicable'.
This can happen if some classification aspects are hidden
at the first sight of the specification. It is especially im-
portant to unfold all classification aspects of fault-causing
inputs. Such aspects become apparent when one test case at
the classification tree level results in multiple test cases af-
ter transformation in a disjunctive normal form. Therefore,
some aspects or parts of the software can remain untested
with test cases from the classification-tree method. More-
over, these test cases do not necessarily contain information
for evaluating the test results.
A significant advantage of the DNF approach is that it
is purely syntax based and, therefore, can be automated in
a straightforward way for formal specifications. The test
cases obtained cover all the specified aspects of the software
explicitly. Furthermore, these test cases contain all the in-
formation available from the formal specification about the
input as well as the output of the test object. On the other
hand, this approach as such has important shortcomings. In
the following, we discuss these shortcomings and suggest
means to overcome them.
e Inconsistent test cases: A test case is inconsistent if
at least two of its predicates have a common variable
and the set containing the solution elements for these
predicates is empty. Many inconsistent test cases are
generated during the process of generating a disjunc-
tive normal form - even if the original schema is free
from any inconsistencies. Therefore, the generated test
cases must be analysed to identify inconsistent ones
which are then discarded. In order to identify incon-
sistent test cases on the basis of an empty solution set,
all possible inputs must be tried. As this problem is
not decidable, some simple heuristics and rules can be
used to obtain a solution [13]. A family of rules in
this connection are rules expressing special syntactical
and semantic knowledge leading to the simplification
of the generated formulas. Such simplification can re-
sult in recognizing the inconsistent test cases automati-
cally. A rule of this category is, e.g.: P A ( P V Q)t- P .
e Semantically indisjoint test cases: The test cases gen-
erated by using the rewriting system described in sec-
tion 2.2 are in general not semantically disjoint. This
can lead to the fact that the test data derived from dif-
ferent test cases only test a common portion of the in-
put domain for these test cases and that the remain-
ing input domain remains untested. To overcome this
'According to the uniformity hypothesis, if a test object passes the test
for one value of the sub-domain, it passes the test for all the values of the
sub-domain.
84
problem, the disjointedness of the generated test cases
must be achieved. This is done by extending the rewri-
ting system for a DNF to generate a canonical disjunc-
tive normal form. The idea [4] is based on the natural
partitioning of the union of two arbitrary sets:
A U B = (A f l B ) U ( A f l B )U ( A f l B ) ,
whose syntactical counterpart in propositional logic is
the following rule:
PV Q b ( P A Q) V (7 P A Q) V ( P A 7 Q),
The or connector (V) on the right side of this rule is, in
fact, an exclusive or operator. It can be seen easily that
if a schema is a disjunction of m conjunctions, then
the application of the above rule results in a canonical
DNF with '2" - 1 conjunctions. Therefore, to reduce
a combinational explosion, all possibilities for reduc-
ing m (e.g., through simplification of terms, through
recognition and discarding of inconsistent predicates)
should be exploited before the application of this rule.
Unstructured test cases: The test cases in the DNF (as
well as in the canonical DNF) approach are completely
unstructured [ 171 as they all are generated at the same
level. There is no schematic graphical representation
to guide the user with respect to the relation between
the test cases and the corresponding input domain. We
propose to overcome this shortcoming by combining
the canonical DNF approach with the classification-
tree method (see section 2.4).
In the following, the canonical disjunctive normal form ap-
proach will be used, i.e., hereafter DNF stands for canoni-
cal disjunctive normal form. Dick and Faivre [4] have sug-
gested a rewriting system for transforming VDM predicates
in disjunctive normal form and for simplifying them. We
plan to adapt their system for Z specifications and to im-
prove it by introducing relevant rules for making it more
powerful in recognizing inconsistent test cases.
2.4. Combination
The major shortcoming of the disjunctive normal form
approach lies in its completely unstructured test cases. This
is shown schematically on the left side of Figure 3 where the
outermost rectangle represents the semantics of the whole
schema under consideration, and each small square within
this rectangle represents a different test case in the DNF ap-
proach. These test cases are all at the same (the lowest) level
of complexity and cannot be refined further. Moreover, the
number of generated test cases quickly becomes very large
so that the whole process gets complicated for a user. Es-
pecially, there is no guidance to find the relevant test cases
for a particular input domain, the input domains not tested
so far, and whether or not a particular (for instance safety-
critical) input domain has been thoroughly tested.
 I rU 6mt IewI At m d 1-
PI P2 qf qz
I 1
sA(P *PI) - described at first. This concept is then applied to generate
Figure 3. Classification of DNF test cases
These shortcomings can be overcome by combining the
disjunctive normal form approach with the classification-
tree method. The key point is to establish a direct link be-
tween the input domain and the DNF test cases by overlay-
ing the DNF partitions with a hierarchical partition of the
input domain. The criteria for a hierarchical classification
of the input domain should be important semantic charac-
teristics of the schema variables. Such characteristics are
used as the classification aspects in the classification-tree
method. In Z schemas, characteristics of the schema vari-
ables are expressed through their predicates.
For example, let a specification of a test object be char-
acterized by a Z schema S whose predicate part is P V Q,
where P and Q represent disjoint sets. Furthermore, assume
that P = p l V p2 and Q = ql V 92 V 93 where each sub-
predicate can be further split into lower level sub-predicates
until the resulting sub-predicates are atomic. The DNF test
cases for this schema are represented by dotted squares in
Figure 3 on the left. The outermost rectangle representing
schema S also represents the whole input domain of the test
object. A classification of this input domain into two sub-
domains at the first level of hierarchy is described by the
predicates P and Q in Figure 3 on the left. Each of these
sub-domains can be further partitioned at the second level
of hierarchy through the predicates p l , p2 and q l , q2, q3,
respectively.
The classification tree offers a clear, graphical and hier-
archical structure for such a partition of the input domain
whereby the basis of the classifications are the predicates in
Z, as shown in Figure 3 on the right. The original schema
together with the constraining predicates of a selected test
case can be finally transformed into a disjunctive normal
form as discussed in the two technical possibilities below.
The correspondance between the test case S A ( Q A 42)
and its DNF test cases is indicated by an arrow in the mid-
dle of Figure 3. In contrast to the test cases in the original
classification-tree method, the test cases obtained here are
refined and contain information, i.e. predicates over state
and output variables, for evaluating the test results. In the
following, the test cases generated with the classification-
tree method alone are called high level test cases; test cases
generated by using the DNF approach are, accordingly,
called rejned test cases (or atomic test cases because they
cannot be further refined).
3. Test Case Design Based on Z Specifications
q3
I In this section, our concept for the test case design is
test cases for a part of the adaptive cruise control system
(see section 2.1) on the basis of its specification written in
Z.
3.1. Concept
A central point of our concept for the test case design
on the basis of Z specifications is the combination of the
classification-tree method and the disjunctive normal form
approach. Furthermore, a maximum use of the automation
potential offered by Z specifications is envisaged: Firstly,
a concept is presented for constructing a classification
tree semi-automatically. Secondly, it is shown, how to
get Z specifications of high level test cases automatically
from such classification trees. Thirdly, a method based on
the contents of section 2.4 is outlined for combining the
disjunctive normal form approach with the classification-
tree method. The main steps for the test case design are
summarized at the end.
Classification-tree construction. Any implemented
operation, whose specification is given by a Z operation
schema, can be considered to be a test object. The input
domain of the Z operation schema is analysed according
to the different classification aspects for partitioning this
domain. The basis of such classification aspects are
test-relevant properties of the schema variables. These
properties are expressed in the schema signatures and
schema predicates. For example, if a schema contains a
predicate P. a classification aspect is whether P is true
or false. Accordingly, the corresponding classes for this
classification are P and P. With complex predicates, such
7
classifications can be carried out iteratively. Therefore,
different classification aspects and their classes can be
determined automatically by using syntactical and semantic
information about the schema variables. The syntactical
information is fully contained in the formal specification.
For the semantic information, for instance, on standard data
types, an appropriate knowledge base can be used.
A formal specification can lead to classification trees
with different structures depending on
0 the order in which different classification aspects are
considered, and
0 the nodes, the resulting classifications are attached to.
This determines, for example, if the generated tree
grows more in width or in depth.
85
The structure of a classification tree has a decisive effect
on the quality and the number of the generated test cases.
Moreover, the number of inconsistent test cases may be
much larger in a classification tree with one structure as
compared to the other. Consequently, well-considered de-
cisions must be taken with respect to both the points listed
above. For that, first of all, all the test-relevant semantic
knowledge about the specification is required. Furthermore,
some general heuristics xv and strategies are needed for us-
ing this knowledge to generate an appropriate classification
tree for the given specification. Until such a knowledge base
and heuristics/strategies are developed, this role can be per-
formed by the user, who is generally well informed about
the specification.
Classification Tree
Figure 4. Concept for a semi-automatic gen-
eration of a classification tree
Our approach for a semi-automatic classification-tree
construction is depicted in Figure 4. The source for syn-
tactical information is the formal specification of the test
object, and a source for semantic information is an appro-
priate knowledge base. The user can supplement both of
these pieces of information. Furthermore, some general
strategies and heuristics are required to generate meaning-
ful classification trees. Based on all this information, the
system would generate a classification tree which could be
modified by a user.
For software validation, it is often important to test
certain situations which are not explicitly taken into
account in the original specification. Our concept also
allows the consideration of such validation tests during
the test generation phase. The user can define arbitrary
test-relevant classification aspects and the corresponding
classes in the classification tree under consideration. In
order to be integrated with the rest of the classes, these
classes must also be formally defined through predicates in
Z.
Specification of high level test cases. In the
classisification-tree method [6], test cases are defined
86
through a systematic combination of leaf classes by using
a graphical combination table. The test cases can be
specified either by the user or automatically. The aim is
to have maximum coverage of the functionality of the test
object with a minimum possible number of test cases. An
automatic selection can be based on different strategies
such as selecting each class at least once or selecting all
logically possible combinations of classes of different
classifications. The first strategy, for example, can be
supplemented through an intensive selection of those
classes which are related to safety-critical aspects in the
software. An automatic selection of the test cases should
be regarded as a proposal for the user who can change the
selected test cases according to his choice.
The classification tree obtained on the basis of a for-
mal specification is entirely formal since the individual
classes are characterized by formal predicates. Therefore,
the formal descriptions of the selected test cases can
be automatically generated in a straightforward way by
conjugating the predicates of the selected classes (see
section 3.2). During this process, it should be possible to
recognize most of the inconsistent test cases automatically
through an appropriate simplification mechanism.
Generation of refined test cases. In the classification-tree
method, the power of the strategies used and the skills of
the tester determine whether or not all the possible classifi-
cation aspects have been identified and appropriately used.
Consequently, the high level test cases generated by using
this method may not be always detailed enough so that it
could be necessary to refine them further. Moreover, they
may not contain any information about the output variables
and the (input or state) variables which do not appear in
the classes considered. Such information is needed for
a complete specification of the input state and for the
evaluation of the test results. These shortcomings can be
overcome automatically by supplementing each selected
test case with the original schema of the test object since
this schema contains all the information about the test
object.
To illustrate this, let the classes selected for a test case in
the classification-tree method be characterized by the pred-
icates p and q. Then the corresponding high level test case
is characterized by the predicate p A q. The corresponding
complete specification schema for this test case is given by
Testcase E spec A [Signature I p A q],
where Signature is the signature of the specification schema
Spec for the test object. The resulting schema TestCase
is then transformed into the disjunctive normal form to
get fully refined test cases. The process of generating re-
fined test cases from a selected high level test case in the
classification-tree method, therefore, involves the following
steps:
 0 Conjugate the specification schema of the test object
with the predicates characterizing the selected high
level test case and simplify the resulting schema to get
the complete schema for the selected test case.
0 Transform the test case schema into (canonical) dis-
junctive normal form to get refined test cases which
also contain information for the evaluation of test re-
sults.
To carry out these steps efficiently, powerful strategies and
rewriting rules are required (as discussed in section 2.2
and 2.3). Otherwise, the number of refined test cases soon
becomes very large. At each step, full potential for the
simplification of the resulting schemata, especially with
respect to recognizing the inconsistent test cases, should be
used.
Main steps for test case design. Summarizing our
concept for test case design for a test object on the basis of
an operation schema in Z, as described above, leads to the
following main steps:
1. Identify the test-relevant variables for the test object on
the basis of the signature of its specification schema.
2 . Design classification aspects for these variables on the
basis of their signatures and characterizing predicates
in the schema.
3. Generate classes for each classification aspect as con-
crete instances of the predicate used for designing the
corresponding classification aspect.
4. As a class can be partitioned further with respect to a
new classification aspect, repeat steps 2 to 3 iteratively
until the classifications of the important and relevant
variables are treated to the desired level of refinement.
5. If necessary, supplement the classification tree ob-
tained with classification aspects and classes, whose
predicates are not contained in the specification
schema of the test object.
6. Select appropriate (high level) test cases in the combi-
nation table of the classification tree by selecting at the
most one class out of each classification.
7. Conjugate the specification schema with the predicates
characterizing the selected high level test case and sim-
plify the resulting schema to get the complete schema
for the selected test case. Discard the test case if it is
found to be inconsistent (section 2.3).
8. Transform the consistent test case schema into the
canonical disjunctive normal form to get refined test
cases and analyse them to remove inconsistent test
a7
cases. These test cases also contain information for
the evaluation of the test results.
As a Z specification contains most of the information re-
quired for the above activities in a formal way, all these ac-
tivities can be automated to a large extent.
3.2. Application to an Adaptive Cruise
Control System
To illustrate our concept for designing test cases on the
basis of Z specifications, relevant parts of the adaptive
cruise control system SpeDi are formalized first in Z.
Then a classification tree is constructed (steps 1 to 4 in
section 3.1) on the basis of this specification and a high
level test case is selected (step 6). Finally, refined test cases
are generated (steps 7 and 8) for this test case.
Formal specification of SpeDi in Z. The behaviour
of the SpeDi controller depends on the value of the control
switch, the speed of the controlled car, whether or not a
vehicle is detected in front of the controlled car, and the
internal state of SpeDi. To concentrate on the illustration
of our concept of test case design, only a part of the control
logic is formalized, and the internal state of SpeDi is
neglected. The four positions of the control switch are
modelled by a free type [ 161
Switch ::= Set+ 1 Set- 1 Resume I Of.
For safety reasons the SpeDi controller is not allowed to be
active if the speed of the controlled car is less than 40
or higher than 160 9.
This is described by defining the
admissible speed for the SpeDi controller as:
AdmissibleSpeed == { v : Speed I 40 p 5 v 5 160 }.
The speed and distance controllers are considered to be
black boxes and are represented only by the signatures of
their respective transfer functions SC and DC:
SC : Speed x opt Speed + Acceleration
DC : Speed x opt Speed x apt BeamData +Acceleration
The speed controller can be viewed as a function which cal-
culates the required acceleration from the actual speed of
the controlled car and the speed desired by its driver. Since
the desired speed is not always defined, it is modelled by
an optional data type optSpeed2. The distance controller
becomes active when a vehicle is detected in front of the
controlled car (expressed by the schema VehicleInFront in
schema SpeDiControl below) by the infrared beams. The
corresponding function calculates the required acceleration
by giving additional consideration to the optional data (de-
scribed by the schema BeamData in schema SpeDiControl
below) about the detected vehicle. No further information
about VehicleInFront and BeamData is required. Based on
these definitions, the main behaviour of the SpeDi control
logic can be modelled by using three simple rules:
0 If the speed of the controlled car is not admissible, nei-
ther the speed nor the distance controller provide any
* A variable of this optional type can have a defined value (any possible
speed) or can be undefined.
 value for the required acceleration, i.e., the optional
output areq!is not defined.
If the speed of the controlled car is admissible, if no
vehicle is detected in front, and if the speed is set by
the driver through the control switch, SpeDi is in the
speed control mode, i.e., aR4!is defined and its actual
value is determined by SC (def areq!as SC(v,,,: vdex)).
If the speed of the controlled car is admissible, if a
preceding vehicle is detected, and if the speed is set,
SpeDi calculates the required acceleration by switch-
ing into the distance control mode, i.e., areq!is defined
and its actual value is determined by DC.
These rules can be formally described by the following
Z schema where the three predicates formally specify the
three rules for the SpeDi control logic described above:
SpeDiControl
vcor : Speed
vder : opt Speed
Vehicle : opt BeamData
ControlSwitch'? : Switch
amy! : opt Acceleration
(wcor E AdmissibleSpeed A 7 VehiclelnFront A
(ControlSwitch? = Set+ V ControlSwitch'?= Set-) +
defarey!as SC(vcnr,v~/e.v))
(vCnrE AdmissibleSpeed A VehiclelnFront A
(ControlSwitch'? = Set+ V ControlSwitch? = Set-),+
def arey!as DC(v,,,; v , / ~ ,Vehicle))
~:
A classification tree on the basis of SpeDiControl.
The test-relevant schema parameters in the schema
SpeDiControl are vCur.VehicleInFront and ControlSwitch?.
Their properties are expressed by formal predicates which
are used to generate different classifications. The classi-
fication tree obtained is shown in Figure 5. The differ-
ent classes of a classification aspect are different predicates
which specify the given classification aspect in disjoint sit-
uations. As most of the information required is contained in
VI., e
Admiisiblespeed
- VI.. E
Vehic!dnFmni ?
Testcase 1 TRUE
I
FALSE
1
I
1 I
1 I I I
2 T 1 V
Figure 5. A classification tree for SpeDi on
the basis of its formal specification
the formal specification, this classification tree can be gen-
erated semi-automatically. However, the user can modify
this tree, for example, by defining validation-relevant clas-
sification aspects which are not explicitly contained in the
formal specification, e.g. the weather situation in the speci-
fication of SpeDi. Such classification aspects and the corre-
sponding formal classes could be inserted manually at any
desired position in the classification tree of Figure 5 and
would automatically be taken into account for further con-
siderations.
The high level test cases in the classification-tree method
can be selected by using different strategies (see sec-
tion 3.1). The formal description of the selected test cases
can be automatically generated in a straightforward way
by conjugating the predicates of the selected classes. For
example, Testcase4 in Figure 5 is characterized by the
predicate v,,, E AdmissibleSpeed A -- VehiclelnFront.
This test case neither contains information about the input
variable ControlSwitch? nor about the output variable areq!.
Furthermore, it is possible to partition this test case into
more detailed test cases as shown in the next section.
Refined test cases for TestCase4. In this section, it
is shown how to automatically generate refined test cases
corresponding to the high level test case TestCase4 (see
Figure 5).The complete specification schema for TestCuse4
is obtained by conjugating its characterizing predicate with
the original schema of the test object, i.e.,
Testcase4 SpeDiControl A [Signature
I v,,, E AdmissibleSpeed A 7 VehiclelnFront].
where Signature is the signature of SpeDiControl. This
schema can be simplified to the schema:
-TestCase4
Signature
vCRrE AdmissibleSpeed A -, VehiclelnFront
((ControlSwitch'?= Set+ V ControlSwitch'? = Set- V
ControlSwitch'? = Resume j ) d e f a,q! as SC(v,,,. " d e i ) )
Applying transformation rules for implication and for gen-
erating a canonical disjunctive normal form, this schema
can be transformed into the following form:
(vcor E AdmissibleSpeed A 7 VehiclelnFront A
ControlSwitch'? = Set+ A def areq!asSC(v,,, v<les))
V
(vcor E AdmissibleSpeed A 7 VehiclelnFronr A
ControlSwifch'? = Set- A def amy!asSC(v,,. w~/<~))
V
(vcorE AdmissibleSpeed A VehiclelnFront A
7
ConrrolSwifch? = Resume A d e f arey!as SC(vcur.v,ler))
V
(vCorE AdmissibleSpeed A 7 VehiclelnFront A
I
ControlSwitch? # Set+ A ControlSwitch'? # Set- A
I I
ControlSwitch? # Resume A def aEq!as SC(v,,, v,/<,))
(vcor E AdmissibleSpeed A VehicleInFronr A
7
ControlSwitch'? # Set+ A ControlSwitch'? # Set- A
ControlSwitch? # Resume A 7 d e f are#!asSC(v,,. vde.<))
Each of these five disjoint components for the high
level test case Testcase4 represents a different refined
88
test case. The first three of these test cases corres-
pond to the three test cases which could be selected in
the extended combination table of the classification tree
3f Figure 5 by marking the appropriate classes, such
that the predicates 1 VehiclelnFront, ControlSwitch? =
Set+ and 7 VehiclelnFront, ControlSwitch? = Set- and
-,VehicleInFront, ControlSwitch? = Resume are valid, re-
spectively. In this way, the combination of the DNF ap-
proach with the classification-tree method takes into ac-
count the classification aspects which are not explicitly con-
sidered in the classification tree. Furthermore, the refined
test cases contain explicit information about the output vari-
able areq!which can be used for the test evaluation. The
last two refined test cases lead to different output situations
for the same input situation. This is because the behaviour
of SpeDi in schema SpediControl is not specified for the (vex E AdmissibleSpeed A -.I VehkklnFrmt A
bntrdswitcb? =Set- A def a,q!ssSC(v,. v&))
case ControlSwitch? # Set+ A ControlSwitch? # Set- A
ControlSwitch? # Resume. In this way, the analysis of re-
fined test cases can help in recognizing specification flaws
like incompleteness.
Figure 6. The main window of the envisaged
extended classification-tree editor
4. Tool Support
user should be able to define new rules for the mathematical
As described above, the classification-tree method em- objects used in the specification.
ploys a graphical representation of the classification tree
The development of CTE will proceed in two directions.
and the corresponding combination table. In order to sup-
The first direction concerns the implementation of program
port this method, a syntax-directed graphical editor, named
and user interfaces as well as other facilities to handle Z
classification-tree editor CTE 171, has been developed at
specifications [ 181, e.g.:
the Systems Technology Research Center of Daimler-Benz.
This tool enables the tester to work interactively on the tree
and the combination table. The main window in the back- 0 Interface for reading Z specifications.
ground of Figure 6 shows a typical screen image of CTE. 0 User interface for specifying Z predicates as classifica-
The upper part of the window is the area in which a classifi- tions and classes including syntax and type checking of
cation tree can be drawn interactively. The lower part of the the given formulas.
window contains a table corresponding to the tree, in which
test cases can be selected. Additional textual annotations 0 A mechanism for describing test cases in Z through
can be added to classifications, classes and test cases. The conjunction of selected classes with the Z schema of
test case design can be documented by printing out the trees the test object.
and tables.
0 Interface with the tool for transforming Z predicates
It is planned to integrate the concept of test case design into DNF.
based on Z, as described in section 3, into CTE. A sepa-
rate tool will be implemented for transforming Z schemata 0 User interface to represent refined test cases.
into a DNF and for recognizing inconsistent test cases. This
tool will accept Z schemata as input and will transform them Figure 6 shows the main window of the extended envis-
into an abstract syntax as an internal representation. It will aged classification-tree editor where the combination table
contain a rewriting system to transform Z schemata into a is overlapped by a seperate window which contains the Z
DNF and a simplifier for recognizing inconsistent test cases specifications of the refined test cases for the high level test
[lo]. The simplifier will have an interface for defining new case TestCase4 of SpeDi (see section 3.2). With the aid of
rules because the power of the simplification strongly de- this window the tester can observe, scroll and analyse the
pends on the properties of sets, functions, and other pre- refined test cases. For example, the inconsistent test cases
defined data types used in the specification. Therefore, the which have not been recognized by the simplifier could be

89
discarded. Only valid and important test cases (for example,
according to the safety-critical aspects) could be included in
the list of the selected test cases.
The second direction of the extension of CTE concems the
semi-automatic classification-tree generation described in
section 3.1. The upper part of the window in Figure 6
contains the classification tree of SpeDi derived from its Z
specification described in section 3.2. The additional menu
point TreeGeneration with its sub-menus is meant to
support the user by generating classifications and classes.
5. Summary and Outlook
Test case design is the most crucial activity for a trustwor-
thy software test. As formal specifications contain most of
the information needed for black-box testing, we presented
a concept of automating test case design on the basis of Z
specifications. This concept results in a method which is a
combination of the classification-tree method and the dis-
junctive normal form approach. These two approaches are
combined in such a way that the resulting method contains
the advantages of both of them and also overcomes most of
their limitations. Furthermore, some ideas for automating
different steps of the presented concept were outlined.
The presented test case design method is based on an input-
based partitioningstrategy, enabling the user to test all func-
tional and safety requirements. However, at different levels
of test case design and test data generation, failure-based
partitioning [20,2] can and should be realized as well. The
user has the freedom to choose such a partitioning during
the design of high level test cases. For example, the part-
tioning of the domain of an integer variable into 0 and > 0
i s directed by the intuition of the tester that 0 might be a
failure-causing input.
The realization of the presented concept will semi-
automatically lead to refined test cases in the form of small
Z schemata for a given Z specification of the test object.
Based on such test cases, methods and tools for increasing
the automation potential for test data selection and test re-
sults evaluation shall be developed.
References
[ I ] N. Amla and P. Ammann. Using Z specifications in category
partition testing. Technical report, George Mason Univer-
sity, 1992.
[2] T. Y. Chen and Y.T. Yu. On the relationship between par-
tition and random testing. IEEE Transactions on Software
Engineering, 20(12):977-980, December 1994.
90
[3] P. Dauchy, M. C. Gaudel, and B. Marre. Using algebraic
specifications in software testing: A case study on the soft-
ware of an automatic subway. Journal of Systems and Sofr-
ware (USA),21(3):229-244, 1993.
[4] J. Dick and A. Faivre. Automating the generation and se-
quencing of test cases from model-based specifications. In
J. Woodcock and P. Larsen, editors, Proceedings of Formal
Methods Europe '93, volume 670 of LNCS, pages 268-284,
1993.
[SI J. S . Gourlay. A mathematical framework for the investiga-
tion of testing. IEEE Transactions on Software Engineering,
SE-9(6):686-709, November 1983.
[6] M. Grochtmann and K. Grimm. Classification trees for par-
tition testing. Software Testing, Verificationand Reliability,
3:63-82, 1993.
[7] M. Grochtmann, J. Wegner, and K. Grimm. Test case de-
sign using classification trees and the classification-tree ed-
itor. In Proceedings of 8th International Quality Week, San
Francisco, Paper 4-AA, 1995.
[8] P. A. V. Hall. Towards testing with respectto formal specifi-
cation. In 2nd IEE/BCS Con$ on Software Engineering '88,
1988.
[9] D. Hamlet and R. Taylor. Partition testing does not inspire
confidence. IEEE Transactions on Software Engineering,
16(12):1402-141 I , December 1990.
[lo] S. Helke, T. Neustupny, and T. Santen. Automating test case
generation from Z specifications with Isabelle. In Procced-
ings of Z Users Meeting '97, 1997.
[ I l l H. M. Horcher and J. Peleska. Using formal specifica-
tions to support software testing. Software Quality Journal,
4(4):309-328, 1995. ,
[ 121 G. Laycock. Formal specificationand testing. Software Test-
ing, Verificationand Reliability, 2:7-23, 1992.
[ 131 K. Moritz. Automatische Testklassenerzeugung von Z-
Spezifikationen (in german). Master's thesis, Christian-
Albrecht-Universitaetzu Kiel, 1994.
[ 141 G. Nocker. Abstandsregelung (in german). VDI-Berichte,
8171327-337,1990.
[IS] T. J . Ostrand and M. J. Balcer. The category-partitions
method for specifying and generating functional tests. Com-
munications of the ACM, 31(6):676-686, June 1988.
(161 J. Spivey. The Z Notation. A Reference Manual. Prentice
Hall, New York, 2nd edition, 1992.
[I71 S . Stepeny. Testing as abstraction. In ProceedingsofZ Users
Meeting '95, pages 137-151. Springer-Verlag,1995.
[18] T. WeiB. Testfallgenerierung anf der Basis von Z-
Spezifikationen mit Hilfe der Kiassifikationsbaum-Methode
(in german). Master's thesis, Technische Univenitat Berlin,
Institut fur angewandte Informatik, 1997.
[ 191 E. Weyuker,T. Goradia, and A. Singh. Automatically gener-
ating test data from a boolean specification. IEEE Transac-
tions on Software Engineering, 20(5):353-363, May 1994.
[20] E. Weyuker and B. Jeng. Analyzing partition testing
strategies. IEEE Transactions on Software Engineering,
17(7):703 -711, July 1991.