Identifying modules which do not propagate errors

Abstract

Our goal is to identify software m o dules that have some locations which do not propagate errors induced by a suite of test cases. This paper focuses on whether or not data state errors can propagate from a location in the code to the outputs or observable data state during random testing with inputs drawn from an operational distribution. If a c ode-location's probability of propagation is estimated t o b e zero, then a fault in that location could escape detection during testing. Because testing is never exhaustive, there is a risk that failures due to such latent faults could occur during operations.Fault injection is a technique for directly measuring the probability of propagation. However, measurement for every location in the code of a full-scale program is often prohibitively computation-intensive. Our objective is a practical, useful alternative to direct measurement.We present empirical evidence that static software p r oduct metrics can be useful for identifying software m o dules where the e ects of a fault in that module are not observable. A case study of an intricate computer game program revealed a useful empirical relationship between static software p r oduct metrics and propagation of errors. The case study program was an order of magnitude larger than previously reported studies.Readers may contact the authors through Taghi

Probabilistic error propagation model for mechatronic systems

“…The authors use instrumented middleware to discover potential failure points in the application. Khoshgoftaar et al [16] describe identification of software modules, which do not propagate errors, induced by a suite of test cases. A number of papers depict the influence of software error propagation phenomena on system reliability [17,18].…”

An empirical analysis of error propagation in critical software systems

“…Results indicate that the metrics allow to identify candidate modules to be equipped with detection/recovery mechanisms. In Khoshgoftaar et al (1999) it is presented an approach to identify software modules that do not propagate data errors. The work demonstrates -through experimentation on the Nethack adventure game-that static software metrics are good predictors for the identification of such modules, avoiding the evaluation of their error propagation probability.…”

“…But, differently from us, they rely on a users-based collaborative framework to collect past failure data from past experiences with the web services to be composed. With respect to Leeke (2011), Jhumka et al (2001), and Khoshgoftaar et al (1999) our approach is not limited to data errors and it does not require to monitor the output of each component (Voas 1997). In addition, with respect to Yuan et al (2010), our approach does not require static analysis of the source code, which can be either expensive in a large system or inapplicable when the code is not available.…”

Scenario-based reliability analysis of component-based software

“…The algorithm assumes that each component is wrapped such that failures in one component do not propagate [Khoshgoftaar+99] to another component in the "AND" path and hence independent assumption could be valid.…”