Research issues in software fault categorization

Ploski, Jan; Röhr, Matthias; Schwenkenberg, Peter; Hasselbring, Wilhelm

doi:10.1145/1317471.1317478

Cited by 23 publications

(14 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Ploski et al (2007) provided a comparison among different categorization approaches of software faults. They studied six distinguished works (Knuth 1989;Beizer 2003;Gray 1986;Chillarege et al 1992;Eisenstadt 1997;DeMillo and Mathur 1995) and presented a roadmap for the development of a fault categorization schema.…”

Section: Categorization Approachesmentioning

confidence: 99%

Charting the API minefield using software telemetry data

2014

View full text Add to dashboard Cite

Programs draw significant parts of their functionality through the use of Application Programming Interfaces (APIs). Apart from the way developers incorporate APIs in their software, the stability of these programs depends on the design and implementation of the APIs. In this work, we report how we used software telemetry data to analyze the causes of API failures in Android applications. Specifically, we got 4.9 GB worth of crash data that thousands of applications sent to a centralized crash report management service. We processed that data to extract approximately a million stack traces, stitching together parts of chained exceptions, and established heuristic rules to draw the border between applications and the API calls. We examined a set of more than a half million stack traces associated with risky API calls to map the space of the most common application failure reasons. Our findings show that the top ones can be attributed to memory exhaustion, race conditions or deadlocks, and missing or corrupt resources. Given the classes of the crash causes we identified, we recommend API design and implementation choices, such as specific exceptions, default resources, and non-blocking algorithms, that can eliminate common failures. In addition, we argue that development tools like memory analyzers, thread debuggers, and static analyzers can prevent crashes through early code testing and analysis. Finally, some execution platform and framework designs for process and memory management can also eliminate some application crashes.

show abstract

Section: Categorization Approachesmentioning

confidence: 99%

Charting the API minefield using software telemetry data

2014

View full text Add to dashboard Cite

show abstract

“…The Orthogonal Defect Classification (ODC), for example, is designed to provide feedback to developers to reduce the introduction of new faults [1]. Ploski et al report on several attributes of six widely varying schemes, including the purpose of the classification scheme [2].…”

Section: Background and Related Workmentioning

confidence: 99%

A decision support system for the classification of software coding faults

Kidwell

2011

Proceedings of the 33rd International Conference on Software Engineering

View full text Add to dashboard Cite

A decision support system for fault classification is presented. The fault classification scheme is developed to provide guidance in process improvement and fault-based testing. The research integrates results in fault classification, source code analysis, and fault-based testing research. Initial results indicate that existing change type and fault classification schemes are insufficient for this purpose. Development of sufficient schemes and their evaluation are discussed.

show abstract

“…Many researchers have attempted to answer this question and have developed corresponding taxonomies (see for instance [17] [18]). These taxonomies were built to satisfy a wide range of underlying motivations (e.g., understanding root causes of programming mistakes, developing fault tolerance measures, or facilitating testing [19]) which have infl uenced the classifi -cation scheme. In this paper, we classify errors with respect to their impact in terms of physical variations of the code since we are interested in the type and location of secondary faults.…”

Section: Repair Error Taxonomymentioning

confidence: 99%

Predicting the types and locations of faults introduced during an imperfect repair process and their impact on reliability

Song

Smidts

2010

Int J Syst Assur Eng Manag

View full text Add to dashboard Cite

Imperfect debugging of software development faults (called primary faults) will lead to the creation of new software faults denoted secondary faults. Secondary faults are typically fewer in numbers than the initial primary faults and are introduced late in the testing phase. As such it is unlikely that they will be observed during testing and their failure characteristics are unlikely to be assessed accurately. This is an issue since they may possibly display different propagation characteristics than the primary faults that led to their creation. In particular their location will be distributed non-uniformly around the fault being fi xed. This paper proposes a methodology to assess the impact of secondary faults on reliability-based on predicting their possible types and locations. The methodology combines a fault taxonomy, code mutation and Bayesian statistics. The methodology is applied to portions of the application software code of a nuclear reactor protection system. This paper concludes with a discussion on the integration of the results within existing Software Reliability Growth Models.

show abstract

Research issues in software fault categorization

Cited by 23 publications

References 12 publications

Charting the API minefield using software telemetry data

Charting the API minefield using software telemetry data

A decision support system for the classification of software coding faults

Predicting the types and locations of faults introduced during an imperfect repair process and their impact on reliability

Contact Info

Product

Resources

About