2 Why We Need Model-Based Testing

238 Compositional Modeling
14.2.6 Composing the features
Let us now consider a composition of all of the features. We also need some scenarios
to restrict the parameter domains, so that the composed model program becomes
explorable. We consider two scenarios shown in Figure 14.16.
The scenario CreditScenario describes a client who always uses the minimum
available request ID and asks for two credits when sending a request. The scenario
also limits the number of requests to three. In addition, the scenario describes a
“generous” server who always grants the maximum number credits to the client.
Note that this scenario model program is a dependent feature of the credits model
program and can therefore not be explored independently of it.
The second scenario, called CancelScenario, describes a client that cancels only
the last request that was sent, and only if there is more than one request pending.
This scenario is also a dependent feature of the sample protocol model because it
references the state of the cancellation model program.
Full exploration of the sample protocol model with all the features composed
with the scenarios in Figure 14.16 is shown in Figure 14.17. Notice how the features
interact by synchronizing on actions whose symbols are shared. The allowed action
traces of the composed model program belong to the intersection of the traces of the
individual model programs.
A valid trace of actions is illustrated in Figure 14.18. In this trace all requests
were completed, even though request 1 was cancelled by the client. The status field
in the response actions comes from the cancellation model program, whereas the
allowed message IDs come from the credits model program. The fact that setup
has to precede work is due to the setup model program. In state 2 the window
of the credits model program is the set {3, 4, 5, 6} and all the map-valued state
variables are empty maps. If we would remove the restriction that the server always
grants the maximum number of credits, we would obtain a state transition graph
that represents all the valid server behaviors for the given client behaviors. The
state graph would have 24 states and 62 transitions. The final state of every valid
trace would have a credits window equal to one of the sets {3}, {3, 4}, {3, 4, 5},
or {3, 4, 5, 6}, depending on the actual number credits granted by the server in the
responses.
For visual validation of the behavior it is useful to restrict the size of the explored
state space to a small portion of the full state space. However, if the client is
being controlled by the tester and the server is observed only by the tester, it is
important not to restrict the behavior of the server in order to use the composition
as a test oracle. Restricting the observable behavior in the composition may lead
to false negatives during testing. Testing with observable actions is the topic of
Chapter 16.
more free ebooks download links at:
http://www.ebook-x.com