Mutación de expresiones de navegación para testing y reparación

Tesis (Doctor en Ciencias de la Computación)--Universidad Nacional de Córdoba, Facultad de Matemática, Astronomía, Física y Computación, 2018.Evaluar la calidad de un conjunto de tests con respecto a su capacidad de detectar potenciales bugs representa un área muy importante en la ingeniería de software. Métricas indirectas para la medición de este potencial incluyen coberturas de código (sentencias, ramas, decisiones, etc) y cobertura de clases de equivalencia sobre las entradas. Mutation testing es una de las métricas que mejor evalúa el potencial de detección de bugs de una test suite, ya que se basa en el uso de fallas artificiales para realizar la evaluación. Los operadores de mutación utilizados, es decir, las funciones que generan las distintas fallas artificiales, tienen un impacto directo en la precisión de la evaluación. En este trabajo se presenta un nuevo operador de mutación, orientado a fallas en lenguajes de programación orientada a objetos, específicamente a la mutación de expresiones de navegación. Este operador, llamado PRVO, es evaluado en el contexto de mutation testing y reparación automática de programas.Evaluating the quality of a tests set with respect to their ability to detect software defects constitutes a main problem in software engineering. Some indirect metrics for the measurement of a test suite quality includes code coverage (sentences, branches, decisions, etc.) and software's inputs space partition coverage. Mutation testing, which is based on the use of artificial defects, is one of the metrics that best evaluates the potential for bugs detection of a test suite. The mutation operators used, i.e. the functions that generate the various artificial defects, have a direct impact on the evaluation's accuracy. In this work we present a new mutation operator, oriented to generate defects related found in object oriented programming languages, specifically the mutation of navigational expressions. This operator, called PRVO, is evaluated in the context of mutation testing and automatic program repair.Fil: Gutiérrez Brida, Simón Emmanuel. Universidad Nacional de Córdoba. Facultad de Matemática, Astronomía, Física y Computación; Argentina

Criterios de cobertura sobre RepOK para reducir test suites exhaustivas acotadas: estudio de casos

