8.2 Test Model Scoping
8.2.3 Test Model Split and Enrichment
The last remaining process step in the context of Test Model Scoping is theTest Model Split and Enrichment. During processing, the Filtered Test Model of theTest Model Map-
Reconstructed Test Model Filtered Integration Model
<<IMComponent>>
System
<<IMFunctionality>>
CSM
<<IMComponent>>
CSM
<<IMFunctionality>>
CSM_ON
<<IMFunctionality>>
calc_speed_onboard
<<EGPPGraph>>
System
<<EGPPGraph>>
CSM Integration
<<EGPPGraph>>
CSM_ON Integration
<<EGPPGraph>>
calc_speed_onboard Unit
Filtered Test Model
<<EGPPGraph>>
System
<<EGPPGraph>>
CSM Integration
<<EGPPGraph>>
CSM_ON Integration
<<EGPPGraph>>
calc_speed_onboard Unit
Figure 8.5: Algorithmic approach forTest Model Mapping and Reconstructionapplied to the Running Example
ping and Reconstructionstep is split into independent Test Models of uniform integration level and thus do no longer include any hierarchy information. In this step, the set of resulting Test Models can be enriched with information from the Omni Model. This is especially beneficial if this information can be used profitably by external test case generators.
The concepts are illustrated by a schematic representation (see figure 8.6). On the left side of the figure, the starting point is given by the Filtered Test Model.
Filtered Test Model Test Models
Scoped Test Model
Scoped Test Model Scoped Test Model
Enriched Test Models Scoped Test Model
Scoped Test Model Scoped Test Model
OM
OM OM
OM
Figure 8.6: Algorithmic approach for Test Model Split and Enrichment
The model artifacts excluded from the fully-blown Test Model are again displayed in gray color. For the generation of test cases and their subsequent execution, however, it is difficult when test cases of different integration levels appear mixed.
Therefore, the goal of the Filtered Test Model decomposition is to create a set of Test Models that each represent a uniform integration level and can therefore be considered in isolation. I.e. the connection between model elements of the sub-model of the higher integration level and the sub-models of the integration level below have to be suitably
resolved. In the context of the EGPP-based representation of the Test Models, such connections are modeled by anEGPPGraph node in the control flow of the sub-model of higher integration level and a graph contained therein, which describes the sub- model of the integration level below. This can be achieved by extracting the model elements of the included graph and keeping only the stub model information on the EGPPGraph. The concepts of these stub models have been discussed in section 7.2.2, a concrete application is shown in chapter 10. In the middle part of figure 8.6, these stub models are visualized by squares included in the control flow. The model elements extracted from the graph form an independent Test Model. In total, three independent and semantically correct Scoped Test Models are created from the three original sub- models of the Test Model.
After the set of Scoped Test Models is determined, it is possible, to annotate the model components with additional information from the Omni Model. In this way, informa- tion available within the MCSTLC can be made available for external tools. This can improve the quality of the resulting test cases significantly and the necessary documen- tation, e.g. the generated test reports, can be improved. The constructEGPPTaggedData is used to implement a flexible annotation mechanism. In particular, it is possible to specify the information for individual model elements of the Test Model. Furthermore, additional information can be annotated for the entire EGPPGraphof a Test Model. In figure 8.6 the dotted lines in the right area indicate how the information is assigned.
An example of such data is linked requirements that justify the linked tests, or quantifi- cation of investigations regarding the safety evaluation of certain system parts, respec- tively the relevance of the assigned test cases.
Finally, this section refers to the Running Example by applying the steps just presented to the intermediate Test Model of the previous section. Figure 8.7 shows on the left side the initial situation and on the right side some relevant sections of the resultingScoped Test Models.
Filtered Test Model
<<EGPPGraph>>
System
<<EGPPGraph>>
CSM Integration
<<EGPPGraph>>
CSM_ON Integration
<<EGPPGraph>>
calc_speed_onboard Unit
Scoped Test Models
<<EGPPGraph>> CSM Integration
<<EGPPGraph>>
CSM_ON Integration
<<EGPPGraph>>
calc_speed_onboard Unit
calc_speed_onboard (0) V_mrsp = 115
status = 0 V_mrsp = 110 speedOnboard == V_mrsp
Other paths
...
...
Other paths
...
...
V_est = 125 DMICmd == 2
Figure 8.7: Algorithmic approach forTest Model Split and Enrichmentapplied to the Run- ning Example
The Test ModelCSM Integrationis included in the figure for completeness, but con-
tains no information about the included test paths. In contrast, theCSM_ON Integra- tion, as well as the calc_speed_onboard Unit Test Model give insight into details.
The first one shows an example path from the set of paths (test cases), which includes a call of the method/function, tested by the second Test Model. Moreover, the stub model is introduced, visualized as a rectangle. The nodes with rounded corners are EGPPNodes, containing atomic statements of the resulting test cases. This way, a large number of tests are mapped in the model. In figure 8.7 these remaining parts of the graph are represented by the nodes with the labels “|other paths|” or “|...|”. The same holds for the second graphcalc_speed_onboard, which, unlike the other graph, does not contain any stub models.