Uma Infraestrutura Baseada em Serviço para Evolução do Teste de Mutação Utilizando o Tamanho Semântico do Mutante

Transcrição

1 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA LEONARDO DA SILVA SOUSA Uma Infraestrutura Baseada em Serviço para Evolução do Teste de Mutação Utilizando o Tamanho Semântico do Mutante Goiânia 2014

2 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA AUTORIZAÇÃO PARA PUBLICAÇÃO DE DISSERTAÇÃO EM FORMATO ELETRÔNICO Na qualidade de titular dos direitos de autor, AUTORIZO o Instituto de Informática da Universidade Federal de Goiás UFG a reproduzir, inclusive em outro formato ou mídia e através de armazenamento permanente ou temporário, bem como a publicar na rede mundial de computadores (Internet) e na biblioteca virtual da UFG, entendendo-se os termos reproduzir e publicar conforme definições dos incisos VI e I, respectivamente, do artigo 5 o da Lei n o 9610/98 de 10/02/1998, a obra abaixo especificada, sem que me seja devido pagamento a título de direitos autorais, desde que a reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgação da produção acadêmica gerada pela Universidade, a partir desta data. Título: Uma Infraestrutura Baseada em Serviço para Evolução do Teste de Mutação Utilizando o Tamanho Semântico do Mutante Autor(a): Leonardo da Silva Sousa Goiânia, 08 de Agosto de Leonardo da Silva Sousa Autor Cássio Leonardo Rodrigues Orientador

3 LEONARDO DA SILVA SOUSA Uma Infraestrutura Baseada em Serviço para Evolução do Teste de Mutação Utilizando o Tamanho Semântico do Mutante Dissertação apresentada ao Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás, como requisito parcial para obtenção do título de Mestre em Computação. Área de concentração: Ciência da Computação. Orientador: Prof. Cássio Leonardo Rodrigues Co-Orientador: Prof. Márcio Eduardo Delamaro Goiânia 2014

4 LEONARDO DA SILVA SOUSA Uma Infraestrutura Baseada em Serviço para Evolução do Teste de Mutação Utilizando o Tamanho Semântico do Mutante Dissertação defendida no Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás como requisito parcial para obtenção do título de Mestre em Computação, aprovada em 08 de Agosto de 2014, pela Banca Examinadora constituída pelos professores: Prof. Cássio Leonardo Rodrigues Instituto de Informática UFG Presidente da Banca Prof. Auri Marcelo Rizzo Vincenzi Instituto de Informática UFG Prof. Vander Ramos Alves Departamento de Ciência da Computação UnB

5 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador(a). Leonardo da Silva Sousa Graduou-se em Ciência da Computação pela Universidade Federal de Mato Groso (UFMT). Atualmente é aluno de doutorado na Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO).

6 Dedico este trabalho a minha família.

7 Agradecimentos Agradecimento em especial a minha família que sempre esteve ao meu lado. A minha mãe, que bravamente resistiu à saudades. Ao meu pai, o responsável por eu ter chegado onde cheguei. E a minha irmã, que sempre me amou incondicionalmente, mesmo durantes meus momentos de mau humor - que foram mais frequentes do que eu pensei. Agradecimento ao meus orientadores, Cássio Rodrigues e Márcio Delamaro, pelo profissionalismo e dedicação na orientação desse trabalho. Tenho certeza que dei bastante trabalho, principalmente ao professor Cássio. Em nenhum momento ele me deixou desamparado, aliás, me deu bons conselhos e sempre foi presente e importante para as decisões que tomei durante o mestrado. Um agradecimento mais do que especial ao professor Auri Vincenzi. Sem ele esse trabalho não teria acontecido. Tenho uma enorme admiração tanto pelo profissional quanto pela pessoa que ele é. Realmente, uma fonte de inspiração. Também agradeço a todos os meus amigos, em especial aos meus irmãos adotivos, Igor Vieira e Vinicius Lobo. Obrigado pela ajuda e desculpa pelas inúmeras monitorias roubadas. Também não posso deixar de agradecer aos meus amigos Marllos Prado e André Lôbo. Eles foram fundamentais na reta final deste trabalho. Por fim, agradeço à Capes pela ajuda financeira.

8 "Nunca se esqueça de quem você é, porque é certo que o mundo não se esquecerá. Faça disso sua força. Assim, não poderá ser nunca a sua fraqueza. Arme-se com esta lembrança, e ela nunca poderá ser usada para magoá-lo." George R.R. Martin, As Crônicas de Gelo e Fogo - Livro 1: A Guerra dos Tronos.

9 Resumo Sousa, Leonardo da Silva. Uma Infraestrutura Baseada em Serviço para Evolução do Teste de Mutação Utilizando o Tamanho Semântico do Mutante. Goiânia, p. Dissertação de Mestrado. Instituto de Informática, Universidade Federal de Goiás. O Teste de Software é imprescindível caso se queira alcançar e garantir a qualidade do software desenvolvido. Existem algumas técnicas para se testar um software, entre tais técnicas há o Teste Baseado em Defeitos que inclui o critério denominado Teste de Mutação. O Teste de Mutação consiste em usar operadores de mutação para gerar um conjunto de programas alternativos, chamados de mutantes, que se diferem do programa original em um determinado ponto no código. Os casos de testes são aplicados no programa original e nos mutantes com o objetivo de verificar se os casos de testes são capazes de evidenciar a diferença de comportamento entre o programa original e cada mutante. Esse critério de teste se destaca devido sua eficácia em medir a qualidade do conjunto de teste enquanto encontra defeitos no programa, entretanto ela sofre com o alto custo computacional necessário para sua execução. Existem algumas abordagens que visam diminuir o custo do Teste de Mutação, entre elas a Mutação Seletiva. A Mutação Seletiva reduz o custo do teste, aplicando um conjunto reduzido de operadores de mutação capaz de gerar menos mutantes e ainda alcançar alta efetividade no teste. O objetivo desse trabalho é encontrar esse conjunto reduzido de operadores e mostrar que tal conjunto é quase tão bom quanto o conjunto total. Consequentemente, podendo ser usado na Mutação Seletiva. A diferença desse trabalho para outros que usam a Mutação Seletiva é que neste é usado uma abordagem baseada no defeito para selecionar o conjunto reduzido de defeitos, uma vez que o Teste de Mutação usa os defeitos que o programa poderia ter para testálo. Portanto nada mais lógico do que usar o próprio defeito como base para a seleção de operadores. Palavras chave essencial, mutantes, operador, serviço, tamanho, teste

10 Abstract Sousa, Leonardo da Silva. A Service-Based Infrastructure for evolution of Mutation Testing. Goiânia, p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás. Software Testing is indispensable if you want to achieve and guarantee the quality of developed software. There are some techniques to test software, among them Fault-based Testing Technique which includes the Mutation Testing criteria. Mutation Testing uses mutation operators to generate a set of alternative programs, called mutants, which differ from the original program at a particular point in the code. The test cases are applied in the original program and in the mutants in order to verify that the test cases are able to show the difference in behavior between the original program and each mutant. This test criterion stands out because of its effectiveness in measuring the quality of the test while finding defects in the program, however it suffers from the high computational cost required for its execution. There are some approaches that aim to reduce the cost of Mutation Testing, for example, Selective Mutation. Selective Mutation reduces the mutation cost applying a subset of mutation operators that it is capable of generating fewer mutants and still achieving high testing effectiveness. The aim of this paper is find a subset of mutation operators and show such subset is almost as good as the whole set. Thereby, such subset can be used in Selective Mutation.Here, fault is used to select a subset of mutation operators, this is main difference between this work and others works in Mutation Selective. Since Mutation Testing use fault that program could have, there is nothing more logical than using such fault to select operators. Keywords essential, mutants, operator, size, test, web-service

11 Sumário Lista de Figuras 11 Lista de Tabelas 12 Lista de Algoritmos 13 Lista de Códigos de Programas 14 1 Introdução Abordagem do Problema Objetivo e Contribuições Metodologia Organização do Trabalho 20 2 Teste de Mutação Fundamentação Teórica Teste de Mutação 24 Geração dos Mutantes 25 Execução do Programa com os casos de teste 27 Execução dos Mutantes com os casos de teste 27 Análise dos Mutantes Hipóteses que apoiam o Teste de Mutação Trabalhos Relacionados Mutação Seletiva Conjuntos Essenciais de Operadores de Mutação Caracterização Semântica dos Defeitos Mutação Semanticamente Seletiva Considerações Finais 36 3 Mutação Semanticamente Seletiva O Algoritmo Extração do Conjunto SEO Geração da Base de Dados Aplicação do Algoritmo Validação do Conjunto SEO Considerações Finais 49

12 4 Análise dos Resultados Conjunto SEO Efetividade do Conjunto SEO Limitações e Ameaças à Validade Considerações Finais 60 5 Infraestrutura Baseada em Serviço de Teste ProteumService Acurácia do conjunto SEO Proteum como serviço Ambiente padronizado de teste Arquitetura DistributionHandler ReportController ImproveController Interação com o ProteumService Implementação Considerações Finais 75 6 Conclusão e Trabalhos Futuros Conclusão Trabalhos Futuros 78 Referências Bibliográficas 80 A Operadores de Mutação 86 A.1 Arithmetic by Bitwise Operator (u-oabn) 86 A.2 Plain assignment by Shift Assignment (u-oesa) 86 A.3 Arithmetic Operator Mutation (u-oaan) 87 A.4 Statement Deletion (u-ssdl) 87 A.5 Mutate Local Scalar References (u-vlsr) 88 A.6 Constant for Constant Replacement (u-cccr) 88 A.7 Twiddle Mutations (u-vtwd) 89 A.8 Plain assignment by Arithmetic Assignment (u-oeaa) 90 A.9 Domain Traps (u-vdtr) 90 A.10 Constant for Scalar Replacement (u-ccsr) 91 B Implementação 92 B.1 Executando script 92

13 Lista de Figuras 2.1 Caso de Teste Th que mata o mutante SSHOM Etapas do algoritmo para extrair os operadores semanticamente essenciais Geração sequencial dos casos de teste válidos Esquema do Banco de Dados usado pelo algoritmo. 43 (a) Cal 52 (b) Look 52 (c) Comm 53 (d) Checkeq Escore de Mutação para 5-UNIX 54 (e) Uniq Infraestrutura do ProteumService para o Teste de Mutação Distribuição dos operadores entre as máquinas ociosas Representação BPMN do processo de teste por meio da ProteumService Infraestrutura simplificada do ProteumService. 74

14 Lista de Tabelas 3.1 Operadores de Mutação aplicados no programa Cal O conjunto de operadores comparado Conjunto SEO extraído do Cal Cal - Escore de mutação e geração de mutantes Look - Escore de mutação e geração de mutantes Comm - Escore de mutação e geração de mutantes Checkeq - Escore de mutação e geração de mutantes Uniq - Escore de mutação e geração de mutantes Redução de custo em relação aos mutantes gerados. 58

15 Lista de Algoritmos 1 Cálculo do Tamanho Semântico44 2 Seleção dos mutantes45 3 Extração do conjunto SEO45

16 Lista de Códigos de Programas 2.1 Trecho original Mutante 1 - Não equivalente Mutante 2 - Equivalente 26 A.1 Trecho original u-oabn 86 A.2 Mutante u-oabn 86 A.3 Trecho original u-oesa 87 A.4 Mutante u-oesa 87 A.5 Trecho original u-oaan 87 A.6 Mutante u-oaan 87 A.7 Trecho original u-ssdl 88 A.8 Mutante u-ssdl 88 A.9 Trecho original u-vlsr 88 A.10 Mutante u-vlsr 88 A.11 Trecho original - u-cccr 89 A.12 Mutante u-cccr 89 A.13 Trecho original u-vtwd 89 A.14 Mutante u-vtwd 89 A.15 Trecho original u-oeaa 90 A.16 Mutante u-oeaa 90 A.17 Trecho origina u-vdtr 90 A.18 Mutante u-vdtr 90 A.19 Trecho original u-ccsr 91 A.20 Mutante u-ccsr 91

17 Introdução CAPÍTULO 1 Desenvolvimento de software é uma tarefa complexa. São vários fatores que contribuem para que a qualidade do sistema construído seja prejudicada, fatores estes que se acentuam com as características e dimensões do sistema. Diante dessas barreiras surgiu a necessidade de aplicar a Engenharia de Software para alcançar a qualidade do produto desenvolvido. Mesmo utilizando ferramentas e metodologias da Engenharia de Software, a obtenção do produto diferente daquele que se esperava é comum (BOEHM; BASILI, 2001). Em geral esse produto anômalo é resultante de uma única fonte: o engano humano (DELAMARO; MALADONADO; JINO, 2007). Para eliminar ou minimizar os enganos humanos cometidos no desenvolvimento do software, existe uma série de atividades com a finalidade de garantir que tanto o modo pelo qual o software está sendo construído, quanto o produto em si estejam em conformidade com o que foi especificado. Este conjunto de atividades é coletivamente chamado de Validação, Verificação e Teste de Software (DELAMARO; MALADONADO; JINO, 2007). Neste cenário destaca-se o Teste de Software, que é um processo, ou um conjunto de processos, que tem como objetivo verificar se o software faz aquilo que ele foi projetado para fazer e que ele não faça nada que não seja intencional (MYERS; SANDLER, 2004, p. 8). Segundo o IEEE Standard Glossary Teste é o processo de operar um sistema ou componente sob condições específicas, observando e registrando os resultados, avaliando alguns aspectos do sistema ou componente (IEEE, 1990). De acordo com essa definição, o teste é uma das atividades constituintes do ciclo de vida do desenvolvimento do software e de extrema importância. Apesar de ser um processo caro e demorado, ele é imprescindível caso se queira atingir a alta qualidade do produto desenvolvido (COLLOFELLO; VEHATHIRI, 2005). Um dos fatores que influenciam o alto custo da atividade de teste é o número de casos de teste usado para testar o produto. É impraticável gerar todas as combinações de entrada para se testar um software (MYERS; SANDLER, 2004). É necessário escolher um conjunto de teste que seja pequeno e que ao mesmo tempo seja capaz de refletir o comportamento do sistema para todo o universo de entrada. Devido a essa complexidade

18 1.1 Abordagem do Problema 16 em testar um sistema, é necessário que algumas técnicas sejam traçadas antes dos testes iniciarem. São essas técnicas que guiarão o testador durante o processo de teste. O Teste Baseado em Defeitos é um exemplo de técnica de teste. As técnicas de teste têm associados a si critérios de teste. Os critérios de testes são as normas/regras que o sistema ou componente deve seguir caso queira passar pelo teste. Os critérios de teste são usados para auxiliar na geração dos casos de teste e também na avaliação dos mesmos, usando como base a hierarquia de teste do qual se deriva. Por exemplo, os critérios pertencentes à técnica de Teste Baseado em Defeitos usam os defeitos que podem estar presentes no programa como base para a atividade de teste. Os critérios presentes nessa técnica utilizam-se do histórico de enganos frequentes que são cometidos no processo de desenvolvimento de software e tipos específicos de erros que se desejam revelar para testar o software (DEMILLO; KRAUSER; MATHUR, 1991). Um exemplo de critério presente na técnica de Teste Baseado em Defeitos é o Teste de Mutação. O Teste de Mutação (DEMILLO; LIPTON; SAYWARD, 1978) consiste em gerar um conjunto de programas alternativos, chamados de mutantes, que se diferem em determinado ponto do programa original. Esse ponto de diferença representa um defeito no programa e são criados a partir de operadores de mutação. Os casos de teste são aplicados no programa original e em seus mutantes, com o objetivo de verificar se os casos de teste são capazes de evidenciar a diferença de comportamento entre o programa original e cada mutante. Ao mostrar que o conjunto de teste é capaz de mostrar a diferença entre o programa e seus mutantes, é dito que o conjunto é adequado para o teste. Assim aquele defeito que o programa poderia ter, ele não têm, uma vez que ele conseguir pegar o mesmo defeito no mutante. Se esse defeito existisse no programa em teste, o caso de teste seria capaz de pegá-lo. 1.1 Abordagem do Problema O Teste de Mutação se mostra eficaz para medir a qualidade do conjunto de teste enquanto revela a presença de defeitos (ACREE et al., 1979; BUDD et al., 1980; WONG, 1993). Mesmo sendo tão eficaz, o Teste de Mutação sofre com o problema de ser muito caro na prática (ANDREWS; BRIAND; LABICHE, 2005), pois exige um alto custo computacional para gerar todos os mutantes e exercitá-los com os casos de teste. Várias estratégias (JIA; HARMAN, 2011) surgiram para diminuir o custo computacional do Teste de Mutação, ora diminuindo a quantidade de mutantes gerada, ora diminuindo o tempo computacional necessário para executar os mutantes. É justamente nessa primeira estratégia que esse trabalho foca. A redução que se pretende alcançar aqui não está

