ABSTRACT
As described in the subsequent subsections, there are
different variants of MBT processes that make different
use of system and/or test models.
System Model Only Approach
A very common approach of MBT is the exclusive use of
a system model (Fig. 3), which is often defined in UML,
SDL, MSC, or other formal notations like Petri nets,
temporal logic. In this approach, not only the test system
(or parts of it) is generated from the system model, but the
system itself (or parts of it) is also generated. One testing
method used in this setting is the so-called on-the-fly
testing. As in the case of on-the-fly model checking,
instead of generating the system state space fully before
deriving tests (which yields scalability issues), the system
state space is dynamically explored by using the system
model as a test driver.[3] Other methods produce test code
directly from the system model, e.g., for integration tests
from collaboration diagrams[1] or for unit tests from
An advantage of the system model-driven approach is
that only one model is used. Thus, modeling expenditures
are reduced and inconsistencies between system and tests
are limited. However, it also has a big disadvantage: since
system and test system are produced from the same source,
the independence of the system and the test is missing: the
tests can only check whether the system model is correctly
realized in the system itself but cannot identify errors that
are already contained in the system model. The single
source issue makes the test of limited power.