2 Why We Need Model-Based Testing

Systems with Finite Models 147
When we execute this command, the test fails:
TestResult(0, Verdict("Failure"),
"Action ’ClientReceive_Finish(double(\"99\"))’ not enabled in the model",
Unexpected return value of finish action, expected:
ClientReceive_Finish(double "99.9"))
Trace(
Test(0),
ServerSocket(),
ServerBind(),
ServerListen(),
ClientSocket(),
ClientConnect(),
ServerAccept(),
ServerSend(double("100")),
ClientReceive_Start(),
ClientReceive_Finish(double("100")),
ServerSend(double("99.9")),
ClientReceive_Start(),
ClientReceive_Finish(double("99"))
)
)
The output shows the trace of the actual test run through the action that failed
(compare to the trace of the test case in Figure 8.3). The message indicates that this
test failed because the return value 99 in the last finish action is not the same as the
expected return value 99.9 computed by the model program and stored in test case.
8.5 Limitations of offline testing
The five test cases in the first test suite all pass; they do not reveal the defect in
the implementation that we discussed in Chapter 2, Section 2.10. Recall that the
defect causes a failure after the server sends the client more than four characters
(e.g., "100.0"), but the client only fails when it receives the message after the first
message with four characters. At least two messages must be sent and received to
expose the defect (where the first message contains more than four characters). Each
of the test cases in the first test suite only send and receive one message, so they
cannot expose the defect.
The single test case in the second test suite does expose the defect, because
two messages are sent and received, and the first message contains more than four
characters.
more free ebooks download links at:
http://www.ebook-x.com