Lecture Notes in Computer Science 3472

14 Tools for Test Case Generation 415
has never been applied to case studies; its main function is educational, to illustrate
the Canonical Tester theory and the Co-Op method [Wez90, Wez95]
to derive canonical testers. The underlying theory is discussed in Section 6.4.2
(page 166).
Test Generation Process
(Most of the following is quoted/paraphrased from [Wez95].)
Cooper implements the implementation relation conf of [Bri89]. In this notion
a process B1 conforms to B2 if and only if B1 contains no unexpected
deadlocks with respect to traces of B2. So,ifB1 performs a trace that can also
be done by B2, and at a certain point B1 deadlocks, then also B2 should be
able to perform the same trace and deadlock at the same point. This notion of
conformance allows B1 to perform traces that are not in B2. But when we place
B1 in an environment that expects B2, it will not deadlock unexpectedly with
the environment.
A canonical tester is then a process that can test whether an implementation
conforms to a specification with respect to the conf relation. To test whether a
process P conforms to B we place a canonical tester T (B) in parallel with P.
The tester synchronizes with P, as explained below.
In the initial version of the Co-Op method on which Cooper is based, we only
have basic actions (events) without values. There is no partitioning in input and
output actions, and interaction between tester and implementation is by synchronizing
on observable actions. This means that an action can only “happen”
if both the tester and the implementation can “do” it. If only one of them (tester
and implementation) is willing (or able) to do an action, and the other one can
not do the action, then it can not happen. If at a given moment the tester or
the implementation has no actions that it can do, or if the intersection of the
sets of actions that they can do is empty (which means that there are no actions
that they can do together), then they deadlock. There is the notion of an
unobservable, internal (τ) action. And, from there, there is the notion of stable
and unstable states. Stable states are those from which the implementation will
only move after an interaction with its environment. Unstable states are states
from which the implementation can move by itself, by performing some internal
action.
If the tester tries to test an action x that is performed from an unstable
state, it is possible that the implementation has moved to a different state and
no longer wants to do x .So,x can be seen as an action that is (for the given
state) optional in the implementation (the implementation may want to do it,
but it also possible that the implementation no longer can do it because it moved
to a different state where the action is not possible). However, in general, after
the implementation has moved (by doing an internal action) “through” zero or
more unstable states, it will end up in a stable state from which it cannot move
by itself (there are no internal actions possible). For such a stable state, the
tester must be willing to do at least one of actions that the implementation
wants to do from there. Otherwise the tester might deadlock with a correct