Fault localization is a costly task in the debugging process. Usually, developers analyze failing test cases to search for faults in the programs code. Visualization techniques have been proposed to help developers grasp the source code and focus their attention onto locations more likely to contain bugs. In general, these techniques utilize two-dimensional visualization approaches. We introduce a three-dimentional visual metaphor, called CodeForest, which represents a software as a cacti forest. In the CodeForest, nodes (sets of statements executed in sequence) are thorns, methods are branches, and classes are cacti. Heuristicsbased on the frequency that lines of codes are executed in successful and failing test cases are used to assign suspiciousness values to the elements (thorns, branches, and cacti) of the forest. The new metaphor was implemented as a plug-in targeted to the Eclipse Platform. This plug-in includes the mapping of suspiciousness values to elements of a virtual forest, a parameterized trimmer, which filters elements based on their score or text, and a list of most suspicious methods (also known as \"roadmap\"), to guide the developer on his/her debugging session. An exploratory experiment was conducted; the results indicates that the tool supports developers with and without experience. Users with low or no experience utilized the roadmap and the virtual 3D environment to investigate the defect. More experienced users prefer to use the roadmap as a guide to narrow which parts of the source code should be explored. / Localizar falhas é uma tarefa custosa do processo de depuração. Normalmente, os desenvolvedores analisam casos de teste que falham para procurar por defeitos no código fonte de um programa. Técnicas de visualização têm sido propostas para ajudar os desenvolvedores a entender o código fonte e focar sua atenção nos locais com a maior probabilidade de conterem defeitos. Geralmente, essas técnicas utilizam abordagens de visualização bidimensional. Nesse trabalho é introduzida uma metáfora visual em três dimensões, chamada CodeForest, que representa um programa como uma floresta de cactus. Na CodeForest, nós (conjunto de comandos executados em sequência) são representados como espinhos, métodos como galhos e classes como troncos. Para associar valores de suspeição aos elementos da floresta (espinhos, galhos e troncos) utilizam-se heurísticas, baseadas na frequência com que linhas de código são executadas em casos de teste finalizados com sucesso e com falha. A nova metáfora foi implementada como um complemento da plataforma Eclipse de desenvolvimento de programas. Esse complemento inclui o mapeamento dos valores de suspeição para elementos de uma floresta, uma ferramenta de poda parametrizada - que filtra elementos com base em seu texto e valor de suspeição - e uma lista dos métodos mais suspeitos (conhecida como roteiro) para guiar o desenvolvedor em sua sessão de depuração. Um experimento exploratório foi conduzido e os resultados indicam que a ferramenta apoia a tarefa de depuração tanto de desenvolvedores experientes quanto inexperientes. Usuários com pouca ou nenhuma experiência utilizaram o roteiro e o ambiente virtual 3D para investigar o defeito. Usuários mais experientes preferiram utilizar o roteiro como um guia para restringir quais partes do código fonte deveriam ser exploradas.

Fault localization is a costly task in the debugging process. Usually, developers analyze failing test cases to search for faults in the programs code. Visualization techniques have been proposed to help developers grasp the source code and focus their attention onto locations more likely to contain bugs. In general, these techniques utilize two-dimensional visualization approaches. We introduce a three-dimentional visual metaphor, called CodeForest, which represents a software as a cacti forest. In the CodeForest, nodes (sets of statements executed in sequence) are thorns, methods are branches, and classes are cacti. Heuristicsbased on the frequency that lines of codes are executed in successful and failing test cases are used to assign suspiciousness values to the elements (thorns, branches, and cacti) of the forest. The new metaphor was implemented as a plug-in targeted to the Eclipse Platform. This plug-in includes the mapping of suspiciousness values to elements of a virtual forest, a parameterized trimmer, which filters elements based on their score or text, and a list of most suspicious methods (also known as \"roadmap\"), to guide the developer on his/her debugging session. An exploratory experiment was conducted; the results indicates that the tool supports developers with and without experience. Users with low or no experience utilized the roadmap and the virtual 3D environment to investigate the defect. More experienced users prefer to use the roadmap as a guide to narrow which parts of the source code should be explored. / Localizar falhas é uma tarefa custosa do processo de depuração. Normalmente, os desenvolvedores analisam casos de teste que falham para procurar por defeitos no código fonte de um programa. Técnicas de visualização têm sido propostas para ajudar os desenvolvedores a entender o código fonte e focar sua atenção nos locais com a maior probabilidade de conterem defeitos. Geralmente, essas técnicas utilizam abordagens de visualização bidimensional. Nesse trabalho é introduzida uma metáfora visual em três dimensões, chamada CodeForest, que representa um programa como uma floresta de cactus. Na CodeForest, nós (conjunto de comandos executados em sequência) são representados como espinhos, métodos como galhos e classes como troncos. Para associar valores de suspeição aos elementos da floresta (espinhos, galhos e troncos) utilizam-se heurísticas, baseadas na frequência com que linhas de código são executadas em casos de teste finalizados com sucesso e com falha. A nova metáfora foi implementada como um complemento da plataforma Eclipse de desenvolvimento de programas. Esse complemento inclui o mapeamento dos valores de suspeição para elementos de uma floresta, uma ferramenta de poda parametrizada - que filtra elementos com base em seu texto e valor de suspeição - e uma lista dos métodos mais suspeitos (conhecida como roteiro) para guiar o desenvolvedor em sua sessão de depuração. Um experimento exploratório foi conduzido e os resultados indicam que a ferramenta apoia a tarefa de depuração tanto de desenvolvedores experientes quanto inexperientes. Usuários com pouca ou nenhuma experiência utilizaram o roteiro e o ambiente virtual 3D para investigar o defeito. Usuários mais experientes preferiram utilizar o roteiro como um guia para restringir quais partes do código fonte deveriam ser exploradas.

Testing and debugging are key tasks during the development cycle. However, they are among the most expensive activities during the development process. To improve the productivity of developers during the debugging process various fault localization techniques have been proposed, being Spectrum-based Fault Localization (SFL), or Coverage-based Fault Localization (CBFL), one of the most promising. SFL techniques pinpoints program elements (e.g., statements, branches, and definition-use associations), sorting them by their suspiciousness. Heuristics are used to rank the most suspicious program elements which are then mapped into lines to be inspected by developers. Although data-flow spectra (definition-use associations) has been shown to perform better than control-flow spectra (statements and branches) to locate the bug site, the high overhead to collect data-flow spectra has prevented their use on industry-level code. A data-flow coverage tool was recently implemented presenting on average 38% run-time overhead for large programs. Such a fairly modest overhead motivates the study of SFL techniques using data-flow information in programs similar to those developed in the industry. To achieve such a goal, we implemented Jaguar (JAva coveraGe faUlt locAlization Ranking), a tool that employ control-flow and data-flow coverage on SFL techniques. The effectiveness and efficiency of both coverages are compared using 173 faulty versions with sizes varying from 10 to 96 KLOC. Ten known SFL heuristics to rank the most suspicious lines are utilized. The results show that the behavior of the heuristics are similar both to control- and data-flow coverage: Kulczynski2 and Mccon perform better for small number of lines investigated (from 5 to 30 lines) while Ochiai performs better when more lines are inspected (30 to 100 lines). The comparison between control- and data-flow coverages shows that data-flow locates more defects in the range of 10 to 50 inspected lines, being up to 22% more effective. Moreover, in the range of 20 and 100 lines, data-flow ranks the bug better than control-flow with statistical significance. However, data-flow is still more expensive than control-flow: it takes from 23% to 245% longer to obtain the most suspicious lines; on average data-flow is 129% more costly. Therefore, our results suggest that data-flow is more effective in locating faults because it tracks more relationships during the program execution. On the other hand, SFL techniques supported by data-flow coverage needs to be improved for practical use at industrial settings / Teste e depuração são tarefas importantes durante o ciclo de desenvolvimento de programas, no entanto, estão entre as atividades mais caras do processo de desenvolvimento. Diversas técnicas de localização de defeitos têm sido propostas a fim de melhorar a produtividade dos desenvolvedores durante o processo de depuração, sendo a localização de defeitos baseados em cobertura de código (Spectrum-based Fault Localization (SFL) uma das mais promissoras. A técnica SFL aponta os elementos de programas (e.g., comandos, ramos e associações definição-uso), ordenando-os por valor de suspeição. Heursticas são usadas para ordenar os elementos mais suspeitos de um programa, que então são mapeados em linhas de código a serem inspecionadas pelos desenvolvedores. Embora informações de fluxo de dados (associações definição-uso) tenham mostrado desempenho melhor do que informações de fluxo de controle (comandos e ramos) para localizar defeitos, o alto custo para coletar cobertura de fluxo de dados tem impedido a sua utilização na prática. Uma ferramenta de cobertura de fluxo de dados foi recentemente implementada apresentando, em média, 38% de sobrecarga em tempo de execução em programas similares aos desenvolvidos na indústria. Tal sobrecarga, bastante modesta, motiva o estudo de SFL usando informações de fluxo de dados. Para atingir esse objetivo, Jaguar (Java coveraGe faUlt locAlization Ranking), uma ferramenta que usa técnicas SFL com cobertura de fluxo de controle e de dados, foi implementada. A eficiência e eficácia de ambos os tipos de coberturas foram comparados usando 173 versões com defeitos de programas com tamanhos variando de 10 a 96 KLOC. Foram usadas dez heursticas conhecidas para ordenar as linhas mais suspeitas. Os resultados mostram que o comportamento das heursticas são similares para fluxo de controle e de dados: Kulczyski2 e Mccon obtêm melhores resultados para números menores de linhas investigadas (de 5 a 30), enquanto Ochiai é melhor quando mais linhas são inspecionadas (de 30 a 100). A comparação entre os dois tipos de cobertura mostra que fluxo de dados localiza mais defeitos em uma variação de 10 a 50 linhas inspecionadas, sendo até 22% mais eficaz. Além disso, na faixa entre 20 e 100 linhas, fluxo de dados classifica com significância estatstica melhor os defeitos. No entanto, fluxo de dados é mais caro do que fluxo de controle: leva de 23% a 245% mais tempo para obter os resultados; fluxo de dados é em média 129% mais custoso. Portanto, os resultados indicam que fluxo de dados é mais eficaz para localizar os defeitos pois rastreia mais relacionamentos durante a execução do programa. Por outro lado, técnicas SFL apoiadas por cobertura de fluxo de dados precisam ser mais eficientes para utilização prática na indústria

Depuração é a atividade responsável pela localização e correção de defeitos gerados durante o desenvolvimento de programas. A depuração ocorre devido à atividade de teste bem-sucedida, na qual falhas no comportamento do programa são reveladas, indicando a existência de defeitos. Diversas técnicas têm sido propostas para automatizar a tarefa de depuração de programas. Algumas delas utilizam heurísticas baseadas em informações de cobertura obtidas da execução de testes. O objetivo é indicar trechos de código do programa mais suspeitos de conter defeitos. As informações de cobertura mais usadas em depuração automatizada são baseadas no teste estrutural de unidade. A cobertura de integração, obtida por meio da comunicação entre as unidades de um programa, pode trazer novas informações sobre o código executado, possibilitando a criação de novas estratégias para a tarefa de localização de defeitos. Este trabalho apresenta uma nova técnica de localização de defeitos chamada Depuração de programas baseada em Cobertura de Integração (DCI). São apresentadas duas coberturas de integração baseadas nas chamadas de métodos de um programa. Essas coberturas são usadas para a proposição de roteiros de busca dos defeitos a partir dos métodos considerados mais suspeitos. As informações de cobertura de unidade são então utilizadas para a localização dos defeitos dentro dos métodos. A DCI também utiliza uma nova heurística para atribuição de valores de suspeição a entidades de integração estática dos programas como pacotes, classes e métodos, fornecendo também um roteiro para a procura dos defeitos. Os experimentos realizados em programas reais mostram que a DCI permite realizar a localização de defeitos de forma mais eficaz do que o uso de informações de cobertura de unidade isoladamente. / Debugging is the activity responsible for localizing and fixing faults generated during software development. Debugging occurs due to a successful testing activity, in which failures in the behavior of the program are revealed, indicating the existence of faults. Several techniques have been proposed to automate the debugging tasks, especially the fault localization task. Some techniques use heuristics based on coverage data obtained from the execution of tests. The goal is to indicate program code excerpts more likely to contain faults. The coverage data mostly used in automated debugging is based on white-box unit testing. Integration coverage data, obtained from the communication between the units of a program, can bring about new information with respect to the executed code, which allows new strategies to the fault localization task to be devised. This work presents a new fault localization technique called Debugging based on Integration Coverage (DIC). Two integration coverages based on method invocations are presented. These coverages are used to propose two search strategies that provides a roadmap to locate faults by investigating the more suspicious methods. The unit coverage information are used to search the faulty statement inside the suspicious methods. The DIC technique also proposes a heuristic that assigns suspiciousness values to static integration entities of the programs, namely, packages, classes, and methods. This heuristic also provides a roadmap to search for the faults. Experiments using real programs show that DIC is more effective to locate faults than solely using unit coverage information.

Depuração é a atividade responsável pela localização e correção de defeitos gerados durante o desenvolvimento de programas. A depuração ocorre devido à atividade de teste bem-sucedida, na qual falhas no comportamento do programa são reveladas, indicando a existência de defeitos. Diversas técnicas têm sido propostas para automatizar a tarefa de depuração de programas. Algumas delas utilizam heurísticas baseadas em informações de cobertura obtidas da execução de testes. O objetivo é indicar trechos de código do programa mais suspeitos de conter defeitos. As informações de cobertura mais usadas em depuração automatizada são baseadas no teste estrutural de unidade. A cobertura de integração, obtida por meio da comunicação entre as unidades de um programa, pode trazer novas informações sobre o código executado, possibilitando a criação de novas estratégias para a tarefa de localização de defeitos. Este trabalho apresenta uma nova técnica de localização de defeitos chamada Depuração de programas baseada em Cobertura de Integração (DCI). São apresentadas duas coberturas de integração baseadas nas chamadas de métodos de um programa. Essas coberturas são usadas para a proposição de roteiros de busca dos defeitos a partir dos métodos considerados mais suspeitos. As informações de cobertura de unidade são então utilizadas para a localização dos defeitos dentro dos métodos. A DCI também utiliza uma nova heurística para atribuição de valores de suspeição a entidades de integração estática dos programas como pacotes, classes e métodos, fornecendo também um roteiro para a procura dos defeitos. Os experimentos realizados em programas reais mostram que a DCI permite realizar a localização de defeitos de forma mais eficaz do que o uso de informações de cobertura de unidade isoladamente. / Debugging is the activity responsible for localizing and fixing faults generated during software development. Debugging occurs due to a successful testing activity, in which failures in the behavior of the program are revealed, indicating the existence of faults. Several techniques have been proposed to automate the debugging tasks, especially the fault localization task. Some techniques use heuristics based on coverage data obtained from the execution of tests. The goal is to indicate program code excerpts more likely to contain faults. The coverage data mostly used in automated debugging is based on white-box unit testing. Integration coverage data, obtained from the communication between the units of a program, can bring about new information with respect to the executed code, which allows new strategies to the fault localization task to be devised. This work presents a new fault localization technique called Debugging based on Integration Coverage (DIC). Two integration coverages based on method invocations are presented. These coverages are used to propose two search strategies that provides a roadmap to locate faults by investigating the more suspicious methods. The unit coverage information are used to search the faulty statement inside the suspicious methods. The DIC technique also proposes a heuristic that assigns suspiciousness values to static integration entities of the programs, namely, packages, classes, and methods. This heuristic also provides a roadmap to search for the faults. Experiments using real programs show that DIC is more effective to locate faults than solely using unit coverage information.

Testing and debugging are key tasks during the development cycle. However, they are among the most expensive activities during the development process. To improve the productivity of developers during the debugging process various fault localization techniques have been proposed, being Spectrum-based Fault Localization (SFL), or Coverage-based Fault Localization (CBFL), one of the most promising. SFL techniques pinpoints program elements (e.g., statements, branches, and definition-use associations), sorting them by their suspiciousness. Heuristics are used to rank the most suspicious program elements which are then mapped into lines to be inspected by developers. Although data-flow spectra (definition-use associations) has been shown to perform better than control-flow spectra (statements and branches) to locate the bug site, the high overhead to collect data-flow spectra has prevented their use on industry-level code. A data-flow coverage tool was recently implemented presenting on average 38% run-time overhead for large programs. Such a fairly modest overhead motivates the study of SFL techniques using data-flow information in programs similar to those developed in the industry. To achieve such a goal, we implemented Jaguar (JAva coveraGe faUlt locAlization Ranking), a tool that employ control-flow and data-flow coverage on SFL techniques. The effectiveness and efficiency of both coverages are compared using 173 faulty versions with sizes varying from 10 to 96 KLOC. Ten known SFL heuristics to rank the most suspicious lines are utilized. The results show that the behavior of the heuristics are similar both to control- and data-flow coverage: Kulczynski2 and Mccon perform better for small number of lines investigated (from 5 to 30 lines) while Ochiai performs better when more lines are inspected (30 to 100 lines). The comparison between control- and data-flow coverages shows that data-flow locates more defects in the range of 10 to 50 inspected lines, being up to 22% more effective. Moreover, in the range of 20 and 100 lines, data-flow ranks the bug better than control-flow with statistical significance. However, data-flow is still more expensive than control-flow: it takes from 23% to 245% longer to obtain the most suspicious lines; on average data-flow is 129% more costly. Therefore, our results suggest that data-flow is more effective in locating faults because it tracks more relationships during the program execution. On the other hand, SFL techniques supported by data-flow coverage needs to be improved for practical use at industrial settings / Teste e depuração são tarefas importantes durante o ciclo de desenvolvimento de programas, no entanto, estão entre as atividades mais caras do processo de desenvolvimento. Diversas técnicas de localização de defeitos têm sido propostas a fim de melhorar a produtividade dos desenvolvedores durante o processo de depuração, sendo a localização de defeitos baseados em cobertura de código (Spectrum-based Fault Localization (SFL) uma das mais promissoras. A técnica SFL aponta os elementos de programas (e.g., comandos, ramos e associações definição-uso), ordenando-os por valor de suspeição. Heursticas são usadas para ordenar os elementos mais suspeitos de um programa, que então são mapeados em linhas de código a serem inspecionadas pelos desenvolvedores. Embora informações de fluxo de dados (associações definição-uso) tenham mostrado desempenho melhor do que informações de fluxo de controle (comandos e ramos) para localizar defeitos, o alto custo para coletar cobertura de fluxo de dados tem impedido a sua utilização na prática. Uma ferramenta de cobertura de fluxo de dados foi recentemente implementada apresentando, em média, 38% de sobrecarga em tempo de execução em programas similares aos desenvolvidos na indústria. Tal sobrecarga, bastante modesta, motiva o estudo de SFL usando informações de fluxo de dados. Para atingir esse objetivo, Jaguar (Java coveraGe faUlt locAlization Ranking), uma ferramenta que usa técnicas SFL com cobertura de fluxo de controle e de dados, foi implementada. A eficiência e eficácia de ambos os tipos de coberturas foram comparados usando 173 versões com defeitos de programas com tamanhos variando de 10 a 96 KLOC. Foram usadas dez heursticas conhecidas para ordenar as linhas mais suspeitas. Os resultados mostram que o comportamento das heursticas são similares para fluxo de controle e de dados: Kulczyski2 e Mccon obtêm melhores resultados para números menores de linhas investigadas (de 5 a 30), enquanto Ochiai é melhor quando mais linhas são inspecionadas (de 30 a 100). A comparação entre os dois tipos de cobertura mostra que fluxo de dados localiza mais defeitos em uma variação de 10 a 50 linhas inspecionadas, sendo até 22% mais eficaz. Além disso, na faixa entre 20 e 100 linhas, fluxo de dados classifica com significância estatstica melhor os defeitos. No entanto, fluxo de dados é mais caro do que fluxo de controle: leva de 23% a 245% mais tempo para obter os resultados; fluxo de dados é em média 129% mais custoso. Portanto, os resultados indicam que fluxo de dados é mais eficaz para localizar os defeitos pois rastreia mais relacionamentos durante a execução do programa. Por outro lado, técnicas SFL apoiadas por cobertura de fluxo de dados precisam ser mais eficientes para utilização prática na indústria

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-09-28T14:01:43Z No. of bitstreams: 1 DIEGO TAVARES CAVALCANTI - DISSERTAÇÃO PPGCC 2012..pdf: 11733349 bytes, checksum: 59909ce95d6ea71dea6e9686d3d20c33 (MD5) / Made available in DSpace on 2018-09-28T14:01:43Z (GMT). No. of bitstreams: 1 DIEGO TAVARES CAVALCANTI - DISSERTAÇÃO PPGCC 2012..pdf: 11733349 bytes, checksum: 59909ce95d6ea71dea6e9686d3d20c33 (MD5) Previous issue date: 2012-11-26 / Localizar e corrigir defeitos são tarefas comuns no processo de manutenção de software. Entretanto, a atividade de localizar entidades de código que são possivelmente defeituosas e que necessitam ser modificadas para a correção de um defeito, não é trivial. Geralmente, desenvolvedores realizam esta tarefa por meio de um processo manual de leitura e inspeção do código, bem como de informações cadastradas em relatórios de defeitos. De fato, é necessário que os desenvolvedores tenham um bom conhecimento da arquitetura e do design do software a fim de realizarem tal tarefa. Entretanto, este conhecimento fica espalhado por entre a equipe e requer tempo para ser adquirido por novatos. Assim, é necessário o desenvolvimento de técnicas que auxiliem na tarefa de análise de impacto de relatórios de defeitos no código, independente da experiência do desenvolvedor que irá executá-la. Neste trabalho, apresentamos resultados de um estudo empírico no qual avaliamos se a análise automática de vocabulários de relatórios de defeitos e de software pode ser útil na tarefa de localizar defeitos no código. Nele, analisamos similaridade de vocabulários como fator para sugerir classes que são prováveis de serem impactadas por um dado relatório de defeito. Realizamos uma avaliação com oito projetos maduros de código aberto, desenvolvidos em Java, que utilizam Bugzilla e JIRA como seus repositórios de defeitos. Nossos resultados indicam que a análise de ambos os vocabulários é, de fato, uma fonte valiosa de informação, que pode ser utilizada para agilizar a tarefa de localização de defeitos. Para todos os sistemas estudados, ao considerarmos apenas análise de vocabulário, vimos que, mesmo com um ranking contendo apenas 8% das classes de um projeto, foi possível encontrar classes relacionadas ao defeito buscado em até 75% dos casos. Portanto, podemos concluir que, mesmo que não possamos utilizar vocabulários de software e de relatórios de defeitos como únicas fontes de informação, eles certamente podem melhorar os resultados obtidos, ao serem combinados com técnicas complementares. / Locating and fixing bugs described in bug reports are routine tasks in software development processes. A major effort must be undertaken to successfully locate the (possibly faulty) entities in the code that must be worked on. Generally, developers map bug reports to code through manual reading and inspection of both bug reports and the code itself. In practice, they must rely on their knowledge about the software architecture and design to perform the mapping in an efficient and effective way. However, it is well known that architectural and design knowledge is spread out among developers. Hence, the success of such a task is directly depending on choosing the right developer. In this paper, we present results of an empirical study we performed to evaluate whether the automated analysis of bug reports and software vocabularies can be helpful in the task of locating bugs. We conducted our study on eight versions of six mature Java open-source projects that use Bugzilla and JIRA as bug tracking systems. In our study, we have used Information Retrieval techniques to assess the similarity of bug reports and code entities vocabularies. For each bug report, we ranked ali code entities according to the measured similarity. Our results indicate that vocabularies are indeed a valuable source of information that can be used to narrow down the bug-locating task. For ali the studied systems, considering vocabulary similarity only, a Top 8% list of entities has about 75% of the target entities. We conclude that while vocabularies cannot be the sole source of information, they can certainly improve results if combined with other techniques.

Depuração é a tarefa de localizar e corrigir defeitos em um programa. Apesar do esforço de pesquisa em depuração, especialmente nos últimos anos, ela ainda é realizada da mesma forma desde a década de 60, quando os primeiros depuradores simbólicos foram introduzidos. Localização de defeitos baseada em cobertura (LDC) é uma técnica de depuração promissora devido ao seu baixo custo de execução. LDC identifica os elementos mais suspeitos de um programa ao classificar linhas, métodos, classes e pacotes com maior valor de suspeição. Recentemente, ferramentas de visualização têm sido propostas para representar os valores de suspeição dos elementos de um programa. Entretanto, nenhuma delas foi introduzida em ambientes industriais e a utilização de depuradores simbólicos ainda é predominante. Nesta dissertação, foi avaliada a eficácia, a eficiência e a usabilidade de duas ferramentas de depuração, chamadas CodeForest e Jaguar, em ambientes reais. Jaguar apresenta os trechos mais suspeitos de um programa em uma lista ordenada por seus valores de suspeição. A CodeForest recebe informações de classes, métodos e blocos (conjunto de instruções executadas em sequência) suspeitos para construir uma floresta de cactus tridimensional representando o programa inspecionado. Na CodeForest, as classes são representadas como cactus, os métodos como galhos e os blocos como espinhos de um galho. Em ambas as ferramentas, os elementos do programa recebem cores que variam de acordo com o seu valor de suspeição. A questão básica respondida ao término deste trabalho é se as informações da depuração quando exibidas em uma metáfora visual melhoram a eficácia, a eficiência e a usabilidade na localização de defeitos. A eficácia e a eficiência foram avaliadas, respectivamente, pela capacidade da ferramenta direcionar o desenvolvedor ao método ou linha do defeito e o tempo necessário para localizá-los. A usabilidade das ferramentas foi avaliada por meio de um questionário baseado no modelo TAM (Technology Acceptance Model). Os resultados obtidos demonstram que a Jaguar foi mais eficaz, eficiente e com maior grau de usabilidade do que a CodeForest; entretanto, o tamanho do efeito estatístico é insignificante para a eficácia e eficiência e baixo para a usabilidade / Debugging is the task of locating and fixing defects in a program. Despite the research effort in debugging, especially in recent years, this task is still carried out in the same way since the 60s when the first symbolic debuggers were introduced. Spectrum-Based Fault Localization (SFL) is a promising debugging technique due to it is relative low execution cost. SFL pinpoints the most suspicious program elements by ranking lines, methods, classes and packages with greater suspicious values. Recently, visualization techniques have been proposed to represent the suspicious values of program elements. However, none of them have been introduced at industrial settings and the use of symbolic debuggers is still prevalent. This dissertation assessed the effectiveness, efficiency and usability of two debugging tools, called and CodeForest and Jaguar, in real environments. Jaguar presents the most suspicious elements of a program in a list sorted by suspicious values. CodeForest receives lists of suspicious classes, methods and blocks (set of statements executed in sequence) to build a three-dimensional cacti forest representing the program inspected. In CodeForest, classes are represented as cacti, methods as branches and blocks as thorns of a branch. In both tools, the program elements receive colors that vary according to the suspicious values. The basic question answered at the end of this research is whether debugging information when displayed as a visual metaphor improve the effectiveness, efficiency and usability during fault localization. The effectiveness and efficiency were assessed, respectively, by the tool\'s ability to direct the developer to the faulty method or line and the time spent to locate them. The tools\' usability was evaluated using the Technology Acceptance Model (TAM). The results show that Jaguar is more effective, efficient and presented greater usability than CodeForest; however, the statistical effect size is insignificant for effectiveness and efficiency and low for usability

Depuração é a tarefa de localizar e corrigir defeitos em um programa. Apesar do esforço de pesquisa em depuração, especialmente nos últimos anos, ela ainda é realizada da mesma forma desde a década de 60, quando os primeiros depuradores simbólicos foram introduzidos. Localização de defeitos baseada em cobertura (LDC) é uma técnica de depuração promissora devido ao seu baixo custo de execução. LDC identifica os elementos mais suspeitos de um programa ao classificar linhas, métodos, classes e pacotes com maior valor de suspeição. Recentemente, ferramentas de visualização têm sido propostas para representar os valores de suspeição dos elementos de um programa. Entretanto, nenhuma delas foi introduzida em ambientes industriais e a utilização de depuradores simbólicos ainda é predominante. Nesta dissertação, foi avaliada a eficácia, a eficiência e a usabilidade de duas ferramentas de depuração, chamadas CodeForest e Jaguar, em ambientes reais. Jaguar apresenta os trechos mais suspeitos de um programa em uma lista ordenada por seus valores de suspeição. A CodeForest recebe informações de classes, métodos e blocos (conjunto de instruções executadas em sequência) suspeitos para construir uma floresta de cactus tridimensional representando o programa inspecionado. Na CodeForest, as classes são representadas como cactus, os métodos como galhos e os blocos como espinhos de um galho. Em ambas as ferramentas, os elementos do programa recebem cores que variam de acordo com o seu valor de suspeição. A questão básica respondida ao término deste trabalho é se as informações da depuração quando exibidas em uma metáfora visual melhoram a eficácia, a eficiência e a usabilidade na localização de defeitos. A eficácia e a eficiência foram avaliadas, respectivamente, pela capacidade da ferramenta direcionar o desenvolvedor ao método ou linha do defeito e o tempo necessário para localizá-los. A usabilidade das ferramentas foi avaliada por meio de um questionário baseado no modelo TAM (Technology Acceptance Model). Os resultados obtidos demonstram que a Jaguar foi mais eficaz, eficiente e com maior grau de usabilidade do que a CodeForest; entretanto, o tamanho do efeito estatístico é insignificante para a eficácia e eficiência e baixo para a usabilidade / Debugging is the task of locating and fixing defects in a program. Despite the research effort in debugging, especially in recent years, this task is still carried out in the same way since the 60s when the first symbolic debuggers were introduced. Spectrum-Based Fault Localization (SFL) is a promising debugging technique due to it is relative low execution cost. SFL pinpoints the most suspicious program elements by ranking lines, methods, classes and packages with greater suspicious values. Recently, visualization techniques have been proposed to represent the suspicious values of program elements. However, none of them have been introduced at industrial settings and the use of symbolic debuggers is still prevalent. This dissertation assessed the effectiveness, efficiency and usability of two debugging tools, called and CodeForest and Jaguar, in real environments. Jaguar presents the most suspicious elements of a program in a list sorted by suspicious values. CodeForest receives lists of suspicious classes, methods and blocks (set of statements executed in sequence) to build a three-dimensional cacti forest representing the program inspected. In CodeForest, classes are represented as cacti, methods as branches and blocks as thorns of a branch. In both tools, the program elements receive colors that vary according to the suspicious values. The basic question answered at the end of this research is whether debugging information when displayed as a visual metaphor improve the effectiveness, efficiency and usability during fault localization. The effectiveness and efficiency were assessed, respectively, by the tool\'s ability to direct the developer to the faulty method or line and the time spent to locate them. The tools\' usability was evaluated using the Technology Acceptance Model (TAM). The results show that Jaguar is more effective, efficient and presented greater usability than CodeForest; however, the statistical effect size is insignificant for effectiveness and efficiency and low for usability

Debugging is one of the most time-consuming activities in software development. Several fault localization techniques have been proposed in the last years, aiming to reduce development costs. A promising approach, called Spectrum-based Fault localization (SFL), consists of techniques that provide a list of suspicious program elements (e.g., statements, basic blocks, methods) more likely to be faulty. Developers should inspect a suspiciousness list to search for faults. However, these fault localization techniques are not yet used in practice. These techniques are based on assumptions about the developer\'s behavior when inspecting such lists that may not hold in practice. A developer is supposed to inspect an SFL list from the most to the least suspicious program elements (e.g., statements) until reaching the faulty one. This assumption leads to some implications: the techniques are assessed only by the position of a bug in a list; a bug is deemed as found when the faulty element is reached. SFL techniques should pinpoint the faulty program elements among the first picks to be useful in practice. Most techniques use ranking metrics to assign suspiciousness values to program elements executed by the tests. These ranking metrics have presented similar modest results, which indicates the need for different strategies to improve the effectiveness of SFL. Moreover, most techniques use only control-flow spectra due to the high execution costs associated with other spectra, such as data-flow. Also, little research has investigated the use of SFL techniques by practitioners. Understanding how developers use SFL may help to clarify the theoretical assumptions about their behavior, which in turn can collaborate with the proposal of techniques more feasible for practical use. Therefore, user studies are a valuable tool for the development of the area. The goal of this thesis research was to propose strategies to improve spectrum-based fault localization, focusing on its practical use. This thesis presents the following contributions. First, we investigate strategies to provide contextual information for SFL. These strategies helped to reduce the amount of code to be inspected until reaching the faults. Second, we carried out a user study to understand how developers use SFL in practice. The results show that developers can benefit from SFL to locate bugs. Third, we explore the use of data-flow spectrum for SFL. Data-flow spectrum singles out faults significantly better than control-flow spectrum, improving the fault localization effectiveness. / Depuração é uma das atividades mais custosas durante o desenvolvimento de programas. Diversas técnicas de localização de defeitos têm sido propostas nos últimos anos com o objetivo de reduzir custos de desenvolvimento. Uma abordagem promissora, chamada Localização de Defeitos baseada em Espectro (LDE), é formada por técnicas que fornecem listas contendo elementos de código (comandos, blocos básicos, métodos) mais suspeitos de conter defeitos. Desenvolvedores deveriam inspecionar uma lista de suspeição para procurar por defeitos. No entanto, essas técnicas de localização de defeitos ainda não são usadas na prática. Essas técnicas baseiam-se em suposições sobre o comportamento de desenvolvedores durante a inspeção de tais listas que podem não ocorrer na prática. Um desenvolvedor supostamente inspeciona uma lista de LDE a partir do elemento mais suspeito para o menos suspeito até atingir o elemento defeituoso. Essa suposição leva a algumas implicações: as técnicas são avaliadas somente pela posição dos defeitos nas listas; um defeito é considerado como encontrado quando o elemento defeituoso é atingido. Técnicas de LDE deveriam posicionar os elementos de código defeituosos entre as primeiras posições para serem úteis na prática. A maioria das técnicas usa métricas de ranqueamento para atribuir valores de suspeição aos elementos executados pelos testes. Essas métricas de ranqueamento têm apresentado resultados semelhantes, o que indica a necessidade de estratégias diferentes para melhorar a eficácia de LDE. Além disso, a maioria das técnicas usa somente espectros de fluxo de controle devido ao alto custo de execução associado a outros espectros, tais como fluxo de dados. Também, poucas pesquisas têm investigado o uso de técnicas de LDE por programadores. Entender como desenvolvedores usam LDE pode ajudar a esclarecer as suposições teóricas sobre seu comportamento, o que por sua vez pode para colaborar para a proposição de técnicas mais viáveis para uso prático. Portanto, estudos com usuários são importantes para o desenvolvimento da área. O objetivo desta pesquisa de doutorado foi propor estratégias para melhorar a localização de defeitos baseada em espectro focando em seu uso prático. Esta tese apresenta as seguintes contribuições originais. Primeiro, nós investigamos estratégias para fornecer informação de contexto para LDE. Essas estratégias ajudaram a reduzir quantidade de código a ser inspecionado até atingir os defeitos. Segundo, nós realizamos um estudo com usuários para entender como desenvolvedores usam LDE na prática. Os resultados mostram que desenvolvedores podem beneficiar-se de LDE para localizar defeitos. Terceiro, nós exploramos o uso de espectros de fluxo de dados para LDE. Mostramos que o espectro de fluxo de dados seleciona defeitos significamente melhor que espectro de fluxo de controle, aumentando a eficácia de localização de defeitos.