19 1.1 Abordagem do Problema 17 relacionada diretamente com a redução do tempo de execução dos mutantes 1, nem mesmo com a redução de mutantes equivalentes, o objetivo deste é reduzir o custo do Teste de Mutação reduzindo-se o número de mutantes gerados. Entre as várias técnicas para se reduzir o número de mutantes gerado, este trabalho foca na Mutação Seletiva (Selective Mutation 2 ) (MATHUR, 1991; OFFUTT; ROTHERMEL; ZAPF, 1993). A Mutação Seletiva é uma técnica que visa reduzir os mutantes gerados por meio da redução dos operadores de mutação. Os operadores de mutação são os responsáveis pelas alterações sintáticas empregadas no programa original para se criar os mutantes. Esse conjunto de operadores é determinado pela linguagem de programação do programa em teste. O objetivo da Mutação Seletiva é conseguir encontrar um subconjunto de operadores de mutação que seja capaz de ser tão efetivo quanto se o teste estivesse sendo executado com todos os operadores. Portanto, a Mutação Seletiva precisa de um bom conjunto de operadores de mutação, logo deve ser aplicada alguma estratégia para se selecionar os operadores que devem ser usados. Como os operadores de mutação geram diferentes números de mutantes, quando Mathur (1991) propôs a Mutação Seletiva ele usou a estratégia de seleção baseada na quantidade de mutantes que cada operador gerava. Aqueles operadores de mutação que geravam a maior quantidade de mutantes foram suprimidos do conjunto de operadores. Depois desse trabalho inicial em Mutação Seletiva, outras abordagens foram usadas para selecionar o conjunto de operadores de mutação. Ao contrário da estratégia de seleção usada por Mathur, o trabalho proposto aqui irá adaptar uma estratégia desenvolvida por Offutt e Hayes (1996). Offutt e Hayes (1996) sugeriram que é possível resolver alguns problemas da área de teste ao analisar os defeitos por meio da caracterização semântica. Na caracterização semântica 3 os defeitos são analisados não somente pelo aspecto sintático, mas também pelo impacto semanticamente causado por eles. Uma das discussões consistia em utilizar a caracterização semântica dos defeitos na Mutação Seletiva. Para tal os autores trabalharam com o conceito de tamanho semântico de um defeito. O tamanho semântico de um defeito está relacionado com o quanto aquele defeito irá afetar o domínio de entrada, por exemplo, um defeito que afeta todas as entradas pode ser considerado um defeito semanticamente grande. Baseando-se nessa caracterização semântica, Offutt e Hayes teorizaram a hipótese de que a Mutação Seletiva está tentando usar apenas operadores que tendem a produzir mutantes que tem defeitos semanticamente pequenos. Logo, para eles o operador que funciona bem experimentalmente é capaz de produzir mutantes 1 Embora no Capítulo 5 seja proposto uma redução desse tipo, o foco principal desse trabalho é reduzir a geração de mutantes e não o tempo de execução. 2 A princípio a técnica foi chamada de constrained mutation. 3 Os detalhes que envolvem a caracterização semântica dos defeitos serão abordados na Seção

20 1.2 Objetivo e Contribuições 18 que são, na média, semanticamente pequenos. Para verificar essa hipótese, Offutt e Hayes fizeram um estudo preliminar no qual mapearam o tamanho semântico de um defeito para os mutantes, atribuindo-lhes um tamanho semântico. Ao contrário da estratégia de Marthur, que alcançou o conjunto de operadores essenciais eliminando os operadores que mais geravam mutantes, este trabalho usa a caracterização semântica dos defeitos, mais precisamente o tamanho semântico dos mutantes, para desenvolver uma estratégia de seleção de operadores de mutação para Mutação Seletiva. Embora este trabalho use a caracterização semântica e a mesma abordagem para se calcular o tamanho semântico do mutantes usado por Offutt e Hayes (1996) é importante salientar que as semelhanças terminam neste ponto. Embora Offutt e Hayes tenham apresentado dados preliminares que dão suporte ao tamanho semântico, nada mais acurado para explorar a caracterização semântica foi desenvolvido. Por exemplo, nenhum algoritmo foi implementado para selecionar os operadores de mutação que são responsáveis por gerar os mutantes pequenos. Justamente esse algoritmo é uma das contribuições deste trabalho. A estratégia empregada nesse trabalho utilizará o tamanho semântico dos mutantes para selecionar um conjunto de operadores que devem ser usados na Mutação Seletiva, tornando o Teste de Mutação computacionalmente mais barato. Mesmo aplicando a Mutação Seletiva, os operadores que serão encontrados aqui provavelmente não serão adequados a todos os programas, dessa maneira, este trabalho ainda propõe a criação de uma infraestrutura de teste capaz de validar e aprimorar os resultados aqui encontrados. Essa infraestrutura será oferecida como um Serviço de Teste. 1.2 Objetivo e Contribuições O objetivo desse trabalho é reduzir o custo do Teste de Mutação, reduzindo a quantidade de mutantes gerada. Para se alcançar este objetivo, foi escolhido a Mutação Seletiva como estratégia de redução, visto que ela reduz a quantidade de mutantes gerada, reduzindo a quantidade de operadores de mutantes aplicada durante o teste. Porém a Mutação Seletiva precisa de uma estratégia de seleção de operadores, a estratégia desenvolvida neste trabalho baseia-se no trabalho de Offutt e Hayes (1996). Ao cumprir esse objetivo, esse trabalho gera as seguintes contribuições: Usar a caracterização semântica de defeitos para selecionar os operadores para a Mutação Seletiva. A primeira contribuição deste trabalho é disponibilizar um algoritmo que explora a caracterização semântica como uma estratégia para selecionar um conjunto de operado-

21 1.3 Metodologia 19 res de mutação para ser usado na Mutação Seletiva. Essa estratégia é chamada de Mutação Semanticante Seletiva. Validar o algoritmo e o conjunto de operadores retornados por ele. A segunda contribuição é verificar se o algoritmo é capaz de retornar um bom conjunto de operadores de mutação quando aplicado em um programa. Para verificar se o conjunto de operadores é forte o suficiente para ser aplicado na Mutação Seletiva, o conjunto será aplicado em outros programas para verificar sua efetividade. Neste trabalho definimos efetividade como a capacidade de um conjunto de operadores alcançar um alto escore de mutação, mesmo gerando menos mutantes. Se o conjunto de operadores se mostrar satisfatório, então a Mutação Semanticamente Seletiva proposta neste trabalho alcançou o objetivo. Além dessa contribuição, os resultados servirão como uma prova de conceito para o hipótese de Offutt e Hayes, uma vez que eles teorizaram que a Mutação Seletiva tenta usar operadores que tendem a gerar mutantes que tem defeitos semântica pequenos. Desenvolver uma infraestrutura de teste baseada em serviço. O principal objetivo desse trabalho é reduzir o custo do Teste de Mutação usando a Mutação Seletiva. Para se alcançar essa redução foi desenvolvido um algoritmo que retorna um conjunto de operadores de mutação que possa ser usado na Mutação Seletiva. Com base nisso, a última contribuição desse trabalho é oferecer esse conjunto de operadores para os usuários usarem. Para que isso seja possível o objetivo é desenvolver uma infraestrutura de teste baseada em serviço, chamado de ProteumService. Com esse serviço disponível o usuário pode usufruir do Teste de Mutação com o custo reduzido utilizando o conjunto encontrado neste trabalho, ao passo que enquanto o usuário usa o serviço oferecido, o dados coletados por ele serão usados para melhorar o conjunto de operadores encontrados aqui. 1.3 Metodologia Para se alcançar o objetivo e as contribuições desse trabalho é necessário que uma série de etapas aconteça. A primeira etapa consiste em desenvolver um algoritmo para seleção de operadores que explore o tamanho semântico do mutantes discutido por Offutt e Hayes (1996). O algoritmo usa a mesma rotina para se computar de maneira aproximada o tamanho do mutante. Após definido e codificado o algoritmo, a próxima etapa consiste em aplicar o algoritmo em um programa sobre o teste. O objetivo dessa etapa é verificar se o algoritmo

22 1.4 Organização do Trabalho 20 é capaz de usar o tamanho semântico para selecionar um conjunto de operadores de mutação. Esse conjunto de operadores foi denominado de conjunto SEO - conjunto de operadores semanticamente essenciais. A terceira etapa resume-se a verificar a qualidade do conjunto SEO encontrado pelo algoritmo. O objetivo é verificar se esse conjunto é forte o suficiente para ser usado na Mutação Seletiva. Portanto, o conjunto SEO tem que ser capaz de reduzir o custo computacional, gerando menos mutantes, ao mesmo tempo não tenha uma grande perda de efetividade no teste. Para verificar se o conjunto cumpriu essas exigências ele será comparado com outros conjuntos usados na literatura. Se o conjunto SEO for tão bom quanto os conjuntos usados na comparação, então é considerado que o conjunto é forte para ser usado na Mutação Seletiva. A quarta e última etapa consiste em desenvolver o serviço de teste denominado ProteumService. Esse serviço será um conjunto de algoritmos e ferramentas, com o qual o usuário entrará com o programa a ser testado e com o conjunto com os casos de testes. O objetivo do ProteumService é oferecer o Teste de Mutação para os usuários com um custo computacional reduzido. Para que isso seja possível, uma vez verificada a efetivada do conjunto SEO, o mesmo poderá ser empregado no serviço, logo permitindo que o Teste de Mutação possa ser aplicado com custo reduzido. Além de oferecer o Teste de Mutação para os usuários, o ProteumService aqui proposto ainda se beneficiará da atividade de teste do usuário para dar continuidade ao trabalho, aumentando a quantidade de dados sobre os operadores e viabilizando um processo de melhoria constante. Uma vez que é impossível realizar o estudo/experimentação com vários programas, o Serviço de Teste usará os programas do usuário para se aplicar o algoritmo desenvolvido aqui com o objetivo de melhorar o conjunto SEO. 1.4 Organização do Trabalho Este capítulo introduziu o contexto de Teste de Software no qual este trabalho está inserido, descrevendo o problema a ser resolvido, os objetivos a serem atingidos e a metodologia usada. O Capítulo 2 explorará os principais conceitos relacionados ao Teste de Mutação, apresentando os conceitos e desafios inerentes desse critério de teste e algumas abordagens usadas para reduzir o seu custo computacional. Nesse capítulo também será introduzida a abordagem usada nesse trabalho: a mutação semanticamente seletiva. Em seguida, o Capítulo 3 se aprofundará na mutação semanticamente seletiva, abordando como ela é alcançada e usada no trabalho. Primeiro apresentando o algoritmo que explora a caracterização semântica. Em seguida, por meio de uma experimentação, o algoritmo que implementa a abordagem é aplicado em um programa sobre teste. O objetivo é verificar se o algoritmo (abordagem) é capaz de realizar seu propósito.

23 1.4 Organização do Trabalho 21 Nesse mesmo capítulo um segundo experimento é descrito. O objetivo desse segundo experimento é verificar a qualidade dos resultados encontrados no primeiro experimento, para, portanto, validar a abordagem. O Capítulo 4 se encarregará de apresentar e analisar os resultados de ambos experimentos. Nesse capítulo também serão apresentadas as limitações e ameaças à validade do estudo. Ao final do capítulo será apresentada a conclusão do estudo baseando-se nos resultados encontrados com ambas as experimentações. É nessa subseção que é concluído se o estratégia de caracterização semântica (implementada por meio do algoritmo) alcançou de forma satisfatória os objetivos pretendidos: encontrar um conjunto de operadores essenciais que reduz o custo computacional da mutação ao passo que mantém a efetividade do teste. Devido aos resultados encontrados envolvendo a caracterização semântica, o Capítulo 5 apresentará a arquitetura do serviço de teste que explora a abordagem semântica. Nesse capítulo serão apresentados os principais benefícios que uma infraestrutura de teste traz e como ela será capaz de minimizar algumas limitações e ameças do trabalho realizado. O Capítulo 6 sintetiza as contribuições e apresenta a conclusão e perspectivas de desdobramentos decorrentes deste trabalho. Finalmente o Apêndice B traz os scripts utilizados na comunicação entre a ProteumService e a ferramenta Proteum e também apresenta a classe Java responsável por executar os scripts.

24 Teste de Mutação CAPÍTULO 2 Este capítulo abordará alguns conceitos relacionados ao Teste de Software. Primeiramente serão introduzidas as principais técnicas de teste, em seguida serão abordados as características, vantagens, limitações e trabalhos na área de Teste de Mutação. Ao decorrer desse capítulo será apresentado o problema do alto custo computacional exigido pelo Teste de Mutação e qual a estratégia desenvolvida neste trabalho para se alcançar a redução desse custo. 2.1 Fundamentação Teórica Myers e Sandler (2004) afirmam que testar é o processo de executar um programa com o objetivo de encontrar erros, sendo que um bom caso de teste possui a alta probabilidade de revelar a presença deles. Portanto um bom caso de teste é aquele que detecta a presença de um erro ainda não descoberto. Essa é a maneira cujo teste agregará valor ao produto, aumentando sua confiabilidade e qualidade. Para que esse processo ocorra de maneira sistemática e alcance seus objetivos é necessário que algumas técnicas sejam aplicadas. São essas técnicas que guiarão o testador durante o processo de teste. Entre tais técnicas podem ser citadas: Teste Funcional, Teste Estrutural e Teste Baseado em Defeitos. O Teste Funcional ou Teste de Caixa Preta se caracteriza por testar o software sem se preocupar com detalhes de implementação, se concentrando em encontrar circunstâncias cujo programa não se comporta de acordo com a especificação. Dessa maneira o conjunto de teste é construído usando a especificação do sistema como base. São fornecidos entradas e então se avalia se a saída gerada está em conformidade com a especificação (IPATE; LEFTICARU, 2007). O Teste Funcional é capaz de detectar todos os defeitos de forma exaustiva. Na prática esta abordagem se torna inviável devido ao grande domínio de entrada. Para amenizar essa situação, essa técnica é conduzida de maneira sistemática. As vantagens dos critérios da Técnica Funcional é o fato desses critérios apenas necessitarem das especificações do sistema, podendo ser aplicado independente da linguagem em que o

25 2.1 Fundamentação Teórica 23 sistema foi construído (NASEER; REHMAN; HUSSAIN, 2010). Como desvantagem tem-se que não é garantido que partes críticas ou essenciais do sistema sejam testadas. Outro problema diz respeito ao comportamento dos componentes, que na prática pode não condizer com o que foi especificado (DELAMARO; MALADONADO; JINO, 2007, p. 24). Por exemplo, se espera que elementos de uma mesma classe tenham o mesmo comportamento, porém isso pode não acontecer. A Técnica Estrutural ou Caixa Branca estabelece os requisitos de teste com base na estrutura interna do programa, requerendo a execução de partes ou componentes elementares do programa. Nesta técnica o código fonte é o principal centro das atenções (YUNMING; WEI, 2008). Os caminhos lógicos do software são testados, avaliando condições, laços, definições e uso de variáveis. A técnica é vista como complementar às demais, visto o fato que a mesma cobre classes diferentes de defeitos, podendo, portanto, ser aliada a outras técnicas para aumentar o nível de confiabilidade do produto (DELAMARO; MALADONADO; JINO, 2007, p. 48). As desvantagens dessa técnica diz respeito a questões inerentes à implementação, levando a técnica a certas limitações, por exemplo, se houver caminhos ausentes (uma função não implementada) não haverá dado de testes para exercitá-la. Outro problema da técnica diz respeito à correção coincidente, que consiste de o programa apresentar coincidentemente um resultado correto para determinada entrada, apesar de haver um defeito (PEZZè; YOUNG, 2008). Além dessas limitações, a técnica ainda exige que o testador tenha um grande conhecimento sobre o programa. Dessa maneira têm-se vários problemas em relação à automação do processo de validação de software, tais como, o fato de não existir um procedimento de teste geral capaz de provar a correção de um programa. Outro problema reside no fato de ser indecidível se dois programas ou dois caminhos de um mesmo programa ou de programas diferentes computam a mesma função (OFFUTT; PAN, 1996). Em geral é indecidível identificar se um dado caminho é executável. A Técnica de Teste Baseada em Defeitos utiliza-se de defeitos frequentes cometidos no processo de desenvolvimento de software e tipos específicos de defeitos que se deseja revelar (DEMILLO; KRAUSER; MATHUR, 1991). Os critérios presentes nessa técnica utilizam-se dos defeitos para verificar o quão confiável é o conjunto de testes usados para testar o software. Dependendo do resultado é decidido se é necessário melhorar ou não o conjunto de teste. Dois critérios comuns dessa técnica são a Semeadura de Erros e o Teste de Mutação. O critério Semeadura de Erros (KNIGHT; AMMANN, 1985) aplica uma quantidade de defeitos artificiais no programa. O objetivo é verificar quais daqueles defeitos encontrados pelos casos de teste são naturais e quais são artificiais. O critério tem sido utilizado para verificar o quanto um determinado programa tem sido bem testado, já que é possível ter uma estimativa de quantos defeitos ainda existem no programa.

26 2.1 Fundamentação Teórica 24 O Teste de Mutação (DEMILLO; LIPTON; SAYWARD, 1978) consiste em gerar um conjunto de programas alternativos, chamados de mutantes, que se diferem em determinado ponto do programa original. Esse ponto de diferença representa um defeito que o programador poderia cometer durante o processo de desenvolvimento. Os casos de testes são aplicados no programa original e em seus mutantes com o objetivo de verificar se os mesmos são capazes de evidenciar a diferença de comportamento entre o programa original e cada mutante Teste de Mutação O Teste de Mutação é um critério que assume que um programa será bem testado se todos os chamados defeitos simples (por exemplo, o uso de um operador incorreto) são detectados e removidos (DEMILLO; KRAUSER; MATHUR, 1991). Para tal, defeitos são inseridos no programa por meio da criação de diferentes versões sintaticamente corretas do programa, conhecidas como mutantes. Cada mutante é criado aplicando operadores de mutação. Os operadores contêm regras que fazem alterações sintáticas no código do programa em teste. O marco inicial do Teste de Mutação foi na década de 70 quando pesquisadores do Georgia Institute of Technology e Yale University apresentaram a ideia central da técnica, baseando-se na hipótese do programador competente e no efeito de acoplamento. Um dos primeiros artigos a serem públicos sobre o Teste de Mutação foi de DeMillo, Lipton e Sayward (1978). Os mutantes podem ser classificados de acordo com a quantidade de operadores que foram aplicados para gerá-lo (HARMAN; JIA; LANGDON, 2010). De acordo com tal classificação, os mutantes podem ser de primeira ordem, denominados de FOMs (First Order Mutants) e mutantes de alta ordem, HOMs (Higher Order Mutants). FOMs são gerados aplicando operadores de mutação apenas uma vez no programa testado para se gerar um mutante, enquanto HOMs são gerados aplicando operadores de mutação mais de uma vez, ou seja, um mutante é resultado de um ou mais operadores combinados. Historicamente, o Teste de Mutação em geral utiliza mutantes de primeira ordem (FOM Testing) (DEMILLO; LIPTON; SAYWARD, 1978; HAMLET, 1977). O Teste de Mutação destaca-se na comunidade de teste, pois ele é um dos critérios mais efetivos para revelar a existência de defeitos (WONG, 1993; MATHUR; WONG, 1994; OFFUTT et al., 1996; FRANKL; WEISS; HU, 1997). Embora eficaz na detecção de defeitos, o Teste de Mutação sofre com o alto custo computacional para sua execução. Um problema associado com elevado custo diz respeito à quantidade de mutantes que são gerados, executados e (manualmente) analisados. Por essa razão esse critério é considerado muito caro na prática.

