2 Why We Need Model-Based Testing

Overview 47
no confidence that we are converging on a correct design. There might be even
more ways that the controller can fail. How can we be sure that we have considered
enough runs? We need some systematic way to check the design thoroughly.
3.6 Reviews and inspections, static analysis
The traditional way to detect design defects is to conduct reviews or inspections
where people examine design documents and code, often while consulting a checklist
of likely errors. These assurance techniques are a good match to programs like ours,
which have a simple, regular structure. The control program is largely built from
only two kinds of methods, guards and handlers, and has a simple control structure
expressed here by the DispatchHandler method. This makes it easy to express and
check design rules that the code should observe. The design should be complete:
there should be a handler enabled for every event in every state. The design should
be deterministic: there should be only one handler enabled for each event in every
state. The design should make progress: each handler should execute statements
that bring the controller closer to a goal, usually by enabling a different handler.
Each of the failures described in Section 3.4 is caused by a defect that violates these
rules.
Considered against our design rules, the defects in this little program are obvious.
But in general, reviews and inspections are time-consuming, subjective, and fallible.
This little example is based on our experience with a program that has about a
hundred handlers and a hundred variables, where the defects were not so obvious.
It is possible to create a program that automates some of the checking of design
rules that human reviewers do, removing the tedium and subjectivity. This automated
checking of source code is called static analysis, and can be viewed as an extension
of the checking already performed by compilers and style checkers. Static analysis
is a promising research area, but it is not the approach we teach in this book.
3.7 Model-based analysis reveals the design errors
Model-based analysis reveals the design errors in our controller program. We write
a model program that expresses the design, and then use our mpv (Model Program
Viewer) tool to explore, search, and display the finite state machine (FSM) that
expresses the model program’s behaviors (Figure 3.8). (It is not necessary to read
the details in this figure now.) Reading the messages written by mpv, or inspecting
this display while using mpv to highlight features of interest, reveals each defect.
How to do this is explained in chapters to come (especially Chapters 5 and 6). For
now, we just show what can be done.
more free ebooks download links at:
http://www.ebook-x.com