The Search for the Laws of Automatic Random Testing

Can one estimate the number of remaining faults in a software system? A credible estimation technique would be immensely useful to project managers as well as customers. It would also be of theoretical interest, as a general law of software engineering. We investigate possible answers in the context of automated random testing, a method that is increasingly accepted as an effective way to discover faults. Our experimental results, derived from best-fit analysis of a variety of mathematical functions, based on a large number of automated tests of library code equipped with automated oracles in the form of contracts, suggest a poly-logarithmic law. Although further confirmation remains necessary on different code bases and testing techniques, we argue that understanding the laws of testing may bring significant benefits for estimating the number of detectable faults and comparing different projects and practices.Comment: 20 page

Automated Fixing of Programs with Contracts

This paper describes AutoFix, an automatic debugging technique that can fix faults in general-purpose software. To provide high-quality fix suggestions and to enable automation of the whole debugging process, AutoFix relies on the presence of simple specification elements in the form of contracts (such as pre- and postconditions). Using contracts enhances the precision of dynamic analysis techniques for fault detection and localization, and for validating fixes. The only required user input to the AutoFix supporting tool is then a faulty program annotated with contracts; the tool produces a collection of validated fixes for the fault ranked according to an estimate of their suitability. In an extensive experimental evaluation, we applied AutoFix to over 200 faults in four code bases of different maturity and quality (of implementation and of contracts). AutoFix successfully fixed 42% of the faults, producing, in the majority of cases, corrections of quality comparable to those competent programmers would write; the used computational resources were modest, with an average time per fix below 20 minutes on commodity hardware. These figures compare favorably to the state of the art in automated program fixing, and demonstrate that the AutoFix approach is successfully applicable to reduce the debugging burden in real-world scenarios.Comment: Minor changes after proofreadin

A survey on test suite reduction frameworks and tools

Software testing is a widely accepted practice that ensures the quality of a System under Test (SUT). However, the gradual increase of the test suite size demands high portion of testing budget and time. Test Suite Reduction (TSR) is considered a potential approach to deal with the test suite size problem. Moreover, a complete automation support is highly recommended for software testing to adequately meet the challenges of a resource constrained testing environment. Several TSR frameworks and tools have been proposed to efficiently address the test-suite size problem. The main objective of the paper is to comprehensively review the state-of-the-art TSR frameworks to highlights their strengths and weaknesses. Furthermore, the paper focuses on devising a detailed thematic taxonomy to classify existing literature that helps in understanding the underlying issues and proof of concept. Moreover, the paper investigates critical aspects and related features of TSR frameworks and tools based on a set of defined parameters. We also rigorously elaborated various testing domains and approaches followed by the extant TSR frameworks. The results reveal that majority of TSR frameworks focused on randomized unit testing, and a considerable number of frameworks lacks in supporting multi-objective optimization problems. Moreover, there is no generalized framework, effective for testing applications developed in any programming domain. Conversely, Integer Linear Programming (ILP) based TSR frameworks provide an optimal solution for multi-objective optimization problems and improve execution time by running multiple ILP in parallel. The study concludes with new insights and provides an unbiased view of the state-of-the-art TSR frameworks. Finally, we present potential research issues for further investigation to anticipate efficient TSR frameworks

Selecting Highly Efficient Sets of Subdomains for Mutation Adequacy

Test selection techniques are used to reduce the human effort involved in software testing. Most research focusses on selecting efficient sets of test cases according to various coverage criteria for directed testing. We introduce a new technique to select efficient sets of sub domains from which new test cases can be sampled at random to achieve a high mutation score. We first present a technique for evolving multiple sub domains, each of which target a different group of mutants. The evolved sub domains are shown to achieve an average 160% improvement in mutation score compared to random testing with six real world Java programs. We then present a technique for selecting sets of the evolved sub domains to reduce the human effort involved in evaluating sampled test cases without reducing their fault finding effectiveness. This technique significantly reduces the number of sub domains for four of the six programs with a negligible difference in mutation score

Using Mutation Analysis to Evolve Subdomains for Random Testing

Random testing is inexpensive, but it can also be inefficient. We apply mutation analysis to evolve efficient subdomains for the input parameters of eight benchmark programs that are frequently used in testing research. The evolved subdomains can be used for program analysis and regression testing. Test suites generated from the optimised subdomains outperform those generated from random subdomains with 10, 100 and 1000 test cases for uniform, Gaussian and exponential sampling. Our subdomains kill a large proportion of mutants for most of the programs we tested with just 10 test cases

A Divergence-Oriented Approach to Adaptive Random Testing of Java Programs

