Model
Although the mutation operators proposed in Section 5.2 are generic, we combine the use of UML stereotypes and OCL constraints to enable software engineers to configure the mutation process to
5.3. Configuring Mutation Operators to Apply a Specific Fault Model
Table 5.1. Mapping between the SES-DAQ fault model of Table 2.1 and mutation oper- ators and configurations.
Fault Mutation Operator Configuration
Duplicate CADU Class Instance Duplication. «InputData»†
Duplicate ISP Class Instance Duplication. «InputData»†, «Derived»
Missing CADU Class Instance Removal. «InputData»†
Missing ISP Class Instance Removal. «InputData»†, «Derived» Wrong CADU Sequence Class Instances Swapping. «InputData»†
Wrong ISP Sequence Class Instances Swapping. «InputData»†, «Derived», Query to select packets Incorrect Identifier Attribute Replacement with Random. «Identifier», «Derived»‡ Incorrect Checksum Attribute Replacement with Random. «Identifier»
Incorrect Counter Attribute Replacement using Boundary Condition.
«Measure», «Derived»‡
Flipped Data Bits Attribute Bit Flipping. –
†This stereotype need only be applied to the root input container class.‡If necessary.
Note: CADU, Channel Access Data Unit; ISP, Instrument Source Packet.
generate data that matches the specific fault model of the SUT.
The technique presented here simply requires that software engineers annotate the attributes and the classes of the data model with stereotypes that specify the nature of these attributes/classes. Mu- tation operators are then applied to the data according to the stereotypes used. Table 5.1 shows the mutation operators and the corresponding configurations (i.e. stereotypes and queries) that enable the specific faults of the SES-DAQ fault model (Table 2.1). The mutation operator Attribute Bit Flipping does not require the application of a specific stereotype; it is applied on all the attributes not annotated with other stereotypes.
Data mutation may lead to the generation of inconsistent data containing multiple errors that do not enable proper system testing. In particular, it might lead to the generation of trivial faults that do not comply with the given fault model or that mask the intended effect of the mutation operator, thus preventing the possibility to cover the whole fault model.
In the running example, a trivial fault may mask the effect of a mutation operator applied to one of the following attributes (shown in Fig.3.1) of class VcduHeader: versionNumber, spacecraftId, and virtualChannelId. Any change to the values of one of these attributes makes the value of the check symbols (used for error-correction) within attribute headerErrorControl inconsistent. The at- tribute headerErrorControl of class VcduHeader is calculated by applying the Reed-Solomon algo- rithm [Wicker and Bhargava, 1999] against the bit fields that correspond to attributes versionNumber, spacecraftId, and virtualChannelId. For example, mutating the attribute virtualChannelId leads to an inconsistent (wrong) value for the attribute headerErrorControl. In practice, this may prevent testing the effect of a wrong value for the attribute virtualChannelId since the software first verifies the correctness of the check symbols. To properly evaluate the effect of a fault in one of the three attributes of class VcduHeader that are protected by the check symbols, the value of the attribute headerErrorControl should be recalculated (i.e. considering the updated mutant value assigned to
Chapter 5. Automatic Test Input Generation
1 context Isp::cis() : Set(Isp) body:
2
3 let
4 packet1 : Isp = Isp.allInstances()->any(true),
5 vcid : Integer = packet1.mpduActivePacketZone->first().vcdu.vcduHeader.virtualChannelId.intValue,
6 packet2 : Isp =
7 packet1.channelDataPerVcid->select(cd | cd.virtualChannelId = vcid).isp
8 ->select(p | p <> packet1)->any(true)
9 in
10
11 Set { packet1, packet2 }
Figure 5.2. OCL query for the swapping of two packets.
attribute virtualChannelId).
Inconsistent data might also be caused by mutation operators that target class instances. For example, the swapping of packets (represented by the class instances of Isp in Figs. 3.1 and 3.2) that belong to two different virtual channels may lead to the generation of VCDUs that contain packets with invalid APIDs (i.e. inconsistent data). The goal of the swapping operator is, rather, that of generating sequences of packets received in a wrong order. The class instances swapping operator should thus be applied only to instances of the class Isp that belong to the same virtual channel.
To preserve data consistency, we enable software engineers to configure the behaviour of mutation operators by means of OCL queries and UML stereotypes.
OCL queries are used to enable software engineers to specify the characteristics of the object instances on which the mutation operators can be applied. By default, a mutation operator is applied on randomly chosen objects in the absence of an OCL query that configures its behaviour.
Fig. 5.2 shows an example of an OCL query that regulates the swapping of instances of class Isp. Line 1 in Fig. 5.2 indicates that the OCL query controls the application of the operator Class Instances Swapping (CIS)on class instances of type Isp; the query returns a set containing the Isp instances to be swapped (line 11). Line 4 shows the OCL expression that selects the first parameter (this query simply indicates that any Isp instance might be used as first parameter of the CIS operator). Lines 5 to 8 indicate how the second parameter of the CIS operator should be selected. The query identifies the virtual channel (i.e. vcid) that the Isp instance, packet1, belongs to (line 5), and then selects a different Isp instance, packet2, that belongs to this same virtual channel (lines 6 to 8).
We defined a UML stereotype, «Derived», that enables software engineers to specify which at- tributes need to be updated after certain mutations in order to prevent trivial errors. The stereotype requires that software engineers specify the name of a method that is invoked at runtime by the muta- tion framework to regenerate the value of the annotated attribute. The implementation of this function should be provided by the software engineer and we expect to find the method in the class path. Such implementations should match methods present in the SUT, which are expected to be unit tested.
Fig. 3.1 shows that the attribute headerErrorControl of class VcduHeader has been annotated with the stereotype «Derived». In this case, the attribute is associated with a utility function named Util.reedSolomon (a method available in the SES-DAQ implementation) that recalculates the check symbols (e.g. following the mutation of a spacecraftId field).
5.4. Augmenting the Model for Automated Data Mutation