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.

Tese de Mestrado Integrado. Engenharia Informática e Computação. Faculdade de Engenharia. Universidade do Porto. 2012

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.

Made available in DSpace on 2014-06-12T16:00:26Z (GMT). No. of bitstreams: 2 arquivo6606_1.pdf: 4415777 bytes, checksum: 2f6d4d1e8b270706cdf01fd8117be5fd (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2007 / Teste é uma atividade muito importante no processo de desenvolvimento de software, entretanto, é uma atividade cara, uma vez que ela consome uma parte considerável dos recursos de um projeto de desenvolvimento de software. Um problema encontrado na maioria dos processos de desenvolvimento de software é a ausência de uma maneira de se avaliar a efetividade dos casos de teste de unidade, que são executados no código desenvolvido. Uma possível solução para este problema é realizar testes de cobertura de código e obter métricas sobre a cobertura do conjunto de testes de unidade executados. O presente estudo descreve um processo de desenvolvimento de software incluindo análise de cobertura de código, em que utilizamos o Rational Unifield Process como base para o processo proposto

Submitted by Automação e Estatística (sst@bczm.ufrn.br) on 2018-07-02T18:48:21Z No. of bitstreams: 1 DiegoDeAzevedoOliveira_DISSERT.pdf: 1039192 bytes, checksum: a387d372d3c8da2d66010f294542538a (MD5) / Approved for entry into archive by Arlan Eloi Leite Silva (eloihistoriador@yahoo.com.br) on 2018-07-04T13:18:52Z (GMT) No. of bitstreams: 1 DiegoDeAzevedoOliveira_DISSERT.pdf: 1039192 bytes, checksum: a387d372d3c8da2d66010f294542538a (MD5) / Made available in DSpace on 2018-07-04T13:18:53Z (GMT). No. of bitstreams: 1 DiegoDeAzevedoOliveira_DISSERT.pdf: 1039192 bytes, checksum: a387d372d3c8da2d66010f294542538a (MD5) Previous issue date: 2018-02-05 / Softwares precisam ser seguros e corretos. Partindo desse pressuposto, novas tecnologias e técnicas são desenvolvidas para comprovar as competências de um programa. Essa necessidade de segurança se torna mais relevante ao tratar de softwares que atuam em sistemas críticos, como os sistemas ferroviário e aeroviário. A utilização de métodos formais na construção de software busca solucionar o problema. Ao utilizar o método formal B através da plataforma Atelier-B, e após provar os componentes de um projeto é necessária a tradução para a linguagem desejada. Essa tradução ocorre por meio de tradutores e compiladores B. Habitualmente, o processo de compilação em compiladores maduros é seguro, porém não estão completamente livres de falhas e eventualmente erros são encontrados. Ao expandir essa afirmação para tradutores B é necessário cautela, uma vez que esses não são tão comuns e utilizados quanto compiladores que circulam há mais tempo no mercado. Testes de software podem ser utilizados para realizar a análise da tradução. Através de critérios de cobertura é possível inferir o nível de qualidade do software e facilitar a detecção de falhas. Realizar a checagem da cobertura e testes em software pode exigir bastante esforço e tempo, principalmente ao serem realizados manualmente. Para sanar essa demanda, a ferramenta BTestBox visa analisar, de maneira automática, a cobertura atingida por implementações B desenvolvidas através do Atelier-B. BTestBox também testa automaticamente as traduções feitas a partir de implementações B. Para isso, BTestBox utiliza os casos de teste gerados para a verificação de cobertura e compara os valores esperados de saída com os encontrados após a tradução. O processo feito por BTestBox é todo automático e pode ser utilizado a partir do Atelier-B via instalação de plugin com uma interface simples. Essa dissertação apresenta a ferramenta BTestBox. BTestBox foi testado através de pequenas implementações B com os elementos gramaticais possíveis da linguagem B. BTestBox apresenta funcionalidade e vantagens para programadores que utilizam o método formal B. / Software needs to be safe and run smoothly. From that assumption, new technologies and techniques are developed to test the quality of a program. This is more relevant when developing critical systems, such as railways and avionics control systems. Formal methods try to adress this need. When using B in Atelier-B, after proving the components of a project is necessary to translate to the desired language, a translation is made by using B translators and compilers. Usually, the process of compilation is safe when perfomed by mature compilers although they are not free of errors and bugs often crop up. The same reliability is not always observed in B translators since they have been on the market for less time. Software testing may solve and be used to perform the analyses of the translated code. From coverage criteria, it is possible to infer quality of a piece of software and detect bugs. This process is hard and time-consuming, mainly if it is perfomed manually. To address this problem, the BTestBox tool aims to analyze automatically the coverage of B implementations built through Atelier-B. BTestBox also automatically tests the translation from B implementations. For this, BTestBox uses the same test case generated to verify the coverage and compare the output expected values with the values found in the translation. This process is fully automatic and may be started from Atelier-B with a plugin. This thesis presents the tool BTestBox. The tool is a solution to the problems exposed in the previous paragraph. BTestBox was tested with small B implementations and all gramatical elements from B language. It offers various functionalities and advantages to developers that use the B-Method.

Submitted by Automação e Estatística (sst@bczm.ufrn.br) on 2018-07-30T13:26:30Z No. of bitstreams: 1 FladsonThiagoOliveiraGomes_DISSERT.pdf: 2012982 bytes, checksum: 32b3a5c5873614b73f362994472d31a9 (MD5) / Approved for entry into archive by Arlan Eloi Leite Silva (eloihistoriador@yahoo.com.br) on 2018-07-30T22:06:38Z (GMT) No. of bitstreams: 1 FladsonThiagoOliveiraGomes_DISSERT.pdf: 2012982 bytes, checksum: 32b3a5c5873614b73f362994472d31a9 (MD5) / Made available in DSpace on 2018-07-30T22:06:38Z (GMT). No. of bitstreams: 1 FladsonThiagoOliveiraGomes_DISSERT.pdf: 2012982 bytes, checksum: 32b3a5c5873614b73f362994472d31a9 (MD5) Previous issue date: 2016-03-03 / Atualmente, a etapa de testes no processo de desenvolvimento de software tornou-se imprescindível para garantir a confiabilidade e qualidade do código em produção. As constantes evoluções na arquitetura e código de um sistema, criam sérios desafios para os desenvolvedores e testadores, uma vez que modificações podem não se comportar como o esperado. Neste contexto surge a necessidade de ferramentas e mecanismos que diminuam o impacto negativo gerado pelas constantes evoluções do sistema. Dentre as ferramentas que analisam esse impacto, poucas apresentam os fluxos de execução entre métodos que foram afetados e nenhuma apresenta como resultado se esses fluxos afetados pela evolução estão ou não cobertos pelos testes. Assim, este trabalho apresenta uma abordagem que tem como objetivo principal: (i) analisar a cobertura de código levando em consideração os fluxos de chamadas existentes no sistema que foram afetados por evoluções de código, assim como os fluxos de execução oriundos da execução dos testes; (ii) indicar quais fluxos de chamadas do sistema que possuem métodos modificados e não estão sendo cobertos pelos testes atualmente e que, portanto, poderiam ser considerados para melhorar a qualidade dos testes; e (iii) indicar se houve degradação na qualidade da suíte de testes. Um estudo empírico foi realizado em 6 sistemas e os resultados mostram que a abordagem conseguiu identificar entre 19% e 92% de fluxos de execução afetados por mudanças que não estão cobertos e ainda que 3 dos 6 sistemas tiveram uma degradação na qualidade dos testes.

Submitted by JÚLIO HEBER SILVA (julioheber@yahoo.com.br) on 2016-12-05T15:46:39Z No. of bitstreams: 2 Dissertação - Daniel Gomes de Oliveira - 2016.pdf: 1447085 bytes, checksum: f382ec268ae42480adeee8f03e5ccda2 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) / Approved for entry into archive by Jaqueline Silva (jtas29@gmail.com) on 2016-12-13T15:32:34Z (GMT) No. of bitstreams: 2 Dissertação - Daniel Gomes de Oliveira - 2016.pdf: 1447085 bytes, checksum: f382ec268ae42480adeee8f03e5ccda2 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) / Made available in DSpace on 2016-12-13T15:32:34Z (GMT). No. of bitstreams: 2 Dissertação - Daniel Gomes de Oliveira - 2016.pdf: 1447085 bytes, checksum: f382ec268ae42480adeee8f03e5ccda2 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) Previous issue date: 2016-09-29 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - CAPES / Considering the high cost and large amount of time demanded by the activity generation tests in the software development process, the need a proposal to reduce both the time spent as the related costs testing activities is necessary. In this context, the use of tools or processes that make the activities of generation of more agile testing, less costly and meet demands for precision are key to companies operating in software development market can achieve their goals. Based on these information comes to questions regarding how to go about adopting a process that makes possible the achievement of objectives in order to meet the results mentioned previously, even with the difficulties of generating test data as a result of of programs input areas are infinite. There are different tools that use various strategies for generating test data, however, lacks evidence as the quality of these tools. In this context, the aim of this work is conducting an experimental evaluation of some automatic test data generators to identify which one offers the best cost / benefit in terms of effective in detecting defects number of generated test data, code coverage demanded by test data, and generation time of testing. At second step a third tool was included along manually generated tests. New test sets using three automatic generators and included the manually -generated sets project were generated. Finally, results were presented in terms of effectiveness and efficiency through the comparison between the four test sets . / Considerando o alto custo e a grande quantidade de tempo demandada pela atividade de criação de casos de testes dentro do processo de desenvolvimento de software. A utilização de ferramentas ou procedimentos que tornem o processo de geração de dados de testes mais ágil, menos oneroso e que atendam demandas por precisão se tornam fundamentais para que as empresas atuantes no mercado de desenvolvimento de software possam atingir seus objetivos. Com base nessas informações, surge a dúvida relacionada a como proceder para adotar um processo de desenvolvimento e teste de software que tornem possíveis o alcance dos objetivos de forma a atender os resultados mencionados anteriormente, mesmo com as dificuldades de gerar dados de teste em decorrência dos domínios de entrada dos programas serem em geral infinitos. O objetivo do presente trabalho é conduzir uma avaliação experimental de geradores automáticos de dados de teste visando identificar qual deles apresenta a melhor relação custo/benefício em termos de eficácia em detectar defeitos, número de dados de teste gerados e cobertura de código determinada pelos conjuntos de teste. A pesquisa foi dirigida em duas etapas: na primeira, dois geradores foram avaliados em relação a um conjunto de 32 programas Java e os resultados obtidos indicam que, de maneira geral, o gerador CodePro foi o que apresentou a melhor relação custo benefício frente ao Randoop; na segunda, foi inclusa uma terceira ferramenta, juntamente a testes gerados de forma manual. Foram gerados novos conjuntos de teste utilizando os três geradores automáticos e incluso ao projeto conjuntos gerados de forma manual. Ao final, foram apresentados os resultados em termos de eficácia e eficiência por meio dos comparativos entre os quatro conjuntos de teste.