Lecture Notes in Computer Science 3472

7 I/O-automata Based Testing 185
We can read this definition in the following way. An implementation i is
≤iot-correct with respect to a specification s if for all traces with which we test,
the set of outputs of the implementation after such a trace is a subset of the
set of outputs of the specification after the same trace. In terms of observations
this means that we should not be able to observe different or more behavior
from the implementation than from the specification. A possible output is the
absence of output or quiescence. We use the meta-label δ to denote quiescence.
It is interesting to know that the ≤iot relation is equivalent with the quiescent
preorder (and thus with the must preorder) [Tre96b].
Example. We will illustrate the input output testing relation with the example
of the trace inclusion preorder in Figure 7.2. The implementation i1 is ≤iotcorrect
with respect to specification s. We see that it does not implement the
coffee output after pressing the button twice, so how can it be correct? Let us
take a look at the definition of ≤iot. The specification prescribes that the set of
outputs after the trace button·button = {coffee,tea}. When we take a look at
i1 we see that the set of outputs after button·button = {tea}. Because {tea} ⊆
{coffee,tea} it is correct behavior. So the intuition behind non deterministic
output is that we do not care which branch is implemented as long as at least one
is. We can do the same analysis for implementation i2. Here we find that after
pressing the button twice i2 does not give any output; it is quiescent. This means
that out(i2 after button·button) ={δ}. This is not a subset of {coffee,tea} and
there fore i2 �≤iot s. Weseethat≤iot is a stronger implementation relation than
external trace inclusion and furthermore one that agrees more with our intuition.
ioconf relation The input-output variant of the conf relation is called ioconf
[Tre96b]. The difference with the input-output testing relation is that it uses
a different set of traces to test with, namely the set of all possible traces of
the specification: traces(s).Thismeansthatwewillnottestbehaviorthatis
not specified. One way to interpret this is as implementation freedom: “Wedo
not know or care what the implementation does after an unspecified trace”.
The advantage of this is that we can test with incomplete specifications. Since
traces(s) ⊆ L ∗ ,theioconf relation is weaker than the ≤iot relation.
Definition 7.16 (ioconf). Let i ∈IOTS(I , U ), s ∈LTS(I , U )
i ioconf s =def ∀σ ∈ traces(s) :out(i after σ) ⊆ out(s after σ).
Example. In Figure 7.6 we illustrate the ioconf relation. i1 is the same implementation
as in the examples for external trace inclusion and ≤iot. This
implementation is still correct under ioconf. This is easy to see, because
the trace button·button ∈ traces(s); it is a trace of the specification and
out(i1afterbutton·button) ={tea} ⊆out(safterbutton·button) ={coffee,tea}.
Implementation i2 introduces new behavior. When we kick the coffee machine it
outputs soup. This kind of behavior is nowhere to be found in the specification;
the behavior of kicking the machine is underspecified. This kind of behavior
would be a problem for ≤iot since it will test on all possible behavior of the label