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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

136 Structuring <strong>Model</strong> Programs with Features and Composition<br />

Figure 7.18; it includes all the transitions of the scenario. This indicates that the<br />

contract model program can execute the scenario; there are some unsafe runs. The<br />

projection of the product onto the contract model program appears in Figure 7.19<br />

(the product itself is similar but includes some distracting complications). Many runs<br />

described by the scenario machine appear in the projection, including the unsafe<br />

run shown in Figure 6.10 in Chapter 6. (<strong>We</strong> can confirm this by magnifying and<br />

inspecting the graph, or by exploring it interactively.)<br />

It is important to understand that here we did not have to identify any unsafe<br />

states in order to perform this analysis; we only had to write the scenario. Moreover,<br />

we did not have to describe any paths completely in our scenario, we only had to<br />

identify what is common to the unsafe runs: a few actions and their ordering.<br />

This analysis takes a somewhat different view of safety than does the analysis of<br />

Chapter 6. Here, a run is unsafe if it includes the actions of our scenario (in that order);<br />

in Chapter 6, a run is unsafe if it reaches an unsafe state (that violates an invariant<br />

defined by a Boolean expression). To compare the two analyses, in Figure 7.19,we<br />

have highlighted the states that are unsafe according to the analysis in Chapter 6.<br />

Two of the four unsafe states identified in Chapter 6 appear in the projection<br />

here. These two states are highlighted in the right lobe of the FSM of the contract<br />

model program (Figure 6.9 in Chapter 6). Notice how a portion of that contract<br />

FSM appears here in the projected FSM. The left lobe of the contract FSM does<br />

not appear in the projection because in all the paths to that lobe, the out-of-range<br />

message reporting temperature 999.9 precedes any in-range message reporting 99.9<br />

(see Figure 6.12 in Chapter 6 and the accompanying discussion). Therefore, those<br />

paths do not match our scenario and are excluded from the product. Two of the unsafe<br />

states appear in that lobe, so they are not reachable by the scenario we specified.<br />

The two analyses produce results that are similar but not identical. For the temporal<br />

analysis we performed here, we chose a scenario that is a bit more selective<br />

(considers fewer runs to be unsafe) than the state-based analysis we performed in<br />

Chapter 6.<br />

7.6 Exercises<br />

1. <strong>We</strong> say we want to keep contract model programs free of limitations intended<br />

to reduce the number of runs. Is the client/server model program in Chapter 5<br />

entirely free of such limitations? If not, show an example of such a limitation.<br />

2. In the example in Section 7.3.1, the true FSM of the product contained all of the<br />

states and actions of the true FSM of each of the programs that were composed.<br />

Is this always true? If not, provide a counterexample.<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!