Model-Based Round-Trip Engineering and Testing of Evolving Software Product
7.1 Foundations
7.1.2 Model-Based Product-Line Engineering and Testing
dependent sibling child features may be assembled into feature groups, being either or groups (i.e. at least one of its features must be selected if the parent feature is selected), oralternative groups(i.e.exactly onefeature must be selected).
For instance, aCraneeither usesStandard Routing,orExtended Routing, whereas the set of types of supported Plastic WP may include Dark, Light, as well as both in combination. Finally, further dependencies between hierarchically unrelated features can be expressed using cross-tree constraints (e.g. Work Pieces made of Light Plastic require a Stamp with Adaptive Pressure). The set of all valid configurations according to the xPPU feature model is given in Fig.7.5b. Please note that—due to space limitations—we omitted the second half of configurations, which only differs from the given ones by havingERoutingselected instead ofSRouting.
Further note that the first three configurations correspond to the xPPU variantsv1, v2, andv3, as described above.
In the next step of SPLE, a mappingof configuration-specific solution-space artefacts onto corresponding feature selections is defined, in order to relate con- figurations to respective parts in configurable test models and implementation code of the product line.
Solution Space Features not only denote configuration parameters in the problem space but also refer tovariation pointswithin engineering artefacts in the solution space, potentially at all levels of abstraction [Ape+13]. Here, we use an annotation- based approach for a product-line representation of a product family, by integrating variability information into solution-space artefacts (i.e. test models, implementa- tion code, and test artefacts).
Presence Conditions for Variant-Knowledge At the level of design- and test models like STATECHARTS, variant-specific model elements (here: transitions) are equipped with annotations over propositional feature expressions, representing presence conditionsfor well-defined variation points in the solution space. Those model templates therefore virtually include (or superimpose) any possible model variant of the product line into one model, constituting a so-called150% model.
Hence, a configuration-specificmodel variant(i.e. a 100% model) can be obtained from a 150% model by projecting only those model elements whose presence con- ditions are satisfied by the respective feature selection of the configuration [CE00].
Figure 7.6a depicts the 150% test model for the xPPU product line, where the respective test-model variants for the configurationsv1,v2, andv3 correspond to the model variants, as described above.
A similar principle is frequently used in practice for integrating variation points into source-code artefacts of product-line implementations: conditional-compilation directives such as#ifmacro, as provided by the C preprocessor, allow for marking variable code parts (variation points), again, by using propositional formulae over (Boolean) feature variables as presence conditions [Käas+11]. Figure7.6b depicts the variable implementation source code of the xPPU example corresponding to the aforementioned 150% test-model extract.
Standard Run ExtractWP do / Cylinder.pullOut() [MatSensorDetected
&& !SensorMetal
&& SensorLight]
/WPPushedOut = true;
WPMaterial = 3
[MatSensorDetected
&& !SensorMetal
&& !SensorLight]
/WPPushedOut = true;
WPMaterial = 2 [MatSensorDetected
&& SensorMetal]
/WPPushedOut = true;
WPMaterial = 1;
[PressureAdjStatus]
/StatusLampBlue = true;
slideSort()
[MatSensorDetected
&& !SensorMetal]
/WPPushedOut = true;
WPMaterial = 2
[MatSensorDetected /WPPushedOut = true;
APressure SPressure ||
APressure
APressure
SPressure
!SPressure &&
!APressure t0
t1 t2
t3
t4 t5
t8
APressure t9 [!PressureAdjStatus &&
!(Cylinder.PushedOut &&
!MatSensorDetected)]
/ slideSort()
(a) (b)
Fig. 7.6 150% xPPU Test model. (a) Test model. (b) Code
Family-Based Product-Line Testing The additional knowledge in a product-line representation provided by the feature model and corresponding feature mappings onto a 150% test model provides opportunities for improving the efficiency of quality assurance of product families. To this end, family-based product-line analysis strategies aim at analysing whole product families at once instead of using a variant-by-variant approach [Thü+14a]. In particular, family-based test- suite generation potentially reduces the overall number of test-generator runs and therefore the number of required test cases for covering all members of a product family, as compared to considering every variant one by one, as described above [Bür+15a]. For this, the additional information provided by the presence conditions in 150% test-model specifications supports automated reasoning about (re-)usability of derived test cases among different variants. To do so, the set of presence conditions attached to those transitions located on the path being traversed in the test model by a test case for reaching a particular test goals is conjugated to form a presence condition for that particular test case (i.e. a so-calledSoftware product line (SPL) test case). The presence condition of an SPL test case, therefore, characterises exactly the set of configurations for which that test case is applicable.
Based on this notion, we call a set of SPL test cases anSPL test suite, and an SPL test suite is further calledcompleteif for each test goal in the 150% test model (being selected by a given coverage criterion as usual) and for each test-model variant there exists at least one SPL test case covering that test goal and whose presence condition is satisfied by the configuration of that variant (see [Bür+15a,Loc+14] for a precise definition).
As an example, applying family-based SPL test-suite generation to the 150% test model of the xPPU example (see Fig.7.6) for transition coverage may result in the followingcomplete SPL test suite:
• SPL test casetc1:=(t0, t1, t8);[SPressure APressure]
• SPL test casetc2:=(t0, t2, t9);[APressure]
• SPL test casetc3:=(t0, t3, t8);[APressure]
• SPL test casetc4:=(t0, t4, t8);[SPressure], and
• SPL test casetc5:=(t0, t5, t8)[!SPressure&&!APressure].
Here, the feature expressions given in brackets denote the respective presence conditions (i.e. test caset1 is applicable to the variantsv1 andv2; test cases t2, t3, t4 are applicable to variant v1; and test case t5 is applicable to variant v3).
Hence, the resulting test cases exactly correspond to those previously derived by using a variant-by-variant approach but now carry additional information about the respective implementation variants of the xPPU product line to which they are applicable. Hence, test cases being reusable among different product variants are generated only once using a family-based approach, thus reducing the number of (redundant) test-generator calls, as compared to a variant-by-variant approach.