Injection of faults at component interfaces and inside the component code: are they equivalent?

Abstract

The injection of interface faults through API parameter corruption is a technique commonly used in experimental dependability evaluation. Although the interface faults injected by this approach can be considered as a possible consequence of actual software faults in real applications, the question of whether the typical exceptional inputs and invalid parameters used in these techniques do represent the consequences of software bugs is largely an open issue. This question may not be an issue in the context of robustness testing aimed at the identification of weaknesses in software components. However, the use of interface faults by API parameter corruption as a general approach for dependability evaluation in component-based systems requires an in depth study of interface faults and a close observation of the way internal component faults propagate to the component interfaces. In this work we present the results of experimental evaluation of realistic component-based applications developed in Java and C using the injection of interface faults by API parameter corruption and the injection of software faults insidethe components by modification of the target code. The faults injected inside software components emulate typical programming errors and are based on an extensive field data study previously published. The results show the consequences of internal component faults in several operational scenarios and provide empirical evidences that interface faults and software component faults cause different impact in the system.

The impact of fault models on software robustness evaluations

“…We reuse the SWIFI framework of [15,18] and extend it to perform comparisons, as initiated in [24]. In the following section we extend the work presented in [18] and develop generalized and formally accurate definitions the informally specified metrics so that they can be used for (a) any robustness evaluation that aligns with the generic method described in Section 2.1 and (b) quantitative comparisons, i.e.…”

“…incorrect computation results, are considered most critical for a given application. Furthermore, as the applied SWIFI framework did not support injections into CUE Servers, the comparison of models with differing fault locations as the one provided in [24] was impossible.…”

“…Although a multitude of fault models for software robustness evaluations are discussed in the literature, we are aware of only two attempts to compare models. Moraes et al [24] compared the effects of fault injections at different locations, i.e. at the IUE and inside of components providing services to the CUE.…”

“…Software-implemented fault injection (SWIFI) is a widely used approach for evaluating the robustness of software components. Recent research [24,18] indicates that the selection of the applied fault model has considerable influence on the results of SWIFI-based evaluations, thereby raising the question how to select appropriate fault models (i.e. that provide justified robustness evidence).…”

Robustness Evaluation of Operating Systems

“…Finally, in [Moraes et al, 2006] the authors note that errors appearing at interfaces of components, though being useful for robustness evaluation, do not necessarily represent faults in the code. Since we are indeed focusing on robustness, interface errors are relevant.…”