Automatic Identification of Buggy Lines of Code in Bug-Fixing Patches

Abstract

A introdução de técnicas avançadas de localização de falhas, como as Spectrum-based, prometem ajudar os programadores em localizar código defeituoso de forma automática. Essas técnicas assumem como input a abrangência dos testes, calculam a probabilidade de cada linha de código ser responsável pelo comportamento defeituoso e, finalmente, classificam-nas de acordo com a sua probabilidade. Em estudos empíricos realizados em localização de falhas (o contexto desta dissertação), onde a(s) linha(s) defeituosa(s) são conhecidas à partida, tem-se usado métricas para comparar a eficácia de diferentes técnicas, por exemplo, Exam-score. A técnica que atingir o valor Exam-score mais baixo é considerada a melhor.

Contudo, na presença de falhas de omissão, por exemplo, falta de código para lidar com requisitos específicos, o ranking produzido pela técnica de localização de falhas não incluí a linha defeituosa, uma vez não existe nenhuma. Logo, em tal cenário, como é que o Exam-score de uma certa classificação pode ser calculado se não existe uma explícita linha defeituosa?

Para resolver isto, estudos anteriores propuseram o uso de candidatos, por exemplo, o local onde se pode inserir código para corrigir um programa defeituoso, como um substituto para linhas defeituosas. Pressupõe-se que, se uma técnica de localização de falhas é capaz de identificar as linhas em redor a esse local como as mais suscetíveis de explicar o comportamento defeituoso, o programador inspecioná-las-ia primeiro e provavelmente descobriria que há falta de código. Enquanto a atual abordagem tem sido identificar manualmente as linhas candidatas, é uma tarefa com tendência a erros e demorada. Por exemplo, no Defects4J, um dos benchmarks mais conhecidos, 64% dos bugs contêm pelo menos uma falha de omissão, e investigadores investiram demasiado tempo a determinar as linhas candidatas manualmente.

Por isso, este trabalho apresenta uma ferramenta chamada Automatic identification of Buggy lineS of codE in bug-fixiNg paTches (ABSENT) que calcula as linhas candidatas para as falhas de omissão e com fácil integração de novas regras para diferentes tipos de bugs, explorando técnicas diff baseadas em texto e AST (Abstract Syntax Tree). Com isto, não apenas foi introduzido um método mais eficiente de calcular os candidatos para diferentes bugs, como também demonstrámos um Exam-score mais cientificamente correto para técnicas SBFL de modo a eliminar a subjetividade dos candidatos manualmente identificados. Para além disso, também propomos uma nova regra para determinar linhas candidatas em situações com switch-cases cuja a nossa experiência demonstrou ser efetiva.

Alternate abstract:

The introduction of advanced fault localization techniques, such as Spectrum-based, could ease developers at automatically localize faulty code. Such techniques take as input the coverage of test cases and their outcome, compute the likelihood of each line of code to be responsible for the faulty behavior, and finally rank them according to their likelihood. In empirical studies conducted in fault localization (as in our context), where the true faulty line(s) are known at front, metrics have been used to compare the effectiveness of different techniques, e.g., Exam-score. The fault localization technique that achieves the lowest Exam-score is considered the best.

However, in the presence of faults of omission, i.e., missing code to handle specific requirements, the ranking produced by a fault localization technique does not include any faulty line, as there is none. Thus, in such a scenario, how would one compute the Exam-score of a given ranking if there is no explicit faulty line?

To address this, previous works have proposed the use of candidate locations, i.e., the location where code could be inserted to fix a faulty program, as a proxy to faulty lines. The assumption is that, if a fault localization technique is able to pinpoint the lines of code surrounding that location as the most likely to explain the faulty behavior, a developer would inspect those first and likely figure out there is some code missing. While the current approach has been to manually identify these locations, it is an error-prone and time-consuming task. For example, in Defects4J, a widely used benchmark, 64% of the faults contain at least one fault of omission, and researchers have spent a significant time manually determining candidate locations.

Hence, this work presents a tool called Automatic identification of Buggy lineS of codE in bug-fixiNg paTches (ABSENT) that computes candidate locations for faults of omission and easy-to-integrate new rules for different types of faults by exploring text-based diff and AST (Abstract Syntax Tree) techniques. With this, not only did we introduce a more efficient method to compute the candidates for different types of faults, but we also were able to scientifically compute a more accurate Exam-score for SBFL techniques by eliminating the subjectivity in manually identified candidates. Furthermore, we propose a new rule to determine candidate locations in switch-case statements which has shown to be effective in our experiment.