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.

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

actions of both partners. This would not be possible in the implementation, where<br />

the client and server execute separate programs with no shared data.<br />

The sequences of actions that are possible are determined by the enabling conditions,<br />

boolean methods that test the values of the control state variables. Some<br />

enabling conditions test the states of both partners, which would not be possible in<br />

the implementation. For example, ClientConnectEnable and ServerAcceptEnable<br />

ensure that ClientConnect follows ServerListen and precedes ServerAccept. They<br />

prevent the sequences that would cause the client implementation to crash (if it<br />

connects before the server listens) or cause the server implementation to block (if it<br />

accepts before the client connects).<br />

In most states more than one action is enabled, so many different runs are<br />

possible. For example, in states where phase == Phase.Send, both ClientSend and<br />

ServerSend are enabled, so either partner could send the first message.<br />

Unlike the implmentation, here the client’s send method has no command argument,<br />

and the server has no receive buffer. In the runs we wish to model, these<br />

items always have the same value (the T command), so they add no information to<br />

the state. They are only used for synchronization. In the model, synchronization is<br />

achieved by the phase variable.<br />

Like the implementation, here the server’s send method has an argument, a<br />

number that represents the temperature acquired by the server. In the model, the<br />

server’s send method simply assigns this number to the client’s receive buffer. This<br />

models the effect of transmission across the network.<br />

In the model, the receive buffer is a number (a C# double), not a string as it<br />

is in the implementation. To model the situation where this buffer is empty in the<br />

implementation, we set it to a special numeric constant double.MaxValue that we<br />

name EmptyBuffer.<br />

<strong>We</strong> limit the receive buffer to just two temperature values, the constants we call<br />

Temp2 and Temp3. <strong>We</strong> achieve this by limiting the temperatures that can be assigned<br />

to the receive buffer by the ServerSend method. <strong>We</strong> limit that method’s datum<br />

parameter to the two values, by using the Domain attribute:<br />

public static void ServerSend([Domain("Temperatures")] double datum)<br />

{<br />

...<br />

}<br />

To analyze a model, or generate test cases, the arguments of every parameter of<br />

every action method must be drawn from a finite collection called a domain. Parameters<br />

with boolean types or enumerated types always have finite domains. Other<br />

parameters must be labeled with a Domain attribute. The argument of the attribute,<br />

"Temperatures" here, is a string that names a method in the same class that returns<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!