2 Why We Need Model-Based Testing

ServerClose()
Systems with Finite Models 117
3
5
ServerClose()
2
0
ServerSocket()
ClientSocket()
ServerBind() ClientSocket() ServerSocket()
ServerListen()
6
ServerClose() ClientSocket()
10
ClientSocket()
8
ClientConnect()
7
1
4
ServerListen()
Figure 7.2. Client/server: the first few transitions of all runs.
ServerBind()
ServerClose()
ServerClose()
9
ServerClose()
This example shows that we often know a priori – before any exploration or
testing – that we do not want to consider certain runs. We need a way to use this a
priori knowledge – or other preferences – in automated analysis and testing. But we
do not want to put limitations into the model program itself. We want to separate the
contract model program that describes all allowed behaviors from scenario control,
the limitations we introduce to focus on interesting runs. Then we can use the same
contract model program to analyze or test many different scenarios. Features and
composition make this possible.
7.2 Features
A feature is a cluster of related state variables and actions that can be selectively
included or excluded from a model program. Features make it possible to define
different configurations for a model program, which include different subsets of
features, in a single source program file (or collection of files). In addition, features
can be combined for purposes of scenario control.
more free ebooks download links at:
http://www.ebook-x.com