Abstract—Adaptive Random Testing (ART) is a testing technique which is based on an observation that a test input usually has the same potential as its neighbors in detection of a specific program defect. ART helps to improve the efficiency of random testing in that test inputs are selected evenly across the input spaces. However, the application of ART to object-oriented programs (e.g., C++ and Java) still faces a strong challenge in that the input spaces of object-oriented programs are usually high dimensional, and therefore an even distribution of test inputs in a space as such is difficult to achieve. In this paper, we propose a divergence-oriented approach to adaptive random testing of Java programs to address this challenge. The essential idea of this approach is to prepare for the tested program a pool of test inputs each of which is of significant difference from the others, and then to use the ART technique to select test inputs from the pool for the tested program. We also develop a tool called ARTGen to support this testing approach, and conduct experiment to test several popular open-source Java packages to assess the effectiveness of the approach. The experimental result shows that our approach can generate test cases with high quality. I

Applying TSR techniques over large test suites

Tese de mestrado em Engenharia Informática (Engenharia de Software) Universidade de Lisboa, Faculdade de Ciências, 2020Com o aumento da necessidade de garantir a qualidade do software criado atualmente, tem sido cada vez mais indispensável dedicar parte do tempo de desenvolvimento (por vezes mais de metade) a testar o código desenvolvido. Apesar da elevada importˆancia desta tarefa, é uma atividade que algumas vezes é ignorada ou negligenciada, devido a ser um trabalho por vezes monótono e cansativo. Esta é uma área bastante explorada por investigadores que tentam, de diversas maneiras, automatizar algum deste processo e, também, reduzir o tempo e recursos necessários para efetuar esta tarefa. Nomeadamente, considera-se a proposta de técnicas de redução de testes e ferramentas que as implementem, com o objetivo de agilizar esta tarefa, eliminando casos de testes desnecessários sem comprometer a cobertura dada pelo conjunto de testes original, bem como técnicas de prioritização de testes, que reorganizam conjuntos de testes com o objetivo de executar os mais relevantes (de acordo com um determinado critério) primeiramente, aumentando assim a sua capacidade de atingir algum objetivo. Neste contexto, destacam-se os testes de regressão, que permitem testar alterações ao software, verificando se as funcionalidades antigas continuam a funcionar com as alterações feitas. Salientam-se estes testes na medida em que são considerados o tipo de testes de software mais cansativo, comportando elevados custos e não evidenciando ganho claros a curto-prazo e, consequentemente, beneficiando particularmente das técnicas descritas anteriormente. Com o surgimento destas técnicas, é inevitável surgirem algumas comparações, tentando escolher as que melhor se adequam a diferentes necessidades. O objetivo deste trabalho consiste em dar resposta a duas questões, particularmente interessantes dado o estado de arte atual: “Qual a melhor ferramenta de redução de testes?”(de acordo com parâmetros pré-definidos) e “Se uma ferramenta de prioritização de testes for modificada, pode substituir de forma eficiente uma ferramenta de redução de testes?”. Para realizar a presente dissertação, foi estudado um grupo de ferramentas de redução de testes, de forma a ter uma melhor noção do estado de arte atual. Apesar de inicialmente terem sido encontradas onze ferramentas que poderiam vir a ser usadas com este propósito, os testes realizados, assim como as propriedades de algumas ferramentas, restringiram a utilização da maioria delas, Assim, foram consideradas três ferramentas: Evo- Suite, Testler e Randoop. De forma a tornar o objetivo deste trabalho mais enriquecido, foi também estudada uma ferramenta de prioritização de testes, Kanonizo. Para respondermos às questões apresentadas, foi desenvolvida uma ferramenta que integra o conjunto de ferramentas de redução de testes seleccionado e que, dado um conjunto de projetos open-source, aplica as técnicas destas ferramentas a cada um destes, efetuando assim a redução dos seus testes. Seguidamente, a ferramenta desenvolvida utiliza a ferramenta de prioritização Kanonizo para obter uma lista dos vários testes, ordenados consoante a sua importância; finalmente, são eliminados os testes menos importantes, segundo um valor pré-definido. De seguida, utilizando uma ferramenta de análise de código, neste caso a OpenClover, são recolhidas métricas referentes a cada conjunto de testes, para os projetos originais e igualmente para cada um dos reduzidos. Estas são depois utilizadas para avaliar a eficácia da redução para cada ferramenta. A eficácia da redução pode ser influenciada por diversos fatores. No caso da nossa ferramenta, foram considerados o tamanho do ficheiro de testes, o número de testes, o tempo de execução dos mesmos, a percentagem de cobertura total do código e a percentagem de cobertura de “ramos”no código. Por este motivo, decidiu-se adotar uma metodologia de Multi-Criteria Decision-Making, mais especificamente a Analytic Hierarchy Process que, segundo diversos critérios e valores de importância definidos entre eles, deduz a prioridade que cada critério deve ter ao tentar atingir um objetivo comum, isto é, que peso tem cada critério no cálculo da pontuação de cada ferramenta. Após a finalização e aperfeiçoamento da ferramenta, foram realizadas experiências que nos permitiram analisar a eficácia de cada ferramenta. Dada a facilidade de configuração da ferramenta, foram efetuadas diversas análises às reduções efetuadas pelas ferramentas, alterando a importância de cada critério considerado, visando verificar de que maneira estes influenciavam a escolha da melhor ferramenta. As pontuações de cada ferramenta de redução foram calculadas para seis cenários diferentes: um que replicasse as necessidades do ”mundo real”, dando portanto mais importância ao tempo de execução dos testes e cobertura atingida do que à dimensão dos testes em si; e um focando toda a importância para cada um dos sub-critérios definidos. Cada um destes cenários foi feito duas vezes - uma com os testes gerados pelo EvoSuite, e outra com os testes já existentes - com o objetivo de averiguar se as ferramentas de redução teriam um comportamento semelhante na presença de testes gerados automaticamente ou por humanos. Ignorando a ferramenta de prioritização, e tendo em conta o facto de que a EvoSuite só poderia ser usada com testes gerados por si mesma, a ferramenta de redução que teve uma melhor pontuação foi a Testler, o que responde à nossa primeira questão do estudo. Quanto à segunda questão, apesar dos resultados terem mostrado indubitavelmente que a Kanonizo obteve pontuações melhores que as outras ferramentas analisadas, esta é uma questão susceptível à influência de diversos fatores. No contexto das experiências efetuadas, podemos dizer que a Kanonizo pode substituir qualquer uma das ferramentas de redução e, confiando nas pontuações, fazer um trabalho mais eficaz. No entanto, num contexto mais abrangente, torna-se difícil responder a esta questão sem considerar um número mais elevado de ferramentas de redução de testes. Para mais, dependendo do algoritmo utilizado na ferramenta de prioritização, a redução feita por nós pode não ter qualquer critério (no caso de algoritmos random), o que faria essencialmente com que estivéssemos a apagar métodos aleatoriamente, podendo causar grandes perdas em termos de cobertura de código. Quando falamos de “substituir”uma ferramenta de redução por uma de prioritização com uma abordagem semelhante à nossa, é melhor utilizar algoritmos de prioritização que visem algum critério, como dar prioridade a testes que cubram, por exemplo, linhas de código ainda não cobertas, por exemplo, aumentando assim a probabilidade dos testes menos importantes serem redundantes e, consequentemente, apagados. Esta ferramenta foi desenvolvida de modo a que fosse facilmente modificável e expansível, oferecendo assim uma maneira fácil para integrar novas ferramentas de redução de testes, permitindo realizar novas comparações à medida que estas ferramentas forem surgindo. Para além disso, destaca-se também a simplicidade da configuração dos critérios a ter em conta quando calculamos a pontuação de cada ferramenta, e o valor que estes têm em comparação com os outros, possibilitando facilmente o cálculo de pontuações tendo em conta diversos cenários.Ao longo deste trabalho, o maior problema encontrado foi o estudo das ferramentas de redução. Para além de algumas não serem open-source, muitas das que eram não iam de encontro aos nossos requisitos para integração na ferramenta, quer por linguagem de programação, quer por abordagem seguida, e muitas vezes a documentação encontrada estava desatualizada ou errada, dificultando todo o processo.With the growing need to assure the quality of the software created nowadays, it has become increasingly necessary to devote part of the development time (sometimes as much as half) to testing the developed code. Despite the high importance of this task, it is an activity that is sometimes ignored and neglected, due to it being, occasionally, a monotonous and tiring job. This is an area thoroughly investigated by researchers who try to automate some parts of this process, while also reducing the time and resources required for this task. In particular, we highlight the proposal of test reduction techniques and tools that implement them, with the goal of detecting unnecessary test cases without compromising the coverage given by the original test suite. The main objective of this work consists in answering two questions: “What is the best Test Suite Reduction tool?” (according to some criterion) and “Can a Test Case Prioritization tool be adapted to effectively replace a Test Suite Reduction tool?”. To answer these questions, we developed a framework that integrates a set of Test Suite Reduction and Test Cases Prioritization tools, with the possibility to integrate more, and that uses them, given a set of open source Java projects, to apply each of its techniques. We then gather test execution data about these projects and compare them to compute a score for each Test Suite Reduction tool, which is used to rank them. This score is achieved by applying a Multi-Criteria Decision-Making methodology, the Analytic Hierarchy Process, to weigh several chosen code metrics on the final score. To answer the second question we integrated a Test Case Prioritization tool into our framework, with which we will get a list of the less important test cases, that we will then remove, simulating a reduction