27 2.1 Fundamentação Teórica 25 Para aplicar o Teste de Mutação é necessário um programa P a ser testado e um conjunto de teste T, cuja qualidade se deseja avaliar. A qualidade do conjunto de teste T é medida pela sua habilidade de distinguir o programa original P de seus mutantes M s. Se o conjunto T alcançar essa habilidade, então o conjunto de teste revela que o programa não tem todos os possíveis defeitos que ele poderia ter, aumentando o nível de confiança no programa. Os passos para aplicar o critério são: 1. Geração dos Mutantes; 2. Execução do Programa com os casos de teste; 3. Execução dos Mutantes com os casos de teste; 4. Análise dos Mutantes. Geração dos Mutantes A primeira etapa consiste em criar os mutantes do programa P. Cada mutante é criado a partir de uma alteração sintática no código fonte de P. A alteração é realizada por meio do operador de mutação que foi aplicado. Esses operadores contêm regras responsáveis pelas alterações no programa original, cada um deles é aplicado em P para produzir um conjunto de mutantes. Devido à maneira com que o operador realiza as alterações, um mesmo operador pode gerar mais de um mutante. Para cada ponto de mutação encontrado por ele, poderá ser criado um ou mais mutantes. Essa é uma das razões que o Teste de Mutação é tão caro na prática. Por exemplo, considerando o trecho de código apresentado no Código 2.1, ao aplicar o operador de mutação ORRN serão gerados mutantes por meio da substituição de um operador relacional por outro operador relacional. Somente na linha 6 serão gerados 5 novos mutantes (um novo mutante para cada operador relacional). Em qualquer outra linha que ocorrer um operador relacional, a mesma quantidade de mutantes será gerada. Dois exemplos de mutantes 1 que são gerados ao aplicar esse operador são mostrados no Código 2.2 e no Código A linha onde ocorreu o ponto de mutação é indicada por ->.

28 2.1 Fundamentação Teórica 26 Código 2.1 Trecho original 1 int day_in_year(int day, int month, int year) { 2 int i, leap; 3 4 leap = leap_year(year); 5 6 for (i = 1; i < month; i++) 7 day += days_in_month[leap][i]; 8 9 return day; 10 } Código 2.2 Mutante 1 - Não equivalente 1 int day_in_year(int day, int month, int year) { 2 int i, leap; 3 4 leap = leap_year(year); 5 6 -> for (i = 1; i > month; i++) 7 day += days_in_month[leap][i]; 8 9 return day; 10 } Código 2.3 Mutante 2 - Equivalente 1 int day_in_year(int day, int month, int year) { 2 int i, leap; 3 4 leap = leap_year(year); 5 6 -> for (i = 1; i!= month; i++) 7 day += days_in_month[leap][i]; 8 9 return day; 10 } Ao analisar o programa original do Código 2.1 e o mutante do Código 2.3 é possível perceber que ambos os trechos possuem o mesmo comportamento para qualquer

29 2.1 Fundamentação Teórica 27 entrada. Independente da entrada, ambos sempre produzem a mesma saída, nesse caso o Mutante 2 é considerado equivalente ao programa original. Identificar se dois programas são equivalentes é uma tarefa, em geral, indecidível (OFFUTT; PAN, 1996), logo esse é outro problema enfrentado pelo Teste de Mutação. Em geral, essa tarefa precisa da intervenção humana e exige um grande esforço, aumentando os custos da atividade de teste e dificultando o processo de automação. Execução do Programa com os casos de teste Antes de executar os mutantes criados, primeiramente executa o programa P usando os casos de testes disponíveis. O objetivo é verificar se o comportamento de P é aquele definido pela especificação. Se o comportamento não for o esperado, ou seja, se o programa apresentar resultados incorretos, então uma falha foi exposta no programa P e o processo termina. Se nenhuma falha ocorrer, o Teste de Mutação pode continuar. Execução dos Mutantes com os casos de teste O próximo passo é executar cada mutante usando o conjunto de teste T. Se um mutante M apresentar resultado diferente de P, isso significa que os casos de teste conseguiram encontrar essa diferença, logo o mutante M é dado como morto. Caso o mutante gere o mesmo resultado que o programa P para todos casos de teste em T, ele permanece vivo e é enviado para análise. Há dois motivos que levam um mutante a permanecer vivo: ou o conjunto de teste T não é forte o suficiente para distinguir a diferença entre P e M ou o mutante M e o programa P são equivalentes. Análise dos Mutantes Essa é a etapa em que mais exige da intervenção do testador, pois é necessário fazer uma análise dos mutantes que sobreviveram. É preciso decidir se tais mutantes são equivalentes ou não ao programa original. Se o mutante é equivalente, então ele deve ser descartado do conjunto de mutantes vivos. Caso contrário, o conjunto de teste não foi adequado suficiente para diferenciar o mutante do programa original, fazendo-se necessária a inclusão de novos casos de teste ao conjunto T. Terminado a análise dos mutante é gerado um indicador do quanto o conjunto de teste é adequado. Esse indicador é chamado de Escore de Mutação (mutation score) e varia de [0-1]. Quanto mais próximo de 1, mais adequado é o conjunto de teste. O Escore de Mutação (ms) é calculado pela Equação 2-1: Sendo: ms(p,t ) = DM(P,T ) M(P) EM(P) (2-1)

30 2.1 Fundamentação Teórica 28 DM(P,T ): número total de mutantes de P mortos pelo conjunto de teste T; M(P): número total de mutantes gerado a partir do programa P; EM(P): número de mutantes equivalente. No cálculo do escore de mutação apenas DM(P,T ) depende do conjunto de teste utilizado. EM(P) é obtido à medida que o testador decide que determinado mutante vivo é equivalente. A soma dos mutantes que morrem com o conjunto de teste (DM(P,T )), como os mutantes que ficaram vivos e os mutante equivalentes (EM(P)) é igual ao número total de mutantes gerados (M(P)). Portanto, a Equação 2-1 sempre resulta em um valor menor ou igual a. Após definir quais dos mutantes vivos não são equivalentes os passos de 2 a 4 anteriores são refeitos: executá-se P e os mutantes com os novos casos de teste, recalculáse o escore de mutação e realiza a análise dos mutante vivos se houver. E assim por diante, até que o escore de mutação seja 1 ou esteja bem próximo desse valor, então pode ser encerrar o processo de teste e considerar T um bom conjunto de teste para o programa P. Validando o conjunto T Hipóteses que apoiam o Teste de Mutação Budd e Angluin (1982) discorreram sobre o conceito de vizinhanças (neighborhoods) de um programa. A vizinhança de um programa P foi definida como sendo aqueles programas que estão próximos do programa P. Em outras palavras, são programas que são similares a P, porém não são equivalentes. Essa definição é usada para apresentar a Hipótese do Programador Competente (ACREE et al., 1979). Um programador competente é capaz de produz programas que estão próximos de estarem corretos. Um programa escrito por um programador competente pode está incorreto, porém ele estará diferente do programa correto devido a pequenos desvios sintáticos. Os pequenos defeitos apresentados pelo programador competente remetem ao Efeito de Acoplamento (DEMILLO; LIPTON; SAYWARD, 1978). Este efeito diz que defeitos complexos são acoplados a defeitos simples, de tal maneira que um conjunto de teste que é capaz de detectar todas os defeitos simples de um programa, também é capaz de detectar os defeitos complexos. A Hipótese do Programador Competente e o Efeito de Acoplamento são as bases que justificam o Teste de Mutação. Assumindo a primeira hipótese, tem-se que alterações semânticas no programa (via alterações sintáticas nos mutantes) são reveladas por meio da análise de mutantes. Assim o testador pode construir casos de teste que mostrem que essas transformações levam a um programa incorreto. O efeito de acoplamento, por sua vez, garantirá que os casos de teste que revelam os defeitos simples (aqueles simulados pelos mutantes) também são capazes de revelar defeitos mais complexos.

31 2.2 Trabalhos Relacionados Trabalhos Relacionados Apesar de ser um dos critérios mais efetivos para identificar defeitos, o Teste de Mutação é bastante caro na prática, devido o alto custo computacional necessário para executar e analisar um grande conjunto de mutantes (ACREE et al., 1979; BUDD et al., 1980; BUDD, 1981). Além desse problema, ainda é necessário um esforço humano extra para identificar mutantes equivalentes. Para contornar esses obstáculos, algumas técnicas têm sido propostas para reduzir o custo da mutação sem perder a eficácia do critério, ora reduzindo a quantidade de mutantes gerados, ora diminuindo o custo de execução do teste (JIA; HARMAN, 2011). Uma das técnicas usadas para diminuir o custo do Teste de Mutação é o Mutant Sampling, também conhecida como Seleção Aleatória (Randon Selection). Proposta por Acree (1980) e Budd (1980), a ideia por traz dessa técnica consiste em escolher randomicamente um pequeno subconjunto de mutantes entre todos os mutantes gerados. A geração dos mutantes ocorre de maneira tradicional ao Teste de Mutação, então é selecionado randomicamente x% dos mutantes, sendo o restante descartado. A primeira preocupação nesta técnica é definir a taxa de seleção (valor de x). Nos estudos de Wong (1993) e Mathur e Wong (1994) foram conduzidos experimentos com taxas variando de 10% a 40%. Os resultados mostraram que a técnica é válida quando a taxa de seleção é superior a 10%, tendo apenas uma perda de 16% de efetividade em relação a todo o conjunto de mutantes. Outra alternativa para reduzir o número de mutantes é utilizar a técnica Mutação Seletiva (Selective Mutation). A ideia foi proposta por Mathur (1991) e logo em seguida estendida por Offutt, Rothermel e Zapf (1993) e consiste em reduzir o número de operadores de mutação. Operadores de mutação geram diferentes números de mutantes, alguns operadores geram mais mutantes do que outros, sendo que muitos desses mutantes morrem facilmente, agregando pouco para o processo de mutação. O objetivo da Mutação Seletiva é encontrar um pequeno conjunto de operadores que gere um subconjunto de mutantes, sem perder eficácia de teste. Para reduzir a geração de mutantes, Mathur (1991) sugeriu omitir dois operadores de mutação (ASR e SVR) utilizados pela ferramenta de teste Mothra (DEMILLO et al., 1988). Offutt, Rothermel e Zapf (1993) implementaram a ideia de Mathur, chamandoa de 2-selective mutation e ainda estenderam o trabalho omitindo 4 e 6 operadores de mutação (4-selective mutation e 6-selective mutation). Em seus estudos, eles reportaram que ao omitir 2 operadores de mutação alcançou se uma média de 99,99% do escore de mutação, com uma redução de 24% de mutantes gerados. Omitindo 4 operadores o escore de mutação girou em torno de 99,84%, reduzindo 41% dos mutantes. No experimento que foram omitidos 6 operadores de mutação, o escore de mutação alcançado foi de 88,71%,

32 2.2 Trabalhos Relacionados 30 com redução de 60% na geração dos mutantes. Offutt, Lee e Rothermel (1996) ainda estenderam o trabalho com 6-selective mutation. Baseado no tipo de operadores de mutação encontrados na ferramenta Mothra, eles dividiram os operadores em três categorias: declarações, operadores e expressões. Omitindo os operadores de cada classe por vez, os resultados obtidos indicaram que 5 operadores (5-selective mutation) das categorias de operadores e expressões eram os principais. Tais operadores alcançaram um escore de mutação de 99,5%. Hussain (2008) propôs em sua tese de mestrado a ideia de clusterização. Nesta técnica, a escolha dos mutantes não ocorre randomicamente, mas sim usando algoritmos de clusterização (JI et al., 2009). A técnica começa gerando todos os mutantes de primeira ordem. Então é aplicado um algoritmo de clusterização para agrupar mutantes em diferentes clusters. Cada cluster armazenará mutantes que morrem com o mesmo conjunto de teste. Apenas um pequeno número de mutantes é selecionado em todos os clusters e o restante é descartado. Resultados experimentais feitos no trabalho de Hussain sugerem que Mutant Clustering é capaz de selecionar poucos mutantes e ainda assim manter o escore de mutação próximo de 1,0. Jia e Harman (2008) apresentaram uma estratégia para o Teste de Mutação utilizando mutantes HOMs (Higher Order Mutation). A redução de custo acontece ao substituir os FOMs por um único HOM. O objetivo da técnica é encontrar mutantes que são capazes de encontrar defeitos sutis. Um defeito sutil é aquele em que há a necessidade de casos de teste mais elaborados para encontrá-los. Segundo os autores, esses mutantes são raros e valiosos para aumentar a qualidade do conjunto de teste. Para alcançar o efeito desses mutantes raros, Jia e Harman introduziram o conceito de SSHOM (Strong Subsuming HOM). Um SSHOM é um mutante que só é morto por um subconjunto presente na intersecção de casos de teste que matam cada FOM gerador do HOM. Suponha que exista um SSHOM h que é construído a partir dos FOMs fa e fb. Têm-se dois conjuntos de casos de teste: o conjunto Ta e Tb que matam respectivamente os FOMs fa e fb. O caso de teste Th que mata o SSHOM h é encontrado na interseção dos conjuntos Ta e Tb, tal como é visto na Figura 2.1. Não é difícil encontrar um caso de teste na intersecção de Ta e Tb que mate ambos fa e fb, porém a melhor escolha nessa intersecção é o caso de teste que também mata o SSHOM h. Ele se torna a melhor escolha porque além de matar os FOMs fa e fb separadamente, ele também mata os dois mutantes quando eles são combinados para gerar o HOM. Higher Order Mutation foi parcialmente provada no trabalho de Polo, Piattini e García-Rodríguez (2009). No experimento foram propostos diferentes algoritmos para combinar mutantes de primeira ordem com o objetivo de gerar mutantes de segunda

33 2.3 Mutação Seletiva 31 ordem 2. Os resultados dos estudos experimentais sugeriram que ao aplicar os mutantes de segunda ordem os esforços reduzidos foram de aproximadamente 50%, sem muita perda de eficácia do teste. Mais recentemente, Langdon, Harman e Jia (2009) aplicaram programação genética multi-objetivo para a geração de HOMs. No experimento foi encontrado HOMs mais difíceis de matar do que qualquer outro mutante de primeira ordem. Figura 2.1: Caso de Teste Th que mata o mutante SSHOM Todas as estratégias anteriores são focadas na redução dos mutantes gerados, além dessas estratégias ainda existem aquelas que visam reduzir o custo do Teste de Mutação por meio da otimização do processo de execução dos mutantes (DEMILLO; LIPTON; SAYWARD, 1978; HOWDEN, 1982; WOODWARD; HALEWOOD, 1988; DELAMARO; MALDONADO, 1996). 2.3 Mutação Seletiva O objetivo da Mutação Seletiva é encontrar um conjunto reduzido de operadores de mutação, tal que esse conjunto seja capaz de gerar menos mutantes, porém sem perder a eficácia do teste. Para selecionar tais operadores é necessário aplicar alguma técnica de seleção de operadores que sejam capazes de atender o objetivo. A técnica de seleção determina quais operadores devem ser escolhidos para integrar o conjunto de operadores e quais serão descartados. Uma boa técnica de seleção deve ser capaz de encontrar operadores de mutação que gerem menos mutantes e que seus mutantes agreguem qualidade ao conjunto de teste. A seguir duas abordagens voltadas para Mutação Seletiva são apresentadas. Tais abordagens foram usadas e combinadas para desenvolver a técnica de seleção empregada por este trabalho. 2 Um mutante de segunda ordem é um mutante criado aplicando-se dois operadores de mutação.

34 2.3 Mutação Seletiva Conjuntos Essenciais de Operadores de Mutação Como alguns operadores de mutação geram mais mutantes que outros e esses mutantes são diferentes entre si, é provável que certos operadores sejam mais eficazes do que outros para encontrar determinados defeitos. Por exemplo, considerando que o testador deseje avaliar apenas defeitos relacionados a operadores aritméticos, portanto, os operadores que fazem alterações em variáveis, ou alterações em constantes não são relevantes para a análise do testador por fugirem do escopo testado. Dessa maneira a ideia de que alguns operadores possam ser mais importantes do que outros aparenta ser correta. Esse conceito de importância de um operador foi observado nos experimentos de Budd et al. (1980). Eles descobriram que os mutantes gerados com um determinado operador podem ser mais eficazes na detecção de certos tipos de defeitos do que os mutantes gerados por um outro operador. Isto sugere que os operadores de mutação devem ser ponderados de acordo com os defeitos a serem detectados. Essa ponderação na escolha dos operadores a serem aplicados vai de encontro com a proposta de Mutação Seletiva: como é possível selecionar um subconjunto de operadores de mutação, de maneira que tal subconjunto gere uma quantidade reduzida de mutantes, porém sem perder a eficácia que o teste teria se gerasse todo o conjunto de mutantes? Uma resposta para essa pergunta reside no trabalho de Barbosa (1998) (BARBOSA; MALDONADO; VINCENZI, 2001). Utilizando um conjunto de 27 programas, Barbosa determinou um conjunto de operadores de mutação que seriam essenciais para a linguagem de programação C. Porém os resultados obtidos não foram tão satisfatórios em a escore de mutação e redução de mutantes gerados quanto trabalhos similares realizados por Offutt, Lee e Rothermel (1996) e Wong et al. (1997). Barbosa, por sua vez, procurou identificar quais as principais características que deveriam estar presentes em um conjunto essencial de operadores de mutação. Com base nessas características, ela desenvolveu um procedimento genérico, denominado Sufficient (BARBOSA; MALDONADO; VINCENZI, 2001), para a determinação do conjunto essencial de operadores de mutação. Ao aplicar o procedimento desenvolvido, Barbosa determinou um conjunto essencial de operadores de mutação para a linguagem C. Mesmo que o conjunto essencial obtido por sua estratégia tenha se mostrado mais caro que o processo de Offutt e Wong, o escore de mutação alcançado por Barbosa foi superior se comparado com o conjunto essencial de Wong e o obtido pela a estratégia de Offutt. O conceito de conjunto de operadores essenciais também é explorado neste trabalho. Ao contrário do trabalho citado anteriormente, neste pretende-se chegar ao conjunto de operadores essenciais utilizando-se alguma outra estratégia mais focada nos defeitos em si, uma vez que o critério pertence à Técnica de Teste baseada em Defeitos,