La generación exhaustiva acotada de casos de test es una técnica de generación de entradas para programas que consiste en construir todas las posibles entradas válidas hasta cierta cota dada. Aunque el tamaño de la test suite generada está ligado a la cota provista, inclusive para cotas muy pequeñas las test suites obtenidas resultan considerablemente grandes, haciendo al uso de las mismas algo prohibitivo. En este trabajo revisaremos, adicionando nuevos casos de estudios, un enfoque para reducir el tamaño de las test suites generadas exhaustivamente presentado previamente. Este enfoque está basado en el uso de criterios de cobertura de código sobre el invariante de representación de la estructura sobre la cual la test suite es producida. La implementación de este invariante es utilizada para decidir cuándo dos entradas válidas pueden ser consideradas equivalentes, lo cual sucede si éstas ejercitan el código del invariante de representación de manera similar de acuerdo algún criterio de cobertura de código de caja blanca. Esta relación de equivalencia entre las entradas válidas es aprovechada para descartar casos de test que cubren clases de equivalencias ya cubiertas por algún otro caso de test presente en la suite. En este trabajo, se adicionan nuevos casos de estudios que muestran que, a medida que las cotas crecen, reducir las test suites exhaustivas aplicando la técnica presentada, produce resultados similares a las test suites exhaustivas, en cuanto a habilidad para matar mutantes.Eje: Workshop Ingeniería de Software (WIS).Red de Universidades con Carreras en Informática (RedUNCI

Implementación Básica de Typestates en Rust

Generalmente la API de un módulo describe las operaciones disponibles, aunque el orden lícito de aplicación de las mismas queda implícito o documentado externamente debido a que los lenguajes de programación generalmente no proveen mecanismos de especificación del protocolo de uso. Typestates permite especificar estados de objetos de un determinado tipo. Cada estado habilita ciertas operaciones y prohíbe otras, permitiendo especificar el protocolo de uso de una API determinada. En este trabajo se presenta un patrón de implementación de typestates en el lenguaje de programación Rust y se analiza su sistema de tipos y mecanismos que permiten la verificación del typestate en tiempo de compilación, mostrando que cumple con las propiedades requeridas por las propuestas de verificación modular descriptas en la bibliografía especializada.XVI Workshop Ingeniería de Software.Red de Universidades con Carreras en Informátic

Implementación Básica de Typestates en Rust

Generalmente la API de un módulo describe las operaciones disponibles, aunque el orden lícito de aplicación de las mismas queda implícito o documentado externamente debido a que los lenguajes de programación generalmente no proveen mecanismos de especificación del protocolo de uso. Typestates permite especificar estados de objetos de un determinado tipo. Cada estado habilita ciertas operaciones y prohíbe otras, permitiendo especificar el protocolo de uso de una API determinada. En este trabajo se presenta un patrón de implementación de typestates en el lenguaje de programación Rust y se analiza su sistema de tipos y mecanismos que permiten la verificación del typestate en tiempo de compilación, mostrando que cumple con las propiedades requeridas por las propuestas de verificación modular descriptas en la bibliografía especializada.XVI Workshop Ingeniería de Software.Red de Universidades con Carreras en Informátic

Implementación Básica de Typestates en Rust

Generalmente la API de un módulo describe las operaciones disponibles, aunque el orden lícito de aplicación de las mismas queda implícito o documentado externamente debido a que los lenguajes de programación generalmente no proveen mecanismos de especificación del protocolo de uso. Typestates permite especificar estados de objetos de un determinado tipo. Cada estado habilita ciertas operaciones y prohíbe otras, permitiendo especificar el protocolo de uso de una API determinada. En este trabajo se presenta un patrón de implementación de typestates en el lenguaje de programación Rust y se analiza su sistema de tipos y mecanismos que permiten la verificación del typestate en tiempo de compilación, mostrando que cumple con las propiedades requeridas por las propuestas de verificación modular descriptas en la bibliografía especializada.XVI Workshop Ingeniería de Software.Red de Universidades con Carreras en Informátic

Detección de objetos espurios en generación automática de entradas

En el contexto de testing, el uso de entradas generadas de manera automática, sobre las cuales se va a ejecutar el programa bajo prueba, es una práctica cada vez más común. En el caso particular de tipos de datos complejos, como los encontrados en programación orientada a objetos, una de las técnicas utilizadas se basa en el uso de mecanismos de reflexión provistos por el lenguaje, y especificaciones para evitar la generación de entradas inválidas. Sin embargo, cuando las especificaciones son débiles pueden llevar a construir objetos espurios, es decir, inválidos o no construibles por la API asociada al tipo del objeto. Estos objetos pueden llevar a falsos negativos: tests que fallan cuando no existe un bug e incrementan el trabajo del tester que deberá filtrar los tests que efectivamente evidencian un bug de aquellos que fallan solo por una entrada inválida; y falsos positivos: tests que deberían fallar pero que no lo hacen debido a que la entrada inválida enmascara el bug. En este trabajo evidenciaremos el problema mediante un ejemplo y delinearemos los componentes y pasos necesarios para construir una técnica que detecte cuando un objeto es inválido con respecto al API.XVI Workshop Ingeniería de Software.Red de Universidades con Carreras en Informátic

Detección de objetos espurios en generación automática de entradas

En el contexto de testing, el uso de entradas generadas de manera automática, sobre las cuales se va a ejecutar el programa bajo prueba, es una práctica cada vez más común. En el caso particular de tipos de datos complejos, como los encontrados en programación orientada a objetos, una de las técnicas utilizadas se basa en el uso de mecanismos de reflexión provistos por el lenguaje, y especificaciones para evitar la generación de entradas inválidas. Sin embargo, cuando las especificaciones son débiles pueden llevar a construir objetos espurios, es decir, inválidos o no construibles por la API asociada al tipo del objeto. Estos objetos pueden llevar a falsos negativos: tests que fallan cuando no existe un bug e incrementan el trabajo del tester que deberá filtrar los tests que efectivamente evidencian un bug de aquellos que fallan solo por una entrada inválida; y falsos positivos: tests que deberían fallar pero que no lo hacen debido a que la entrada inválida enmascara el bug. En este trabajo evidenciaremos el problema mediante un ejemplo y delinearemos los componentes y pasos necesarios para construir una técnica que detecte cuando un objeto es inválido con respecto al API.XVI Workshop Ingeniería de Software.Red de Universidades con Carreras en Informátic

FLACK: Counterexample-Guided Fault Localization for Alloy Models

Alloy is a specification language that has been used in a wide range of applications, such as program verification, test case generation, IoT and Android security, etc. Unlike imperative languages, such as C or Java, Alloy is declarative, which describes the logic of a computation without describing its control flow and does not generate traces during the execution. Thus, traditional fault localization techniques developed for imperative programs based on analyzing the control flows of passing and failing tests do not directly apply to Alloy. To aid developers in debugging Alloy models, we develop FLACK, a tool to automatically localize Alloy buggy expressions. Given an Alloy model with violated assertions, FLACK automatically outputs a ranking list of expressions based on their spaciousness to the assertions violations. For each assertion, FLACK first queries the Alloy analyzer for counterexamples, i.e. instances of the model that violate the asserted property. FLACK then uses a Partial Max-SAT (PMAXSAT) solver to find instances that satisfy the asserted property and are most similar to the counterexamples. FLACK then identifies the relations and atoms that are different between the counterexamples and the satisfying instances. The differences illustrate how the counterexamples violate the assertion. The PMAXSAT solver guarantees that these differences are “minimal”, containing only essential information related to the assertion violation. By finding expressions most related to these differences, FLACK identifies the potential expressions causing the assertion violation. FLACK is different than the state of the art on Alloy fault localization in that it does not rely on unit tests which are not commonly found accompanying Alloy models. Instead, FLACK relies on assertions and constraint solvers to obtain counterexamples and satisfying instances, which are the main underlying technology in Alloy and commonly used by the Alloy developers.Sociedad Argentina de Informática e Investigación Operativ

Bounded Exhaustive Search of Alloy Specification Repairs

The rising popularity of declarative languages and the hard to debug nature thereof have motivated the need for applicable, automated repair techniques for such languages. However, despite significant advances in program repair for imperative languages, there is a dearth of repair techniques for declarative languages. We present BeAFix, an automated repair technique for faulty models written in Alloy, a first-order relational logic language. BeAFix has a number of distinguishing features. Firstly, it supports any kind of oracle, including assertions typically found in formal specifications, as well as “specification tests”. This is important since unit tests, widely available for programs, are not typically found in formal specifications. Secondly, given a defined set of mutation operations, a set of suspicious expressions and a maximum number of mutations to apply per expression, BeAFix's bounded-exhaustive approach will either find a fix, or guarantee that such a fix is not possible, within the provided bounds. With respect to fault localization, BeAFix is not tightly integrated to any specific technique. In fact, our technique is independent of the fault localization technique used, and the fault localization is run only once before the repair process begins. To support a bounded-exhaustive approach while keeping repair times reasonable, sound state pruning techniques (i.e., those that guarantee that no valid fixes are removed) are introduced. When a faulty model has more than one suspicious expression, we use both syntactic analysis and dynamically generated scenario-based assertions to check the feasibility of a particular repair candidate. A failing check will determine that this candidate would never lead to a fully repaired model, allowing BeAFix to prune significant parts of the search space. We evaluated our technique on two Alloy benchmarks, including one previously used in a state-of-the-art technique for Alloy repair. The results show that BeAFix is able to repair thousands of real-world faulty models, corroborating its ability to effectively, and efficiently generate correct repairs while also being less prone to overfitting than previous techniques.Sociedad Argentina de Informática e Investigación Operativ