Capture-based Automated Test Input Generation

Testing object-oriented software is critical because object-oriented languages have been commonly used in developing modern software systems. Many efficient test input generation techniques for object-oriented software have been proposed; however, state-of-the-art algorithms yield very low code coverage (e.g., less than 50%) on large-scale software. Therefore, one important and yet challenging problem is to generate desirable input objects for receivers and arguments that can achieve high code coverage (such as branch coverage) or help reveal bugs. Desirable objects help tests exercise the new parts of the code. However, generating desirable objects has been a significant challenge for automated test input generation tools, partly because the search space for such desirable objects is huge. To address this significant challenge, we propose a novel approach called Capture-based Automated Test Input Generation for Objected-Oriented Unit Testing (CAPTIG). The contributions of this proposed research are the following. First, CAPTIG enhances method-sequence generation techniques. Our approach intro-duces a set of new algorithms for guided input and method selection that increase code coverage. In addition, CAPTIG efficently reduces the amount of generated input. Second, CAPTIG captures objects dynamically from program execution during either system testing or real use. These captured inputs can support existing automated test input generation tools, such as a random testing tool called Randoop, to achieve higher code coverage. Third, CAPTIG statically analyzes the observed branches that had not been covered and attempts to exercise them by mutating existing inputs, based on the weakest precon-dition analysis. This technique also contributes to achieve higher code coverage. Fourth, CAPTIG can be used to reproduce software crashes, based on crash stack trace. This feature can considerably reduce cost for analyzing and removing causes of the crashes. In addition, each CAPTIG technique can be independently applied to leverage existing testing techniques. We anticipate our approach can achieve higher code coverage with a reduced duration of time with smaller amount of test input. To evaluate this new approach, we performed experiments with well-known large-scale open-source software and discovered our approach can help achieve higher code coverage with fewer amounts of time and test inputs

