D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Legend:
Fig. 5. Basic testing concepts
– requirement: statement about what the system should do
– test model: dedicated model for capturing the expected SUT behavior (Class diagram, State machine)
– test case: a finite sequence of test steps
– test intention: user’s view of testing needs
– test suite: a finite set of test cases
– test script: executable version of a test case
– test step: operation’s call or verdict computation
– test objective: high level test intention.
etc.) have been performed. Test may have a status new in case of a newly generated test
for a newly introduced target.
If none of the model elements covered by the test is impacted, the test is run as
is on the new version of the model M ′ , without modifying the test sequence. The test
is thus said to be reusable. More precisely, there are two cases: unimpacted and reexecuted.
A test is unimpacted if the test sequence is identical to its previous version,
and the covered requirements still exist. The test is re-executed if it covers impacted
model elements, but it can still be animated on the new version of the model without
any modification.
If a test covers model elements impacted by the evolution from M to M ′ , and if the
test cannot be animated on M ′ the test becomes obsolete. There are two cases: either
the target represents deleted model elements, and thus the test does not make any sense
on M ′ and it is said to be outdated, or, the test fails when animated on model M ′ (e.g.
due to a modification of the system behaviour), it is then failed. When the test case
operations can be animated but produce different outputs, a new version of the test is
created in which the expected outputs (i.e. the oracle) are updated w.r.t. M ′ . In this case
the tests have the status updated. When the test case operations can not be animated as
is in the first version of the test, a new operation sequence has to be computed to cover
the test target. In the latter case, tests have status adapted.
To determine the status of a test when evolution takes place, the SeTGaM approach
relies on dependency analysis that is performed to compute the differences between the
models, and their impacts on test cases. We have four different classification suites.
– evolution test suite contains tests classified as new and adapted;
8