Information Technology Reference
In-Depth Information
However the precise difference between a (standard) specification and one that serves
as a model for MBT is still unclear. That is the topic of this paper. More specifically, its
purpose is to consider the following question, particularly in the context of web-based
systems:
What can a specifier do, when constructing a (state-based, or model-based)
specification, to facilitate the subsequent task of testing, particularly by auto-
mated techniques like MBT?
The nature of testing has changed as a result of specification. One of the benefits of
specification is that it provides notation and a place in the development cycle to make
precise conditions that once were routinely incorrect in code; then they were picked
up only by testing. Perhaps the best examples of that nature are boundary conditions:
indices out of bounds, loops iterating too many or too few times, etc . Of course the
specifier might still get those details wrong, but with MBT the mistake is likely to be
picked up in the model rather than in the implementation.
One of the strengths of MBT is that the model and tests generated from it can be
reused even when the implementation changes. This means that MBT is useful in black-
box testing, whose focus is on the properties of the system rather than the low-level
coding details. This facilitates the development of a model that is abstract and is de-
rived only from observable behaviour. This is not to say that MBT cannot be used in
whitebox testing. But the more the details of the implementation are exposed, the less
abstract the model—and hence the less reusable—it becomes.
In this paper, however, it is argued that some implementation details have to be ex-
posed for certain types of property. The properties addressed include standard 'func-
tional' properties like laws between operations, system invariants, confidence conditions
(like pre- and postcondition analysis), boundary analysis; and they include 'nonfunc-
tional' properties like security leaks.
For MBT to be really useful, the tests generated from the model must be linked to the
implementation. The link must provide sufficient information to automate the process of
testing the implementation from the model. It acts as an 'action refinement', translating
test sequences obtained from the model into suitable test sequences for the implemen-
tation. The action word approach [6,5] has been proposed as a simple way to establish
the link. This approach applies naturally to models which are labelled transition sys-
tems whose labels represent aspects of functionality that are to be tested. The link then
associates code, which actually performs the testing, to the label. For example, if the
link associates the code ca to the label a and cb to the label b , then the test sequence
ab results in execution of the code ca 9 cb . Usually the oracle is built into the code.
1.1
Related Work and Outline
The study of the interplay between specifications and testing is far from new. Of the
many contributions which predate MBT, a large number can with hindsight be seen as
precursors. Specification-based testing is a term that has for long been used to describe
the 'generation' of tests from a (formal) specification.
Some work has focused on the animation of specifications, either by choice of speci-
fication notation [7,13,14,15,18] or by translating the specification into executable form
Search WWH ::




Custom Search