EMPIRICAL ASSESSMENT OF THE IMPACT OF USING AUTOMATIC STATIC ANALYSIS ON CODE QUALITY

Automatic static analysis (ASA) tools analyze the source or compiled code looking for violations of recommended programming practices (called issues) that might cause faults or might degrade some dimensions of software quality. Antonio Vetro' has focused his PhD in studying how applying ASA impacts software quality, taking as reference point the different quality dimensions specified by the standard ISO/IEC 25010. The epistemological approach he used is that one of empirical software engineering. During his three years PhD, he's been conducting experiments and case studies on three main areas: Functionality/Reliability, Performance and Maintainability. He empirically proved that specific ASA issues had impact on these quality characteristics in the contexts under study: thus, removing them from the code resulted in a quality improvement. Vetro' has also investigated and proposed new research directions for this field: using ASA to improve software energy efficiency and to detect the problems deriving from the interaction of multiple languages. The contribution is enriched with the final recommendation of a generalized process for researchers and practitioners with a twofold goal: improve software quality through ASA and create a body of knowledge on the impact of using ASA on specific software quality dimensions, based on empirical evidence. This thesis represents a first step towards this goa

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

Analysis of Human Affect and Bug Patterns to Improve Software Quality and Security

The impact of software is ever increasing as more and more systems are being software operated. Despite the usefulness of software, many instances software failures have been causing tremendous losses in lives and dollars. Software failures take place because of bugs (i.e., faults) in the software systems. These bugs cause the program to malfunction or crash and expose security vulnerabilities exploitable by malicious hackers. Studies confirm that software defects and vulnerabilities appear in source code largely due to the human mistakes and errors of the developers. Human performance is impacted by the underlying development process and human affects, such as sentiment and emotion. This thesis examines these human affects of software developers, which have drawn recent interests in the community. For capturing developers’ sentimental and emotional states, we have developed several software tools (i.e., SentiStrength-SE, DEVA, and MarValous). These are novel tools facilitating automatic detection of sentiments and emotions from the software engineering textual artifacts. Using such an automated tool, the developers’ sentimental variations are studied with respect to the underlying development tasks (e.g., bug-fixing, bug-introducing), development periods (i.e., days and times), team sizes and project sizes. We expose opportunities for exploiting developers’ sentiments for higher productivity and improved software quality. While developers’ sentiments and emotions can be leveraged for proactive and active safeguard in identifying and minimizing software bugs, this dissertation also includes in-depth studies of the relationship among various bug patterns, such as software defects, security vulnerabilities, and code smells to find actionable insights in minimizing software bugs and improving software quality and security. Bug patterns are exposed through mining software repositories and bug databases. These bug patterns are crucial in localizing bugs and security vulnerabilities in software codebase for fixing them, predicting portions of software susceptible to failure or exploitation by hackers, devising techniques for automated program repair, and avoiding code constructs and coding idioms that are bug-prone. The software tools produced from this thesis are empirically evaluated using standard measurement metrics (e.g., precision, recall). The findings of all the studies are validated with appropriate tests for statistical significance. Finally, based on our experience and in-depth analysis of the present state of the art, we expose avenues for further research and development towards a holistic approach for developing improved and secure software systems

Code Smells and Refactoring: A Tertiary Systematic Review of Challenges and Observations

In this paper, we present a tertiary systematic literature review of previous surveys, secondary systematic literature reviews, and systematic mappings. We identify the main observations (what we know) and challenges (what we do not know) on code smells and refactoring. We show that code smells and refactoring have a strong relationship with quality attributes, i.e., with understandability, maintainability, testability, complexity, functionality, and reusability. We argue that code smells and refactoring could be considered as the two faces of a same coin. Besides, we identify how refactoring affects quality attributes, more than code smells. We also discuss the implications of this work for practitioners, researchers, and instructors. We identify 13 open issues that could guide future research work. Thus, we want to highlight the gap between code smells and refactoring in the current state of software-engineering research. We wish that this work could help the software-engineering research community in collaborating on future work on code smells and refactoring

A systematic literature review on the code smells datasets and validation mechanisms

The accuracy reported for code smell-detecting tools varies depending on the dataset used to evaluate the tools. Our survey of 45 existing datasets reveals that the adequacy of a dataset for detecting smells highly depends on relevant properties such as the size, severity level, project types, number of each type of smell, number of smells, and the ratio of smelly to non-smelly samples in the dataset. Most existing datasets support God Class, Long Method, and Feature Envy while six smells in Fowler and Beck's catalog are not supported by any datasets. We conclude that existing datasets suffer from imbalanced samples, lack of supporting severity level, and restriction to Java language.Comment: 34 pages, 10 figures, 12 tables, Accepte