2 Why We Need Model-Based Testing

Advanced Topics 229
FSM(0, AcceptingStates(0),
Transitions(t(0,ReqSetup(0,0),0), t(0,ReqSetup(0,1),0),
t(0,ResSetup(0,0),0), t(0,ResSetup(0,1),0)),
Vocabulary("ReqWork", "ResWork"))
Figure 14.2. A parameter restriction scenario for the credits model.
3
0
ReqA(0,1)
1
ResA(0,1) ResA(0,0)
2
Figure 14.3. Composition of the model programs in Figures 14.1 and 14.2. State 2 violates the state invariant
in Figure 14.1.
Figure 14.2). The FSM disables all Work actions and provides concrete parameter
domains for message IDs and credits in the Setup actions. We can compose the
credits model program with the FSM. The resulting finite state machine is shown in
Figure 14.3. We can see that state 2 is unsafe, because the update rule of the action
ResSetup(0,0, ) from state 1 removes all pending requests and adds no credits, so
the client cannot send further requests.
We need to strengthen the enabling condition of the response action so that if
there are no pending requests and the window is empty, then the granted number of
credits must be at least one. We do so by adding the additional enabling condition
to the credits model.
[Requirement("Section ...: Client must have enough credits")]
static bool ResEnabled1(int m, int c)
{
return requests.Count > 1 || window.Count > 0 || c > 0;
}
Notice that if the window is empty and no credits are granted then there must be
at least two requests pending when this enabling condition is checked, because the
response action update rule will remove one of the requests.
more free ebooks download links at:
http://www.ebook-x.com