Isolating relevant component interactions with JINSI

Orso, Alessandro; Joshi, Shrinivas; Bürger, Martin; Zeller, Andreas

doi:10.1145/1138912.1138915

Cited by 25 publications

(19 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Finally, we plan to explore more aggressive ways to cluster, filter, and abstract changes before presenting them to the developers. In this context, we may also be able to leverage bug isolation techniques targeted at specific parts of the code (e.g., [19]) to further reduce the developers' inspection efforts. We also plan to investigate filtering of the behavioral differences based on diversity metrics other than distance of dynamic call graph (e.g., [20]), which may provide more accurate feedback to the developers.…”

Section: Discussionmentioning

confidence: 99%

Automated Behavioral Regression Testing

Jin

Orso

Xie

2010

2010 Third International Conference on Software Testing, Verification and Validation

Self Cite

View full text Add to dashboard Cite

When a program is modified during software evolution, developers typically run the new version of the program against its existing test suite to validate that the changes made on the program did not introduce unintended side effects (i.e., regression faults). This kind of regression testing can be effective in identifying some regression faults, but it is limited by the quality of the existing test suite. Due to the cost of testing, developers build test suites by finding acceptable tradeoffs between cost and thoroughness of the tests. As a result, these test suites tend to exercise only a small subset of the program's functionality and may be inadequate for testing the changes in a program. To address this issue, we propose a novel approach called BEhavioral Regression Testing (BERT). Given two versions of a program, BERT identifies behavioral differences between the two versions through dynamical analysis, in three steps. First, it generates a large number of test inputs that focus on the changed parts of the code. Second, it runs the generated test inputs on the old and new versions of the code and identifies differences in the tests' behavior. Third, it analyzes the identified differences and presents them to the developers. By focusing on a subset of the code and leveraging differential behavior, BERT can provide developers with more (and more detailed) information than traditional regression testing approaches. To evaluate BERT, we implemented it as a plug-in for Eclipse, a popular Integrated Development Environment, and used the plug-in to perform a preliminary study on two programs. The results of our study are promising, in that BERT was able to identify true regression faults in the programs.

show abstract

Section: Discussionmentioning

confidence: 99%

Automated Behavioral Regression Testing

Jin

Orso

Xie

2010

2010 Third International Conference on Software Testing, Verification and Validation

Self Cite

View full text Add to dashboard Cite

show abstract

“…More importantly, Jinsi is able to isolate a failure-inducing sequence of calls. This work is an extension of an earlier work [15] by Orso et al The work from Orso et al [15] isolates relevant interactions between the observed component and other layers of a complex application. The work combines record and replay technique with delta debugging [26] to isolate relevant events.…”

Section: Related Workmentioning

confidence: 75%

Locating failure-inducing environment changes

Ngo

Sun

et al. 2011

Proceedings of the 10th ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools

View full text Add to dashboard Cite

Traditionally, debugging refers to the process of locating the program portions which are responsible for a program failure. However, a program also fails when the execution environment does not meet the requirement/assumption of the program. Unfortunately, few existing debugging techniques addresses the problem of changing operating system environment. In this paper, we propose an effective record-replay technique called Semi-replay to solve this problem. Semi-replay records all the essential interactions between an application and its underlying operating system environment where it successfully executed. Semi-replay then allows the recorded interactions to be partially replayed and partially executed in another operating system to identify those interactions which contribute to the root cause of the application failure induced by the environment changes. We have conducted three case studies on real-life programs which show the significance and efficiency of the Semi-replay technique in locating failure-inducing environment changes. We have also implemented a tool for the Linux kernel to demonstrate the feasibility of the proposed approach.

show abstract

“…In earlier work [10], we had presented JINSI, a tool to assist debugging by capturing and minimizing the interaction of a component. As sketched in Figure 2, JINSI wraps around a component and records its interaction with the environment for later replay.…”

Section: Wwwcolumbamailorgmentioning

confidence: 99%

“…To make this paper self-contained, let us give a brief overview of the original JINSI technique at first, as described in [10] and [11]. JINSI works in two phases:…”

Section: The Original Jinsi Approachmentioning

confidence: 99%

See 1 more Smart Citation

Replaying and isolating failing multi-object interactions

Bürger

Zeller

2008

Proceedings of the 2008 International Workshop on Dynamic Analysis: Held in Conjunction With the ACM SIGSOFT International Symp

Self Cite

View full text Add to dashboard Cite

When a program fails, there are typically multiple objects that contribute to the failure. Our JINSI tool automatically captures the failure-causing interaction between objects and isolates a sequence of calls that all are relevant for reproducing the failure. In contrast to existing work, JINSI also isolates relevant interaction within the observed component and thus across all layers of a complex application. In a proof of concept, JINSI has successfully isolated the interaction for a failure of the COLUMBA e-mail client, pinpointing the defect: "Out of the 187,532 interactions in the addressbook component, two incoming calls suffice to reproduce the failure."

show abstract

Isolating relevant component interactions with JINSI

Cited by 25 publications

References 6 publications

Automated Behavioral Regression Testing

Automated Behavioral Regression Testing

Locating failure-inducing environment changes

Replaying and isolating failing multi-object interactions

Contact Info

Product

Resources

About