35 2.3 Mutação Seletiva 33 logo nada mais lógico do que analisar os defeitos com base em características que não foram exploradas por outros trabalhos. A estratégia desse trabalho se baseia na análise das características semânticas de um defeito. Tais características são explicadas a seguir Caracterização Semântica dos Defeitos A IEEE (1990) define um defeito (fault) como um passo, processo ou definição de dados incorreta, como por exemplo, uma instrução ou comando incorreto. Em outras palavras o defeito é a diferença sintática entre o programa correto e um programa incorreto. Um defeito pode está localizado em uma instrução ou espalhado em vários lugares no código. Logo um dos principais objetivos da área de testes é identificar se o programa possui ou não defeitos. Sendo assim nada mais lógico do que buscar compreender as características que um defeito introduzido pelo programador causará no programa. No artigo A Semantic Model of Program Faults, Offutt e Hayes (1996) argumentaram sobre como alguns problemas da área de teste podem ser melhores compreendidos ou parcialmente resolvidos olhando para a caracterização sintática e semântica dos defeitos. Exemplos de caracterização sintática dos defeitos são gerados a partir de enganos cometidos pelo programador, como errar o nome de uma variável. Da mesma maneira o defeito também pode ser caracterizado semanticamente. Cada programa P tem uma especificação S que define um domínio de entrada D, que é mapeado em um domínio de saída R. Um programa P que produz uma saída R incorreta ao receber uma entrada do domínio D é um exemplo de caracterização semântica do defeito. Com base nessa caracterização, Offutt e Hayes usaram o tamanho de um defeito para mensurar o quanto o defeito será impactante para a execução do programa. Eles observaram que um defeito sintaticamente pequeno pode resultar em um defeito que é grande semanticamente. Suponha um programa que recebe como entrada um vetor. O programa erroneamente decrementa cada elemento do vetor ao invés de incrementálo. Embora a troca do operador de adição pelo operador de subtração seja um defeito sintaticamente pequeno, ele na verdade é um defeito semanticamente grande. Ele é semanticamente grande porque além de afetar todos os vetores passados como entrada, tal defeito ainda afetará cada elemento do vetor, portanto, configurando-se como um defeito semanticamente grande. Logo um defeito grande semanticamente tem impacto sobre todas ou várias entradas. O oposto também ocorre, por exemplo, o programador troca o cálculo da média pelo cálculo da mediana. Mesmo que sintaticamente os cálculos sejam bem diferentes, há muitas listas de números que tanto a média quanto a mediada são as mesmas. Portanto, tal cálculo leva a um defeito sintaticamente grande, porém semanticamente pequeno. Considerando esse modelo conceitual, especialmente o tamanho semântico dos

36 2.3 Mutação Seletiva 34 defeitos, Offutt e Hayes (1996) afirmam que é possível ter uma visão sobre várias questões relacionadas à área de Teste de Software. A questão central é que muitas pesquisas são focadas em defeitos que são pequenos sintaticamente, sem considerar o tamanho semântico. Tal visão é estendida para o Teste de Mutação. Como um mutante é a representação de um possível defeito, um mutante que é semanticamente pequeno representa um defeito semanticamente pequeno. Ou seja, um mutante pequeno gera uma saída errada apenas para uma pequena porção do domínio de entrada. Embora os sistemas de mutação criem mutantes que são pequenos sintaticamente (os operadores empregam apenas uma alteração sintática no código), os mutantes semanticamente pequenos seriam mais difíceis de matar segundo as observações de Offutt e Hayes. Esses mutantes seriam mais difíceis de matar porque eles geram saída incorreta apenas para um pequeno domínio de entrada, logo não é qualquer caso de teste que o detecta. Portanto, tais mutantes teriam o potencial de aumentar a qualidade do conjunto de teste. Offutt e Hayes complementam que o modelo semântico pode trazer outros benefícios. Por exemplo, eles sugerem que o modelo pode ser utilizado na Mutação Seletiva. Segundo a teoria de ambos, a Mutação Seletiva tenta usar apenas operadores de mutação que tendem a produzir defeitos que são semanticamente pequenos. Se a teoria estiver correta, o operador que funciona bem experimentalmente é capaz de produzir mutantes que são, na média, semanticamente pequenos. Que seriam justamente os mutantes que aumentariam a qualidade dos casos de teste. Para verificar que o modelo semântico pode ser válido e explicar porque Mutação Seletiva funciona, Offutt e Hayes fizeram um estudo preliminar com os cinco operadores de mutação (5-selective mutation) que Offutt havia encontrado com a ferramenta Mothra (OFFUTT; LEE; ROTHERMEL, 1996). O objetivo do experimento era verificar se esse conjunto com 5 operadores usados na Mutação Seletiva tendem a gerar defeitos semanticamente pequenos. Para tal, o experimento consistia em comparar o tamanho médio dos mutantes gerados operadores usados na Mutação com os operadores não usados na Mutação Seleção. Para realizar essa comparação Offutt e Hayes dividiram os operadores em dois conjuntos, o conjunto selective composto pelos 5 operadores de mutação usado na Mutação Seletiva e o conjunto non-selective, composto pelos 17 operadores não usados na Mutação Seletiva. Para calcular o tamanho médio dos mutantes usados na comparação, foram selecionados 10 programas para experimentação, cada um gerando de 183 a 1048 mutantes. Para cada programa foram criados 500 casos de teste aleatórios. Para se chegar ao um valor aproximado do tamanho semântico, cada mutante foi executado com cada caso de teste. Após essa execução foi possível contar quantos casos de teste mataram cada mutante. Esse valor correspondia ao tamanho semântico do mutante. Por exemplo, suponha que um mutante foi morto por 50 casos de teste, então o tamanho semântico dele era igual

37 2.4 Mutação Semanticamente Seletiva 35 a 50. Após calcular o tamanho semântico de todos os mutantes, foi realizado a média desses tamanhos. Esse processo foi realizado tanto para o conjunto selective quanto para o conjunto non-selective. Foi encontrado que o tamanho médio dos mutantes gerados pelos operadores do conjunto selective era 31,60%, enquanto que os mutantes do conjunto non-selective foi de 39,88%. Mesmo que a diferença do tamanho médio dos dois conjuntos não tenha sido extraordinariamente grande, ao menos foi de encontro com o que foi previsto, de que os mutantes gerados pelos operadores usados na Mutação Seletiva possuíam tamanhos menores. De fato houve uma grande variação entre os programas. Alguns geravam 183 mutantes enquanto outros geravam mais de 1000, esse valor tinha influência na média do tamanho semântico. Isso levou a uma variação da média, por exemplo, para alguns programas a diferença de tamanho médio dos dois conjuntos (conjunto selective e conjunto non-selective) era de apenas 1%. Ao passo que para outros programas, a diferença de média entre os dois conjuntos era de 18%. Enquanto isso, o desvio padrão foi de 7,6. Esses resultados sugerem que ou o modelo semântico não está acurado, ou os operadores de mutação usados não são os mais significados em relação ao ponto de vista do modelo. 2.4 Mutação Semanticamente Seletiva O objetivo de Mutação Seletiva é encontrar um subconjunto de operadores de mutação que seja capaz de reduzir o número de mutantes gerados (redução de custo) e ao mesmo tempo manter o escore de mutação alto. Obviamente a seleção de bons operadores é fundamental para o sucesso da técnica. Logo alguma estratégia de seleção de operadores deve ser aplicada. No trabalho de Offutt e Hayes os autores supõem que a Mutação Seletiva tenta usar operadores de mutação que tendem a produzir mutantes que são semanticamente pequenos. Embora eles tenham apresentado dados preliminares que dão suporte ao tamanho semântico, nada mais acurado para explorar a caracterização semântica foi desenvolvido. Por exemplo, nenhum algoritmo foi implementado para selecionar os operadores de mutação que são responsáveis por gerar os mutantes pequenos. Baseado nessa suposição de Offutt e Hayes sobre a Mutação Seletiva, o uso do tamanho do mutante pode ser um bom indicador da importância do mutante para melhorar o conjunto de teste. Por exemplo, se um mutante morre com vários casos de teste (mutante grande), isso significa que a chance de se escolher um caso de teste aleatoriamente que o mata é muito grande. Logo tal mutante não acrescenta muito para melhorar o conjunto de teste, pois qualquer caso de teste é capaz de matá-lo. Por outro lado, se há um mutante que morre com apenas um pequeno grupo de casos de teste, ou seja, um mutante pequeno, tal mutante se torna relativamente importante. Supõem-se, na melhor das hipóteses, que

38 2.5 Considerações Finais 36 um caso de teste que mata esse mutante pode ser capaz de matar muitos outros mutantes. Essa característica leva a crer que um mutante pequeno possui um defeito mais difícil de ser detectado, configurando-o como um mutante mais difícil de matar: um mutante harder-to-kill. Baseando-se na hipótese de que mutantes pequenos contribuem mais para a melhoria do conjunto de teste, tal hipótese será usada nesse trabalho para selecionar o conjunto de operadores essenciais. O tamanho semântico discutido por Offutt e Hayes será usado, portanto, como base para criar a estratégia de seleção de operadores de mutação. O presente trabalho irá usar a caraterização semântica para encontrar os mutantes pequenos e deles extrair o conjunto de operadores. Esses operadores formarão o Conjunto de Operadores Semanticamente Essenciais (conjunto SEO). Essa estratégia de usar a caracterização semântica de defeitos para selecionar operadores de mutação é chamada neste trabalho de Mutação Semanticamente Seletiva 2.5 Considerações Finais Nesse capítulo foi apresentado o Teste de Mutação em mais detalhe. O capítulo começa fazendo uma apresentação de algumas técnicas de teste até chegar ao critério de mutação. Em seguida são apresentadas as características do Teste de Mutação. Entre tais características é abordado o quanto o critério é eficaz, porém sofre com o alto custo computacional exigido para sua execução. Dessa maneira muitas abordagens surgiram com o intuito de diminuir o seu custo computacional. Uma dessas abordagens é a Mutação Seletiva, que visa reduzir o número de mutantes gerados reduzindo-se a quantidade de operadores de mutação. Essa redução de operadores levou à ideia de criar um conjunto de operadores essenciais. Barbosa (1998) propôs um procedimento genérico para alcançar esse conjunto. Ao contrário do procedimento de Barbosa, esse trabalho utiliza uma estratégia baseada na caracterização semântica de defeitos, discutida por Offutt e Hayes (1996). Essa caracterização foi a base para desenvolver a técnica de seleção dos operadores essenciais. A técnica usará o tamanho do mutante para selecionar os menores mutantes, pois se acredita que os mutantes pequenos possuem defeitos que aumentam a qualidade do conjutno de casos de teste. Os mutantes pequenos serão usados para extrair seus operadores de mutação. Esses operadores são denominados de operadores semanticamente essenciais. Agora que a estratégia de seleção de operadores foi introduzida, a seguir será apresentado o algoritmo desenvolvido para se aplicar a Mutação Semanticamente Seletiva.

39 Mutação Semanticamente Seletiva CAPÍTULO 3 Este capítulo esclarece como a caracterização semântica de defeitos é usada nesse trabalho para selecionar os operadores para a Mutação Seletiva. Essa abordagem, chamada de Mutação Semanticamente Seletiva, foi implementada por um algoritmo que se utiliza do tamanho semântico dos mutantes para selecionar um conjunto de operadores de mutação que possam ser usados na Mutação Seletiva. Também é neste capítulo que é explicado como foi realizada a validação do algoritmo e do conjunto de operadores que ele retorna. De maneira geral, este capítulo pode ser dividido em três partes: a primeira parte apresenta o algoritmo para se extrair os conjuntos; a segunda parte apresenta o primeiro experimento controlado, que visa aplicar o algoritmo em um programa sobre teste, e a terceira e última parte que apresenta o segundo experimento controlado, que tem como objetivo verificar a qualidade do conjunto de operadores encontrado no primeiro experimento. 3.1 O Algoritmo Como descrito na Seção 2.4 (Mutação Semanticamente Seletiva), o objetivo da abordagem é extrair um conjunto de operadores essenciais usando a caracterização semântica dos mutantes. A hipótese levantada é que mutantes que morrem com poucos casos de teste (mutantes pequenos) são mais relevantes do que mutantes que morrem com vários casos de teste (mutantes grandes). Essa hipótese baseia-se na suposição de que se um mutante morre facilmente com qualquer caso de teste, então ele passa a ser menos relevante do que um mutante que morre com apenas poucos casos de teste. Essa característica é a responsável pelo algoritmo priorizar os mutantes pequenos, pois eles são mais difíceis de matar (harder-to-kill). O algoritmo (Figura 3.1) que implementa essa abordagem pode ser dividido em três etapas, como observado a seguir: Etapa 1 - Computar o tamanho do mutante; Etapa 2 - Selecionar os melhores mutantes;

40 3.1 O Algoritmo 38 Etapa 3 - Extrair os operadores semanticamente essenciais. Figura 3.1: Etapas do algoritmo para extrair os operadores semanticamente essenciais. Na primeira etapa o algoritmo irá computar o tamanho semântico para todos os mutantes gerados. O algoritmo usa a mesma estratégia de Offutt e Hayes (1996) para computar aproximadamente o tamanho do mutante. Ele percorre cada mutante contabilizando quantos casos de testes o matam, esse valor corresponderá ao tamanho do mutante. A segunda etapa seleciona os mutantes mais importantes segundo a caracterização semântica. É justamente nessa etapa que o procedimento de selecionar os menores mutantes acontece. O primeiro passo dessa etapa é ordenar os mutantes em ordem crescente de tamanho semântico. O primeiro mutante da lista, consequentemente o menor mutante do conjunto, é selecionado. A partir desse momento tal mutante é incluído no Conjunto de Mutantes Selecionados. Será desse conjunto que os operadores essenciais serão extraídos. Segundo a caracterização semântica, esse primeiro mutante é o que mais contribui para a melhoria do conjunto de teste, logo ele deve ser priorizado. Após selecionar o mutante é necessário remover da lista todos os mutantes que lhe possam ser redundantes. Neste cenário a redundância é caracterizada por mutantes

41 3.2 Extração do Conjunto SEO 39 que morrem com o mesmo conjunto de teste que mata os mutantes selecionados. Primeiramente todos os casos de teste que matam o mutante são recuperados e um deles é escolhido aleatoriamente. Esse caso de teste escolhido é usado para eliminar da lista todos os mutantes que seriam redundantes ao mutante selecionado. Portanto, todos mutantes que morrem com o caso de teste são removidos do conjunto. Em seguida o procedimento reinicia com o próximo menor mutante da lista que não foi morto pelo caso de teste. Essa rotina termina quando não houver mais nenhum mutante a ser analisado, ou seja, quando se alcançar o final da lista de mutantes. O motivo para a seleção randômica dos casos de teste é para se evitar que a escolha dos melhores mutantes não seja comprometida. Por exemplo, supondo que o algoritmo selecionasse o caso de teste que mais mata mutantes, ao invés de selecionar um caso de teste randomicamente, pode ser que tal caso de teste remova do conjunto mais mutantes do que é necessário ou desejado. Logo o Conjunto de Mutantes Selecionados se tornaria muito pequeno, dificultando ou até mesmo inviabilizando a extração dos operadores essenciais. A terceira e última etapa extrai os operadores de mutação dos mutantes que foram selecionados durante a etapa anterior. Cada mutante selecionado durante a segunda etapa foi adicionado ao Conjunto de Operadores Selecionados. O algoritmo percorre cada mutante desse conjunto verificando qual foi o operador de mutação que o gerou. Cada novo operador encontrado é adicionado ao Conjunto de Operadores Semanticamente Essenciais. Após percorrer todos os mutantes o algoritmo retorna os operadores de mutação extraídos, esses operadores formam o conjunto SEO. 3.2 Extração do Conjunto SEO Para verificar se o algoritmo apresentado na seção anterior foi capaz de extrair o conjunto SEO, ele deve ser aplicado em um programa de teste. O programa escolhido para o experimento deve permitir a geração de todo o domínio de entrada. É necessário gerar todo o domínio de entrada, porque a quantidade de dados de entrada tem impacto direto no cálculo do tamanho semântico do mutante. Mais entradas implicam em mais casos de teste, por sua vez, mais casos de teste permitem calcular com maior precisão o tamanho do mutante. Diante dessa restrição o Cal 1 foi o programa escolhido para experimentação. O Cal é um programa escrito em linguagem de programação C, logo a geração dos mutantes pode ser realizada por intermédio da ferramenta Proteum (Program Testing 1 O código fonte do programa Cal pode ser obtido em < browse/trunk/src/cal.c>

42 3.2 Extração do Conjunto SEO 40 Using Mutants) (DELAMARO; MALDONADO, 1996). Entretanto é importante frisar que o algoritmo (abordagem) é independente da linguagem. Por exemplo, para se aplicar o algoritmo em programas escrito em Java, é apenas necessário usar alguma ferramenta para geração dos mutantes, por exemplo, usar o µjava (PECEV et al., 2012) ao invés da Proteum Geração da Base de Dados Antes de se aplicar o algoritmo é necessário criar uma base de dados. Essa base de dados é usada pelo algoritmo para buscar informações sobre o programa em teste. Na base são armazenadas informações sobre os casos de teste gerados e os mutantes criados para o programa em análise. Nos exemplos serão utilizados dados coletados para o Cal. O Cal é um utilitário UNIX/Linux que escreve na saída padrão do sistema (terminal) um calendário. As datas aceitas pelo calendário obedecem duas especificações. A primeira especificação diz respeito ao calendário Juliano, permitindo que as datas suportadas pelo Cal variem de 1 o de Janeiro do ano 1 até 2 de Setembro de A segunda especificação é em relação ao calendário Gregoriano, adotado em 14 de Setembro de 1752, as datas permitidas variam de 14 de Setembro de 1752 até 31 de Dezembro de O Cal é chamado no terminal Linux com os seguintes parâmetros: cal (sem parâmetro): exibe o calendário do mês do ano corrente; cal ano: exibe o calendário do ano passado como parâmetro; cal mês ano: exibe o calendário do ano e mês passados como parâmetros. Com essas informações sobre o Cal têm-se 12 meses válidos distribuído entre 1 e anos válidos, possibilitando, portanto, a geração de aproximadamente casos de testes válidos. A geração dos casos de teste válidos foi sequencial, usando todas as possíveis combinações. A Figura 3.2 apresenta o processo de geração dos casos de teste válidos: A geração dos casos de teste inválidos se deu por meio da geração de parâmetros fora do limites definidos pela especificação do Cal ou por intermédio de caracteres ou combinações inválidas. Combinando os casos de teste válidos com inválidos, foram gerados casos de teste no total. Os casos de teste foram armazenados na Tabela TCase. Após a geração dos casos de teste, o próximo passo foi popular a base de dados com as informações sobre os mutantes gerados para o Cal. A Tabela Mutante foi usada para armazenar as informações sobre o mutante e o operador de mutação que o gerou. Usando a ferramenta Proteum foram gerados ao total mutantes ao aplicar os 74 operadores de mutação de mutação sobre o programa Cal, dos quais 46 operadores

