2 Why We Need Model-Based Testing

14 Why We Need Model-Based Testing
Temperature
sensor
✛
✲
Embedded
computer
(Server)
✛
Figure 2.1. Remote instrument, a client/server system.
✛
commands
TCP/IP network
responses
At the data storage computer, we invoke the client program Logger:
Logger 128.95.165.121 8023 3 10 F
✲
✲
Data logging
computer
(Client)
Here the command line arguments are the server host IP address and port number, the
number of temperature samples to acquire before exiting, the time interval between
samples in seconds, and the units (Celsius or Fahrenheit) for expressing the samples.
Logger then acquires the samples and writes them to the console, along with a time
stamp and information about the server.
2006-10-26 13:12:42Z Temperature server at port 8023 reports 72.2 F
2006-10-26 13:12:52Z Temperature server at port 8023 reports 72.4 F
2006-10-26 13:13:02Z Temperature server at port 8023 reports 72.5 F
Monitor also writes messages about client connections to the console on the
embedded computer.
2006-10-26 13:12:34Z Temperature server binds port 8023
2006-10-26 13:12:42Z Temperature server accepts connection
2006-10-26 13:13:12Z Temperature server connection closed
2006-10-26 13:13:12Z Temperature server exits
It might seem that not much could go wrong with such a simple system. But we
have already experienced failures, and some have been intermittent and difficult to
reproduce. Therefore, we have resolved to test and analyze the system thoroughly,
to discover the different ways it can fail, in order to prepare for correcting defects
or designing a more robust system.
Before we can describe our testing and analysis, we must explain a bit more about
how our programs work.
2.2 Protocol
Our two programs implement a protocol, an agreement about how to work together.
A protocol is defined by rules for forming messages and rules that constrain the
ordering of the messages. In this example, the “messages” in the protocol are the
more free ebooks download links at:
http://www.ebook-x.com