![](bg6.png)
3.1 Preprocessing
As previously described in Section 2.1.1, the inte-
gration model enables modelers to specify connec-
tions between elements of the system and test model.
Those connections are used to determine the start
node and possible end nodes for the verification pro-
cess of this test case. For example, the initial system
node of a test case execution is either explicitly spec-
ified by a linked model artifact of the respective sys-
tem model part, or implicitly determined by the initial
node of the system model part. The same holds for fi-
nal system nodes of a test case execution, which may
be specified explicitly. All the mapping information
given for intermediate model artifacts are processed
according to the merged paths rule set detailed in the
following section
Basically, a connection is relevant for the process,
if it includes a test model element of the test case un-
der analysis. Therefore, at least one relevant connec-
tion needs to be specified to validate the test case.
3.2 Abstract Test Case Verification
The first step of the abstract test case verification
(ATCV) is to integrate the test case into one of sev-
eral associated paths of the system model. Thereby,
each element of the test case is merged into paths of
the system model, with respect to the previously de-
termined start node and possible end nodes. These so
called merged paths are derived with regard to the fol-
lowing rules. First, the sequence of the elements of a
path is always retained. Second, test steps are always
inserted before guards of the system model. Third,
verification points are always added after guards of
the system model, if the associated verification point
is not connected to the integration model. Otherwise,
in consideration of rule two, the verification point is
inserted after the connected system node and subse-
quent guard if the affected transition is guarded.
In consideration of the running example, the
merging process is shown in Figure 4. There, a par-
tial path of the test model is merged into a sub path of
the system model by following the predefined rules.
The possible merge spots are accentuated by dotted
arrows. As a result, six valid merged paths exist.
It should be mentioned that the instructions of the
merged paths are compacted versions of the instruc-
tions of the test and system model, clarified by brack-
ets. In general, the combination of one test case and
one path of the system model can possibly result in
multiple merged paths as seen in Figure 4. We restrict
the number of generated merged paths to be consid-
ered in this case, since the sheer number of node com-
binations can easily explode. Please note that this re-
striction does not limit the merging of the test case
with other paths of the system model. For short, ev-
ery test case can be merged with several paths of the
system model, whereby every merging of two differ-
ent paths results in exactly one merged path. Thus,
the validation of one test case can take several merged
paths into account.
This lazy evaluation minimizes the workload, but
due to path restriction can lead to falsely unfulfill-
able test cases, as shown in Figure 4. To compen-
sate this, we allow the over-assignment of variables.
Thus, every variable can have multiple valid values.
In general, the system state is determined by vari-
ables introduced by modifying instructions contained
in the merged path. Modifying instructions modify
the value of a contained variable. In contrast, veri-
fying instructions evaluate the system state by com-
paring the set of variables with their expected values.
Due to over-assigned variables, multiple system states
can be valid at the same time, which solves the prob-
lem of falsely unfulfillable test cases.
In general, a merged path consists of instructions,
which modify or verify the system state. Overall,
modifying instructions alter the system state, whereas
verifying instructions check if a certain system state is
reached. The system model consists of guards, which
are verifying instructions and nodes, which possibly
contain modifying instructions. The test model holds
test steps and verification points. The former are able
to contain modifying instructions, whereas the latter
can hold verifying instructions.
When analyzing a merged path, guards are gener-
ally ignored during path exploration, but a fault is reg-
istered whenever a guard may not be evaluated posi-
tively, i.e. a guard may not be fulfilled. A fault is also
registered if a mapped end node can not be reached.
Another fault is the detection of an unknown variable
in an instruction. Whenever a variable is initialized
or updated, the new value is interpreted and then as-
signed to the identifier. The uninterpreted value is
able to contain variable identifiers and mathematical
or logical operators. All variable identifiers are re-
solved and their associated values are merged by us-
ing the operators. Whenever a variable identifier is
not resolvable, a fault is registered, except when a ver-
ification point contains an unknown variable then the
analysis of the merged path will be terminated and the
resulting report is not considered as result of the test
case. Therefore, we differentiate between the follow-
ing faults (F
x
):
(F
1
) A verification point is unfulfillable or challenged
with an over-assigned variable
(F
2
) A guard could not be fulfilled
Towards Abstract Test Execution in Early Stages of Model-driven Software Development
221