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.

94<br />

6 Exploring and<br />

Analyzing Finite<br />

<strong>Model</strong> Programs<br />

In this chapter we introduce exploration, our primary technique for analyzing model<br />

programs. Exploration generates a finite state machine (FSM) from a model program.<br />

The FSM can then be used for visualization, analysis, and offline test generation.<br />

In this chapter we show how model-based analysis reveals the design errors in<br />

the reactive system we discussed in Chapter 3, by exploring the model program we<br />

developed in Chapter 5, Section 5.7. <strong>We</strong> explain and demonstrate safety analysis<br />

that identifies unsafe (forbidden) states and liveness analysis that identifies dead<br />

states from which goals cannot be reached. Dead states indicate deadlocks (where<br />

the program seems to stop running and stops responding to events) or livelocks<br />

(where the program keeps running but can’t make progress).<br />

In this chapter we also introduce the mpv (<strong>Model</strong> Program Viewer) tool for<br />

visualization and analysis, and explain how to use the modeling library features that<br />

support analysis.<br />

6.1 Finite state machines<br />

In this section we motivate and explain FSMs.<br />

Simulation is the most limited and labor-intensive model-based analysis technique<br />

because it only considers one run at a time (Chapter 5, Section 5.5). To<br />

perform more thorough analyses – to detect the design errors discussed in Chapter<br />

3, for example – we need to consider many different runs. The obvious way<br />

would be to code a large number of runs, but this is not a practical solution. In order<br />

to get good coverage of program behaviors, we would usually have code a great many<br />

runs, and some would be very long. But the collection of runs would be redundant.<br />

The same sequences of actions would appear again and again in different runs, and<br />

even within a single run. <strong>We</strong> use a better representation of behaviors that removes<br />

the redundancy, representing a great many runs in a compact way: the FSM. Exploration<br />

automatically generates an FSM from a model program.<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!