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.