2 Why We Need Model-Based Testing

84 Model Programs
Timeout();
Poll();
Message("100.0");
CheckMessage();
Command();
Calibrate();
Compare this trace to the test method (Figure 3.7) and the test output (Section 3.3).
The calls to ReceiveEvent in the test method are modeled by different actions for
each kind of event: Timeout, Message, and Command (the Exit event is not modeled).
The calls to DispatchHandler are modeled by the actions for each handler: Reset,
Poll, and Calibrate.
The simulation in Section 3.4 that shows an unsafe run, labeled OutOfRangeMessageWhenIdle,
is expressed by this trace:
Timeout();
Reset();
Message("99.9");
CheckMessage();
Timeout();
Poll();
TimeoutMsgLate();
ReportLostMessage();
Message("999.9");
NoHandler();
Command();
Calibrate();
In this trace, two different time-out actions appear: Timeout and TimeoutMessageLate.
The NoHandler action here indicates that no handlers are enabled after the
second message.
State variables
In this example, the parts of the model program that model the Controller class are
similar to the implementation. The model program has these control state variables,
which also occur in the implementation: cevent, the most recent event; waitfor, the
kind of event the controller is waiting for; and sensor, the inferred sensor status.
The model program has additional control state variables that are not in the
implementation. TimeoutScheduled and MessageRequested model the timer and the
sensor to ensure that events are modeled realistically. They are tested by the enabling
conditions for the event actions, and are updated by the event actions. Finally, the
phase variable controls the alternation of events and handlers.
more free ebooks download links at:
http://www.ebook-x.com