Consider the simple example in Figure 8.6. Minimal transition
coverage will generate two test cases: A(),B(),C() and A(),D(). The assumption
is that the model state really does determine the behavior; there is no need to
cover every path; D() will not be affected by B() preceding it. This assumption
can be false if the implementation has hidden state that is not represented in the
model. In that case, we should also attempt some amount of path coverage by also
testing the paths A(),B(),D(), and maybe even A(),B(),B(),D(). In our client/server
implementation, the hidden state is the client??™s receive buffer.
These are limitations of minimal transition coverage, not offline test generation
in general. We can imagine an offline test generator with a more thorough traversal
algorithm. But the requirement in offline testing that the entire test suite must be
computed in advance discourages thorough coverage. Moreover, it is not feasible
to explore the true FSM of many ???infinite??? model programs at all. And, when the
implementation exhibits nondeterminism, it is wasteful to compute paths that may
never be taken. For these reasons, the tools emphasize on-the-fly testing, where the
tests are computed as the test executes. In contrast with the limited choice of traversal
algorithms built into the otg tool (just one at this writing), the ct tool provides rich
opportunities for testers to program their own on-the-fly testing strategies, as we
shall see in Chapters 12 and 16.
Pages:
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217