Enfoque para pruebas de unidad basado en la generación aleatoria de objetos

El testing del software es una tarea crucial y a la vez muy desafiante dentro del proceso de desarrollo de software. El testing permite encontrar errores y problemas del software contra la especificación del mismo y cumple un rol fundamental en el aseguramiento de la calidad del producto. Entre los tipos de pruebas que se pueden realizar al software están las pruebas de unidad, carga, integración y funcionales. Cada una de ellas tiene distintos objetivos y son realizadas en diferentes etapas del desarrollo del software. En el primer tipo mencionado, se desarrollan pruebas a componentes individuales de un sistema de software. Los desarrolladores especifican y codifican pruebas para cubrir todos o al menos una parte significativa de los posibles estados/configuraciones del artefacto o unidad de software, para simular el entorno del componente y descubrir la presencia de errores o “bugs”. Dado que escribir todas esas pruebas de forma manual es costoso, las pruebas de unidad son generalmente realizadas de manera ineficiente o simplemente dejadas de lado. El panorama es aún peor, más allá del esfuerzo, porque el testing no puede ser usado para probar la usencia de errores en el software sino tan solo la presencia. Por eso es necesario atacar el problema desde diferentes enfoques, cada uno teniendo sus fortalezas y ventajas. Actualmente existen muchas técnicas para hacer testing de software, y la mayoría de ellos se basan en la automatización de pasos o caminos de ejecución, con valores fijos o componentes predefinidos (hard-coded) o estáticos, y condiciones específicas. En este trabajo de maestría, se presenta un enfoque para pruebas de unidad en la programación orientada a objetos, basado en la generación de objetos de manera aleatoria. El fundamento básico de este enfoque propuesto es el testing aleatorio. También se presenta una herramienta de testing de unidad que usa el enfoque dicho, y que fue escrita en un lenguaje orientado a objetos de amplia difusión. El testing aleatorio (RT o random testing) como técnica no es nueva. Tampoco lo es la generación de valores aleatorios para pruebas. En el paradigma funcional, existe una herramienta muy conocida para probar especificaciones sobre funciones llamada QuickCheck. Ésta herramienta (escrita en Haskell) y sus ideas subyacentes son usadas como fundamento para la herramienta creada en este trabajo. La herramienta desarrollada en el presente trabajo cubre además características que existen en el paradigma orientado a objetos de manera inherente, tales como el estado de los objetos (en particular los objetos singleton con estado), clases abstractas e interfaces, que no existen en la programación funcional pura. La constribución de este trabajo de maestría es la presentación de una forma alternativa de realizar tests de unidad en la programación orientada a objetos (POO), basada en un trabajo anterior para el paradigma funcional. También se presenta una herramienta llamada YAQC4J que plasma esas ideas en un lenguaje orientado a objetos de amplia difusión. Finalmente se incluyen ejemplos que ilustran el uso de la herramienta, y se presenta una comparación con herramientas existentes que han intentado implementar el enfoque de testing. Este trabajo está dirigido a los desarrolladores de software interesados en conocer soluciones alternativas para el testing de unidad, y al mismo tiempo una forma complementaria a las ya existentes para pruebas de unidad.Facultad de Informátic