43 3.2 Extração do Conjunto SEO 41 Figura 3.2: Geração sequencial dos casos de teste válidos. geraram mutantes para o Cal. A Tabela 3.1 exibe esses 46 operadores de mutação, bem como a quantidade de mutantes que cada um gerou. Com os mutantes gerados e os casos de teste definidos, o próximo passo foi executar cada mutante com todos os casos de testes. Como resultado foi gerado uma terceira tabela, Tabela Matança, no banco de dados com a relação mutante e o caso de teste. Essa tabela contém o status de determinado mutante M em relação a cada caso de teste T. 1. EXEC_VIVO: mutante M executado com o caso de teste T e permaneceu vivo. 2. EXEC_MORTO_SAIDA: mutante M morto por ter resultado diferente do programa P. 3. EXEC_MORTO_RETCOD: mutante M morto por ter code de retorno diferente do programa P. 4. EXEC_MORTO_TIMEOUT: mutante M morto por timeout. 5. EXEC_MORTO_TRAP: mutante morto por função TRAP. 6. AVOIDED: mutante M permaneceu vivo pois o caso de teste não alcançou o ponto de mutação. 7. NO_EXEC_COMP: mutante anômalo. A Figura 3.3 apresenta o esquema do Bando de Dados utilizado pelo algoritmo. A Tabela Matança possui uma chave composta formada por NUM (uma chave estrangeira vinda da Tabela Mutantes) e NTCASE (uma chave estrangeira vinda da Tabela TCASE). A Tabela StatusMatanca é explicada na próxima subseção Aplicação do Algoritmo Após a criação da base o algoritmo para extrair o conjunto SEO pôde ser executado. Como descrito na Seção 3.1 a primeira etapa do algoritmo é computar o

44 3.2 Extração do Conjunto SEO 42 Tabela 3.1: Operadores de Mutação aplicados no programa Cal. Operador Mutantes Gerados Operador Mutantes Gerados Operador Mutantes Gerados Cccr 1026 Ccsr 734 CRCR 310 OAAA 41 OAAN 125 OABA 30 OABN 90 OAEA 10 OALN 68 OARN 204 OASA 20 OASN 60 OCNG 20 OEAA 135 OEBA 81 OESA 54 Oido 15 OIPM 2 OLAN 20 OLBN 12 OLLN 4 OLNG 12 OLRN 24 OLSN 8 ORAN 110 ORBN 66 ORLN 44 ORRN 110 ORSN 44 SBRC 1 SMTC 8 SMTT 8 SMVB 1 SRSR 100 SSDL 101 SSWM 3 STRI 24 STRP 102 SWDD 2 VDTR 186 VGAR 52 VLAR 4 VLPR 18 VLSR 391 VSCR 18 VTWD 124 tamanho semântico de cada mutante. Para isso, o algoritmo percorreu cada mutante da Tabela Matança contabilizando o status da execução do mutante com cada caso de teste. Essa informação é armazenada na Tabela StatusMatança (Figura 3.3). Após preenchê-la com cada status, o algoritmo contabiliza quantos casos de teste mataram cada mutante. Ou seja, para um mutante M é contado quantos status com os valores 2 3, 4 e 5 existem na tupla. Essa soma corresponde ao tamanho do mutante. Por exemplo, suponha que o mutante 4619 tenha a seguinte tupla na Tabela StatusMantanca o banco de dados: NUM = 4619 ST1 = ST2 = 20 ST3 = 0 ST4 = 0 ST5 = 0 ST6 = 0 ST7 = TAMANHO = 0 Nesse caso, somando os status 2, 3, 4 e 5, o tamanho do mutante 4619 é 20. Portanto,o campo TAMANHO (que a princípio é inicializado com zero) é atualizado com o valor 20. O Algoritmo 1 apresenta o pseudocódigo para a primeira etapa: cálculo do tamanho semântico dos mutantes.

45 3.2 Extração do Conjunto SEO 43 Figura 3.3: Esquema do Banco de Dados usado pelo algoritmo. Após computar o tamanho do mutante, a Tabela StatusMatança sofreu uma alteração na ordem de suas tuplas. Os mutantes foram ordenados em ordem crescente de tamanho. Iniciando-se a Etapa 2 do algoritmo: seleção de mutantes. Essa sub-rotina consiste em priorizar os menores mutantes, excluindo aqueles mutantes que seriam redundantes ao mutante selecionado. Ao final do procedimento o Conjunto de Mutantes Selecionados contém apenas os mutantes que seriam relevantes para o Teste de Mutação segundo a caracterização semântica de defeitos. O Algoritmo 2 apresenta o pseudocódigo para a Etapa 2: seleção dos melhores mutantes. Segundo a hipótese esses mutantes são mais relevantes justamente pelo fato deles serem mutantes pequenos. É verdade que devido à maneira como o algoritmo foi implementado é bem provável que esse conjunto de mutantes selecionados pelo algoritmo contenha mutantes que não sejam tão pequenos quanto outros mutantes que foram gerados. Porém esses mutantes foram selecionados priorizando o tamanho. Portanto, mesmo que alguns não sejam tão pequenos, espera-se que esses mutantes sejam mais relevantes do que os outros, pois aqueles que seriam redundantes a eles ou que segundo a estratégia pouco agregaria valor ao teste, foram removidos durante o procedimento de seleção. Por fim, a terceira etapa do algoritmo percorre todos os mutantes do Conjunto de Mutantes Selecionados para extrair os operadores de cada mutante. Ao final desse procedimento, os operadores extraídos formam o conjunto de operadores semanticamente

46 3.2 Extração do Conjunto SEO 44 Algorithm 1 Cálculo do Tamanho Semântico if (Tabela StatusMatança não existe) then criatabelastatusmatança() end if /*Retorna todos os mutantes do BD*/ MUTANTESarray = busca(tabela Mutantes) for i = 1 to MUTANTESarray.size() do NUM = MUTANTES[i].getNumMutante() /*Retorna todos as tuplas que tem como chave parcial o mutante NUM*/ MATarray = busca(tabela Matanca, NUM) STM = new StatusMatanca(NUM) /*Retorna a quantidade de ocorrências do status X*/ STM.ST1 = buscastatus(matarray, 1) STM.ST2 = buscastatus(matarray, 2) STM.ST3 = buscastatus(matarray, 3) STM.ST4 = buscastatus(matarray, 4) STM.ST5 = buscastatus(matarray, 5) STM.ST6 = buscastatus(matarray, 6) STM.ST7 = buscastatus(matarray, 7) STM.TAMANHO = STM.ST2 + STM.ST3 + STM.ST4 + STM.ST5 savetablestatusmatanca(stm) end for essenciais - conjunto SEO. Espera-se que o conjunto SEO seja capaz de reduz o número de mutantes gerados (redução de custo) ao mesmo tempo em que seja capaz de manter o escore de mutação alto. O Algoritmo 3 apresenta o pseudocódigo para a terceira etapa: extração do conjunto SEO. É importante ressaltar que o algoritmo foi executado 32 vezes. Isso ocorreu porque a escolha aleatória, empregada na Etapa 2, poderia fazer com que o algoritmo deixasse de selecionar alguns bons mutantes. Em média cada execução selecionava um conjunto com 18 mutantes e após as primeiras 17 execuções do algoritmo foi observado que o conjunto de mutantes não era mais alterado, ou seja, nenhum novo mutante era adicionado ao conjunto. Ao final das 32 execuções o conjunto total de mutantes selecionados continha 23 mutantes e para cada mutante tinha-se associado o caso de teste escolhido aleatoriamente. Cada um dos 23 mutantes foi analisado para descobrir qual foi o operador de mutação que o gerou. Ao total o conjunto SEO foi formado pelos seguintes operadores de mutação: u-oabn, u-oesa, u-oaan, u-ssdl, u-vlsr, u-cccr, u-vtwd,

47 3.2 Extração do Conjunto SEO 45 Algorithm 2 Seleção dos mutantes CMSarray = [ ] /*Conjunto de Mutantes Selecionados*/ /* Retorna todas as tuplas em ordem crescente do tamanho do mutante*/ STMarray = buscaordenadoportamanho(tabela StatusMatanca) while STM = getnextmutante(stmarray)!= NULL do NUM = STM.getNumMutante() CMSarray += buscamutante(tabela Mutantes, NUM) /*Retorna o mutante com id = NUM*/ /* Retorna todos os casos de teste que mataram o mutante NUM*/ STATUS = [2,3,4,5] NTCASEarray = buscantcase(tabela Matanca, NUM, STATUS) NTCASE = randon(ntcasearray) /*seleciona um caso de teste aleatório*/ /*Remove do array todas as tuplas que tem algum mutante que morreu com o caso de teste NTCASE*/ remove(stmarray, NTCASE, STATUS) end while return CMSarray Algorithm 3 Extração do conjunto SEO SEO = new Set() call Algorithm 1 CMSarray = call Algorithm 2 /* Extrai os operadores dos mutantes selecionados */ for i = 1 to CMSarray.size() do MUT = CMSarray[i] SEO += MUT.getOperator() end for return SEO

48 3.3 Validação do Conjunto SEO 46 u-oeaa, u-vdtr, u-ccsr. Para detalhes dos operadores de mutação vide Apêndice A 3.3 Validação do Conjunto SEO Para comprovar se o algoritmo foi capaz de encontrar operadores de mutação capazes de reduzir o custo do Teste de Mutação, porém sem perder a eficácia do critério é necessário realizar uma validação do conjunto SEO. Para realizar essa validação, o conjunto SEO será comparado com outros conjuntos essenciais. O objetivo é mensurar a redução de mutantes que o conjunto é capaz de atingir e ainda assim alcançar um alto escore de mutação quando comparado com os outros conjuntos. Para isso, apenas os mutantes que são gerados pelos operadores semanticamente essenciais deverão ser avaliados. Se os mutantes gerados pelo conjunto SEO atingirem um bom escore de mutação quando comparado com outro conjunto, então o algoritmo foi capaz de cumprir seu propósito. Essa comparação será realizada em função de duas perguntas: 1. O conjunto SEO alcança um bom escore de mutação (próximo de 1.0)? 2. O conjunto SEO reduz o custo do teste de mutação (sem perder a eficácia do teste)? Para obter respostas para essas perguntas foi escolhido um conjunto de cinco programas Unix (Cal, Checkeq, Comm, Look e Uniq), chamados 5-UNIX. A escolha desse grupo de programas foi em função dos mesmos serem utilizados em estudos anteriores (BARBOSA, 1998; BARBOSA; MALDONADO; VINCENZI, 2001). Basicamente a ideia é verificar o comportamento e efetividade do conjunto SEO quando aplicado nesses programas durante o Teste de Mutação. Para tal, o conjunto foi organizado em duas ordens de aplicação: Ordem do Algoritmo e Ordem de Prioridade. Na Ordem do Algoritmo os operadores do conjunto são ordenados na mesma sequência entregue pelo algoritmo. Ou seja, o primeiro operador semanticamente essencial encontrado pelo algoritmo é o primeiro da lista. Na Ordem de Prioridade os operadores são ordenados baseados na taxa de mutantes selecionados pelo algoritmo versus total de mutantes gerado pelo operador. O operador que gerou menos mutantes e ao mesmo tempo teve mais mutantes selecionados pelo algoritmo é o primeiro da lista. Para cada operador é verificado quantos mutantes foram adicionados ao Conjunto de Mutantes Selecionados, esse valor é divido pelo número de mutantes que o operador gera. Esse cálculo é apresentado pela Equação 3-1. No qual strength representar a força do operador, ou seja, a porcentagem de mutantes que ele gera e que que foram selecionados pelo o algoritmo. MSA representa a quantidade de mutantes selecionados pelo algoritmo e TMG o total de mutantes gerados pelo operador. strength = MSA 100 T MG (3-1)

49 3.3 Validação do Conjunto SEO 47 Após calcular a força de cada operador, eles foram ordenados em ordem decrescente, formando a Ordem de Prioridade. Os operadores foram ranqueados, para que cada um seja aplicado incrementalmente. O primeiro operador é aplicado no programa de teste e então é verificado o escore de mutação obtido pelos seus mutantes. Logo em seguida o segundo operador, em conjunto com o primeiro, também é aplicado, verificando-se novamente o escore de mutação. E assim por diante. O motivo por criar duas ordens de aplicação para o conjunto SEO se deve ao fato do algoritmo retornar os operadores à medida que ele vai os encontrando, sem levar em consideração nenhuma estratégia de ranqueamento. Em contrapartida, aplicar uma estratégia de ranqueamento apenas baseada na quantidade de mutantes que cada operador gera é uma tarefa que já foi realizada (Vide Seção 2.2) e pouco agrega à Mutação Semanticamente Seletiva implementada pelo algoritmo. Portanto, a organização do conjunto SEO na Ordem de Prioridade consegue cobrir ambas vertentes ao aplicar (i) uma estratégia de ranqueamento que não seja baseada apenas na quantidade de mutantes que o operador gera e que essa (ii) estratégia está relacionada com a caracterização semântica. A estratégia está relacionada com a Mutação Semanticamente Seletiva pelo fato da Equação 3-1 usar no cálculo a quantidade de mutantes que foram selecionados pelo algoritmo e não somente a quantidade de mutantes gerada pelo operador. Analisar duas ordens de aplicação ainda traz como benefício poder verificar o impacto que cada operador traz consigo ao escore de mutação. Naturalmente, ambas ordens irão ter o mesmo escore de mutação, já que é o mesmo conjunto de operadores. Entretanto, pode ser que algumas dessas ordens traga algum benefício imediato, por exemplo, suponha que a Ordem de Prioridade mostre que é mais vantajoso deixar determinados operadores no final do ranque do que em qualquer posição. Esse tipo de informação é importante e só pode ser obtida ao se comparar o mesmo conjunto de operadores, porém organizados de forma diferente. Os conjuntos de operadores de mutação escolhidos para a comparação com o conjunto SEO são: SS-5 e SS-27. Ambos são conjuntos essenciais de operadores e foram encontrados por Barbosa, Maldonado e Vincenzi (2001) usando o procedimento Sufficient (BARBOSA, 1998). Esse procedimento foi criado para determinar o conjunto de operadores de mutação suficientes para a linguagem de programação C. O conjunto SS-5 foi encontrado usando o mesmo conjunto de programas 5-UNIX, enquanto que o conjunto SS-27 foi encontrado usando um conjunto de 27 programas pertencentes a um editor de texto simplificado. O motivo para a escolha do conjunto SS-27 se deve ao fato dele ter sido encontrado a partir do mesmo conjunto de programas 5-UNIX usado na experimentação. Como o conjunto SEO também foi encontrado a partir do programa Cal (pertencente ao 5-UNIX), consequentemente, se tornando um bom conjunto para a comparação. A escolha do conjunto SS-5 se deve por razões opostas. O objetivo é verificar

50 3.3 Validação do Conjunto SEO 48 como o conjunto SEO se comporta quando comparado com um conjunto extraído de outo escopo de programas. A Tabela 3.2 mostra os operadores SEO em ambas ordem de aplicação, os dois conjuntos de operadores de Barbosa também são apresentados. Tabela 3.2: O conjunto de operadores comparado. Conjunto SEO Conjunto de Barbosa Classificação Ordem do Algoritmo Ordem de Prioridade SS-5 SS-27 1 u-oaan u-vtwd u-smtc u-swdd 2 u-vtwd u-oesa u-ssdl u-smtc 3 u-ccsr u-oeaa u-oeba u-ssdl 4 u-cccr u-oabn u-orrn u-olbn 5 u-vlsr u-ssdl u-vtwd u-oasn 6 u-oesa u-oaan u-vdtr u-orrn 7 u-oabn u-vdtr u-vtwd 8 u-vdtr u-vlsr u-vdtr 9 u-oeaa u-cccr u-cccr 10 u-ssdl u-ccsr u-ccsr Com os conjuntos de operadores definidos e a ordem de aplicação estabelecida, o próximo passo foi aplicar cada operador nos programas. A aplicação foi realizada por meio dos seguintes passos: 1. Seleciona o primeiro operador do conjunto; 2. Gera os mutantes do operador; 3. Seleciona um conjunto de teste adequado ao operador selecionado; 4. Calcula-se o escore de mutação em relação ao conjunto total de mutantes; 5. Analisa o custo/benefício; 6. Reinicia o processo, adicionando o próximo operador. O primeiro operador selecionado depende da ordem de aplicação. Depois de selecionado, todos os mutantes do operador são gerados e aplicado no programa sobre teste. Seleciona-se casos de teste adequados ao operador selecionado, então o escore de mutação é calculado. O próximo operador na lista é selecionado, reiniciando o processo. Todos os mutantes do novo operador são gerados e junto com os mutantes gerados anteriormente, um novo escore de mutação é computado. O objetivo de computar novamente o escore de mutação é para verificar o impacto de adicionar um novo operador de mutação ao processo. Ou seja, se o aumento no escore de mutação compensa o custo de se criar novos mutantes. Após a execução desse procedimento de verificação no conjunto 5-UNIX é possível confirmar se o algoritmo atingiu seu objetivo: utilizar o tamanho semântico do mutante para selecionar operadores de mutação que são capazes de reduzir o custo ao mesmo tempo em que alcança um bom escore de mutação.

