27.07.2013 Views

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

46 <strong>Why</strong> <strong>We</strong> <strong>Need</strong> <strong>Model</strong>-<strong>Based</strong> Analysis<br />

CheckMessage ’99.9’, compare to 999.9, Error<br />

?Timeout, Timeout, Error<br />

Reset<br />

?Message ’100.1’, Message, Error<br />

CheckMessage ’100.1’, compare to 999.9, Error<br />

?Timeout, Timeout, Error<br />

Reset<br />

?Message ’101.5’, Message, Error<br />

CheckMessage ’101.5’, compare to 999.9, Error<br />

?Timeout, Timeout, Error<br />

Reset<br />

?Message ’102.3’, Message, Error<br />

CheckMessage ’102.3’, compare to 999.9, Error<br />

3.5 Design defects<br />

The defects that caused these failures are deeper than the coding defect discussed in<br />

Chapter 2. <strong>We</strong> consider these to be design errors. Recall that a design describes how<br />

a system is built up from parts and how the parts communicate. Here the controller<br />

is built up from events and handlers that communicate through variables and the<br />

timer. The design is expressed by the guard expressions that test the variables to<br />

determine which handler to run, and the statements in the handlers that assign these<br />

variables and start or cancel the timer. Each failure results from tests or assignments<br />

that do not produce the intended behaviors, when combined with the other tests and<br />

assignments in the program. All the tests and assignments cooperate to produce the<br />

behaviors, and it is necessary to consider them all to understand the failures.<br />

All of the failures shown in Section 3.4 can be understood in this way. The<br />

CommandWhenWaiting run fails because no handler for the Command event is enabled<br />

when the controller is waiting for a message. The OutOfRangeMessageWhenIdle run<br />

fails because no handler for the Message event is enabled when the controller is<br />

waiting for a time-out. The LostMessageWhenIdle run reaches a deadlocks after<br />

a message is lost because no handler for the Timeout event is enabled when the<br />

controller is waiting for a message and the sensor is considered erroneous, and<br />

no preceding handler requested another message or scheduled another time-out.<br />

The InitialOutOfRangeMessage run cycles endlessly because none of the enabled<br />

handlers can make progress by assigning the sensor status to OK.<br />

<strong>We</strong> designed the controller by considering some typical runs and coding tests<br />

and assignments to make them work. But many more runs are possible than the<br />

ones we considered and tested, so our design is defective. <strong>We</strong> are getting tired of<br />

experimenting with the simulator. Discovering defects by trial and error provides<br />

more free ebooks download links at:<br />

http://www.ebook-x.com

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!