The paper explores Static Execute After (SEA)

In this paper, we introduce

No abstract

Although the slicing of programs written in a high-level language has been widely studied in the literature, very little work has been published on the slicing of binary executable programs. The lack of existing solutions is really hard to understand since the application domain for slicing binaries is similar to that for slicing high-level languages. In this paper we present a method for the interprocedural static slicing of binary executables. We applied our slicing method to real size binaries and achieved an interprocedural slice size of between 56%-68%. We used conservative approaches to handle unresolved function calls and branching instructions. Our current implementation contains an imprecise (but safe) memory dependence model as well. However, this conservative slicing method might still be useful in analysing large binary programs. In the paper we suggest some improvements to eliminate useless edges from dependence graphs as well.

No abstract

Impact analysis plays an important role in many software engineering tasks such as software maintenance, regression testing and debugging. In this paper, we present a static method to compute the impact sets of particular program points. For large programs, this method is more effective than the slightly more precise slicing. Our technique can also be used on larger programs with over thousands of lines of code where no slicers can be applied since the determination of the program dependence graphs, which are the bases of slicing, is an especially expensive task. As a result, our method could be efficiently used in the field of impact analysis. Keywords impact analysis • execute after and execute before relations • program slicing Acknowledgement The author wishes to thank the co-porative work of Árpád Beszédes, Tamás Gergely, Tibor Gyimóthy and Vaclav Rajlich.

Assessing the overall quality (adequacy for a particular purpose) of existing test suites is a complex task. Their code coverage is a simple yet powerful attribute for this purpose, so the additional benefits of mutation analysis may not always justify the comparably much higher costs and complexity of the computation. Mutation testing methods and tools slowly start to reach a maturity level at which their use in everyday industrial practice becomes possible, yet it is still not completely clear in which situations they provide additional insights into various quality attributes of the test suites. This paper reports on an experiment conducted on four open source systems' test suites to compare them from the viewpoints of code coverage, mutation score and test suite reducibility (the amount test adequacy is degraded in a reduced test suite). The purpose of the comparison is to find out when the different attributes provide additional insights with respect to defect density, a separately computed attribute for the estimation of real faults. We demonstrate that in some situations code coverage might be a sufficient indicator of the expected defect density, but mutation and reducibility are better in most of the cases.

Abstract-Impact analysis based on code dependence can be an integral part of software quality assurance by providing opportunities to identify those parts of the software system that are affected by a change. Because changes usually have far reaching effects in programs, effective and efficient impact analysis is vital, which has different applications including change propagation and regression testing. Static Execute After (SEA) is a relation on program elements (procedures) that is efficiently computable and accurate enough to be a candidate for use in impact analysis in practice. To assess the applicability of SEA in terms of capturing real defects, we present results on integrating it into the build system of WebKit, a large, open source software system, and on related experiments. We show that a large number of real defects can be captured by impact sets computed by SEA, albeit many of them are large. We demonstrate that this is not an issue in applying it to regression test prioritization, but generally it can be an obstacle in the path to efficient use of impact analysis. We believe that the main reason for large impact sets is the formation of dependence clusters in code. As apparently dependence clusters cannot be easily avoided in the majority of cases, we focus on determining the effects these clusters have on impact analysis.