2 Why We Need Model-Based Testing

Systems with Finite Models 129
Recall that the purpose of scenario control is to eliminate runs allowed by a
contract model program that are not pertinent to the particular issue we wish to
analyze or test. The unwanted runs can be eliminated by composing the contract
model program with a scenario model program that encodes the runs we wish to
see. It is often convenient to code the scenario model program as an FSM. Recall
that composition has the effect of selecting only the runs that are allowed by both
composed programs. If there is a particular sequence of actions you want to see
in the product, put that sequence in the scenario model program. If there are other
actions you would allow to interleave in the product, do not mention those actions
in the scenario model program. If there are actions you want to eliminate from the
product, include those actions in the vocabulary of the scenario model program but
do not write any transitions that use them. This has the effect of disabling those
actions in all states.
There is a typical scenario that we often want to use for testing: first, a sequence of
setup actions, then several (or many) interleaved test actions, and finally, a sequence
of cleanup actions. Figure 7.14 shows a model program for generating such a
scenario from the client/server model program. Compare this to the true FSM for
the contract model program (Figures 7.1, and 7.2). The setup and cleanup sequences
in the scenario model program select one run through the many paths allowed by the
contract model program. The scenario model program does not mention the send
and receive actions; those are the test actions that are allowed to interleave.
This command displays the test scenario model program composed with the
contract model program:
mpv /fsm:Scenario.txt /r:ClientServer.dll ClientServer.Factory.Create
Figure 7.15 shows the result. The setup and cleanup sequences from the scenario
model program also appear in the product. The loops in the middle of the diagram
represent the interleaving of the test actions, send and receive. We will use this
product in Chapter 8 to generate and check tests that reveal the defect we discussed
in Chapter 2.
7.4 Choosing among options for scenario control
There are three ways to control the scenarios of a model program: enabling conditions,
features, or composition. We recommend that the model program should
be a specification or contract, so its enabling conditions should permit all allowed
runs, not just particular scenarios. Scenario control should be separated out with
features or composition, so the same contract model program can analyze or test
different scenarios. Features can access the model program state, so use features for
more free ebooks download links at:
http://www.ebook-x.com