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.

Systems with Finite <strong>Model</strong>s 73<br />

exceptions are thrown. Therefore, certain sequences of method calls are forbidden.<br />

If the client attempts to connect before the server is listening on its socket, the client<br />

throws an exception. If one partner attempts to receive before the other partner<br />

sends, the receive method will block and never return. The model program must not<br />

generate runs like these.<br />

The runs that the implementation can execute depend on its configuration. If<br />

the client and server run in separate threads, then one partner could call its receive<br />

method before the other partner sends. A different model program would be needed<br />

to model that configuration. Selecting the configuration can be an important step in<br />

preliminary analysis.<br />

The challenges in this example are to write a model program that generates all<br />

the runs we want but none that are forbidden, and that generates enough different<br />

temperatures to expose the defect while keeping the model finite.<br />

Features<br />

<strong>We</strong> will model all of the features of the implementation client and server classes<br />

(Chapter 2, Section 2.4). Usually, a model program only represents some of the<br />

features of the implementation. But for this example we selected a very small<br />

implementation, so we could show the complete implentation and write a complete<br />

model program.<br />

Actions<br />

<strong>We</strong> plan to generate test runs that call the methods of the implementation, so there<br />

must be an action in the model for each public method in the implementation. The<br />

client and server actions are distinct; the client’s send is a different action from the<br />

server’s send, so we have actions ClientSend and ServerSend, and so on.<br />

Traces<br />

<strong>We</strong> write some sample traces to make sure that the actions we chose can express the<br />

behaviors we wish to model. There are many examples in Chapter 2. For example,<br />

the run discussed in Section 2.8, which is coded in the test method in Figure 2.10,<br />

is expressed by this trace:<br />

ServerSocket();<br />

ServerBind();<br />

ServerListen();<br />

ClientSocket();<br />

ClientConnect();<br />

ServerAccept();<br />

ClientSend();<br />

ServerReceive();<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!