51 3.4 Considerações Finais Considerações Finais Nesse capítulo foi apresentado o algoritmo usado para extrair os operadores essenciais de mutação. Na primeira seção é explicado o funcionamento do algoritmo e como ele explora a abordagem de selecionar os melhores mutantes. Nessa seção o algoritmo é explicado em três etapas. A primeira etapa calcula o tamanho do mutante. A segunda etapa usa o tamanho do mutante para selecionar os melhores menores mutantes. A terceira etapa usa esses mutantes selecionados para extrair o conjunto de operadores essenciais, denominado de conjunto SEO. Na seção seguinte o algoritmo é aplicado em um programa sobre teste. O objetivo é verificar se o algoritmo é capaz de selecionar os operadores essenciais. Para tal foi escolhido o programa Cal para experimentação. Os casos de teste para o Cal foram gerados, bem como seus mutantes. Ao aplicar o algoritmo um conjunto com 10 operadores de mutação foi selecionado. São eles: u-oabn, u-oesa, u-oaan, u-ssdl, u-vlsr, u-cccr, u-vtwd, u-oeaa, u-vdtr, u-ccsr. Por fim, na próxima seção foi definida a experimentação usada para verificar se os operadores encontrados pelo algoritmo são capazes de reduzir o custo do teste de mutação sem perder eficácia de teste. O conjunto SEO foi organizado em duas ordens de aplicação e ambas as ordens foram comparadas com os conjuntos de operadores de mutação encontrados por Barbosa. O próximo capítulo apresentará os resultados obtidos a partir dos experimentos definidos neste capitulo. Nele será descrito como o conjunto SEO se comportou ao ser aplicado nos programas 5-UNIX e se o conjunto foi capaz de rivalizar com os operadores encontrados por Barbosa. Por fim, esses resultados servirão para concluir se a Mutação Semanticamente Seletiva cumpriu seu propósito: encontrar um conjunto de operadores (conjunto SEO) usando a caracterização semântica de defeitos capaz de reduzir o custo do teste de mutação enquanto mantém o escore de mutação alto.

52 Análise dos Resultados CAPÍTULO 4 O capítulo anterior apresentou como o algoritmo explora a caracterização semântica de defeitos e também apresentou dois experimentos controlados, o primeiro experimento para se extrair o conjunto de operadores de mutação e o segundo experimento para verificar se o conjunto é adequado para ser usado na Mutação Seletiva. Este capítulo, por sua vez, apresenta os resultados de ambos os experimentos. É aqui que os dados são apresentados, discutidos e as limitações e ameaças à validade dos experimentos são explicadas. Com os resultados dos experimentos analisados será possível concluir se a estratégia de caracterização semântica pode ser usada para se extrair bons operadores de mutação. Se o conjunto se mostrar satisfatório, então o objetivo do trabalho foi alcançado. 4.1 Conjunto SEO Como descrito na Seção 3.2 (Extração do Conjunto SEO) o algoritmo foi aplicado 32 vezes no programa Cal. Cada execução selecionava em média 18 mutantes, ao final de todas execuções foi encontrado um conjunto com 23 mutantes. Como cada mutante possuía um caso de teste associado consigo, após as execuções, tinha-se um conjunto com 23 casos de teste. Isso significa que segundo a abordagem do algoritmo, tais mutantes e casos de teste são capazes de representar todo o conjunto de mutantes e casos de teste gerados para o Cal. Ao comparar os 23 mutantes selecionados pelo algoritmo com os mutantes gerados, tem-se uma redução de 99,5%. Em relação aos casos de teste selecionados, tem-se que o algoritmo os usa para eliminar mutantes do conjunto, isso significa que o conjunto com os 23 casos de teste é capaz de matar todos os mutantes que foram gerados, alcançando escore de mutação de 1,0. Ao final da execução do algoritmo, foram extraídos 10 operadores de mutação dos 23 mutantes selecionados. A Tabela 4.1 apresenta a quantidade total de mutantes que o operador gera e quantos deles foram selecionados pelo algoritmo. Como observado na Tabela 4.1, utilizando-se apenas os operadores do conjunto SEO, é gerado um total de mutantes. Uma redução de 35,83% de mutantes gerados.

53 4.2 Efetividade do Conjunto SEO 51 Tabela 4.1: Conjunto SEO extraído do Cal. Operator Total de Mutantes Quantidade de Mutantes Gerados selecionados pelo algoritmo u-oesa 54 1 u-oabn 90 1 u-ssdl u-vtwd u-oaan u-oeaa u-vdtr u-vlsr u-ccsr u-cccr Total Obviamente o escore de mutação continua em 1,0. Embora a redução de operadores aplicados no programa Cal não tenha reduzido o escore de mutação, nada garante que esse mesmo conjunto terá um bom desempenho quando aplicado em outros programas. Diante disso, a próxima subseção apresentará os resultados obtidos com a comparação entre o conjunto SEO e outros conjuntos de operadores essenciais. 4.2 Efetividade do Conjunto SEO Como discutido na Seção 3.3, a maneira para se verificar se o conjunto SEO é capaz de reduzir o custo do Teste de Mutação sem perder a eficácia do critério é comparando-o com outros conjuntos. Para tal, foram escolhidos para a comparação dois outros conjuntos de operadores de mutação: SS-5 e SS-27. Antes de realizar a comparação, o conjunto SEO foi reorganizado em duas ordens: Ordem do Algoritmo e Ordem de Prioridade. Os dois conjuntos de operadores de Barbosa e ambas as ordens tiveram seus operadores aplicados incrementalmente. O objetivo era verificar o impacto que cada operador de mutação exerce no escore de mutação. A Figura 4.1 apresenta os gráficos dos escores de mutação incremental dos quatro conjuntos de operadores para cara um dos programas 5-UNIX. Comparando os resultados obtidos pelo conjunto SEO (Ordem do Algoritmo e Ordem de Prioridade) com os resultados dos conjuntos de Barbosa, fica evidente que o conjunto SEO é tão eficaz quanto o conjunto de Barbosa em se tratando de escore de mutação. Analisando individualmente os resultados, para os programas Cal, Look e Comm o escore de mutação do conjunto SEO é levemente maior do que o escore obtido pelo conjunto SS-5. Em relação ao conjunto SS-27, o conjunto SEO apresenta escore de mutação maior apenas para os programas Cal e Look. Entretanto, mesmo quando o

54 4.2 Efetividade do Conjunto SEO 52 (a) Cal (b) Look conjunto SEO não é capaz de superar o escore de mutação obtido por ambos os conjuntos de Barbosa, ele alcança um valor muito próximo. Como descrito na Seção 3.3, os operadores de cada conjunto foi aplicado incrementalmente: aplica-se o primeiro operador, deriva-se um conjunto de teste adequado ao operador, calcula o escore de mutação em relação ao total de mutantes gerado, adicionase o segundo operador, acrescenta-se novos casos de teste ao conjunto de teste, recalcula

55 4.2 Efetividade do Conjunto SEO 53 (c) Comm (d) Checkeq

56 4.2 Efetividade do Conjunto SEO 54 (e) Uniq Figura 4.1: Escore de Mutação para 5-UNIX o escore de mutação e assim por diante. Usando essa estratégia foi possível analisar o impacto que cada operador influencia no escore de mutação. Diante dessa análise, dois pontos chamaram a atenção. O primeiro ponto diz respeito à convergência de cada conjunto. O conjunto SEO já inicia com um escore de mutação bem alto. Ou seja, os primeiros operadores de cada ordem de aplicação do conjunto SEO já geram mutantes que alcançam um alto escore de mutação. De fato, os dois primeiros operadores de mutação já são mais do que suficientes para levar o escore de mutação para valores próximo de 1,0. Comparando os dois primeiros operadores em cada conjunto, Comm (Figura 4.1(c)) é o único programa cujo escore de mutação do conjunto SS-5 de Barbosa é maior do que o escore obtido por ambas as ordens de aplicação do conjunto SEO. Para os demais programas, ao menos uma das duas ordens de aplicação do conjunto SEO possuem um escore de mutação superior ao escore obtido pelos conjuntos de Barbosa. Essa análise da convergência dos operadores mostra que além do conjunto SEO alcançar um alto escore de mutação, ele ainda faz isso muito rápido do que os conjuntos de Barbosa, principalmente quando a Ordem de Prioridade é aplicada. Essa convergência sugere que talvez não seja preciso aplicar todos os 10 operadores de mutação do conjunto SEO para se alcançar um escore de mutação alto, consequentemente reduzindo a quantidade de mutantes, portanto, reduzindo o custo relacionado ao teste. O segundo ponto que chamou a atenção foi o comportamento dos operadores

57 4.2 Efetividade do Conjunto SEO 55 quando aplicados no programa Uniq (Figura 4.1(e)). O operador u-oaan não gerou nenhum mutante. O motivo é que o operador não tem nenhum ponto de mutação no programa Uniq, consequentemente o escore de mutação permanece o mesmo após se aplicar o operador. Em relação às ordens de aplicação, pelo fato do operador ser o primeiro da Ordem do Algoritmo, o escore de mutação permanece em 0. Entretanto é evidente que o conjunto nessa ordem alcança um alto escore de mutação quando o próximo operador é aplicado. Embora esse problema não tenha atingido nenhum operador nos conjuntos de Barbosa, o segundo operador da Ordem do Algoritmo é capaz de atingir um escore de mutação maior do que os dois primeiros operadores dos conjuntos de Barbosa. Essa situação mostra que qualquer conjunto reduzido de operadores está vulnerável a este tipo de problema e que mesmo que o conjunto SEO tenha sofrido com esse problema no programa Uniq, ele ainda foi capaz de atingir um escore de mutação muito próximo dos conjuntos de Barbosa. Esses resultados são evidências da qualidade do conjunto SEO. Mesmo quando o conjunto não é capaz de superar os escores de mutação dos conjuntos de Barbosa, ele converge mais rápido e ainda atinge um escore de mutação muito próximo de 1,0. Consequentemente, tais resultados respondem à primeira pergunta levantada na Subseção 3.3. Quando comparado com os conjuntos de Barbosa, o conjunto SEO alcança um ótimo escore de mutação. Entretanto, o escore de mutação não deve ser o único ponto a ser observado, também é importante verificar a redução de custo obtida com o uso de cada conjunto. Ou seja, a quantidade de mutantes gerados também deve ser analisada. Nas Tabelas 4.2 à 4.6 são apresentados os escores de mutação incremental, bem como a quantidade incremental de mutantes gerados. Ao comparar o escore de mutação, os mutantes gerados e a quantidade de mutantes equivalentes apresentados nas tabelas, é evidente que em todos os 5 programas testados o conjunto SEO alcança praticamente o mesmo escore de mutação que os dois conjuntos de Barbosa. Embora a diferença entre os escores de mutação seja mínima, os resultados mostram que o conjunto SEO gerou em todos os 5 programas mais mutantes do que os dois conjuntos de Barbosa. Em relação aos mutantes equivalentes, o conjunto SEO em quase todos os programas, praticamente, gerou mais mutantes equivalentes, porém a diferença de mutantes equivalentes gerados entre os conjuntos foi bem pequena. Embora o conjunto SEO se apresente mais custoso em relação à geração de mutantes e equivalentes, mais uma vez a rápida convergência do conjunto SEO faz com que os resultados se tornem mais vantajosos do que os resultados obtidos pelos conjuntos de Barbosa. Por exemplo, voltando para a comparação dos dois primeiros operadores é perceptível que o custo gasto pelos conjuntos de Barbosa é bem maior para se alcançar

58 4.2 Efetividade do Conjunto SEO 56 Tabela 4.2: Cal - Escore de mutação e geração de mutantes. Ordem do Algoritmo Ordem de Prioridade SS-5 SS-27 Op MS Mut/Eq MS Mut/Eq MS Mut/Eq MS Mut/Eq 1 0, / 1 0, / 11 0, / 0 0, / 0 2 0, / 12 0, / 15 0, / 4 0, / 0 3 0, / 14 0, / 33 0, / 34 0, / 4 4 0, / 112 0, / 39 0, / 47 0, / , / 134 0, / 43 0, / 58 0, / , / 138 0, / 44 0, / 157 0, / , / 144 0, / 143 0, / , / 243 0, / 165 0, / , / 261 0, / 263 0, / , / 265 1, / 265 0, / 234 Tabela 4.3: Look - Escore de mutação e geração de mutantes. Ordem do Algoritmo Ordem de Prioridade SS-5 SS-27 Op MS Mut/Eq MS Mut/Eq MS Mut/Eq MS Mut/Eq 1 0, / 0 0, / 11 0, / 0 0, / 1 2 0, / 11 0, / 13 0, / 6 0, / 2 3 0, / 13 0, / 25 0, / 18 0, / 8 4 0, / 52 0, / 25 0, / 25 0, / , / 59 0, / 31 0, / 36 0, / , / 61 0, / 31 0, / 84 0, / , / 61 0, / 79 0, / , / 109 0, / 86 0, / , / 121 0, / 125 0, / , / 127 0, / 127 0, / 119 o mesmo escore de mutação alcançado pelo dois primeiros operadores da Ordem de Prioridade. Quando os dois conjuntos de Barbosa alcançam o mesmo escore de mutação que foi alcançado pela Ordem de Prioridade apenas aplicando os dois primeiros operadores, eles já geraram muito mais mutantes e equivalentes. Por exemplo, para o programa Cal (Tabela 4.2) o segundo operador da Ordem de Prioridade alcança um escore de mutação de 0,99836, gerando 178 mutantes, dos quais 15 deles são mutantes equivalentes. Para o conjunto SS-5 alcançar esse mesmo escore de mutação, ele teve que gerar 424 mutantes, dos quais 58 deles são mutantes equivalentes. Portanto, o custo associado ao SS-5 é bem maior. Algo semelhante acontece com o conjunto SS-27. Essa vantagem do conjunto SEO sobre os conjuntos de Barbosa é vista em quase todos os 5 programas. Em relação às duas ordens de aplicação definidas para o conjunto SEO, têm se que a Ordem de Prioridade se mostra melhor no início, embora ambas alcancem o mesmo escore de mutação quando todos os operadores são aplicados. Na Ordem de Prioridade os operadores foram ordenados baseado no número de mutantes que ele gerou versus o número de mutantes que o algoritmo selecionou. Portanto, o operador mais caro, isto é, o operador que gerava mais mutantes, seria aplicado por último. Por essa razão, essa ordem

59 4.2 Efetividade do Conjunto SEO 57 Tabela 4.4: Comm - Escore de mutação e geração de mutantes. Ordem do Algoritmo Ordem de Prioridade SS-5 SS-27 Op MS Mut/Eq MS Mut/Eq MS Mut/Eq MS Mut/Eq 1 0, / 0 0, / 2 0, / 0 0, / 1 2 0, / 2 0, / 2 0, / 3 0, / 1 3 0, / 4 0, / 13 0, / 14 0, / 4 4 0, / 63 0, / 13 0, / 31 0, / 7 5 0, / 63 0, / 16 0, / 33 0, / 7 6 0, / 63 0, / 16 0, / 64 0, / , / 63 0, / 47 0, / , / 94 0, / 47 0, / , / 105 0, / 106 0, / , / 108 0, / 108 0, / 118 Tabela 4.5: Checkeq - Escore de mutação e geração de mutantes. Ordem do Algoritmo Ordem de Prioridade SS-5 SS-27 Op MS Mut/Eq MS Mut/Eq MS Mut/Eq MS Mut/Eq 1 0, / 0 0, / 0 0, / 0 0, / 0 2 0, / 0 0, / 0 0, / 2 0, / 0 3 0, / 0 0, / 12 0, / 15 0, / 2 4 0, / 2 0, / 12 0, / 27 0, / , / 7 0, / 14 0, / 27 0, / , / 7 0, / 14 0, / 128 0, / , / 7 0, / 115 0, / , / 108 0, / 120 0, / , / 120 0, / 122 0, / , / 122 0, / 122 0, / 127 atinge melhores resultados no começo do que a Ordem do Algoritmo. Como a Ordem de Prioridade já começa com valores altos para o escore de mutação, se torna viável remover alguns dos últimos operadores. Considerando o pior cenário é possível remover os dois últimos operadores dessa ordem (u-cccr e u-ccsr). Esses dois operadores são responsáveis por gerar mais do que 30% dos mutantes do conjunto SEO. Entretanto, tais operadores contribuem pouco para o aumento do escore de mutação. Logo não compensa aplicar esses dois operadores de mutação, uma vez que ambos geram muitos mutantes sem acrescentarem aumento significativo no escore de mutação. De fato, ao observar as Tabelas 4.2 à 4.6, o escore de mutação não tem uma diminuição drástica quando os dois últimos operadores da Ordem de Prioridade são removidos. Apenas o escore de mutação para o programa Checkeq (Tabela 4.5) permaneceu abaixo de 0,98. Como resultado dessa remoção, a Tabela 4.7 apresenta a redução de mutantes gerados para o conjunto SEO quando os operadores u-cccr e u-ccsr são removidos. Claramente observa-se que ao remover os operadores u-cccr e u-ccsr do conjunto SEO a redução de mutantes é ainda maior e como comentado anteriormente, essa remoção não exerce um grande impacto no escore de mutação. Em comparação com os

