Abstract:Defect localization aims to locate buggy program elements (e.g., buggy files, methods or lines of code) based on defect symptoms, e.g., bug reports or program spectrum. However, when we receive the defect symptoms, the defect has been exposed and negative impacts have been introduced. Thus, one challenging task is: whether we can locate buggy program prior to the appearance of the defect symptom (e.g., when buggy program elements are being committed to a version control system). We refer to this type of defect localization as “Just-In-Time (JIT) Defect localization”. Although many prior studies have proposed various JIT defect identification methods to identify whether a new change is buggy, these prior methods do not locate the suspicious positions. Thus, JIT defect localization is the next step of JIT defect identification (i.e., after a buggy change is identified, suspicious source code lines are located). To address this problem, we propose a two-phase framework, i.e., JIT defect identification and JIT defect localization. Given a new change, JIT defect identification will identify it as buggy change or clean change first. If a new change is identified as buggy, JIT defect localization will rank the source code lines introduced by the new change according to their suspiciousness scores. The source code lines ranked at the top of the list are estimated as the defect location. For JIT defect identification phase, we use 14 change-level features to build a classifier by following existing approach. For JIT defect localization phase, we propose a JIT defect localization approach that leverages software naturalness with the N-gram model. To evaluate the proposed framework, we conduct an empirical study on 14 open source projects with a total of 177,250 changes. The results show that software naturalness is effective for our JIT defect localization. Our model achieves a reasonable performance, and outperforms the two baselines (i.e., random guess and a static bug finder (i.e., PMD)) by a substantial margin in terms of four ranking measures.

Using Changeset Descriptions as a Data Source to Assist Feature Location

Feature Location in Source Code by Trace-Based Impact Analysis and Information Retrieval.

Who Should Review This Change?: Putting Text and File Location Analyses Together for More Accurate Recommendations

Just-In-Time Defect Identification and Localization: A Two-Phase Framework.

Improving Feature Location Practice with Multi-Faceted Interactive Exploration

An exploratory study of feature location process: Distinct phases, recurring patterns, and elementary actions

Understanding Code Change with Micro-Changes

How developers perform feature location tasks: a human-centric and process-oriented exploratory study.

How do software engineers understand code changes?: an exploratory study in industry.

Improving Feature Location Using Structural Similarity and Iterative Graph Mapping

Software reconnaissance: Mapping program features to code

Segmentation of Change in Surface Geometry Analysis for Cultural Heritage Applications

Learning and Suggesting Source Code Changes from Version History: A Systematic Review

Visual exploration of software evolution via topic modeling

SNIAFL: Towards a Static Non-Interactive Approach to Feature Location

Identifying change patterns in software history

Reflective Feature Location: Knowledge in Mind Meets Information in System.

Understanding Systematic and Collaborative Code Changes by Mining Evolutionary Trajectory Patterns

When functions change their names: automatic detection of origin relationships

Multi-perspective change impact analysis using linked data of software engineering.

Examining Requirements Change Rework Effort: A Study