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.

96 Exploring and Analyzing Finite <strong>Model</strong> Programs<br />

Topics<br />

WithText<br />

ByMostRecent<br />

ShowTitles()<br />

ShowText()<br />

Topics<br />

TitlesOnly<br />

ByMostRecent<br />

Figure 6.1. Newsreader scenario FSM: state transition diagram.<br />

SortByFirst()<br />

SortByMostRecent()<br />

Topics<br />

TitlesOnly<br />

ByFirst<br />

Figure 6.1 shows a state transition diagram for the same run. This is another way<br />

to represent the same FSM that is shown in Table 6.1. The diagram is a picture of a<br />

data structure called a graph, where bubbles called nodes (or vertices) are connected<br />

by arrows called links (or arcs or edges). In a state transition diagram, the nodes<br />

represent states. The links represent state transitions. Each is labeled by its action (a<br />

method invocation). The diagram shows a directed graph because each link points<br />

in one direction, from the current state to the next state. <strong>We</strong> can reconstruct the run<br />

from the diagram by following the links. In our diagrams the initial state is usually<br />

distinguished by shading.<br />

It is important to understand that the effects of an action only depend on the<br />

current state. To compute (or predict) the effects (the next state), it is not necessary<br />

to keep track of the history leading up to the current state.<br />

An FSM represents behavior compactly because each transition only occurs once<br />

in the FSM, no matter how many times it occurs in the run. In a state transition<br />

diagram, each state also appears only once. If the run reaches the same state more<br />

than once, the diagram contains loops called cycles. In this example there are cycles<br />

through all of the states.<br />

6.1.1 Runs and scenarios<br />

<strong>We</strong> generated our FSM (Table 6.1, Figure 6.1) from a run of our model program.<br />

It is also possible to generate runs from an FSM. This is how we do offline test<br />

generation.<br />

Each FSM describes every run that can be obtained by traversing a path around<br />

the nodes and links in its graph. Here is an informal description of the algorithm for<br />

generating one run: Begin in the initial state. In a state that has transitions to next<br />

states, choose any one. For example, the middle node in Figure 6.1 has two outgoing<br />

transitions, so two choices are available. If we reach a state with no outgoing transitions,<br />

the run finishes in that state. Or, if the state has been designated an accepting<br />

state, we may choose to finish the run in that state. In this example, we have have<br />

not designated any accepting states, so every state is considered an accepting state;<br />

the run may finish in any state.<br />

<strong>We</strong> often describe this process in terms of actions, rather than transitions. An<br />

action is enabled in a state if it is allowed to begin in that state; otherwise, it is<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!