60 4.2 Efetividade do Conjunto SEO 58 Tabela 4.6: Uniq - Escore de mutação e geração de mutantes. Ordem do Algoritmo Ordem de Prioridade SS-5 SS-27 Op MS Mut/Eq MS Mut/Eq MS Mut/Eq MS Mut/Eq / 0 0, / 7 0, / 2 0, / 0 2 0, / 7 0, / 9 0, / 9 0, / 2 3 0, / 12 0, / 20 0, / 21 0, / 9 4 0, / 53 0, / 20 0, / 37 0, / , / 58 0, / 27 0, / 44 0, / , / 60 0, / 27 0, / 71 0, / , / 60 0, / 54 0, / , / 87 0, / 59 0, / , / 98 0, / 100 0, / , / 105 0, / 105 0, / 112 Tabela 4.7: Redução de custo em relação aos mutantes gerados. Conjunto SEO (%) SEO sem {u-cccr, u-ccsr} (%) SS-5 (%) SS-27 (%) Cal 35,83 73,91 86,80 48,87 Comm 55,10 68,64 81,16 69,70 Look 60,73 80,90 79,99 60,83 Checkeq 32,55 79,14 86,68 40,02 Uniq 65,82 80,90 80,10 65,70 conjuntos de Barbosa, o conjunto SEO perdia justamente por gerar mais mutantes e equivalentes, porém removendo esses dois operadores, o conjunto SEO ultrapassa o conjunto SS-27 e se aproxima ainda mais do conjunto SS-5. Os resultados apresentados nas Tabelas 4.2 à 4.7 respondem à segunda pergunta levantada na Subseção 3.3. O conjunto SEO reduz o custo do teste de mutação sem perder muita eficácia. Mesmo quando o conjunto SEO é usado com todos os operadores, ele reduz o custo enquanto alcança um alto escore de mutação. Considerando os resultados encontrados nos dois experimentos controlados (extração do conjunto SEO e a validação) é justificável afirmar que o objetivo pretendido com esse trabalho foi alcançado. Foi possível usar a caracterização semântica como uma estratégia de seleção de um conjunto de operadores de mutação. Operadores, estes, que reduzem a quantidade de mutantes gerados, porém sem perder a eficácia do Teste de Mutação. Embora os resultados tenham mostrado que o conjunto SEO não foi capaz de superar os conjuntos de Barbosa em todos os cenários é evidente que o conjunto se mostrou competitivo e com resultados satisfatórios. O conjunto além de alcançar um alto escore de mutação, ainda é capaz de reduzir o custo do teste de mutação. Em relação ao custo/benefício, de maneira geral o conjunto SEO obtém o mesmo escore de mutação que os conjuntos de Barbosa. Além do mais o conjunto SEO organizado como Ordem de Prioridade é praticamente melhor do que o conjunto SS-27 e se mantém muito próximo

61 4.3 Limitações e Ameaças à Validade 59 do conjunto SS-5. Além do mais, os dados mostram que a Ordem de Prioridade faz com que o conjunto SEO se torne mais vantajoso do que os conjuntos de Barbosa. A rápida convergência dos operadores nessa ordem faz com que o conjunto SEO alcance um alto escore de mutação bem mais rápido do que os conjuntos de Barbosa, além do mais, gerando menos mutantes e menos equivalentes. Essa rápida convergência pode ser usada para afirmar que o conjunto SEO é mais vantajoso que os conjuntos de Barbosa. Portanto, a estratégia de ranqueamento usada para criar a Ordem de Prioridade pode ser agregada ao algoritmo, para que o mesmo entregue uma ordem de aplicação dos operadores que poderá alcançar um alto escore de mutação, gerando menos mutantes. Também é importante enfatizar que há 74 operadores de mutação para programas escritos na linguagem de programação C. Entretanto, no primeiro experimento apenas 46 operadores geraram mutantes para o programa Cal. Isso significa que o conjunto SEO pode não está acurado ainda, portanto, ele pode ser melhorado. Independente do conjunto SEO não ter conseguido superar em todos os aspectos os outros dois conjuntos usados na comparação é importante deixar bem claro que o trunfo do trabalho é mostrar que com um conjunto reduzido de operadores é capaz de alcançar os mesmos resultados que um conjunto com todos os operadores. Além do mais, esse conjunto ainda tem o bônus da redução do custo proposto como objetivo do trabalho. 4.3 Limitações e Ameaças à Validade Essa subseção apresenta alguns pontos que podem ameaçar a validade dos experimentos. Devido a algumas limitações, tais ameaças podem afetar os resultados obtidos, por exemplo, os operadores que compõem o conjunto SEO. A primeira ameaça está relacionada com a maneira com a qual o conjunto SEO foi encontrado. Para extrair os operadores, o algoritmo foi aplicado no programa Cal. Embora o conjunto SEO tenha alcançado bons resultados para os programas 5-UNIX, ele pode não ser tão eficiente para outros programas. É provável que o conjunto SEO não esteja acurado, uma vez que ele foi extraído apenas do programa Cal. De fato apenas 46 operadores de mutação, dos 74 implementados pela Proteum, geram mutantes para o Cal. Essa ameaça pode ser superada com a constante melhoria do conjunto SEO. Consequentemente, o algoritmo precisa se aplicado em outros programas. Na verdade, tal ameaça é resultado da limitação de tempo. Para se extrair os operadores semanticamente essenciais do programa Cal foi gasto um tempo extra apenas para se criar a base de dados para aplicar o algoritmo. A qualidade do conjunto de teste é outra potencial ameaça. Para aplicar o conjunto SEO em outro programa e alcançar um bom escore de mutação é necessário ter um bom conjunto de teste. Entretanto, essa ameaça é intrínseca do Teste de Mutação,

62 4.4 Considerações Finais 60 já que o critério se baseia justamente na melhoria do conjunto de teste. Portanto, essa ameaça pode ser superada na mesma maneira que ela é superada nas demais estratégias: melhorando o conjunto de teste. Justamente essa melhoria é uma das etapas do Teste de Mutação. De fato, evoluir o conjunto de teste é uma etapa do Teste de Mutação. O importante é que este trabalho está provando que melhorar o conjunto de teste pode ser realizado com um conjunto reduzido de operadores. Assim como a qualidade do conjunto de teste, a quantidade de mutantes equivalentes também pode ser uma ameaça aos resultados. Embora tenha sido gerado todos os casos de teste para se extrair o conjunto SEO a partir do programa Cal, isso dificilmente irá acontecer em um cenário real. Portanto, os casos de testes gerados para um cenário real podem não ser suficientes para diferenciar um mutante equivalente de um mutante harder-to-kill (difícil de matar). Pode ser que muitos mutantes marcados como equivalentes, de fato não seriam equivalentes. Um mutante equivalente possui um tamanho semântico igual a zero, enquanto que um mutante harder-to-kill possui um tamanho semântico próximo de zero. Portanto, tal ameaça se encaixa no mesmo problema descrito anteriormente: a qualidade do conjunto de teste. Se não houver nenhum caso de teste que mate determinado mutante, ele terá tamanho igual a zero e será marcado como equivalente, mesmo não sendo de fato. A última ameaça diz respeito à validação do conjunto SEO. A validação se deu por meio da comparação com os dois conjuntos de Barbosa. Logo, se o escore de mutação e a redução de mutantes gerados pelo conjunto SEO fossem tão boas quanto os conjuntos de Barbosa, concluía-se que o conjunto SEO alcançou a eficiência pretendida. Entretanto essa conclusão só pode ser feita porque está sendo assumido que os conjuntos de operadores de Barbosa são bons o suficiente. Para superar essa ameaça é necessário comparar o conjunto SEO com outros conjuntos que também se dizem essenciais. 4.4 Considerações Finais Nesse capítulo foi realizada uma análise dos resultados obtidos pelas experimentações. Foi visto que o procedimento de seleção conseguiu gerar um conjunto de 10 operadores de mutação capaz de atingir o escore de mutação próximo de 1,0 quando tal conjunto é aplicado em outros programas. De maneira geral, os resultados mostraram que o conjunto SEO é capaz de alcançar um alto escore de mutação enquanto reduz o custo do teste. De fato, quando comparado com os conjuntos de Barbosa, o conjunto SEO se mostrou bastante competitivo, embora ele gere um pouco mais de mutantes e equivalentes quando todos os operadores são analisados. A conclusão extraída desses resultados é que a estratégia do tamanho semântico, implementada pelo algoritmo, se mostrou válida. Foi possível encontrar um

63 4.4 Considerações Finais 61 conjunto de operadores que reduz o custo e ao mesmo tempo mantém a eficácia do teste. Além de ter como bônus uma rápida convergência, podendo alcançar um ótimo escore de mutação com baixo custo, em geral, melhor que os conjuntos SS-5 e SS-27. A comparação com os conjuntos de Barbosa também revelou que talvez o conjunto SEO ainda não esteja acurado. É necessário que outros programas também sejam usados para melhorar o conjunto SEO. Para isso é preciso avaliar programas que tenham operadores de mutação que não foram analisados neste experimento. Esse procedimento de melhoria do conjunto SEO com outros programas será apresentado no próximo capítulo. Nele será introduzido um Serviço de Teste. Esse serviço terá como objetivo testar os programas dos usuários e usar os resultados obtidos para melhorar o conjunto SEO.

64 CAPÍTULO 5 Infraestrutura Baseada em Serviço de Teste A seção anterior apresentou indícios de que a caracterização semântica é capaz de encontrar um conjunto de operadores de mutação que reduz o custo e ainda manter a efetividade do teste. De maneira geral, o objetivo de usar a caracterização semântica como estratégia para seleção de bons operadores de mutação foi dado como satisfatório. Logo o objetivo de reduzir o custo do Teste de Mutação proposto neste trabalho foi alcançado. Devido aos bons resultados encontrados, este trabalho ainda estende as contribuições por meio de uma infraestrutura baseada em serviço. Uma vez que foi possível reduzir o custo do Teste de Mutação, nada mais lógico do que oferecê-lo para os usuários. Como discutido no decorrer deste trabalho, o Teste de Mutação, embora bastante eficaz, sofre com o custo computacional. Este capítulo apresenta como o Serviço de Teste irá usar a abordagem da Mutação Seletiva descrita neste trabalho. 5.1 ProteumService A primeira motivação desse trabalho é a aplicação da Mutação Seletiva para reduzir o custo do Teste de Mutação. Essa redução foi alcançada por meio do uso da caracterização semântica de defeitos, mais precisamente do tamanho semântico, como estratégia para seleção de um conjunto de bons operadores de mutação, tal estratégia foi denominada de Mutação Semanticamente Seletiva. Porém ao se lidar com Mutação Seletiva algumas limitações se tornam presentes. Algumas dessas limitações foram apresentadas no capítulo anterior, por exemplo, a qualidade do subconjunto de operadores encontrados pela Mutação Semanticamente Seletiva. De fato, a comparação com os conjuntos de Barbosa indicou que o conjunto SEO (Semantically Essential Operators), embora efetivo, ainda não está acurado. Para alcançar a acurácia é necessário que outros programas sejam analisados. A submissão de outros programas tanto ao conjunto SEO quanto à estratégia da Mutação Semanticamente Seletiva permite que resultados da atividade de teste sirvam para melhorar tanto o conjunto quanto a estratégia de mutação seletiva. Em outras palavras, os resultados indicarão se o conjunto SEO se mostrou efetivo para os programas

65 5.1 ProteumService 63 testados, caso contrário, os próprios resultados poderão ser usados para melhorar o conjunto, uma vez que a estratégia também pode ser aplicada no programa testado. Segundo esse objetivo, a ideia de implementar o Serviço de Teste é permitir que outros programas possam ser analisados, de tal maneira que os operadores que não foram cobertos pela experimentação anterior também possam ser verificados. Logo, ao invés de replicar o experimento com outros programas, se torna mais interessante coletar tais dados em cenários reais. Consequentemente o Serviço de Teste pode estender a contribuição desse trabalho em ambas as direções. De um lado o usuário se beneficiará de uma estrutura de teste e do outro lado os resultados serão usados para evoluir o conjunto SEO. Para o usuário o serviço retornará informações sobre o processo de teste, tais como, o escore de mutação, quais casos de testes foram mais efetivos, quais foram os mutantes que não morreram etc. Tais resultados permitem que o usuário interaja com o serviço a fim de melhorar a atividade de teste. Por outro lado, uma importante responsabilidade do serviço é melhorar o conjunto SEO. Dessa maneira a redução do custo do teste viabiliza o uso do serviço pelos usuários, possibilitando que as informações coletadas possam ser usadas usadas para melhorar a efetividade do conjunto SEO Acurácia do conjunto SEO Para melhorar o conjunto SEO, o Serviço de Teste usa a mesma estratégia da Mutação Semanticamente Seletiva descrita no Capítulo 3. O objetivo é extrair e analisar os operadores de mutação que não extraídos no experimento descrito no Capítulo 3. Após extrair os operadores, eles podem ser usados para acurar o conjunto SEO, permitindo oferecer aos usuários um conjunto reduzido de operadores. Justamente nesse ponto que é necessário aplicar alguma estratégia de ranqueamento dos operadores, uma vez que o conjunto pode variar de um programa para outro. Por exemplo, suponha que o conjunto SEO encontrado é formado pelos operadores (a,b, c, d, e, f), logo após aplicar o algoritmo em outros programas e extrair outros operadores de mutação, o novo conjunto SEO é formado pelos operadores (b, c, f, g). Qual dos dois conjuntos deve ser disponibilizado como o conjunto SEO final? O primeiro que já foi validado com outros programas ou o segundo que foi gerado a partir de operadores não analisados anteriormente? Para decidir qual os operadores devem constituir o conjunto SEO acurado, alguma estratégia de ranqueamento precisa se aplicada. A estratégia de ranqueamento dos operadores será a mesma usada na Ordem de Prioridade, uma vez que o conjunto SEO organizado nessa ordem apresentou um bom custo/benefício. Dessa maneria os operadores poderão ser ordenados e ponderados de acordo com a caracterização semântica, ou seja, de acordo com a força de cada operador segundo a Equação 3-1 apresentada no Capítulo 3. Consequentemente, aqueles

66 5.1 ProteumService 64 operadores que se tornarem frequentes a medida que o algoritmo é aplicado em outros programas, sempre estarão no topo do ranqueamento. Embora outras estratégias possam ser usadas para melhorar o conjunto de operadores essenciais (por exemplo, uso de meta-heurísticas), nesse trabalho a melhoria é baseada na mesma estratégia empregada para se encontrar o conjunto SEO. Essa operação é feita dessa maneira para manter a coerência com a estratégia desenvolvida aqui. Portanto, o conjunto SEO sempre manterá a caracterização semântica, uma vez que já foi provado que a estratégia alcança bons resultados Proteum como serviço Embora nos últimos anos tenha crescido a quantidade de ferramentas que dão suporte ao teste de software, ainda existe desafios a serem superados, por exemplo, criação de ferramentas que providenciam ambientes transparentes para a atividade de teste. De fato, algumas pesquisas têm focado em web services que oferecem ambientes similares (GAO et al., 2013; CHEN; HUANG; GONG, 2013; ELER et al., 2010). Em adição a esses trabalhos, o Serviço de Teste proposto aqui, chamado de ProteumService, oferece um ambiente plugável que permite que o teste de mutação seja explorado como um serviço disponível aos usuários, assim como outras técnicas de testes são exploradas. Além disso, o ProteumService permite que diferentes atividades de teste possam ser posteriormente plugadas na arquitetura do serviço. Devido a natureza do Teste de Mutação é de extrema importância ter uma ferramenta de suporte. Embora a Proteum tem se mostrado importante para automatizar o Teste de Mutação para programas escritos em C, além de algumas estratégias de otimização (DELAMARO; MALDONADO; VINCENZI, 2000), ela tem pouco uso fora do campo acadêmico. A falta de popularização da ferramenta está intrinsecamente ligada ao Teste de Mutação, logo havendo pouca demanda para seu uso. Além disso há outros pontos a serem considerados, como por exemplo, a usabilidade. De fato, a Proteum é uma ferramenta que disponibiliza uma interface gráfica, logo é necessário que os usuários estejam cientes das etapas do Teste de Mutação e então aplicá-los por meio da interface. Entretanto, para usuários que buscam por estratégias automatizadas, usar a Proteum por linha de comando se torna mais interessante. Surgindo a primeira barreira: não são todos os usuários que possuem tal conhecimento 1. Enquanto que usabilidade é um requisito subjetivo, há outras ameaças que desafiam o uso da Proteum fora do mundo acadêmico. Suponha um cenário onde uma equipe de teste lida com um ambiente distribuído de teste, introduzir a Proteum nesse tipo 1 Para outras ferramentas, como por exemplo µjava, as implicações são semelhantes.

67 5.1 ProteumService 65 de ambiente é uma tarefa que exigirá esforço e possui várias barreiras a serem enfrentadas, como abordado na subseção anterior. Ter uma infraestrutura que lide com a ferramenta pode ser uma solução. Além do mais, os usuários podem ficar livres de detalhes de configuração. Como resultado, a Proteum encapsulada em um ambiente amigável pode ser útil até mesmo para popularização do Teste de Mutação. Há outros benefícios de encapsular ferramentas como a Proteum em serviço. Este trabalho aplicou a Mutação Seletiva para reduzir o custo do Teste de Mutação, entretanto, como apresentado na Subseção 2.2, existem outras estratégias para se alcançar a redução do custo computacional do Teste de Mutação. Além das estratégias que reduzem o número de mutantes gerados, a redução do custo computacional também pode ser alcançada otimizando o processo de execução dos mutantes. No artigo de Jia e Harman (2011), eles agrupam as técnicas usadas para otimizar o processo de execução que tem sido citadas na literatura em três conjuntos. O terceiro conjunto (Advanced Pratforms Support for Mutation Testing) são de técnicas que distribuem o custo computacional total do teste entre diferentes processos. O serviço de teste proposto aqui cria uma infraestrutura semelhante para distribuir o custo computacional entre diferentes máquinas. Essa distribuição é realizada baseada na quantidade de mutantes gerados, distribuindo as execução dos mutantes entre diferentes máquinas, permitindo que vários mutantes sejam executados separadamente. Essa estratégia permite explorar a independência entre os mutantes e ao final do processo é possível realizar uma união dos resultados retornados Ambiente padronizado de teste Como dito no inicio deste capítulo, é necessário que outros sejam submetidos à Mutação Semanticamente Seletiva, uma vez que o conjunto SEO ainda não está acurado. Diante dessa necessidade surgiu o serviço de teste ProteumService. Com o ProteumService disponível aos usuários é possível que os mesmos possam usufruir do Teste de Mutação para testar seus programas. Em contrapartida, o ProteumService pode usar o programa dos usuários para melhorar o conjunto SEO dando continuidade à experimentação da Mutação Semanticamente Seletiva. Porem, um dos desafios atuais de se conduzir estudos experimentais envolvendo teste de software, consiste em encontrar materiais adequadamente preparados para a replicação de experimentos. Existem poucas infraestrutura para experimentos controlados estabelecidos, documentados e disponibilizados na literatura nessa área (DO; ELBAUM; ROTHERMEL, 2005), o que dificulta a reprodução dos cenários originais dos experimentos, podendo reduzir a capacidade de generalização dos resultados (WOHLIN, 2012; WOOD et al., 1997; FAROOQ; QUADRI, 2013; FAROOQ; QUADRI, 2014).

