07.01.2013 Views

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

8 Test Derivation from Timed Automata 229<br />

• Impl has no more states then Spec and<br />

• Impl has a s<strong>in</strong>gle transition fault or Impl can be transformed to Spec by a<br />

sequence of s<strong>in</strong>gle transition faults.<br />

It can be shown that for a TTTS specification Spec, the test suite Test (Spec)<br />

that is generated by the TTTS Test generation Algorithm detects any Impl<br />

∈ Nonconf(Spec) [CO00]. If the implementation satisfies the test hypotheses<br />

then all tests for Spec will be passed by the implementation if and only if the<br />

implementation is trace equivalent to Spec.<br />

Example. Spec = 〈QSpec, L, −→, q0〉, V =({sen}, ∅, {c}, {on, off })<br />

(1) Reach all states<br />

• reach(q0) ={〈〉}<br />

• reach(q1) ={〈0, <strong>in</strong>p, on, {c :=0}〉,...,〈8, <strong>in</strong>p, on, {c :=0}〉}<br />

• reach(q2) ={〈0, <strong>in</strong>p, on, {c := 0} ·5, out, off , {c := -1}〉,...,〈3, <strong>in</strong>p, on,<br />

{c :=0}·5, out, off , {c :=-1}〉}<br />

(2) Dist<strong>in</strong>guish states <strong>in</strong> the same visible equivalence class: S<strong>in</strong>ce q0 is not a<br />

dest<strong>in</strong>ation state for some transition we do not need to dist<strong>in</strong>guish between<br />

q0 and q1 although both are <strong>in</strong> the same visible equivalence class. q2 has no<br />

other state <strong>in</strong> its visible equivalence class. Therefor, all dist<strong>in</strong>guish<strong>in</strong>g traces<br />

are trivial, i.e. {〈〉}<br />

(3) Pair traces with oracles.<br />

• diff(q1, q1) ={〈〉 ∗ yes}<br />

• diff(q2, q2) ={〈〉 ∗ yes}<br />

(4) Compose tests for every transition.<br />

• testfor(t1) =〈0, <strong>in</strong>p, on, {c :=0}〉 ∗ yes<br />

• ...<br />

• testfor(t10) =〈0, <strong>in</strong>p, on, {c :=0}·1, <strong>in</strong>p, on, {c :=0}〉 ∗ yes<br />

• ...<br />

• testfor(t15) =〈0, <strong>in</strong>p, on, {c :=0}·5, out, off , {c :=-1}〉 ∗ yes<br />

• testfor(t16) =〈0, <strong>in</strong>p, on, {c := 0} ·5, out, off , {c := -1} ·0, <strong>in</strong>p, on, {c :=<br />

0}〉 ∗ yes<br />

S<strong>in</strong>ce the tester has control over the event on we can choose one trace of all<br />

possible reach() traces for each state, although the states may be reached by<br />

different traces. If on were under control of the SUT we had to <strong>in</strong>clude all<br />

possible reach() traces for the accord<strong>in</strong>g states. Furthermore, if we allowed off<br />

events to occur between an lower and upper time bound we had to <strong>in</strong>clude all<br />

possible traces <strong>in</strong>clud<strong>in</strong>g an off event <strong>in</strong>to the accord<strong>in</strong>g reach sets.<br />

Please note, that transitions with yes oracles may be <strong>in</strong>cluded <strong>in</strong> longer transitions,<br />

e.g. testfor(t16) subsumes testfor(t1) andtestfor(t15).

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!