1 / 20

Automatic Identification of Bug-Introducing Changes .

Automatic Identification of Bug-Introducing Changes. Presenter: Haroon Malik. Abstract. Bug-fixes do not contain information about the change that initially introduced the bug. Extraction of bug-introducing changes is challenging.

Download Presentation

Automatic Identification of Bug-Introducing Changes .

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Automatic Identification of Bug-Introducing Changes. Presenter: Haroon Malik

  2. Abstract • Bug-fixes do not contain information about the change that initially introduced the bug. • Extraction of bug-introducing changes is challenging. • An algorithm to automatically and accurately identify a bug-introducing changes. • Algorithm can remove 30%~51% of false positive and 14%~15% of false negative to previous algorithm.

  3. Introduction • Software project control their changes using SCM and capture bug reports using bug tracking software e.g Bugzilla. • Records which changed in SCM system fixes a Specific bug in the change tracking system. • Bug Progression: • Programmer makes the change • Bug-introducing change • Bug manifest itself in some undesirable external behavior. • Recorded in bug tracking system • Developer modifies the code to fix bug • Bug-fix change

  4. Introduction (Cont’d) • Wide spread use of SCM, data concerning bug fix changes in readily availble. • It is easy to mine SCM repository to mine changes that have repaired a bug • Linking key words with bug report refrence • E.g: “Bug” or “Fixed” #902340

  5. Major Problems with bug-fix data • It shed no light on when a bug was injected • Not always person who fixes a bug is one who caused • Can not determine where a bug occurred.

  6. Background • SZZ Algoritham • Working: • Firstly locates key words to mark bug-fixed changes • Secondly, running a diff tool what changed in bug-fix • Diff tool returns “Hunk” • Utilizes annotate feature of SCM to find the changes • Most recent revision • Who made the chage

  7. Background (Cont’d) • Revision1: Origin of bug (Line 3). • Revision 2: Function name changed (bar foo). • Revision 3: Bug removal

  8. SZZ Limitations • Blank spaces and Comments • Formatting changes (Line 3) • Name of function containing bug.

  9. Proposed Approach • Applied of method level for two java open source projects • Columba and Eclipise • Two human judges manually verified all hunk in series of bug-fix to ensure the corresponding hunks are real bug fixes.

  10. Proposed Approach • Steps(1-5) remove 38%~51% of false positive and 14%~15% of false negatives as compared to SZZ.

  11. Experimental setup • History Extraction • Used Kenyon to extract histories from SCM systems

  12. Experimental setup (Cont’d) • Accuracy Measures • Bug-introducing change set consists of all the changes with in specific project revisions that have been identified as bug-introducing • Assuming R is the more accurate bug-introducing change set, then compute false positives and false negatives for the set P can be computed as follow:

  13. Annotation Graph • Annotation Graph • A graph which contains information on the cross-revision mappings of individual lines. • Major improvement over the SZZ

  14. Experimental setup (Cont’d) • Non behavior changes • Code format, comments & blank lines. • 14%~20% false positive • Format changes

  15. Manual Verification • If a change log indicates the revisions is a bug-fix, it is assumed all the hunks in revision are bug fixes. • Two humans judges marked each bug-fix hunk for both projects. • Used bug-fix hunk verification tool

  16. Real Bugs?

  17. Validation Hurdles • Non representative systems. • Open Source. • Bug fix data is incomplete. • Manual Varicication

  18. Bug-Introduction Statistics Eclipse Columba

  19. Conclusion • Refined SSZ approach by introducing Annotation Graph. • Experiments showed the achievement of 38~51% of false positive and 14% of false negative removal as compared to SSZ

  20. Thank You

More Related