2 Why We Need Model-Based Testing

106 Exploring and Analyzing Finite Model Programs
drawn from a set called a domain. In each state, exploration executes each action
method repeatedly, using as many different values as it can from the domains of all
its parameters. Each combination of parameter values defines a different action, so
larger domains result in more actions and more transitions. Enabling conditions can
depend on parameters as well as state variables, so each combination of parameter
values must be checked; some combinations may not be enabled in some states.
6.3 Analysis
6.3.1 Safety
It can be helpful to simply view the graph of the FSM, but it is more useful to
investigate particular issues. Exploration can provide the answers to several kinds
of specific questions.
Several statistics are computed during exploration, including the number of states
and transitions found (this is not shown in the algorithm of Figure 6.7). These statistics
can provide useful diagnostic information. For example, they reveal whether
exploration did in fact generate the true FSM. The default for the limit MaxTransitions
is quite small, only 100. If exploration reaches this limit, it does not generate
the true FSM, but only some portion of it. When this happens, the number of transitions
found equals MaxTransitions. You may also notice unexpected dead ends in
the graph. In that case, you should increase MaxTransitions and explore again.
Many analysis questions can be expressed in terms of safety or liveness. In the
following subsections we use safety and liveness analyses to reveal design errors in
the reactive system we discussed in Chapter 3, whose model program we developed
in Chapter 5, Section 5.7.
Safety analysis checks whether anything bad can happen. It searches for unsafe
states that violate safety requirements. We express safety requirements by writing
a Boolean expression called an invariant, which is supposed to be true in every
state that can be reached. An unsafe state is a state where an invariant is false.
For the tools, an invariant is a Boolean field, property, or method labeled with the
[StateInvariant] attribute.
Safety analysis depends on writing an invariant that expresses the safety property
we wish to check. We must consider which states are allowed (that make the invariant
true) and which are forbidden (that make the invariant false). Identifying the safe
states requires judgment and understanding the program’s purpose.
Recall that the purpose of our reactive system is to perform a calibration with
a valid temperature sample. Performing a calibration with an invalid temperature
sample would be bad. Here the bad thing is an action (performing a calibration) but
more free ebooks download links at:
http://www.ebook-x.com