68 5.1 ProteumService 66 Experimentos controlados envolvendo Teste de Software depende de um número de artefatos de software, incluindo sistemas de gerência, conjuntos de teste, analisadores automáticos de dados, entre outros. Obter tais artefatos e organizá-los para oferecer suporte à experimentação controlada é uma tarefa difícil (ROCIO et al., 2012). Um dos empecilhos na definição e uso desses artefatos pode ser justamente o tipo de ferramentas envolvidas e como elas interagem entre si. Por exemplo, ao se considerar ferramentas de teste stand-alone 2 ameaças à viabilidade e validade do experimento passam a ser consideradas. Algumas ameaças são: Escalabilidade de reprodução: dependendo do número de participantes, máquinas envolvidas e demanda de configuração manual da ferramenta, a preparação da replicação do experimento atinge elevado custo. Transferência de conhecimento tácito: necessidade de expertise dos pesquisadores sobre a configuração correta de ferramentas (às vezes com pouca ou nenhuma documentação) para disponibilizar o uso aos participantes (SHULL et al., 2002). Tangibilidade do ambiente: possibilidade de incompatibilidade entre ferramentas de teste e ambiente de software disponível (sistema operacional distinto, dependência de pacotes de software indisponíveis, versões distintas do experimento original etc). Além disso, há alterações pontuais após o ambiente configurado em função de mudanças dinâmicas no decorrer da execução do experimento, como atualização automática e não prevista de dependências da ferramenta. Por outro lado, ao viabilizar uma infraestrutura de teste na forma de um serviço de software, essas ameaças passam a ser atenuadas da seguinte forma: O custo de preparação da replicação do experimento para 1 ou n participantes/- máquinas é o mesmo do ponto de vista de configuração, uma vez que basta que o serviço esteja disponível para acesso. Além disso, o serviço facilita a adoção da abordagem online labor market (HORTON; RAND; ZECKHAUSER, 2011) para condução de experimentos. Pesquisadores que irão replicar o experimento não precisam entender a mecânica da ferramenta para poder operá-la. Apenas saber acessar o serviço. Ao diminuir o acoplamento das ferramentas com o ambiente dos usuários, alcançase a portabilidade da ferramenta, uniformizando o acesso. Mudanças dinâmicas e imprevistas do ambiente sobre o qual o serviço roda podem ser mais evidentes e passíveis de ajuste, já que o efeito sempre afetará todos ou nenhum dos participantes. 2 No contexto deste trabalho, uma ferramenta stand-alone é um software que não precisa estar conectado a rede para desempenhar suas funções.

69 5.2 Arquitetura 67 Fornecer um infraestrutura como serviço isenta os usuários de certas preocupações e limitações que não pertencem ao seu escopo. Uma vez que o serviço esteja disponível, os participantes podem usufruir da infraestrutura montada sem se preocupar como ela é mantida. Detalhes de manutenibilidade, viabilidade e configuração passam a ser de responsabilidade dos mantedores do serviço. 5.2 Arquitetura Como discutido anteriormente, a infraestrutura proposta aqui vai além do Teste de Mutação, mas, por motivos de coerência com o trabalho e limitação de escopo, a infraestrutura será descrita seguindo como exemplo o cenário do Teste de Mutação. Entretanto é importante frisar que a maneira como o serviço está arquitetado permite que posteriormente módulos sejam acoplados a ele, independente do critério de teste, uma vez que os mesmo respeitem as interfaces de comunicação definidas na arquitetura. A Figura 5.1 apresenta os principais componentes do ProteumService. O usuário irá submeter ao serviço o programa que será testado, bem como o conjunto de teste. A interação do usuário com o ProteumService é feita usando-se o navegador web e, por meio do mesmo, ele pode escolher algumas configurações. Após submetido o programa para o serviço, inicia-se a atividade de teste. O componente DistributionHandler faz um primeiro pré-processamento sobre os dados enviados e então cria uma sessão de teste para o usuário. Este mesmo componente distribuirá a criação e execução dos mutantes entre diferentes máquinas. Cada máquina é controlada pelo componente ProteumController Após cada máquina realizar sua tarefa, os resultados são mandados de volta para o DistributionHandler. O DistributionHandler repassa o controle para o componente ReportController. Este, por sua vez, processará os resultados e gerará um relatório da atividade de Teste. O relatório então é enviado para o usuário. Os resultados analisados também são enviados para o componente ImproveController para serem para melhorar o conjunto SEO. Para isso ele usará a caracterização semântica para analisar a efetividade de cada operador baseado no tamanho de seus mutantes. O ImproverControler ainda se comunica com o DistributionHandler caso seja necessário continuar a atividade de teste com outros operadores de mutação.

70 5.2 Arquitetura 68 Figura 5.1: Infraestrutura do ProteumService para o Teste de Mutação DistributionHandler O primeiro componente da infraestrutura é o DH (DistributionHandler). Quando o usuário envia o programa e os casos de teste para o serviço é de responsabilidade do DH verificar se o usuário submeteu os arquivos com o código fonte do programa e os casos de teste. Caso esteja em conformidade, o mesmo pode iniciar uma sessão de teste. A sessão é iniciada de acordo com as configurações estabelecidas pelo usuário (Subseção 5.3). O componente DH mantém uma tabela com máquinas 3 disponíveis para uso. Utilizando-se de uma algoritmo de alocação de recursos, o DH estima a quantidade de mutantes que serão gerados e distribui eles entre as máquinas. Essa estimativa é baseada na quantidade de operadores de mutação. Os operadores geram diferentes quantidades de mutantes, uns mais do que outros. Por isso o DH faz uma simulação de uma sessão de teste usando a Proteum. Essa simulação retorna a quantidade de mutantes que seria gerada por cada operador, baseado nesse resultado o DH divide os operadores de mutação em conjuntos. Após montar os conjuntos, DH envia cada conjunto para um máquina. A distribuição dos operadores ocorre da seguinte maneira: 1. Recupera a quantidade de máquinas ociosas. Cada máquina receberá um conjunto de operadores de mutantes. 3 Uma máquina não representa necessariamente uma máquina física. Pode ser uma máquina composta por um conjunto de máquinas virtuais.

71 5.2 Arquitetura Para cada operador é contabilizado a quantidade de mutantes que ele gera. 3. Soma-se a quantidade de mutantes de todos os operadores e divide pela quantidade de máquinas disponíveis. Esse será o valor médio de mutantes gerados por cada conjunto de operadores que será enviado para a máquina. 4. Aplica um algoritmo guloso (GRAHAM et al., 1979; FRANKE; LEPPING; SCHWIEGELSHOHN, 2007) para seleção de operadores. O algoritmo percorre todos os operadores, selecionando cada operador que irá compor o conjunto. A seleção é baseada na quantidade de mutantes que ele gera e quantidade de mutantes média que será atribuído a cada máquina. 5. Envia uma requisição para cada máquina com o programa que será testado, os casos de teste e o conjunto de operadores que deverão ser usados. A Figura 5.2 ilustra um cenário no qual ocorre a divisão dos operadores (cada operador é representado por uma letra e possui a quantidade de mutantes que ele gera) entre as máquinas. O primeiro passo da distribuição é recuperar a quantidade de máquinas ociosas (M = 4). Em seguida é verificado a quantidade de mutantes que cada operador gera, somando-as (Total = 2.385). Em seguida esse valor é dividido pela quantidade de máquinas (Média por máquina 597). Logo cada máquina deve receber um conjunto de operadores que gerem em média 597 mutantes. O algoritmo guloso começa a selecionar os operadores para formar um conjunto. Cada conjunto montado é enviado para uma máquina, que por sua vez inicia o teste de mutação com aqueles operadores do conjunto passado como parâmetro. Figura 5.2: Distribuição dos operadores entre as máquinas ociosas. Cada máquina é controlada pelo componente ProteumController. Ele é o responsável por receber a requisição do DH, executar a Proteum com as configurações recebidas e retornar os resultados. Para isso o ProteumController cria uma sessão de teste na Proteum com aqueles operadores que ele recebeu como parâmetro, os mutantes gerados

72 5.2 Arquitetura 70 usando a Proteum e o relatório com as informações sobre a execução dos mutantes é enviado para o DH. Após receber os relatórios de todas as máquinas, DH repassa os relatórios para o ReportController ReportController Após DH receber os relatórios do teste de mutação gerados pelas máquinas distribuídas, ele os repassa para o RC (ReportController). O componente RC, por sua vez, mescla os conteúdos dos relatórios, criando um relatório final. O escore de mutação, os casos de teste que foram efetivos, a quantidade de mutantes mortos por cada caso de teste, mutantes que não foram mortos por nenhum caso de teste, o tempo de execução, o código de retorno e os parâmetros para cada caso de teste são algumas das informações que estão presentes no relatório final. Após recuperar esses dados, RC monta o relatório final e envia para o usuário. Usando-se desse relatório o usuário terá as informações referentes ao teste de mutação. Com essas informações ele poderá tomar as devidas decisões, podendo continuar a atividade de teste: adicionando novos casos de teste, habilitando ou desabilitando mutantes, marcando mutantes como equivalentes etc. Para que o usuário possa continuar com a atividade de teste posteriormente, os dados recebidos pelo RC são passados para o componente ImproveController ImproveController A primeira função do IC (ImproveController) é manter e armazenar no banco de dados algumas informações sobre a sessão de teste do usuário. Essas informações permitem que o usuário continue realizando a atividade de teste durante uma sessão. O banco de dados armazena o id da sessão de teste atribuída ao usuário e permite que ele altere configurações nos operadores e casos de testes já submetidos. Uma vez que o usuário finaliza uma sessão, tais dados são deletados do bando de dados. Quando o usuário faz uma nova requisição ao serviço, o DH percebe que o usuário já possui uma sessão ativa e que ele deve se comunicar com o IC antes de realizar qualquer atividade. O componente IC, por sua vez, irá informar para DH quais são as novas configurações que devem ser repassadas para as máquinas distribuídas. É necessário fazer essa comunicação com o IC poque o componente DH não possui conhecimento de quais foram as configurações já definidas anteriormente pelo usuário. Quando IC repassa essas informações para DH, ele pode repassar a nova configuração para as máquinas distribuídas. Dessa maneira, essa nova rodada de teste manterá a configuração integra com a que foi estabelecida pelo usuário.

73 5.2 Arquitetura 71 Suponha o seguinte caso no qual o usuário interage três vezes com o serviço. Na primeira interação é criado uma sessão de teste para o usuário e o teste de mutação é executado. Com os resultados em mãos, o usuário verifica que alguns mutantes são equivalentes. Ele inicia uma segunda interação com o serviço, marcando alguns mutantes como equivalentes e informando que o teste de mutação deve acontecer novamente, porém sem aqueles mutantes. Para tal, o componente DH verifica que já existe uma sessão com o usuário e envia uma mensagem para IC para que o mesmo marque que aqueles mutantes são equivalentes e caso seja necessário executar novamente os mutantes, tais mutantes não devem ser contabilizados. Ainda não satisfeito com os resultados obtidos, o usuário resolve adicionar novos casos de teste. Na terceira interação ele envia ao serviço os novos casos de teste. Nesse ponto, irá iniciar uma nova rodada de teste com os novos casos de teste. Nesse ponto DH se comunica com IC e verifica que existe um conjunto de mutantes que não devem ser analisados, pois foram marcados como equivalentes anteriormente. Dessa maneira DH propaga a informação para os ProteumControler (máquinas) e tais mutantes não serão usados no teste. Se não houvesse essa comunicação do DH com o IC, seria necessário que tais informações fossem repassadas a todo instante pelo usuário ou que elas fossem armazenadas diretamente nas máquinas distribuídas e controladas pelo ProteumController, onde estar instalada a Proteum. Essa última solução tem algumas desvantagens. Além do fato de replicar a mesma configuração definida pelos usuários, tais máquinas não são alocadas por usuário e sim por disponibilidade de processamento. Portanto, em diferentes interações de um único usuário, pode ser usada diferentes máquinas, sendo que em uma nova interação, uma nova máquina pode ser selecionada. Como essa nova máquina não foi usada nas interações anteriores, ela não possui as configurações outrora definida. A segunda função do IC é melhorar o conjunto de operadores essenciais. Como discutido anteriormente, é necessário que a abordagem da caracterização semântica seja aplicada em outros programas para melhorar o conjunto SEO com aqueles operadores que não foram analisados no experimento controlado. Uma vez que os usuários podem optar por usar o conjunto de operadores semanticamente essenciais é importante que o conjunto esteja acurado com todos os operadores de mutação. A ideia por trás da melhoria do conjunto é usar os programas submetidos pelo usuário para extrair da sessão de teste informações sobres os operadores que foram empregados. Para isso quando o usuário finalizar uma sessão de teste com o serviço, o componente IC assume controle da sessão de teste, aplicando o mesmo algoritmo usado na Seção 3.1 para se extrair o conjunto SEO do programa do usuário. Após extrair o novo conjunto SEO, o componente IC compara o novo conjunto de operadores de mutação com o antigo conjunto, em busca de remover ou adicionar novos operadores. É importante frisar que essa alteração do conjunto SEO não é feita diretamente

74 5.3 Interação com o ProteumService 72 após aplicar o algoritmo no programa. Um novo operador só é removido ou adicionado ao conjunto uma vez que ele se mostrou eficiente para vários outros programas. Para manter essa questão de eficiência e quando um operador deve ser adicionado ou removido do conjunto SEO, cada operador recebe um valor de eficiência de acordo com o tamanho semântico de seus mutantes. Os operadores de mutação que foram encontrados com o experimento controlado a princípio recebem valores alto de eficiência, uma vez que os mesmo já foram submetidos à estratégia e se mostraram efetivos. Porém a medida que novos operadores forem se mostrando mais efetivos, seus valores de eficiência vão crescendo, podendo substituir operadores no conjunto SEO que possuem valores inferiores. Isso implica que os operadores que geram os menores mutantes terão maior probabilidade de se manter no conjunto SEO. Embora essa atividade cronologicamente aconteça após o usuário terminar a sua sessão de teste, ela só é ativada esporadicamente. Não necessariamente toda sessão de teste dará origem à atividade de melhoria do conjunto. Essa atividade só acontece quando o algoritmo de alocação de recursos, implementado no DC, informar que há máquinas ociosas ou quando tal operação for agenda. 5.3 Interação com o ProteumService A interação com o serviço de teste ProteumService ser dá por intermédio do navegador web. Usando o navegador o usuário pode escolher as configurações da atividade de teste e submeter os programas e casos de teste que serão usados no teste de mutação. Também é por meio do navegador que o usuário recebe as informações do teste. Essas informações são apresentadas na forma de um relatório. Tal relatório pode ser usado pelo usuário para melhorar uma possível nova rodada de teste. Na primeira interação com o serviço, o usuário define as configurações de teste que deverão ser aplicadas durante a sessão do usuário. Uma das primeiras opções de configuração disponíveis ao usuário é a escolha dos operadores de mutação que serão aplicados. O usuário pode selecionar individualmente o conjunto de operadores que ele deseja aplicar ou ele pode optar por usar apenas os operadores presentes no conjunto SEO. Após definido os operadores que serão aplicados, o usuário pode enviar os arquivos para o serviço. Para ser específico, o usuário deve enviar um arquivo compactado contendo o código fonte do programa a ser testado e um diretório contendo os casos de teste. O diretório deve conter vários arquivos, cada um representando um caso de teste. Após receber o relatório da atividade de teste, o usuário pode fazer uma nova interação. Nessa nova interação ele pode submeter novos casos de teste ao conjunto já existente ou ele pode habilitar/desabilitar alguns casos de teste submetidos anteriormente. Além de alterar o conjunto de teste, o usuário também pode gerar novos mutantes,

75 5.4 Implementação 73 selecionando novos operadores a serem aplicados. Em relação aos mutantes, o usuário também tem a opção de habilitar/desabilitar mutantes, bem como marcar alguns mutantes como equivalentes. A Figura 5.3 apresenta a representação BPMN (Business Process Model and Notation) da interação do usuário com a ProteumService Figura 5.3: Representação BPMN do processo de teste por meio da ProteumService. 5.4 Implementação Como apresentado na Seção 5.2 a arquitetura do ProteumService possui 4 principais componentes. Sendo DistributionHandler o responsável por fazer a paralelização do processo de mutação. É esse componente que divide a carga entre máquinas ociosas. Máquinas estas que são controladas pelo ProteumController. A distribuição do custo de execução dos mutantes nessa arquitetura visa alcançar a escalabilidade do serviço ao mesmo tempo em que propõem uma estratégia extra para redução do custo de mutação. Embora as vantagens dessa arquitetura sejam evidentes, a implementação seguida nesse trabalho é levemente reduzida. A Figura 5.4 apresenta a mesma arquitetura discutida anteriormente, porém simplificada.

76 5.4 Implementação 74 Figura 5.4: Infraestrutura simplificada do ProteumService. Na arquitetura simplificada, o componente DistributionHandler é eliminado, dando lugar ao componente ProteumController. As funções de interação com os componentes ReportController e ImproveController mantém-se, porém agora são desempenhadas pelo próprio ProteumController. A única função que ProteumController não desempenha é a distribuição do processamento entre as máquinas ociosas, uma vez que só existe uma única máquina na arquitetura reduzida. O motivo por simplificar a arquitetura durante a implementação é para delimitar o escopo da aplicação. Mesmo que o DistributionHandler seja um componente importante na infraestrutura e que traz benefícios práticos, ele a priore não impacta diretamente no objetivo principal do trabalho: encapsular a Proteum, oferecendo um serviço de teste transparente ao usuário. Uma vez alcançado a prova de conceito, a arquitetura implementada pode ser melhorada, ampliando-a para a arquitetura original. Todos os componentes da arquitetura são implementados na linguagem de programação Java. Porém a Proteum foi desenvolvida em linguagem de programação C. Para realizar a integração, o componente ProteumController faz chamadas para a Proteum usando shell scripts como intermediário (Vide Apêndice B.1). Cada comando suportado pela Proteum é mapeado para um scipt, que por sua vez é chamado pelas classes implementadas no ProteumController usando a classe RunScript (Vide Apêndice B.1). A interação do usuário como o serviço é feita por meio da Axis2 (JAYASINGHE,