Uma Abordagem Coevolucionária para Seleção de Casos de Teste e Mutantes no Contexto do Teste de Mutação

Transcrição

1 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA ANDRÉ ASSIS LÔBO DE OLIVEIRA Uma Abordagem Coevolucionária para Seleção de Casos de Teste e Mutantes no Contexto do Teste de Mutação Goiânia 2013

2 TERMO DE CIÊNCIA E DE AUTORIZAÇÃO PARA DISPONIBILIZAR AS TESES E DISSERTAÇÕES ELETRÔNICAS (TEDE) NA BIBLIOTECA DIGITAL DA UFG Na qualidade de titular dos direitos de autor, autorizo a Universidade Federal de Goiás (UFG) a disponibilizar, gratuitamente, por meio da Biblioteca Digital de Teses e Dissertações (BDTD/UFG), sem ressarcimento dos direitos autorais, de acordo com a Lei no 9610/98. o documento conforme permissões assinaladas abaixo, para fins de leitura, impressão e/ou download, a título de divulgação da produção científica brasileira, a partir desta data. 1. Identificação do material bibliográfico: [ X ] Dissertação [ ] Tese 2. I d ent1 'f' 1caçao - d a T ese ou D1ssertaçao Autor(a): l André Assis Lôbo de Oliveira l andre.assis.lobo@gmail.com Seu pode ser disponibilizado na página? [X ]Sim [ ] Não Vínculo em_qregatício do autor Agência de fomento: Coord. de Aperf. de Pessoal de Nível Superior País: Brasil I UF: GO I CNPJ: I Título: Palavras-chave: Uma Abordagem Coevolucionária para Seleção de Casos de Teste e Mutantes no Contexto do Teste de Mutação Search-Based Software Testing (SBST), Metaheurística, Algoritmos Genéticos (Ags), Efetividade Genética, Teste de Mutação, Seleção de Casos de Teste A Coevolutionary Approach to Test Cases Selection and Mutant Pro- grams in Mutation Testing Context Título em outra língua: I I Sigla: I CAPES Palavras-chave Search Based Software Testing (SBST), Metaheuristics, Coevolutionem outra língua: ary Genetic Algorithm, Genetic Effectiveness, Mutation Testing, Test Case Selection. Area de concen- Engenharia de Software tração: Data defesa: I os; Programa de Pós-Graduação: I Orientador (a): Celso Gonçalves Camilo-Junior celso@inf.ufg.br 3. Informações de acesso ao documento: Concorda com a liberação total do documento [ X ] SIM Havendo concordância com a disponibilização eletrônica, torna-se imprescindível o envio do(s) arquivo(s) em formato digital PDF ou DOC da tese ou dissertação. O sistema da Biblioteca Digital de Teses e Dissertações garante aos autores, que os arquivos contendo eletronicamente as teses e ou dissertações, antes de sua disponibilização, receberão procedimentos de segurança, criptografia (para não permitir cópia e extração de conteúdo, permitindo apenas impressão fraca) usando o padrão do Acrobat. Data: 27/01/2013 Neste caso o documento será embargado por até um ano a partir da data de defesa. A extensão deste prazo suscita justificativa junto à coordenação do curso. Os dados do documento não serão disponibilizados durante o período de embargo.

3 ANDRÉ ASSIS LÔBO DE OLIVEIRA Uma Abordagem Coevolucionária para Seleção de Casos de Teste e Mutantes no Contexto do Teste de Mutação 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: Otimização em Teste de Software. Orientador: Prof. Celso Gonçalves Camilo-Junior Goiânia 2013

4 Dados Internacionais de Catalogação na Publicação (CIP) GPT/BC/UFG O482a Oliveira, André Assis Lôbo de. Uma Abordagem Coevolucionária para Seleção de Casos de Teste e Programas Mutantes no Contexto do Teste de Mutação [manuscrito] / André Assis Lôbo de Oliveira f. : il. Orientador: Prof. Dr. Celso Gonçalves Camilo-Junior; Dissertação (Mestrado) Universidade Federal de Goiás, Instituto de Informática, Bibliografia. Inclui lista de figuras, abreviaturas, siglas e tabelas. Apêndices. 1. Search Based Software Testing (SBST). 2. Metaheurística. 3. Algoritmos genéticos. 4. Efetividade genética. I. Título. CDU:

5 André Assis Lôbo de Oliveira Uma Abordagem Coevolucionária para Seleção de Casos de Teste e Mutantes no Contexto do Teste de Mutação 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 Ciência da Computação, aprovada em 05 de dezembro de 2013, pela Banca Examinadora constituída pelos professores: Pr f. e arlos Maldonado Instituto de Ciênc1as Matempticas e de Computação - USP ~ Rizzo Vincenzi Informática - UFG

6 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador(a). André Assis Lôbo de Oliveira Graduou-se em Informática na Universidade Federal de Mato Grosso (UFMT), Campus Universitário do Araguaia (IUniAraguaia). Especializouse em Gestão de Projetos pelas faculdades Alves Faria (ALFA). Atuou como Analista de Sistemas, Consultor de Qualidade de Software e Gerente de Projetos na Agenda Assessoria. Foi bolsista CAPES durante a pós-graduação. Atua como professor no Instituto Federal de Goiás (IFG).

7 Como evidência de gratidão e honra, dedico este trabalho: A Jesus Cristo porque d Ele, por Ele e para Ele são todas as coisas. À minha esposa, Célia Márcia, por tamanho amor exercido em todos os momentos. Linda, sua oração, confiança, compreensão, motivação e carinho, foram essenciais para o cumprimento dessa etapa. Minha princesa, nosso amor é Eterno! Te amo muito... Aos meus pais, Francisco e Rozelha, por terem me ensinado: o conhecimento como uma grande virtude de um homem, a ler,..., e, principalmente, o que é uma família e o que é amar. Amo vocês... Aos pais da minha esposa, José Donizete e Creuza Senhorinha, por me ajudarem a despertar o desejo de seguir carreira acadêmica e, principalmente, por terem me adotado e me amarem como filho. Amo vocês...

8 Agradecimentos Agradeço a Deus, pelo infinito amor dispensado sobre a minha vida. Pai, obrigado por Sua benigna vontade e se revelar a mim, utilizando-se de várias ferramentas para me fazer perceber que És o Alfa e o Ômega. A Ti, toda a minha adoração e o meu louvor. Agradeço ao meu Primo Gláucio Cardoso... Por não medir esforços em me apoiar na busca pelo conhecimento. Por me apresentar a Engenharia de Software como uma área de grande importância cujo o bom emprego determina a maturidade de uma empresa que produz software de qualidade. Por me confiar credibilidade, juntamente com o Guerra Júnior, para o exercício das minhas funções no setor de Qualidade de Software da Agenda Assessoria, empresa que tanto estimo. Por ter me inserido no seio da sua família, a qual detenho grande amor. Agradeço ao Professor Auri Marcelo Rizzo Vincenzi... Por ter me respondido a um antes mesmo da minha inscrição no processo seletivo do mestrado. Desse , nos encontramos e conversamos sobre pesquisas e, muito embora fosse uma noite chuvosa, saí do Instituto de Informática convicto de um primeiro passo dado para o ingresso na carreira acadêmica. Por acreditar em mim e idealizar uma pesquisa no campo da Search-Based Software Testing (SBST), direcionando o professor Celso como orientador mais indicado para o projeto. Por ter acompanhado toda a pesquisa me dando orientações, na parte de Teste de Software, de maneira eficaz. Valorizo o seu caráter e sua simplicidade, ambos demonstrados durante todo esse tempo. Agradeço ao Professor orientador Celso Gonçalves Camilo-Junior... Pelo apoio demandado durante todos os momentos da pesquisa. Por saber transmitir que o alcance do entendimento, sobre determinado assunto, requer um vislumbre muito maior do que as evidências que se tem em mãos. Por estar sempre a um passo a frente que deveria ser dado, enquanto eu me esforçava em reportar o estágio atual da pesquisa. Pela liberdade que me foi confiada nas investigações da pesquisa e, ao mesmo tempo, por me mostrar as situações que poderia me fazer perder o foco. Por estabelecer metas em cada estágio da pesquisa e por atender aos meus telefonemas nos momentos decisivos...rs. De fato, esse tempo em que trabalhos juntos gerou em mim uma grande admiração pelo seu caráter e serenidade, essenciais nas tomada de decisões. Agradeço ao Professor Cássio Leonardo Rodrigues...

9 Por sempre ter sido solícito um muitas ocasiões em que precisei de uma ajuda e/ou opinião sobre diversificados assuntos que surgiram no âmbito acadêmico. Em tudo isso, percebi a simplicidade e a prontidão, virtudes tais que valorizo e admiro. Agradeço ao meu irmão caçula Sandino Barros Jardim... Por desde a época da graduação ter estado ao meu lado. Aprendemos juntos muitos assuntos acadêmicos que, de fato, nos geraram conhecimento. Nos ajudamos e, a medida que o tempo passou, crescemos juntos em maturidade. Agradeço a Deus porque hoje também seguimos juntos buscando, muito mais do que conhecimento: a sabedoria. Agradeço ao meu amigo Adaílton... Por ser um exemplo de determinação e garra durante nossa jornada no mestrado. Por demonstrar que, independente das cirscunstâncias, eu poderia contar com você. Enfim, por ser meu amigo. Agradeço ao meu amigo Alex Bastos... Pelo seu exemplo de superação para realização da pesquisa. Pela sua grande simplicidade e humildade que configuram o seu valioso caráter. Enfim, por ser meu amigo. Agradeço ao meu amigo Jorge Peixoto... Por ser um exemplo de pesquisador observando muitos detalhes essenciais para obtenção de uma conclusão. Pelas nossas longas conversas acerca das nossas convicções, ideais e valores. Enfim, por ser meu amigo. Agradeço aos colegas de laboratório Higor, Leonardo Silva, Marllos e Vinícius... Pela companhia nos momentos de finalização e escrita da minha dissertação. Em especial ao meu conterrâneo e parceiro pesquisador Leonardo Silva, por tantas conversas que tivemos acerca das futuras pesquisas que podemos realizar juntos no prosseguimento das nossas carreiras acadêmicas. Enfim, pelo início das nossas amizades. Um agradecimento especial ao meu amigo Leonardo Teixeira Queiroz... Por estar presente em todos os momentos dessa minha trajetória na UFG. Por ter me apresentado ao professor Cássio, como um potencial pesquisador. Por ter sido o meu irmão mais velho sempre me perguntando sobre o andamento da pesquisa e por sempre se colocar à disposição, para me ajudar. Tenho grande admiração pelo seu exemplo de humildade e integridade. Enfim, por ser meu amigo, meu irmão. Agradeço as minhas irmãs Paula Kamilla e Lidianne Lôbo Pela torcida, orações, amor e carinho. Por saber que posso contar com vocês sempre. Lindas, amo vocês... Agradeço aos irmãos da minha esposa Paulo e Wilhan... Pela força e torcida expressa ao longo da minha trajetória. Em especial, agradeço ao Wilhan por todo apoio que me foi dado durante o estágio final da minha pesquisa. Agradeço à Coordenação de Aperfeiçoamento de Nível Superior (CAPES) pelo apoio financeiro à pesquisa realizada.

10 Lista de Publicações Partes da presente dissertação têm sido publicadas ou submetidas, em forma de artigo para apreciação de revistas, conferências e workshops. Segue abaixo a lista desses trabalhos: 1. OLIVEIRA, A. A. L.; CAMILO, C. G.; VINCENZI, A. A coevolutionary algorithm to automatic test case selection and mutant in mutation testing. In: Evolutionary Computation (CEC), 2013 IEEE Congress on, p , 2013 (Qualis: A1) [54]. 2. OLIVEIRA, A. A. L.; CAMILO, C. G.; VINCENZI, A. Um algoritmo genético coevolucionário com classificação genética controlada aplicado ao teste de mutação. In: IV Workshop de Engenharia de Software Baseada em Busca (WESB) [53] OLIVEIRA, A. A. L.; CAMILO, C. G.; VINCENZI, A. O teste de mutação apoiado pelo algoritmo genético coevolucionário com classificação genética controlada. Publicação em breve na Revista de Informática Teórica Aplicada (RITA) (Qualis B4) [52]. 4. OLIVEIRA, A. A. L.; CAMILO, C. G.; VINCENZI, A. A new genetic algorithm coevolutionary with controlled genetic classification applied to mutation analysis. Submitted to the Journal of Systems and Software, Special Issue on Search Based Software Engineering (Qualis A2) [51]. 1 Trabalho premiado como o melhor artigo do IV Workshop de Engenharia de Software Baseada em Busca (WESB ).

11 ... se der ouvidos à sabedoria e inclinar o coração para o discernimento; se clamar por entendimento e por discernimento gritar bem alto, se procurar a sabedoria como se procura a prata e buscá-la como quem busca um tesouro escondido, então você entenderá o que é temer ao Senhor e achará o conhecimento de Deus. Provérbios, 2:2-5.

12 Resumo Oliveira, André A. L. Uma Abordagem Coevolucionária para Seleção de Casos de Teste e Mutantes no Contexto do Teste de Mutação. Goiânia, p. Dissertação de Mestrado. Instituto de Informática, Universidade Federal de Goiás. Atividades de Validação e Verificação (V&V) consomem cerca de 50% a 60% do custo total no ciclo de vida de um software. Dentre essas, o Teste de Software é uma das atividades mais empregadas. Um dos maiores problemas do Teste de Software é encontrar um conjunto de teste (subconjunto do domínio de entrada do problema) que seja eficaz em detectar os defeitos remanescentes no software. Neste contexto, a Search-Based Software Testing (SBST) é uma linha de pesquisa recente que vem propondo boas soluções, uma vez que utiliza-se de metaheurísticas para encontrar um conjunto de teste com baixo custo e grande eficácia na detecção de defeitos. Dentre os diversos critérios de teste existentes, o Teste de Mutação é bastante promissor na revelação de defeitos, entretanto apresenta um alto custo computacional em termos de aplicabilidade. Por isso, a pesquisa aborda o problema de seleção de programas mutantes e casos de teste no contexto do Teste de Mutação. Para tal, propõe o Algoritmo Genético Coevolucionário (AGC) que traz o conceito de Efetividade Genética, implementado pela Classificação Genética (CG) e por novos operadores genéticos adaptados à representação proposta. Além disso, propõe o Algoritmo Genético Coevolucionário com Classificação Genética Controlada (AGC CGC op ) para a melhoria da eficiência da CG do AGC. O algoritmo AGC é aplicado em três classes de benchmarks e comparado com outros cinco métodos. Os resultados demonstram um melhor desempenho do AGC na seleção de subconjuntos com melhor escore de mutação, bem como um aprimoramento do AGC CGC op no uso da CG. Tais resultados evidenciam a abordagem proposta com uso promissor no contexto do Teste de Mutação. Palavras chave Search Based Software Testing (SBST), Metaheurística, Algoritmos Genéticos (AGs), Efetividade Genética, Teste de Mutação, Seleção de Casos de Teste.

13 Abstract Oliveira, André A. L. A Coevolutionary Approach to Test Cases Selection and Mutant Programs in Mutation Testing Context. Goiânia, p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás. Verification and Validation Activities (V&V) consume about 50% to 60% of the total cost of a software lifecycle. Among those activities, Software Testing technique is one which is mostly used during this process. One of the main problems related to detected in Software Testing is to find a set of tests (subset from input domain of the problem) which is effective to detect the remaining bugs in the software. The Search-Based Software Testing (SBST) approach uses metaheuristics to find low cost set of tests with a high effectiveness to detect bugs. From several existing test criteria, Mutation Testing is considered quite promising to reveal bugs, despite its high computational cost, due to the great quantity of mutant programs generated. Therefore, this dissertation addresses the problem of selecting mutant programs and test cases in Mutation Testing context. To this end, it is proposed a Coevolutionary Genetic Algorithm (CGA) and the concept of Genetic Effectiveness, implemented by Genetic Classification (GC) and new genetic operators adapted to the proposed representation. Furthermore, the Genetic Algorithm Coevolutionary with Controlled Genetic Classification (CGA CGC op ) is proposed for improving the efficiency of CGA s GC. The CGA is applied in three categories of benchmarks and compared to other five methods. The results show a better performance of the CGA in subsets selection with better mutation score, as well as improvement of CGA CGC op in use of GC. These results evidence the proposal approach with promising use in the context of Mutation Testing. Keywords Search Based Software Testing (SBST), Metaheuristics, Coevolutionary Genetic Algorithm, Genetic Effectiveness, Mutation Testing, Test Case Selection.

14 Sumário Lista de Figuras 14 Lista de Tabelas 16 Lista de Algoritmos 17 1 Introdução Objetivo Justificativa Proposta e Contribuições Organização da Dissertação 21 2 Teste de Software Conceitos Fases Critérios Teste Funcional Teste Estrutural Teste Baseado em Defeitos Análise de Mutantes Fundamentos Passos de Aplicação Ferramentas Aplicabilidade O que é importante para o Teste de Mutação? Considerações Finais 42 3 Search Based Software Testing (SBST) Algoritmos Genéticos Conceitos Representação 47 Representação Binária 48 Representação Inteira 48 Representação Real População Inicial Avaliação Seleção Cruzamento Mutação 52

15 3.2 Algoritmos Coevolucionários Aplicações no Teste de Software Considerações Finais 54 4 O Algoritmo Genético Coevolucionário (AGC) Descrição do Algoritmo A Representação de Indivíduo e a Classificação Genética (CG) Funções de Aptidão Operadores Genéticos Operador de Cruzamento Filho Efetivo (FE): Operador de Mutação Muta Genes (MG): A Classificação Genética Controlada (CGC) Considerações Finais 69 5 Estudos Experimentais Modelagem do Problema Algoritmos de Comparação Algoritmo A Algoritmo A Algoritmo A Algoritmo AGC-GE Algoritmo A2-GE Um benchmark simulado Descrição Parâmetros Análise dos Resultados Benchmarks escritos em linguagem Java Descrição Parâmetros Análise dos Resultados 87 Escore de Mutação 88 Seleção de Mutantes Equivalentes 92 Redução dos testes Benchmarks escritos em linguagem C Descrição Parâmetros Análise dos resultados 97 Perspectiva dos benchmarks 98 A variação dos parâmetros 102 Os subconjuntos selecionados 109 Comparação das metaheurísticas com base no método aleatório 122 A eficácia e a eficiência das abordagens 127 Perspectiva dos operadores de mutação Algumas Limitações Considerações Finais Conclusões e Trabalhos Futuros 146

16 Referências Bibliográficas 149 A Glossário 155

17 Lista de Figuras 2.1 Exemplo de grafo de fluxo de controle adaptado de [25] Exemplo de programas mutantes (adaptado de [61]) Evolução do Conjunto de Testes Fluxo Básico de um AG, adaptado de [37] Representação Binária, adaptada de [37] Diferentes tipos de Cruzamento, adaptado de Camilo-Junior [24] Dois tipos de operador de Mutação, adaptado de [37] Fluxograma do ambiente coevolucionário do AGC A) Indivíduo da população de casos de teste (IndTC) e B) indivíduo da população de programas mutantes (IndMT) Exemplos de seleções com o emprego do conceito de Efetividade Genética pelo AGC Exemplo de fucionamento do operador de cruzamento Filho Efetivo (FE) Exemplo de fucionamento do operador de mutação Muta Gene (MG) Ambiente Coevolucionário do AGC CGC op Utilização dos operadores genéticos FE e GM pelo AGC CGC op Experimentos: tamanhos de população expandida (Tabelas: 5.4 e 5.5) - Número de Soluções Ótimas X Algoritmos Experimentos: tamanhos de população reduzida (Tabelas: 5.6 e 5.7) - Número de Soluções Ótimas X Algoritmos Experimentos Tamanho População Expandida - Redução do Custo Computacional X Algoritmos Experimentos Tamanho População Reduzida - Redução do Custo Computacional X Algoritmos Benchmark Cal: escore médio geral obtido pelos algoritmos Benchmark Comm: escore médio geral obtido pelos algoritmos Benchmark Look: escore médio geral obtido pelos algoritmos Benchmark Uniq: escore médio geral obtido pelos algoritmos Benchmark Cal - Desempenho dos algoritmos pela variação dos tamanhos dos IndTCs) Benchmark Comm - Desempenho dos algoritmos pela variação dos tamanhos dos IndTCs) Benchmark Look - Desempenho dos algoritmos pela variação dos tamanhos dos IndTCs) Benchmark Uniq - Desempenho dos algoritmos pela variação dos tamanhos IndTCs 105

18 5.13 Benchmark Cal - Desempenho dos algoritmos pela variação dos tamanhos das populações Benchmark Comm - Desempenho dos algoritmos pela variação dos tamanhos das populações Benchmark Look - Desempenho dos algoritmos pela variação dos tamanhos das populações Benchmark Uniq - Desempenho dos algoritmos pela variação dos tamanhos das populações Distribuição das classes de mutantes por benchmark Percentual de seleção de mutantes difíceis por algoritmo Percentual de seleção por classes de mutantes Comparação entre a média dos escores de mutação na perspectiva de subconjunto e na perspectiva individual - Mutantes Percentual médio de mutantes equivalentes selecionados nos subconjuntos do Algoritmo aleatório A Distribuição das classes de casos de teste por benchmark Percentual de seleção dos casos de teste fortes por benchmark Percentual de seleção dos casos de teste fortes por classe Comparação entre a média dos escores de mutação na perspectiva de subconjunto e na perspectiva individual - Casos de Teste Comparativo do escore de mutação das metaheurísticas considerando o subconjunto dos mutantes sobreviventes ao Algoritmo A3 (método aleatório) Benchmark Cal (Experimentos 6, 7 e 8) - Comparação dos escores de mutação pelos algoritmos Benchmark Cal (Experimentos 6, 7 e 8) - Comparação dos tempos de execução alcançados pelos algoritmos Algoritmo AGC CGC op - Escore de Mutação Vs TCG Algoritmo AGC CGC op - Tempo de Execução Vs TCG. 133

19 Lista de Tabelas 2.1 Histórico de Publicações de Ferramentas de Teste de Mutação. Tabela adaptada de [35] Terminologias entre a Natureza e os AGs, adaptado de [37] Resultados Benchmark Simulado Informações sobre os Benchmarks de Polo, Mario e García [55] Parâmetros por Benchmark Resultados AGC, A1, A2 e A3 - população expandida Resultados AGC-GE e A2-GE - populacao expandida Resultados AGC, A1, A2 e A3 - experimentos: população reduzida Resultados AGC-EG e A2-EG - experimentos: população reduzida Informações sobre os utilitários UNIX (benchmarks) utilizados nos experimentos Informações sobre a geração dos dados de teste Variações nos tamanhos de indivíduos e populações Desempenho geral dos escores de mutação - Algoritmos Vs. Benchmarks Faixas para classificação para os mutantes Classes dos mutantes difíceis de matar Faixas para classificação dos casos de teste Classes dos casos de teste fortes Quantitativo de mutantes vivos considerando todos os experimentos Quantitativo de mutantes vivos a partir do método aleatório - uma perspectiva dos benchmarks por variação nos tamanhos dos subconjuntos de casos de teste Quantitativo dos mutantes mortos pelos AGs considerando os sobreviventes da abordagem aleatória para o benchamark Cal (Tabela 5.17) Análise do tempo de execução por benchmark (algoritmos A1, A3 e AGC) Benchmark Cal - escores de mutação e tempos de execução dos algoritmos para análise de eficácia e eficiência Percentuais dos operadores de mutação do conjunto essencial de Barbosa Percentuais dos operadores de mutação do conjunto essencial de Banzi Percentuais dos operadores de mutação não essenciais Informações dos operadores que geraram os sobreviventes ao método aleatório (Algoritmo A1) - conjunto de Barbosa Informações dos operadores que geraram os sobreviventes ao método aleatório (Algoritmo A1) - conjunto de Banzi Informações dos operadores que geraram os sobreviventes ao método aleatório (Algoritmo A1) - conjunto dos Não essenciais 141

20 Lista de Algoritmos 4.1 Algoritmo Genético Coevolucionário (AGC) Algoritmo proposto por Adamopoulos, Harman e Hierons [1] (A1) Algoritmo A1 com modificação na função de aptidão (A2) Algoritmo de seleção aleatória (A3) Algoritmo AGC com o Grupo dos Eleitos (AGC-GE) Algoritmo A2 com o Grupo dos Eleitos (A2-GE). 80

21 Introdução CAPÍTULO 1 O aumento da dependência do ser humano por softwares está cada vez mais visível. A tecnologia está presente como um bem tangível em muitos lugares do globo terrestre. As crianças têm facilidade em operar muitos softwares embutidos nos mais diversificados dispositivos eletrônicos. Os softwares têm prestado serviços e soluções para a humanidade nos mais variados setores e segmentos da economia. As exigências da sociedade na caracterização de um software com atributos de precisão na manipulação e no gerenciamento das informações crescem, proporcionalmente, à automatização de importantes tarefas que somente eram exercidas por mãos humanas. Desde sua criação, em 1970, a Engenharia de Software tem gerado grandes avanços para o aumento da qualidade de sistemas computacionais com o desenvolvimento e o aprimoramento de modelos, técnicas e ferramentas. Entre as áreas do conhecimento da Engenharia de Software, o Teste de Software tem realizado um papel muito importante para esse avanço. Por meio de um princípio, matematicamente simples, fundamentado no conceito de que o domínio de entrada de um programa é formado por infinitos pontos, o Teste de Software objetiva melhorar a qualidade do software por meio da revelação dos seus defeitos, uma vez que é impossível provar sua corretude, considerando a infinidade de pontos existentes de tal domínio. Utiliza-se, para isso, critérios bem definidos que subdividem esse domínio de entrada numa busca por diversos tipos de defeitos possíveis de acontecer. A Análise de Mutantes (ou Teste de Mutação) é um desses critérios, sendo caracterizada pela sua grande capacidade na revelação de defeitos. Entretanto, apresenta dois grandes problemas que diminuem sua aplicabilidade: alto custo computacional e detecção não automatizada de mutantes equivalentes. Diante disso, uma vasta gama de estudos vem sendo desenvolvidos objetivando a melhoria da aplicabilidade da Análise de Mutantes. Vale destacar os seguintes temas: a redução do custo computacional, minimização e detecção de mutantes equivalentes, criação e aprimoramento de operadores de mutação, a seleção de casos de teste, geração

22 1.1 Objetivo 19 de dados de teste, automatização da etapa de análise de mutantes, etc. O fato é que a aplicabilidade da Análise de Mutantes envolve o desenvolvimento e a evolução de estratégias eficazes. Neste contexto, um campo recente do Teste de Software surge para atuar, especificamente, nos cenários da área de teste no qual não se conhecem técnicas e métodos eficientes na solução de problemas. A este campo é dado o nome de Search Based Software Testing (SBST) que, por sua vez, utiliza-se de metaheurísticas para resolver problemas da área de teste. Como exemplo de metaheurística, tem-se os Algoritmos Evolucionários (AEs), com crescente utilização e aplicação em problemas da Engenharia de Software, especificamente, na área do Teste de Software. Dentre os AEs, os Algoritmos Genéticos (AGs) recebem um destaque especial, pois têm sido aplicados em diversos tipos de problemas, fornecendo soluções mono e multiobjetivo. 1.1 Objetivo Os AGs são fundamentados nos conceitos de evolução das espécies. A coevolução abstraída para os AEs é uma forma multiobjetivo de lidar com problemas e pode ser incorporada a um AG para melhorar seu desempenho e adequação ao problema. Por exemplo, analisando-se o critério da Análise de Mutantes, considerando alguns de seus problemas, podem ser propostas soluções que compreendem mais de um objetivo. Em vista disso, o objetivo desta pesquisa consiste em propor um Algoritmo Genético Coevolucionário (AGC) como uma solução multiobjetivo para o Teste de Sofwtare, especificamente, para Análise de Mutantes 1. Para tal, dois objetivos são tratados: 1. selecionar um bom subconjunto de casos de teste; 2. selecionar um bom subconjunto de programas mutantes. 1.2 Justificativa Em geral, as metaheurísticas são utilizadas em atividades custosas, principalmente quando realizadas por pessoas. Por exemplo, no Teste de mutação, a análise dos mutantes vivos (Seção 2.4.2) é uma atividade que exige esforço humano. Um fator que aumenta esse esforço, consiste na presença dos mutantes equivalentes dentre os gerados, tendo em vista a indecidibilidade da verificação automática da equivalência entre dois programas [35]. 1 A fim de quantificar o quão bom é um caso de teste e um programa mutante, a pesquisa utiliza-se de uma métrica chamada escore de mutação, explicada com maiores detalhes na Seção 2.4.

23 1.3 Proposta e Contribuições 20 No Teste de Regressão, existe necessidade de selecionar um subconjunto de casos de teste que realize uma boa cobertura do teste. Em uma indústria de software, considerando os possíveis defeitos que podem ser gerados e propagados nas liberações de diferentes versões de um software, a proposta da pesquisa realizada pode ser aplicável também em apoio ao Teste de Regressão. Nesse caso, a Análise de Mutantes pode ser realizada em versões preliminares do programa e um conjunto definido de casos de teste pode subsidiar a verificação e a correção dos defeitos no software que evolui. Logo, a seleção de um subconjunto de casos de teste que garanta boa qualidade no teste, de fato, também é desejável. Além disso, apesar da coevolução se apresentar como uma estratégia com grandes potencialidades, ainda existem poucos trabalhos que exploram essa metaheurística no contexto do Teste de Mutação. 1.3 Proposta e Contribuições A pesquisa propõe um Algoritmo Genético Coevolucionário (AGC) para seleção automática de bons subconjuntos de casos de teste e bons subconjuntos de mutantes para o Teste de Mutação, reduzindo o custo computacional, sem reduzir a eficácia da solução. Para tal, foi desenvolvida uma nova representação de solução para o AG coevolutivo que objetiva explorar o novo conceito de Efetividade Genética, concebido na presente pesquisa. Sendo assim, a fim de melhorar o processo de busca evolucionária para AGs no Teste de Mutação, as principais contribuições desta pesquisa são: 1. Definição de uma representação genética apropriada ao problema e uma caracterização genotípica intitulada Efetividade Genética; 2. Formulação de uma nova função objetivo baseada no conceito Efetividade Genética; 3. A apresentação de novos operadores genéticos, adaptados à representação proposta; 4. O uso de uma abordagem coevolucionária para seleção de dois subconjuntos: programas mutantes e casos de teste, como uma solução para o problema multiobjetivo do Teste de Mutação. Além das contribuições enumeradas acima, a pesquisa também propõe o Algoritmo Genético Coevolucionário com Classificação Genética Controlada (AGC CGC op ) como evolução do AGC. O AGC CGC op aprimora o emprego da Classificação Genética (CG) exercida pelo AGC agregando uma maior eficiência para o seu uso.

24 1.4 Organização da Dissertação Organização da Dissertação Além dessa parte introdutória, a dissertação está organizada em outros seis capítulos. O Capítulo 2 realiza uma revisão sobre o Teste de Software, contextualizando e descrevendo o Teste de Mutação. O Capítulo 3 discorre sobre Search Based Software Testing (SBST) com o objetivo principal de dar subsídios ao entendimento da proposta da presente pesquisa. Pode-se pontuar dois objetivos específicos do Capítulo 3: fornecer conceitos básicos sobre Algoritmos Genéticos (AGs) e apresentar algumas pesquisas que aplicam abordagens coevolucionárias no Teste de Software. A proposta da pesquisa é apresentada no Capítulo 4. Os estudos experimentais são apresentados no Capítulo 5. Por fim, as conclusões e os trabalhos futuros se encontram no Capítulo 6.

25 Teste de Software CAPÍTULO 2 Este capítulo apresenta alguns dos principais conceitos da área do Teste de Software. Inicialmente, os fundamentos que ajudam na compreensão da importância dessa atividade no processo de desenvolvimento de um software são descritos. Em seguida, apresenta-se as principais fases para realização das atividades de teste. Na sequência, os critérios de teste são abordados. Dentre esses critérios, uma seção especial destaca a Análise de Mutantes, uma vez que esse critério é o foco de aplicação desta pesquisa. Ao final, algumas considerações resumem o capítulo. 2.1 Conceitos A criação de um programa é um ato de resolução de problemas [2]. O desenvolvimento de um software pode envolver a construção de vários programas que se relacionam. Dependendo das dimensões e das características do software, esta atividade pode ser extremamente complexa [18]. Dessa forma, a construção de um software depende da interpretação de pessoas e, apesar da utilização de métodos e ferramentas da Engenharia de Software, surgem problemas nos softwares alterando o seu comportamento esperado. Portanto, é necessário dar uma grande importância às atividades que ajudam na descoberta de erros ainda no processo de desenvolvimento do software [18] para se obter um produto de qualidade [18]. Validação, Verificação e Teste de Software Dentro do processo de garantia de qualidade de um software, estão inseridas as atividades de Validação, Verificação e Teste de Software (VV&T). Elas objetivam a minimização da ocorrência de falhas e a maximização da confiabilidade e um software que está sendo desenvolvido [58]. O conjunto de atividades que garante a correspondência entre o software e os requisitos do cliente, define o termo Validação. O termo Verificação, refere-se ao conjunto de atividades que garantem a implementação correta de uma função específica pelo software [56]. Por fim, o termo Teste referencia aquelas atividades que

26 2.1 Conceitos 23 objetivam encontrar falhas na execução de um programa [46]. Observados os conceitos desses termos, fica perceptível que as atividades de VV&T não se restringem ao software como produto final, mas sim em tarefas mais abrangentes inseridas em todo o processo de seu desenvolvimento [18]. Apesar de existirem as atividades de VV&T, não é possível provar que um programa está sujeito a não ocorrêcia de falhas [46], considerando que o domínio de entrada de um programa é inifinito. Entretanto, os testes realizados de maneira sistemática com a aplicação de critérios adequados, ajudam os envolvidos no desenvolvimento do sofware a construí-lo com um comportamento mais próximo do esperado [25]. Engano, Defeito, Erro e Falha Diversos problemas podem emergir durante a construção de um software [18]. Para esses problemas, também citados anteriormente como "erros", o padrão IEEE classificou-os com as seguintes definições: 1. Engano (Mistake): consiste em uma ação humana que produz um resultado incorreto; 2. Defeito (Fault): consiste em um passo, processo ou definição de dados incorretos; 3. Erro (Error): consiste na diferença entre o valor computado, medido ou observado e o valor real; 4. Falha (Failure): consiste em um resultado incorreto em relação a uma especificação. Engano e Defeito são tipos de problemas estáticos, pois estão associados a um determinado programa e não dependem de uma execução em particular [18]. Já os conceitos Erro e Falha são tipos dinâmicos de problemas, pois dependem da execução do programa para serem revelados. O objeto de estudo dessa pesquisa trata o teste de software como uma atividade dinâmica. Domínio de Entrada, Dado de Teste e Caso de Teste O domínio de entrada de um programa P consiste no conjunto de todos os valores que podem ser utilizados para executar P e pode ser denotado por D(P) [18]. Um dado de teste para um programa P é um elemento do domínio de entrada de P. Um caso de teste é formado por um par constituído de um dado de teste mais o resultado esperado pela execução do programa com este mesmo dado de teste. Dessa forma, um caso de teste pode ser denotado pelo par (d,s(d)), sendo que d é o dado de teste e S(d) a saída esperada, conforme a especificação (S).

27 2.2 Fases 24 O ideal seria certificar-se que o programa P responde corretamente sobre todo o domínio de entrada. Entretanto, o teste exaustivo é impraticável por restrições de tempo e custo [61]. Evidencia-se, então, a relevância de selecionar um subconjunto T de casos de teste que proporcione, ao mesmo tempo, eficiência e baixo custo [58]. Uma vez definido o conjunto de casos de teste T, a atividade de teste pode ser basicamente descrita da seguinte forma: executa-se T com o programa em teste P. Caso o resultado da execução seje diferente do resultado esperado, a existência de defeito em P foi revelada. Caso contrário, nenhum defeito foi revelado. 2.2 Fases Em geral, aumentar o tamanho de um software ocasiona no aumento de sua complexidade. Em cenários semelhantes a este, para se obter um melhor resultado, existe a necessidade de dividir a atividade de testes em fases [61]. Além do tamanho, existem diversos fatores que colaboram para tornar a atividade de teste complexa 1. Dessa forma, a atividade de teste é tradicionalmente dividida em quatro fases em sequência [25]: 1. Teste de Unidade: esta fase objetiva testar cada unidade de forma isolada com a intenção de revelar falhas na implementação lógica do código; 2. Teste de Integração: esta fase auxilia na identificação de problemas que competem à interface entre as unidades e partes do software; 3. Teste de Validação: é desempenhada após o teste de integração e auxilia na revelação de falhas grosseiras que não funcionam conforme a especificação; 4. Teste de Sistema: nesta fase, os testadores tentam contabilizar todos os elementos envolvidos na execução do software. Tem como principal objetivo testar as funções e desempenho do sistema em termos gerais. Além dessas fases, há uma fase que não ocorre durante o processo normal de desenvolvimento do software. É o chamado Teste de Regressão em que, após a liberação do sistema, modificações podem acontecer e novos defeitos podem surgir como consequência dessas modificações. O teste de regressão é a reexecução de algum 1 Um bom exemplo que pode ser citado, consiste na comparação de diferentes problemas em um software [18]: o primeiro problema é a utilização de um algoritmo que computa um valor incorreto das mensalidades a serem pagas em um empréstimo e; o segundo problema é a não utilização de uma política de segurança em alguma funcionalidade do software. O primeiro problema refere-se a um tipo de erro que exige verificação a nível de codificação. Já o segundo problema remete a uma verificação de todos os pontos que exigem a aplicação dessa política, bem como sua utilização de forma correta tendo como base o padrão de segurança adotado, exigindo uma verificação a nível de aplicação de funcionalidade.

28 2.3 Critérios 25 subconjunto de funcionalidades que já foi testado para garantir que as modificações não inseriram efeitos colaterais indesejados [56]. A seleção de casos de teste consiste em uma atividade de grande importância para o Teste de Regressão, pois emprega-se a reexecução de testes para a avaliação do impacto das novas funcionalidades inseridas. Uma abordagem ideal seria considerar todos os casos de teste previamente utilizados para se testar o sistema novamente. Entretanto, pode ser que alguns fatores, por exemplo: tamanho do sistema e os recursos disponíveis [14]; desfavoreçam a utilização de todos os casos de teste. O Teste de Regressão configura um cenário ideal para o uso da abordagem proposta pela presente pesquisa (Capítulo 4), uma vez que o Algoritmo Genético Coevolucionário (AGC) visa a seleção de um subconjunto de casos de teste que tenha qualidade igual ou aproximada à de todo o conjunto. Dessa forma, a abordagem proposta pode ser empregada no Teste de Regressão. Contudo, embora existam fases diferentes na atividade de teste com objetivos distintos, há etapas bem definidas que são comuns em todas as fases de teste: planejamento, projeto dos casos de teste, execução e análise [18]. 2.3 Critérios Um programa pode ter em seu domínio de entrada uma quantidade infinita de elementos. Por isso, existe a necessidade de reduzir o número de casos de teste com a utilização de subconjuntos de forma que estes propiciem o alcance de uma qualidade adequada ao teste. O critério de teste auxilia nessa redução, pois consiste em um conjunto de regras que define subconjuntos de dados de teste do domínio de entrada, formando, portanto, os subconjuntos de casos de teste [28]. Em outras palavras, o critério de teste define os elementos do programa em teste (ou alguma outra parte do produto) que deverão ser exercitados durante a execução do software, orientando o engenheiro em todo o processo de teste [25]. Os critérios de teste podem ser classificados em três técnicas: funcional, estrutural e baseado em defeitos. Tais técnicas se diferenciam no tipo de informação utilizada para formação de subconjuntos de dados de teste (subdomínios) [18]. Nenhuma dessas técnicas é completa, mas se complementam para melhorar a garantia da qualidade do software [61] Teste Funcional O Teste Funcional é conhecido como caixa preta [46]. O foco deste critério está em como a caixa (o programa) se comporta, sob diferentes cirscunstâncias, sem se

29 2.3 Critérios 26 preocupar com o conteúdo da caixa (detalhes de implementação). Em outras palavras, tem o objetivo de observar se, para uma entrada dada, o software produz saída correta [3]. Dessa forma, o testador deriva os casos de teste utilizando-se das especificações funcionais do programa [61]. Existem dois passos principais para aplicação de critérios do Teste Funcional [25]: 1. Identificar quais as funcionalidades do software que necessitam ser testadas; 2. Designar quais casos de teste serão utilizados para verificar se as funcionalidades estão de acordo com as especificações funcionais Dentre os critérios mais conhecidos da técnica funcional, estão [18]: 1. Particionamento de Equivalência: divide o domínio de entrada em classes de dados válidas e inválidas de acordo com a especificação da funcionalidade alvo, dos quais os casos de teste podem ser derivados [56]; 2. Análide do Valor Limite: consiste em verificar a capacidade de um programa realizar a manipulação de dados nos limites das condições de entrada [61]; 3. Teste Funcional Sistemático: requer que dois casos de teste sejam criados para exercitar cada classse de equivalência a fim de descobrir as falhas que podem manter escondidas com a execução de um caso de teste singular para um dada classe de equivalência; 4. Grafo de Causa e Efeito: fornece uma representação das condições lógicas e das ações correspondentes, dando subsídios aos testadores à validação dos conjuntos de ações e condições [3]. Entretanto, problemas podem ser identificados na técnica funcional. Vale citar: a dificuldade de quantificação da atividade de teste, porque não se pode ter a certeza de que as partes críticas do programa sejam executadas e; os erros decorrentes de especificação, que são base para derivação dos casos de teste [61]. Outro problema, não menos importante, é a existência de uma dependência dos conhecimentos heurísticos do testador para seleção de bons casos de teste [58] Teste Estrutural O Teste Estrutural é conhecido como caixa branca [46], porque ao contrário do caixa preta, objetiva saber o que está acontecendo dentro da caixa (o programa). Dessa forma, o teste caixa branca complementa o teste caixa preta, pois se preocupa em exercitar e dar cobertura lógica do programa. Portanto, detalhes do código são considerados para derivar casos de teste sendo que os requisitos de teste são estabelecidos com base na implementação do programa [58].

30 2.3 Critérios 27 A maioria dos critérios dessa técnica, em geral, utiliza uma representação de programa conhecida como grafo de fluxo de controle ou grafo de programa [61]. Um programa P pode ser considerado como um conjunto de vários comandos, sendo que um bloco consiste em um conjunto de comandos. A execução do primeiro conjunto de comandos traz como consequência a execução de todos os outros comandos do mesmo bloco, seguindo a sequência de codificação do programa. Com exceção do primeiro e do último comando, cada bloco tem apenas um único predecessor e um único sucessor[10]. A representação desse programa em um grafo de fluxo de controle é o estabelecimento da correspondência entre os nós do grafo com os blocos do programa. Dessa forma, um grafo de fluxo de controle é um grafo orientado que tem um único nó de entrada e saída, sendo que as arestas representam um possível desvio de um bloco para outro [61]. Um caminho completo no grafo de fluxo de controle consiste num caminho que vai do nó de entrada a um nó de saída 2. Por meio do grafo de fluxo de controle, caminhos a serem executados podem ser escolhidos com apoio de diferentes critérios da técnica estrutural. A Figura 2.1 consiste num exemplo de um grafo de fluxo de controle de um código de indentificadores em Java. Figura 2.1: Exemplo de grafo de fluxo de controle adaptado de [25] 2 Outro termo sobre o conceito de caminho no Teste Estrutural é o de caminhos não-executáveis: caminho impossível de ser coberto para qualquer elemento do domínio de entrada.

31 2.3 Critérios 28 Como exemplos de critérios estruturais pode-se destacar: Critérios Baseados em Fluxo de Controle e Critérios Baseados em Fluxo de Dados. Critério Baseado em Fluxo de Controle Os critérios baseado em fluxo de controle realizam um agrupamento de caminhos baseando-se no grafo de fluxo de controle. Dentre os critérios dessa categoria destacam-se [59]: 1. Critério Todos-Nós: Existe a restrição de que cada nó seja executado pelo menos uma vez. Em outras palavras, cada nó n pertecente a N, define-se um conjunto de caminhos 3 CTN n = {K n K}.; 2. Critério Todos-Arcos: Há a restrição que cada arco seja executado pelo menos uma vez. Em outras palavras, para cada arco (n1,n2) pertecente a E, define-se um conjunto de caminhos 4 CTA (n1,n2) = {K (n1,n2) K}; 3. Critério Todos-Caminhos: Neste critério, todos os caminhos possíveis do programa devem ser exercitados. Em geral, esse critério é impraticável, uma vez que, na presença de um laço, o número de caminhos pode ser infinito. Critério Baseado em Fluxo de Dados A classe de critérios baseados em fluxo de dados utiliza informações de fluxo de dados do programa para derivar requisitos de teste. Tais critérios podem ser definidos para o estabelecimento de requisitos de teste com base nas computações realizadas e em como as variáveis do programa são utilizadas [57]. Dessa forma, temos dois conceitos fundamentais para este tipo de critério: 1. Definição de Variável: A variável é definida quando atribui-se um valor a ela; 2. Utilização de Variável: A variável é usada quando seu valor é referenciado. Vale observar que existe uma distinção entre o uso de uma variável em uma computação e em uma expressão de decisão, por exemplo, a condição de um laço [30]; A ideia por trás dessa abordagem está na utilização do valor de uma variável. Por exemplo, se um conjunto de casos de teste não utiliza o valor de uma variável, definida em alguma computação e em uma expressão de decisão, não existem indícios de que tal computação foi realizada de maneira adequada. Logo, os critérios de teste são definidos em função da definição e do uso de variáveis [30]. Valem ser destacados os seguintes critérios: 3 Se um nó n ocorre em um caminho K, então n K[59]. 4 Um arco (n1,n2) pertence a K, se n1 e n2 aparecem consecutivamente em K [59].

32 2.4 Análise de Mutantes Critério Todas-Definições: De acordo com cada definição de uma variável, a seleção de ao menos um caso de teste deve induzir a um caminho livre de definição 5 até um uso dessa variável [57]. 2. Critério Todos-Usos: requer que todas as associações entre uma definição de uma variável e seus subsequentes usos sejam exercitados pelos casos de teste, por pelo menos um caminho livre de definição (um caminho em que a variável não é redefinida) Teste Baseado em Defeitos O teste baseado em defeitos utiliza informações sobre os tipos específicos de defeitos que se deseja revelar e os enganos mais frequentes cometidos no processo de desenvolvimento de software. Dentre os critérios baseados em defeitos, valem ser destacados: Semeadura de Erros e Análise de Mutantes. No critério de Semeadura de Erros uma quantidade conhecida de defeitos é semeada no programa, de maneira artificial. Após a realização do teste, dentre o total de defeitos encontrados, realiza-se a verificação de quais defeitos são naturais e quais são artificiais. Em seguida, o número de defeitos artificiais ainda existentes no programa pode ser calculado por meio de estimativas de probabilidade [61]. Já no critério de Análise de Mutantes um conjunto de programas mutantes P (modificados a partir de um programa original P) são utilizados para avaliar se um conjunto de teste T é adequado para testar o programa P. O objetivo consiste em encontrar um conjunto de teste capaz de revelar as diferenças entre os programas mutantes P e o programa original P. Uma vez que a Análise de Mutantes é o critério utilizado na presente pesquisa, a Seção 2.4 descreverá esta técnica com maiores detalhes. 2.4 Análise de Mutantes Fundamentos A Análise de Mutantes (Mutation Testing) surgiu na década de 1970, na Yale University e Georgia Institute of Technology. Um dos primeiros artigos publicados sobre o Teste de Mutação foi o de DeMillo [20]. Nesse artigo, ele apresenta a ideia central da técnica que está baseada na hipótese do programador competente e no efeito de acoplamento. 5 Um caminho K é livre de definição para uma variável x se x não for definida em K, exceto, possivelmente, nos nós n1 e ni.

33 2.4 Análise de Mutantes 30 A hipótese do programador competente assume que programadores experientes escrevem programas muitos próximos do correto de modo que, assumindo-se a validade dessa hipótese, pode-se dizer que os defeitos são introduzidos no programa por meio de pequenos desvios sintéticos que, embora não causem erros sintáticos, alteram a semântica do programa [61]. Por sua vez, o efeito de acoplamento assume que defeitos complexos estão ligados a defeitos simples e, por isso, a detecção de um defeito simples podem levar a descoberta de defeitos complexos. Assumindo a validade dessas hipóteses, a Análise de Mutantes utiliza um conjunto de programas mutantes P para verificar o quanto um conjunto de teste T é adequado para realizar o teste [20]. Portanto, é possível avaliar o desempenho desse conjunto de casos de teste sobre os programas mutantes tendo como base avaliativa o programa original P. A geração dos programas mutantes é feita por meio dos chamados operadores, responsáveis por modelar os desvios sintáticos mais comuns em determinado contexto. Quando um operador de mutação é aplicado no programa original P, e este possui a estrutura sintática de que o operador de mutação necessita, um conjunto de mutantes P é gerado. Se o programa original e um programa mutante geram saídas diferentes sobre determinado caso teste, este programa mutante é considerado como um mutante morto. O conceito de matar mutantes é a identificação do programa mutante realizada pelo caso de teste na comparação da saída de P com as saídas de P. O Escore de Mutação é um número real que varia entre 0,0 e 1,0 (Equação 2-1). Quanto maior o conjunto de teste, maior o número de mutantes que ele consegue matar e, consequentemente, maior o nível de confiabilidade desses casos de teste. Por meio do cálculo do Escore de Mutação é possível avaliar a qualidade do conjunto de teste T ou de um caso de teste particular que se resume em matar os mutantes não equivalentes. MS(P,T ) = DM(P,T ) M(P) EM(P) (2-1) Onde: DM(P,T ): número de mutantes mortos pelo conjunto de teste em T ; M(P): número total de mutantes gerados; EM(P): número de mutantes gerados equivalentes a P Passos de Aplicação Dado um programa P e um conjunto de teste T cuja a qualidade se deseja avaliar [61], a Análise de Mutantes pode ser aplicada pelos seguintes passos [20]: 1. Geração do conjunto de programas mutantes P 2. Execução de P com T ;

34 2.4 Análise de Mutantes Execução do conjunto P com T ; 4. Análise dos Mutantes Vivos. Nas próximas seções, os passos citados são descritos. Geração dos Programas Mutantes P Para geração do conjunto de programas P são utilizados os operadores de mutação. Os operadores de mutação são os elementos que contêm regras sintáticas responsáveis pelas alterações do programa original P, formando o conjunto de programas mutantes P. A aplicação de um operador de mutação pode gerar mais que um mutante, pois o programa original P pode conter mais de uma estrutura sintática que está no domínio do operador. Dessa forma, o operador, quando aplicado, desempenha ações de mutação sobre cada uma dessas estruturas. A escolha dos operadores de mutação depende da linguagem e do defeito que se deseja modelar [61] 6. A Figura 2.2 mostra exemplos de mutantes: a parte (a) mostra o programa Fibonacci (implementado em linguagem C), as partes (b) e (c) apresentam dois mutantes possíveis de serem gerados: parte (b) um mutante não-equivalente e parte (c) um mutante equivalente. 6 A ferramenta Mothra possui um conjunto de 22 operadores de mutação para programas escritos em linguagem Fortran 77 DeMillo88. Para o teste de programas em linguagem C, em nível de unidade, a ferramenta Proteum contém 71 operadores de mutação e, para essa mesma linguagem, em nível de integração, a ferramenta Proteum/IM possui 33 operadores de mutação [61].

35 2.4 Análise de Mutantes 32 Figura 2.2: Exemplo de programas mutantes (adaptado de [61]). Execução do Programa em Teste P Da mesma forma que nos outros critérios de teste, este passo consiste na execução do programa original P utilizando os casos de teste selecionados. Neste passo, verifica-se o comportamento de P. Se o comportamento do programa for conforme o esperado, executa-se o passo seguinte (Execução dos Programas Mutantes), caso contrário, o processo termina, uma vez que o programa original apresenta resultados incorretos para algum caso de teste. Geralmente, da mesma forma que nas outras técnicas, a tarefa de se decidir se o programa está correto ou não é desempenhada pelo testador [18].

36 2.4 Análise de Mutantes 33 Execução dos Programas Mutantes P Este passo pode ser totalmente automatizado, não requerendo a intervenção do testador [61]. Cada um dos mutantes contidos em P é executado contra os casos de teste de T. Os resultados das execuções dos mutantes são comparados com o resultado da execução do programa original P (saída esperada). Considerando cada mutante individualmente, se o resultado do mutante for diferente de P, este mutante é dito estar morto. Caso contrário, o mutante continua vivo. Um mutante pode continuar vivo por um dentre dois motivos [61]: 1. Ser equivalente ao programa original P; 2. O conjunto de casos de teste selecionado não é adequado o suficiente para distinguir o comportamento entre o mutante e o programa original P. Após a execução dos mutantes, o escore de mutação dos casos de teste pode ser calculado. Análise dos Mutantes Vivos A análise dos mutantes vivos objetiva é uma etapa que objetiva decidir quais dos mutantes vivos são equivalentes ao programa original. Uma vez que a verificação da equiavalência entre dois programas é uma questão indecidível [35], essa é uma etapa que requer maior intervenção humana [18]. Pode-se descrever esta verificação, brevemente, da seguinte forma [61]: 1. Se o programa mutante for equivalente, o mesmo deve ser descartado; 2. Caso não seja, os casos de teste selecionados não foram capazes de diferenciá-lo do programa orginal P. Logo, existe a necessidade de incluir novos casos de teste ao conjunto T para torná-lo mais adequado à realização do teste. Após isso, deve-se voltar ao passo de execução do programa original. Dependendo do número de mutantes gerados, bem como as características do programa em teste, para que a aplicação deste critério seja eficiente, é de fundamental importância o uso de ferramentas computacionais, principalmente na execução e comparação de resultados [61]. A próxima Seção, realiza uma breve descrição de algumas ferramentas que auxilia a aplicação deste critério Ferramentas A partir da primeira ideia sobre Teste de Mutação na década de 70 [20], muitas ferramentas vem sendo desenvolvidas para dar suporte a Análise de Mutantes. A Tabela 2.1 apresenta o histórico de publicações de algumas dessas ferramentas.

37 2.4 Análise de Mutantes 34 Tabela 2.1: Histórico de Publicações de Ferramentas de Teste de Mutação. Tabela adaptada de [35] Nome Aplicação Ano Disponível PIMS Fortran 1977 Não EXPER Fortran 1979 Não CMS.1 Cobol 1980 Não FMS.3 Fortran 1981 Não Mothra Fortran 1987 Não Proteum 1.4 C 1993 Não TUMS C 1995 Não Insure ++ C/C Comercialmente Proteum/IM 2.0 C 2001 Sim Jester Java 2002 Sim Pester Python 2001 Sim TDS Corba IDL 2001 Não Nester C# 2002 Sim JavaMut Java 2002 Sim MuJava Java 2004 Sim Plextest C/C Comercialmente SQLMutation SQL 2006 Sim Certitude C/C Comercialmente SESAME C, Lustre, Pascal 2006 Não ExMAn C, Java 2006 Sim MUGAMMA Java 2006 Sim MuClipse Java 2007 Sim CSAW C 2007 Sim Heckle Ruby 2007 Sim Jumble Java 2007 Sim Testejooj Java 2007 Sim ESPT C/C Sim MUFORMAT C 2008 Não CREAM C# 2008 Não MUSIC SQL(JSP) 2008 Não MILU C 2008 Não Javalanche Java 2009 Sim Gamera WS-BPEL 2009 Sim Mutate-Me PHP 2009 Sim AjMutator AspectJ 2009 Sim JDAMA SQL(JDBC) 2009 Sim

38 2.4 Análise de Mutantes 35 Dentre as ferramentas apresentadas na Tabela 2.1, vale destacar: PIMS e Mothra: A primeira aplicação do teste de mutação foi realizada em Fortran. Os primeiros operadores de mutação foram desenvolvidos para Fortran IV em 1977 e, em consequência desses estudos, foi desenvolvida uma ferramenta nomeada PIMS [8], todavia, os operadores de mutação para Fortran foram formalmente definidos em 1987 [35], em que foram propostos 22 operadores de mutação para Fortran 77 - ferramenta Mothra [38]. Estes conjuntos de operadores de mutação influenciaram definições posteriores de operadores de mutação para outras linguagens [35]. Proteum [16] e Proteum/IM [17] : Foram desenvolvidas no Instituto de Ciências Matemáticas e de Computação - ICMC/USP, a fim de apoiárem os critérios de Análise de Mutantes e Mutação de Interface, respectivamente 7. Mujava e MuClipse: Foi desenvolvida pelo Instituto Coreano de Ciência e Tecnologia (KAIST) e pela Universidade de George Marson [41]. Concebida como uma ferramenta geral de Teste de Mutação, ela suporta todo o processo de mutação empregando Mutação Forte e técnicas de Mutação de Esquemas. Além disso, melhora o comportamento dos operadores de Mutação de Classes e operadores de mutação de Classes Estruturais utilizando a Mutação Seletiva [35]. Já o MuClipse é um plugin do Eclipse que fornece uma ponte entre a ferramenta MuJava e o Eclipse IDE [60]. AjMutator: É uma ferramenta para programas AspectJ com três tipos de operadores: operadores para PCDs (Point Cut Descriptor), para declarações AspectJ e para AspectJ [15]. GAmera: É uma ferramenta de geração automática de programas mutantes para sistemas WS-BPEL baseado em Algoritmo Genético [21]. É composto, basicamente, de operadores de mutação com três diferentes elementos: um analizador, um gerador de mutantes e um sistema que executa e evolui os mutantes. Objetiva minimizar o número de mutantes gerados, independentemente dos operadores, e detectar potenciais mutantes equivalentes. Dentre as ferramentas apresentadas acima, a Protem/IM 2.0 [17] e a Mujava foram utilizadas para geração dos programas mutantes dos benchmarks que fazem parte do Capítulo 5 que descreve a experimentação da presente pesquisa. A atividade de teste pode ser mais eficaz quando exercida com apoio de ferramentas que automatizam algumas etapas. Na Análise de Mutantes não é diferente. Alguns passos desse critério requerem a utilização de ferramentas. Além disso, a utilização de 7 Tanto a Proteum como a Proteum/IM são ferramentas multi-linguagem, porém, atualmente estão configuradas para a linguagem C [61]

39 2.4 Análise de Mutantes 36 ferramentas pode propiciar a condução de estudos empíricos para comparar os diversos critérios de teste existentes [30], uma vez que a interação entre diferentes critérios pode revelar um maior número de defeitos em um software. Outra contribuição que uma ferramenta de teste pode gerar está no contexto do Teste de Regressão. Os casos de teste utilizados anteriormente, durante a vida do software, podem ser novamente utilizados e as funcionalidades do software podem ser revalidadas com as novas alterações que foram feitas no software, bem como o impacto das mudanças que podem ser avaliados comparando o antes e o depois, em termos de alterações efetuadas [61] Aplicabilidade Apesar do Teste de Mutação possibilitar uma boa avaliação de um conjunto de casos de teste, ainda é critério que apresenta problemas acerca de sua aplicabilidade. Um destes problemas consiste na grande quantidade de mutantes que são gerados, pois exige um alto custo computacional na etapa de execução dos programas mutantes pelos casos de teste. Além disso, muitas vezes é necessário aumentar a quantidade de casos de teste para se obter melhores resultados e, de fato, isso implica no aumento do esforço para a realização da atividade de teste. Outro problema enfrentado é o grande esforço humano exigido na verificação da equivalência entre programas. Como a verificação automática da equivalência entre programas é uma questão indecidível, o olhar humano ainda consiste no principal guia desse processo [35]. A solução completa destes problemas ainda não é algo computacionalmente possível, por isso, muitos estudos vêm sendo desenvolvidos em busca de uma maior automatização das etapas do Teste de Mutação, a fim de se obter resultados cada vez mais aceitáveis à viabilização da aplicabilidade do critério. As seções seguintes descrevem alguns trabalhos e estratégias com foco na redução do custo para o emprego da técnica e a detecção de equivalência entre programas. Custo Computacional A redução do custo computacional é um dos grandes alvos de pesquisa no critério do Teste de Mutação. Jia e Harman [35] propõem duas classificações para redução do custo: 1. Redução na geração dos mutantes: consiste na redução do número de mutantes gerados sem perder a efetividade no teste. Podem ser subdivididos em quatro grupos:

40 2.4 Análise de Mutantes 37 Mutação Aleatória (Mutant Sampling): Uma porcentagem X% de cada operador é escolhida aleatoriamente e selecionada para se obter um conjunto P de mutantes sem diminuir a quantidade de operadores utilizados. Mutação por Clusterização (Mutant Clustering): a ideia de mutação por agrupamento foi primeiramente proposta por Hussain [33] em sua dissertação de mestrado. Mutantes são selecionados aleatoriamente utilizando algoritmos de clusterização. Cada mutante em um mesmo cluster tem a garantia de ser morto por um conjunto de casos de teste e apenas um subconjunto de mutantes é utilizado no teste de mutação, os remanescentes são descartados. Mutação Seletiva: A mutação seletiva foi proposta por Mathur [42] e parte do princípio de que a redução do número de mutantes pode ser alcançada com a redução do número de operadores aplicados. O objetivo desta técnica consiste em buscar um pequeno subconjunto de operadores que gera um subconjunto de todas as possibilidades de mutantes sem perder a efetividade no teste [35]. Mutação de Ordem Superior (Higher Order Mutation): este conceito foi introduzido por Jia e Harman [34]. Nesse trabalho, os mutantes foram classificados de duas formas: Mutantes de Primeira Ordem (FOMs - First Order Mutants) e Mutantes de Ordem Superior (HOMs - Higher Order Mutation) 8. Nesta técnica procura-se substituir FOMs por simples HOMs para redução do número de mutantes. 2. Redução na execução dos mutantes: além de reduzir o número de mutantes gerados pode-se também otimizar o processo de execução dos mutantes. Vale destacar algumas técnicas: Mutação Forte e Mutação Fraca: a Mutação Forte é frenquentemente referenciada como mutação tradicional [35], ou seja, a mutação proposta por DeMillo [20], em que um mutante só é considerado morto quando gera saídas diferentes do programa original. Para otimizar a execução da Mutação Forte, William [63] propôs a Mutação Fraca. A Mutação Fraca parte do princípio que um programa pode ser constituído por um conjunto de componentes. A mutação é realizada em cada componente do programa. O programa mutante é checado somente no componente em que houve mutação. Em outras palavras, o mutante não executado completamente, somente no componente que sofreu mutação. Entretanto, a saída do programa pode ser diferente das saídas dos componentes, por isso esta técnica reduz o custo de execução mas pode ser menos efetiva na revelação de defeitos que a Mutação Forte. 8 FOMs são gerados pela aplicação de um operador de mutação uma única vez. Já HOMs são gerados pela aplicação de um operador de mutação mais de uma vez [34].

41 2.4 Análise de Mutantes 38 Técnicas de Otimização do Tempo de Execução: a Técnica de Compilação Integrada foi proposta por Ficici [26] para otimizar as técnicas de compilação tradicionais. Nesta técnica, um compilador instrumental é utilizado para gerar e compilar mutantes que reduz efetivamente o custo redudante de compilação das partes iguais entre os programas mutantes e o programa original. Outra técnica é a Técnica de Tradução do Bytecode [41] em que mutantes são gerados do código-objeto de compilação do programa original de forma que os mutantes podem ser executados diretamente do bytecode sem compilação. A desvantagem desta técnica é que nem todas as linguagens trabalham facilmente com o bytecode, além disso, nem todos os operadores de mutação podem ser representados neste nível [35]. Plataformas de Suporte Avançado ao Teste de Mutação: o teste de mutação também tem sido empregado em novas arquiteturas de computadores para distribuir o custo entre muitos processadores [35], por exemplo, na execução concorrente de mutantes em computadores SIMD (Single Instruction Multiple Data)[40]. O objetivo das técnicas para redução do número de mutantes consiste em gerar um número reduzido de mutantes que tenha grande qualidade. Elas fundamentam-se na possibilidade de identificar um subconjunto pequeno de operadores, de forma que, sendo revelados os defeitos desse subconjunto de mutantes, os defeitos do conjunto total dos mutantes gerados, considerando todos os operadores, também seriam revelados. A esse subconjunto reduzido de operadores é dado o nome de conjunto essencial de operadores e o problema em se determinar tal subconjunto é chamado de suficiência de operadores [47]. No Teste de Mutação, dentre alguns trabalhos que realizaram a determinação do conjunto essencial de operadores vale citar o de Ofutt et al. [48] que obteve apenas 5 operadores de um conjunto de 22 operadores da ferramenta Mothra, preservando um alto índice no escore de mutação. Um estudo realizado por Wong et al. [66] traz indícios de uma forte relação entre os operadores obtidos por Ofuut et al. [48] com os operadores da ferramenta Proteum [16]. Barbosa [7], por sua vez, propõe um procedimento genérico para determinação de um conjunto essencial de operadores de mutação, uma vez que reproduziu os experimentos de Ofuut et al. [48] e Wong et al. [66], com os operadores que esses autores propuzeram, com resultados não satisfatórios [61]. O procedimento proposto por Barbosa [7] embora apresente maior custo, é o que proporciona o maior escore de mutação em relação ao critério Análise de Mutantes se comparado com o conjunto essencial de Wong et al. [66] e o obtido com a estratégia de Offutt et al. [48]. Mais recentemente, Banzi et al. [6], com o objetivo de minimizar conjuntos de programas mutantes e maximizar o escore de mutação, propõe uma abordagem que se

42 2.4 Análise de Mutantes 39 utiliza de algoritmos multiobjetivo para tal. Como resultado, obteve um conjunto essencial de 12 operadores de mutação que proporcionaram alto escore de mutação. Este trabalho também foi aplicado no contexto da linguagem C com a utilização da ferramenta Proteum [17]. A experimentação realizada pela presente pesquisa (Capítulo 5), emprega uma breve análise dos resultados obtidos sob a perspectiva dos operadores de mutação com ênfase no conjunto essencial de operadores obtidos para a linguagem C. Os conjuntos essenciais de operadores de mutação utilizados são os obtidos pelas pesquisas de Barbosa [7] e Banzi et al. [6], considerando os bons resultados que foram obtidos. Equivalência entre Programas A verificação automática entre programas equivalentes é um problema indecidível [35]. Por esse motivo, essa tarefa na análise dos mutantes vivos demanda a intervenção humana. Neste contexto, pesquisas são desenvolvidos para minimizar o impacto dos mutantes equivalentes no Teste de Mutação. No trabalho de Grun [29] é retratada a existência de quatro razões para os mutantes serem equivalentes. A primeira razão afirma que estes mutantes podem ser gerados por códigos desnecessários, ou seja, que não afetam semanticamente a saída em relação ao programa original. A segunda razão é que os mutantes podem melhorar a rapidez do código, o que podemos considerar como uma aspecto positivo, na ótica de evoluir o código. A terceira razão é que estes mutantes somente alteram estados internos. E a quarta razão é que estes mutantes não podem ser acionados. Um agravante, consiste no resultado da pesquisa de Offut [49] constatando que a quantidade de mutantes equivalentes está na faixa de 10 % à 40% dos mutantes gerados. De fato, os mutantes equivalentes não são interessantes no Teste de Mutação, pois, além de aumentar o custo computacional e o esforço humano, não contribuem em nada para a evolução do conjunto de teste. Existem ferramentas de suporte à Análise de Mutantes que objetivam a separação entre os mutantes equivalentes e os mutantes não equivalentes. Este é o caso da ferramenta JAVALANCHE, caracterizada por ser uma ferramenta que utiliza uma abordagem que prioriza a execução de mutantes não-equivalentes [29]. Outro trabalho que tenta evitar os mutantes equivalentes é o de Adamopoulos, Harman e Hierons [1]. Este trabalho propõe a utilização de uma metaheurística como forma de detecção automática de mutantes equivalentes. Devido a forte correlação deste trabalho com a proposta da presente pesquisa, ele será melhor descrito no Capítulo 4.

43 2.4 Análise de Mutantes O que é importante para o Teste de Mutação? Após conhecer os principais conceitos e os problemas do Teste de Mutação, uma pergunta pode ser levantada: o que realmente é importante para o Teste de Mutação? Antes de responder a essa pergunta, vale destacar que o Teste de Mutação objetiva revelar defeitos no programa em teste por meio da evolução do conjunto de teste. Deve-se observar que são os mutantes que determinam a evolução do conjunto de teste. A Figura 2.3 descreve os passos do Teste de Mutação. O primeiro passo consiste na geração dos programas mutantes. No segundo, o conjunto de teste T executa sobre P. Na sequência, T executa todo o conjunto de mutantes P. O quarto passo consiste na avaliação dos mutantes vivos. Nessa etapa, os mutantes equivalentes são identificados e um conjunto de mutantes vivos não equivalentes é formado. Figura 2.3: Evolução do Conjunto de Testes. Além dos quatro passos do Teste de Mutação, a Figura 2.3 também apresenta um quinto passo: a evolução do conjunto de testes. O conjunto de mutantes vivos não equivalentes, formado após o quarto passo, certifica que T ainda não é capaz de revelar todos os defeitos representados pelos mutantes. É necessário evoluir o conjunto T, pois ainda não está totalmente adequado para testar P. Isso significa que novos casos de teste precisam ser incorporados ao conjunto T para que haja um escore de mutação total sobre o conjunto de mutantes não equivalentes, ou seja, para que T seja capaz de revelar todos os defeitos modelados por P no programa em teste P. Pode ser que os passos descritos sejam realizados várias vezes a fim de se chegar no conjunto de teste evoluído (adequado).

44 2.4 Análise de Mutantes 41 Por isso, na Figura 2.3 o conjunto T está representado por T, uma vez que tal conjunto pode variar até que se obtenha um conjnto T evoluído. Diante disso, percebe-se que o conjunto de teste evolui a partir dos mutantes não equivalentes que permaneceram vivos após a primeira execução de T sobre todo P. Nesse mesmo contexto, Offutt [50] afirma que a maioria dos casos de teste consegue matar a maioria dos mutantes. Delamaro, Maldonado e Jino [18] afirmam que em geral, independentemente da qualidade do conjunto de teste T, 80% dos mutantes morrem na primeira execução de T sobre P. Portanto, uma grande quantidade de mutantes que morrem com a maioria dos casos de teste não proporcionam evolução do conjunto de teste. Ao subconjunto de mutantes vivos não equivalentes, representados pelos mutantes vivos não equivalentes da Figura 2.3, [50] os chama de Hard-to-kill, ou seja, mutantes "difíceis de matar". Acerca dessa classe de mutantes, Offutt acredita que são esses mutantes difíceis de matar que conduzem aos casos de teste fortes. Acredita-se que se for obtido o subconjunto de casos de teste que consiga matar os mutantes difíceis, consequentemente, esse subconjuntos matará todos os outros mutantes não equivalentes. Logo, os mutantes difíceis de matar são importantes para o Teste de Mutação porque contribuem na evolução do conjunto de testes. Offutt [50] traz o conceito de tamanho semântico do mutante. Assumindo que o programa em teste P está correto, o tamanho semântico de um mutante P i pode ser definido como o tamanho do conjunto de pontos do domínio de entrada de P que consegue diferenciar as saídas entre P e P i. Em outras palavras, a quantidade de casos de teste que matam P i. Por isso, os equivalentes possuem tamanho semântico igual a zero, uma vez que não há diferença entre sua saída e a saída de P. Dessa forma, os mutantes difíceis de matar possuem um tamanho semântico muito próximo a zero porque poucos casos de teste os matam. Logo, existe uma linha tênue entre a classe dos difíceis de matar, desejáveis para o Teste de Mutação, e os equivalentes que não são importantes para o Teste de Mutação. Dado que: a) uma faixa de 10 % à 40% do conjunto total de mutantes [49] são equivalentes e b) 80% dos mutantes morrem na primeira execução [18]; considera-se que encontrar mutantes difíceis não é uma tarefa fácil. importância: Contudo, no Teste de Mutação, pode-se destacar alguns pontos com grande 1. Selecionar o subconjunto de mutantes difíceis de matar para evolução do conjunto de casos de teste; 2. Selecionar um subconjunto de casos de teste com alta capacidade na revelação de defeitos.

45 2.5 Considerações Finais 42 Pode-se visualizar com maior clareza a importância dos pontos destacados acima, quando insere-se o Teste de Mutação no contexto do Teste de Regressão. Por exemplo, a seleção de um subconjunto s T objetiva a redução de custos. Para isso, s deve ter um tamanho, consideravelmente, menor que T, porém com um escore de mutação igual ou aproximado de todo T. O papel da otimização, nesse processo, consiste em maximizar o escore de mutação do subconjunto s a fim de que tenha um escore igual ou muito próximo de todo T. Portanto, selecionar bons subconjuntos de casos de teste e bons subconjuntos de mutantes pode ser considerado com um problema multiobjetivo da Análise de Mutantes. Nesse contexto, metaheurísticas podem ser utilizadas, por exemplo, na seleção de bons subconjuntos de casos de teste e mutantes para redução de custos da Análise de Mutante no contexto do Teste de Regressão. O objetivo da presente pesquisa consiste em empregar uma busca por mutantes difíceis de matar para que esses contribuam na seleção de um subconjunto de teste. Para isso, a abordagem proposta pela pesquisa consiste em um Algoritmo Genético que coevolui subconjuntos de programas mutantes e casos de teste. A busca explora essa possibilidade de obter casos de teste evoluídos utilizando os mutantes difíceis de matar, ou vice-versa. A abordagem proposta está descrita no Capítulo Considerações Finais Nesse capítulo foi realizada uma breve revisão sobre o Teste de Software. Alguns dos principais conceitos foram apresentados bem como uma explanação suscinta dos seus principais critérios. A Análise de Mutantes foi contextualizada como um dos mais importantes critérios de teste na capacidade de detectar defeitos. O capítulo trouxe uma descrição dos principais fundamentos, fases e dificuldades enfrentadas para aplicação da Análise de Mutantes. Foram pontuados dois grandes problemas enfrentados pelo critério: a grande geração de programas mutantes e a detecção de mutantes equivalentes. Diante disso, algumas das pesquisas que tentam minimizar o impacto gerado por estes problemas foram descritas, porém, evidenciam que tais problemas precisam ter soluções aprimoradas a fim de melhorar a aplicabilidade da Análise de Mutantes. O capítulo também discorreu sobre alguns pontos que são significativos para realizar o Teste de Mutação destacando os mutantes difíceis de matar como importantes para evoluir um conjunto de teste. Portanto, os problemas enfrentados pelo critério foram descritos e os pontos importantes para realização do Teste de Mutação foram destacados para subsidiar a

46 2.5 Considerações Finais 43 compreensão do que é proposto no Capítulo 4 desta dissertação.

47 Search Based Software Testing (SBST) CAPÍTULO 3 O desenvolvimento de modelos, normas e metodologias são algumas das contribuições da Engenharia de Software no desenvolvimento de sistemas. Desde a sua criação, em 1970, essa área de estudo tem gerado grandes avanços à qualidade de software [22]. Entretanto, ainda existem problemas no desenvolvimento de software que ainda não são resolvidos de forma satisfatória [14]. Na Engenharia de Software, é comum a existência de problemas que exijam soluções com restrições e objetivos conflitantes. O trabalho de Harman, Mansouri e Zhang [32] fornece alguns exemplos de problemas dessa área de pesquisa: Qual é o menor conjunto de casos de teste que cobre todos os nós de um programa?; Qual é a melhor forma para estruturar a arquitetura de um sistema?; Qual é o conjunto de requisitos que atinge o menor custo de desenvolvimento do software e satisfação do cliente? Qual é a melhor alocação de recursos para o desenvolver o projeto desse software? Qual é a melhor sequência de etapas de refatoração para aplicar a este sistema? Todos os exemplos citados podem ser modelados matematicamente e se constituem em problemas de otimização cuja as soluções, normalmente, não são possíveis com a aplicação de métodos exatos. Nesse contexto, surge a Search Based Software Engineering (SBSE) como uma área que faz o uso de metaheurísticas para resolver problemas de otimização da área da Engenharia de Software. A SBSE é uma área de pesquisa recente sendo primeiramente proposta por Harman [31] em 2001, embora trabalhos anteriores já houvessem sugerido aplicações de metaheurísticas na Engenharia de Software. O Teste de Software é uma das áreas com maior destaque na SBSE, principalmente pela quantidade de problemas que podem ser modelados e resolvidos a partir de metaheurísticas. Dada a importância e o destaque do Teste de Software na Engenharia de Software, surge a Search-Based Software Testing (SBST) como uma subárea da SBSE que consiste no uso de metaheurísticas para otimizar atividades de teste.

48 3.1 Algoritmos Genéticos 45 A primeira publicação sobre SBST foi a de Miller e Spooner [44], em 1976, que propôs uma abordagem de geração de dados de teste por meio de maximização numérica para entradas em ponto flutuante. Tal publicação também foi o primeiro passo na criação da SBSE. Os AGs, por sua vez, se destacam dentro da SBST como uma importante metaheurística utilizada na resolução de problemas na área de Teste de Software [43]. A abordagem da presente pesquisa, está no contexto da SBST, pois propõe um Algoritmo Genético Coevolucionário (AGC) para selecionar casos de teste e programas mutantes no Teste de Mutação, descrito mais detalhadamente no Capítulo 4. Nesse contexto, o presente capítulo não objetiva apresentar uma vasta revisão sobre todas as metaheurísticas utilizadas na SBST. Este capítulo centra-se em três objetivos principais: a) abordar alguns dos principais conceitos de um Algoritmo Genético (AG); b) descrever a estrutura básica de um AG e; apresentar uma revisão sobre alguns trabalhos que aplicam abordagens coevolucionárias no Teste de Software, com maior foco, no Teste de Mutação. Os objetivos a) e b) são abordados na Seção 3.1 e o objetivo c) é descrito na Seção Algoritmos Genéticos Pesquisas no âmbito da Inteligência Computacional buscam o aprimoramento de formas inteligentes em sistemas computacionais. Uma forte tendência nesta área, consiste na abstração de tais formas em conceitos presentes na natureza. Essa tendência culminou no desenvolvimento formal dos Algoritmos Evolucionários (AEs), dentre os quais são exemplos: a Programação Genética (PG), a Programação Evolucionária (PE) e os Algoritmos Genéticos (AGs). O bom desempenho dessas estruturas biológicas na resolução de problemas difíceis desperta grande interesse por parte dos pesquisadores da área. Esses mecanismos encontrados na natureza tem sido aplicados em diversos tipos de problemas de otimização, merecendo destaque: otimização de funções matemáticas, otimização combinatória, problemas de roteirização, etc. A estrutura básica e modular do AG, bem como seu bom desempenho e fácil adaptação aos problemas, são características que contribuem para sua grande aplicabilidade [37] e destaque entre os AEs Conceitos A primeira ideia de Algoritmo Genético (AG) surgiu com artigos de Holland, no início da década de Inspirado em Darwin (Teoria da Seleção Natural), Holland

49 3.1 Algoritmos Genéticos 46 trouxe conceitos e princípios básicos de sistemas capazes de se adaptarem por meio de interações com seus ambientes de funcionamentos, sistemas adaptativos [36]. Holland acreditava que, da mesma forma que a natureza utiliza a evolução para resolver seus problemas, era possível utilizar uma técnica com característica evolucionária para resolver problemas reais. Tal convicção de Holland, fez com que fosse iniciada uma pesquisa sobre algoritmos que manipulavam strings binárias (composta de 0 s e 1 s) que foram nomeadas por ele de cromossomos. O interessante é que, semelhante à natureza, esses cromossomos não têm nenhum conhecimento sobre o problema e a única informação disponível consiste em suas avaliações que mostram quais são os mais aptos, que tem maiores chances de serem selecionados para reprodução [3]. Dado que os AGs imitam as etapas do processo da evolução natural das espécies, existem algumas analogias entre os AGs e a natureza que implicam em algumas terminologias necessárias ao alcance da abstração, nesse processo. A descrição das principais terminologias e conceitos podem ser visualizadas na Tabela 3.1. Tabela 3.1: Terminologias entre a Natureza e os AGs, adaptado de [37] Natureza Gene Alelo Locus Genótipo Fenótipo Indivíduo População Geração Algoritmo Genético Característica - variável que compõe o cromossomo Valor da característica Posição do gene no cromossomo Cromossomo codificado Cromossomo decodificado Solução do problema Conjunto de soluções (indivíduos) Ciclo Holland propõe o Algoritmo Genético Simples (Simple Genetic Algorithm) podendo ser descrito em seis passos [13]: 1. Inicie a população, de tamanho N, com cromossomos gerados de forma aleatória; 2. Aplique a função de adequação em cada cromossomo desta população; 3. Crie novos cromossomos por meio de cruzamentos de cromossomos selecionados desta população; 4. Elimine membros da população antiga para que se tenha espaço com a finalidade de inserir estes novos cromossomos, mantendo a população com o mesmo número N de cromossomos.

50 3.1 Algoritmos Genéticos Aplique a função de adequação nestes cromossomos e os insira na população. 6. Caso a solução ideal seja encontrada ou, se o tempo (número de gerações) se esgotou, retorne ao cromossomo mais apto. Caso contrário, retorne ao Passo 3. A Figura 3.1 apresenta o fluxo básico de um AG para uma melhor visualização do algoritmo Genético Simples proposto por Holland. Figura 3.1: Fluxo Básico de um AG, adaptado de [37]. Os AGs adotam dois espaços fortemente definidos: espaço de busca e espaço da solução. O espaço de busca refere-se ao espaço formado pelas soluções codificadas (genótipo/cromossomo codificado) para o problema em questão. Por sua vez, o espaço da solução, corresponde às soluções reais (fenótipo/cromossomo decodificado) que são avaliadas pela função de aptidão [11]. Após uma explanação sobre conceitos de um AG, será exposta, com maiores detalhes nas Seções seguintes, uma breve apresentação de alguns dos componentes que formam a estrutura básica de um AG Representação O primeiro estágio da construção de um AG está na definição da sua representação como uma solução candidata para o problema. Este estágio envolve a definição de genótipo e o mapeamento do genótipo para o fenótipo. A escolha da representação correta é um processo de extrema importância. Na Figura 3.2 pode-se diferenciar genótipo de fenótipo. O genótipo é a cadeia de bits, e o par (X,Y) é o fenótipo.

51 3.1 Algoritmos Genéticos 48 utilizadas. Nas seções seguintes, serão mostradas três das representações mais comumente Representação Binária A representação binária é um dos tipos mais utilizados, por ser de fácil implementação e gerar bons resultados em diferentes problemas. Neste tipo de representação os cromossomos são constituídos por cadeias binárias compostas de 0s,1s. Um exemplo de representação binária pode ser ilustrada na Figura 3.2 em que os três primeiros genes representam a variável X e os dois últimos a variação Y. Figura 3.2: Representação Binária, adaptada de [37]. Representação Inteira A representação binária nem sempre é a mais adequada. O problema pode ser naturalmente mapeado para um conjunto de valores, por exemplo, a necessidade de se desenvolver um caminho em uma grade quadrada, sendo que a restrição dos valores sejam os números: 0, 1, 2 e 3. Neste caso, a representação inteira é mais adequada que a binária. Segundo Barcellos [13], quando os parâmetros de codificação são inteiros a representação é direta. Representação Real A representação real facilita o trabalho de variáveis contínuas e, pelo fato dos alelos e os genes serem números reais, é necessário realizar uma implementação específica dos operadores genéticos [37]. O genótipo para uma implementação com uma solução com k genes é um vetor (x 1,..., x k ), tal que x i pertence ao conjunto de números reais. Em parâmetros de codificação com valores reais, uma estratégia a ser adotada consiste em trabalhar com valores inteiros. Por exemplo, se houver variação de um parâmetro entre [2.12 a 15.72] com duas casas decimais de precisão, pode-se multiplicar esses valores por 100 e utilizar a parte inteira do produto [13].

52 3.1 Algoritmos Genéticos População Inicial Os cromossomos são as possíveis soluções do problema e juntos formam a população. A população inicial é o ponto de partida para um AG. Camilo-Junior [37] ratifica que uma população diversificada gera uma maior probabilidade de encontrar um bom resultado, pois ela inicia com um amplo espaço de busca. Camilo-Junior [37] apresenta algumas das várias abordagens existentes para geração de população inicial: 1. Geração Aleatória: é atribuído um valor gerado aleatoriamente a cada gene do cromossomo no escopo de um domínio estabelecido; 2. Geração por Otimização anterior: o foco desse método está na reutilização de soluções já encontradas. Consiste na insecção de soluções anteriores encontradas na população inicial, podendo estas soluções serem de outros algoritmos externos ou pelo próprio AG; 3. Geração por Conhecimento avançado: este método exige conhecimento prévio do problema, pois ele consiste na insecção de possíveis soluções do problema já na população inicial; 4. Geração Heurística: utiliza-se de informações disponíveis e de uma função orientadora que são melhoradas para compor a população inicial; 5. Geração Complementar: a geração dos dados é aleatória, porém, o que acontece é que uma metade recebe estes dados gerados e a outra metade recebe a inversão dos dados da primeira metade da população; 6. Geração Híbrida: é a geração de uma população utilizando mais de uma abordagem, por exemplo, uma população gerada pela combinação das abordagens conhecimento e otimização. A construção de uma população inicial exige um cuidado no parâmetro que define o tamanho da população, pois deve ser adequado ao problema. Uma população pequena demais pode estagnar a evolução da população e, ao contrário, uma população grande demais pode tornar o processo de evolução lento [3]. Camilo-Junior [37] ratifica o cuidado com os métodos utilizados para não gerar indivíduos inválidos na população inicial Avaliação As regras da função de avaliação servem para apresentar requisitos de adaptação. Ela forma a base da seleção contribuindo para uma melhoria significativa da qualidade das soluções no contexto evolucionário [23]. Cada indivíduo passa pela função de avaliação que verifica sua aptidão para solucionar o problema.

53 3.1 Algoritmos Genéticos 50 Nos AGs também existem associações entre um valor numérico de adaptação para que se conheça o seu grau de utilidade ou habilidade, em relação à sua função objetivo [3]. A função de avaliação pode possuir, por exemplo, como valor de entrada uma cadeia de bits e gerar um valor real como saída. Dessa forma, espera-se associar, através da função de avaliação, o grau de resistência e de adaptabilidade do indivíduo. Barcellos [13] afirma que é necessário ter um mecanismo para avaliar a distância que um cromossomo está da solução e, dependendo da complexidade do problema, este processo pode não ser exato Seleção A Seleção é um dos principais operadores dos Algoritmos Evolucionários (AEs) e, consequentemente, dos AGs. Este operador é importante, pois ele tende a selecionar, dentre toda a população, os indivíduos com boa aptidão, a fim de gerar descendentes no processo de evolução. Nesse processo, os mais aptos têm mais chances de serem selecionados como progenitores. Este fenômeno recebe o nome de pressão de seleção. Quanto maior a pressão de seleção maior a busca em torno das melhores soluções. Uma pressão de seleção muito baixa pode levar a uma busca que acompanhe a tendência genética da população e perder a orientação na busca pelas melhores soluções. Por outro lado, uma pressão alta pode ocasionar uma convergência prematura do algoritmo [37]. Existem vários operadores de seleção desenvolvidos para AEs: Seleção por Pressão, Seleção Aleatória, Seleção Proporcional, Seleção por Torneio, Seleção por Classificação, Seleção Boltzmann, Elitismo e Corredor da Fama [24]. A Roleta é um operador de seleção proporcional e, dentre os operadores existentes, é o mais utilizado. Neste operador de seleção, cada indivíduo ocupa um espaço na roleta, conforme sua aptidão. Um número é sorteado (a roleta gira) e o indivíduo selecionado é aquele cuja a faixa engloba o número sorteado. Sendo assim, este indivíduo comporá o conjunto de pais selecionados para o cruzamento. Embora o método da roleta seja o mais utilizado, ele também apresenta problemas, por exemplo, o algoritmo pode ter uma convergência prematura [37] se uma solução predominar consideravelmente sobre as outras logo nas populações iniciais. Uma alternativa, muito usada é o método chamado Torneio. Neste método, um grupo de n ts indivíduos são selecionados, de forma que n ts < n s, sendo que n s é a população. Geralmente, n ts é um número pequeno. Dessa forma, a pressão de seleção sobre as melhores soluções é mais baixa que no método da roleta, uma vez que o grupo n ts é escolhido considerando toda a população e as chances de uma solução ruim ser

54 3.1 Algoritmos Genéticos 51 selecionada aumentam [24]. A intenção desse método, consiste em selecionar aquelas soluções que podem ser ruins no todo, mas que tem partes boas, além de manter um grau de diversidade Cruzamento A criação de descendentes é um processo que ocorre após a seleção por meio do código genético dos progenitores. A finalidade é que indivíduos com maior qualidade genética sejam criados. No processo de recombinação, os indivíduos progenitores são selecionados e recombinados com a probabilidade de cruzamento (pc). Na sequência, um número aleatório r é gerado. Se r > pc, a recombinação não é realizada e os filhos são cópias dos pais. Caso contrário, se r < pc, os indivíduos selecionados são recombinados [37]. A representação e a escolha do operador de cruzamento devem caminhar juntas, pois o operador de cruzamento deve ser adequado à representação escolhida. Um exemplo de cruzamento, é o cruzamento de um ponto, que pode ser facilmente generalizado para um cruzamento de n pontos quando mais de dois pedaços contínuos de genes são quebrados em mais de um ponto na representação cromossômica [23], geralmente utilizado na representação binária. A Figura 3.3 apresenta três diferentes tipos de cruzamentos, cuja a diferença está na formação dos filhos pela quantidade de pontos de corte obtidos por meio de uma máscara binária. Figura 3.3: Diferentes tipos de Cruzamento, adaptado de Camilo- Junior [24]. O cruzamento uniforme é o que pode possuir maior troca de informações entre os pais na formação dos filhos. Os filhos são criados considerando toda a máscara binária que possui o mesmo tamanho dos pais. Cada descendente assume o valor do pai ou da mãe se o valor da máscara for zero ou for um, conforme regra estabelecida. Diferentemente

55 3.2 Algoritmos Coevolucionários 52 do cruzamento de um ponto e dois pontos, no qual os filhos são formados pela troca de informações dos pais limitadas na quantidade de cortes Mutação A mutação auxilia na introdução de um novo material genético dentro de um indivíduo existente que, por sua vez, adiciona uma variedade de características genéticas na população. A mutação é usada para apoiar o cruzamento e assegurar que toda uma variedade de alelos esteja acessível para cada gene [24]. O operador de mutação, diferentemente do operador de cruzamento, pode ser aplicado em um único cromossomo. Tal aplicação pode ser realizada antes ou depois do cruzamento. A Figura 3.4 apresenta dois operadores de mutação. Figura 3.4: Dois tipos de operador de Mutação, adaptado de [37]. 3.2 Algoritmos Coevolucionários O conceito de coevolução em CE é inspirado na natureza. Basicamente, pode ser definida como uma evolução complementar de espécies associadas, em que organismos sugeridos - por exemplo, predadores e presas, hospedeiros e parasitas - influenciam na evolução dos outros. A coevolução requer que cada uma das espécies em interação mude sua composição genética adaptativa em resposta a uma(s) mudança(s) na(s) outra(s). São duas as classes principais de coevolução: coevolução competitiva e cooperativa [24]. Pode-se diferenciar tais classes olhando-se para as coevoluções que ocorrem na natureza. Por exemplo, a coevolução por Competição e por Mutualismo. Em coevoluções por competição, as respostas evolutivas à competição pode conduzir a uma divergência no uso de um recurso. Nesse tipo de coevolução, se uma espécie A estiver isolada de uma espécie competidora B, a espécie A poderia expandir sua dieta (ou recurso). Por exemplo, uma ilha onde há populações de pássaros e outras espécies.

56 3.2 Algoritmos Coevolucionários 53 Geralmente, com uma diversidade de espécies menor, haverá menos competições e uma maior variedade de alimentos [12]. No contexto da CE, Engelbrecht [24] diz que as espécies se inibem. Ou seja, as funções de aptidões são inversas entre as populações, de modo que o sucesso de uma população implica no fracasso da outra. Já as coevoluções por mutualismo são diferentes. Espécies que interagem mutualisticamente não contribuem propositalmente com o sucesso recíproco. Na verdade, exploram uma a outra como recurso. A seleção favorece genótipos que beneficiam outra espécie se essa ação retorna benefícios [12]. Um exemplo de mutualismo é a relação da anêmona do mar e o caranguejeiro paguro. Esse caranguejo tem o hábito de viver em conchas abandonadas de moluscos. As anêmonas, por sua vez, se instalam nessas conchas e com seus tentáculos afugentam os predadores, conferindo uma maior proteção ao caranguejo. Por outro lado, os caranguejos oferecem um passeio para as anêmonas que vivem presas em rochas. Tal passeio expande o raio de ação alimentar das anêmonas [45]. Algoritmos Coevolucionários são métodos de busca com processos de mútuas adaptações ocorrendo entre agentes que interagem estrategicamente. O resultado dessa interação revela a estrutura que guia a evolução, uma vez que esta interação aumenta os comportamentos adaptativos entre os agentes [26]. A utilização de Algoritmos Coevolucionários exigem um conhecimento prévio do domínio da aplicação. Neste sentido, Ficici [26] destaca três pontos de aprendizagem inerentes ao Algoritmo Coevolucionário: Descobrir os comportamentos dos agentes; Aprender a estrutura de premiação do domínio (valor da aptidão); Aproximar-se de uma solução ótima. Outro exemplo de coevolução competitiva é o dado por Engelbrecht [24]: A planta necessita evoluir um mecanismo de defesa para sobreviver aos insetos predadores; Os insetos precisam das plantas como fonte de alimento; Nesse processo coevolucionário, as plantas e os insetos, em cada geração, melhoram suas regras ofensivas e defensivas. Tal interação entre as espécies, faz com que as próximas gerações recebam informações genéticas das gerações anteriores. Portanto, um indivíduo em um algoritmo coevolucionário somente conseguirá evoluir por meio da sua interação com membros de outras populações associadas à sua espécie. Considerando que cada população contém indivíduos que resolvem um dado problema para o alcance de um objetivo, duas populações em coevolução, é uma abordagem multiobjetivo de lidar com problemas que requerem soluções associadas.

57 3.3 Considerações Finais Aplicações no Teste de Software Muitos problemas da Engenharia de Software podem ser otimizados por meio de um modelo coevolutivo no qual uma ou mais populações podem coevoluir com outra. Por exemplo: componentes, agentes, modelo comportamental dos envolvidos (stakeholders), modelos cognitivos, requisitos, casos de teste, casos de uso, planos de gerenciamento de projetos, etc [32]. Algumas pesquisas utilizam a coevolução para otimizar atividades do Teste de Software. Arcuri e Yao [4] aplicam a coevolução no desenvolvimento do primeiro arcabouço para gerar programas genéricos de suas especificações. Utilizam a Programação Genética (PG) para evoluir programas e ao mesmo tempo exploram as especificações para coevoluir conjuntos de testes de unidade. Outro trabalho de Arcuri e Yao [5] descreve um algoritmo capaz de detectar defeitos de implementação que são, automaticamente, corrigidos de modo que programas e casos de teste coevoluam. Já Wilkerson e Tauritz [62] apresentam o sistema Coevolutionary Automated Software Correction (CASC) objetivando automatizar um ciclo que compreende o teste de artefatos de software, local do defeito e fases de correção, coevoluindo artefatos de software e casos de testes. Adamopoulos, Harman e Hieron [1] propõem uma abordagem coevolucionária cuja a finalidade é detectar possíveis mutantes equivalentes. Neste trabalho, uma função objetivo penaliza possíveis mutantes equivalentes. Durante o processo coevolucionário entre populações de programas mutantes e casos de teste, somente mutantes difíceis de matar e casos de teste com alto escore são selecionados. Entre os trabalhos apresentados, a abordagem de Adamopoulos, Harman e Hierons [1] é a mais similar com a proposta da presente pesquisa. Comparando as abordagens, existem dois objetivos em comum: selecionar bons subconjuntos de programas mutantes e bons subconjuntos de casos de teste com coevolução (uma espécie evolui em detrimento da outra) para o Teste de Mutação. Entretanto, existem diferenças que são detalhadas na Seção 5.2.1: 3.3 Considerações Finais De forma breve, este capítulo discorreu sobre alguns aspectos conceituais sobre AG. A compreensão desses conceitos pode fornecer subsídios para aplicações em problemas reais, não somente no escopo da Engenharia de Software, mas também nas mais diversificadas áreas de aplicação dessa metaheurística.

58 3.3 Considerações Finais 55 Uma vez que a característica coevolucionária faz parte da proposta da presente pesquisa, uma revisão sobre aplicações de algoritmos coevolucionários para otimização de problemas da área de Teste de Software também foi apresentada. Por meio dessa revisão, foi encontrado apenas um trabalho que propõe a aplicação de um algoritmo coevolucionário na Análise de Mutantes. No Capítulo 4 a abordagem proposta pela presente pesquisa é descrita e no Capítulo 5 a abordagem proposta é comparada a outros cinco métodos, sendo o algoritmo proposto por Adamopoulos, Harman e Hierons [1]] um desses métodos.

59 CAPÍTULO 4 O Algoritmo Genético Coevolucionário (AGC) Coforme já descrito, a coevolução pode ser utilizada para modelar vários problemas de otimização da Engenharia de Software. Considerando as possibilidades do uso dessa metaheurística bem como sua pouca exploração no Teste de Mutação, a abordagem dessa pesquisa consiste em propor um Algoritmo Genético Coevolucionário (AGC) dando uma solução multiobjetivo para o Teste de Mutação. A Seção 4.1 descreve o algoritmo proposto; já a Seção 4.2 explica a representação proposta; a função de aptidão proposta é descrita na Seção 4.3 e; por fim, os operadores genéticos desenvolvidos são apresentados na Seção Descrição do Algoritmo O Algoritmo Genético Coevolucionário (AGC) 1 coevolui duas populações, uma de casos de teste e a outra de programas mutantes. A Figura 4.1 ilustra o ambiente coevolucionário do AGC, representado pelo Algoritmo 4.1, que realiza os seguintes passos: 1. Inicialização das Populações: Consiste na função inicializarpopulações() do Algoritmo 4.1. Inicialmente, as duas populações são geradas, aleatoriamente, considerando os conjuntos de teste e programas mutantes, respectivamente. Cada população tem um tamanho fixo para formar os indivíduos, conforme estabelecido pelos parâmetros de entrada do AGC; 2. Cálculo da Aptidão das Populações: Consiste na função avaliaraptidões() do Algoritmo 4.1: Seleção do melhor Indivíduo (Melhor IndMT): Consiste na função selecionarmelhorindmt() da função avaliaraptidões(). Na primeira geração, um indivíduo da população de programas mutantes é escolhido 1 A proposta do AGC foi primeiramente publicada no Congresso de Computação Evolucionária (2013 IEEE Congress on Evolutionary Computation - CEC) que aconteceu no período de 20 à 23 de Junho, em Cancum no México.

60 4.1 Descrição do Algoritmo 57 aleatoriamente como o melhor IndMT. A partir da segunda geração, o melhor IndMT é o indivíduo de maior escore da geração anterior. Após selecionar o melhor IndMT, os genes desse indivíduo passam a compor o subconjunto MelhoresIndMT, que armazena os genes não repetidos dos melhores IndMT de cada geração. Cálculo da Aptidão dos Indivíduos da População de Casos de Teste: Consiste na função interarindmtxpoptc() da função avaliaraptidões(). Para cada indivíduo, aplicam-se os casos de teste sobre todos os mutantes contidos em MelhoresIndMT. Em outras palavras, os casos de teste do indivíduo executam sobre o programa original e os programas mutantes do melhor IndMT comparando suas respectivas execuções. Em seguida, sua Classificação Genética é realizada e sua aptidão é calculada baseando-se no escore de mutação, conforme Seção 4.3. A Classificação Genética é representada pela função classificargeneticamente() do Algoritmo 4.1 e está descrita na Seção 4.2. Seleção do melhor Indivíduo (Melhor IndTC): Consiste na função selecionarmelhorindtc() da função avaliaraptidões() que seleciona o melhor IndTC da população de casos de teste. Após selecionar o melhor IndTC, os genes desse indivíduo passam a compor o subconjunto MelhoresIndTC que armazena os genes não repetidos dos melhores IndTC de cada geração. Cálculo da Aptidão dos Indivíduos da População de Programas Mutantes: Consiste na função interarindtcxpopmt() da função avaliaraptidões(). Para cada indivíduo, os programas mutantes são executados por todos os casos de teste em MelhoresIndTC que realizam a comparação das execuções sobre os mutantes com as respectivas execuções do programa original. Posteriormente, aplica-se a Classificação Genética e calcula-se a aptidão dos indivíduos da população de mutantes, conforme descrita na Seção Condição de Parada do AGC: Caso o AGC atinja o limite de gerações estabelecido pelos parâmetros de entrada, sua execução é interrompida retornando como saída os melhores indivíduos das populações (melhor IndTC e o mellhor IndMT). Caso contrário, o AGC continua a execução n do Passo 4, descrito em seguida; 4. Operador de Seleção: Consiste na função selecionar() do Algoritmo 4.1 que seleciona os pais para o cruzamento utilizando o operador de seleção torneio; 5. Operador de Cruzamento: Consiste na função cruzar() do Algoritmo 4.1 que gera os filhos conforme operador de cruzamento Filho Efetivo (FE), descrito na Seção 4.4.1;

61 4.1 Descrição do Algoritmo Operador de Mutação: Consiste na função mutar() do Algoritmo 4.1 que realiza a mutação conforme operador de mutação Muta Gene (MG), descrito na Seção 4.4.2; 7. Substituição: Consiste na função substituir() do Algoritmo 4.1. Nessa função, os filhos gerados substituem as populações mantendo os melhores indivíduos (melhor IndTC e melhor IndMT) que passam para a próxima geração. Dessa forma, implementa-se o elitismo de um indivíduo. Posteriormente, o passo 2 é executado como uma nova geração, repetindo todo o processo. Algoritmo 4.1: Algoritmo Genético Coevolucionário (AGC). inicializarpopulações() geração=1; while (geração <= limitegerações) do function AVALIARAPTIDÕES() selecionarmelhorindmt() interarindmtxpoptc() selecionarmelhorindtc() interarindtcxpopmt() classificargeneticamente() calcularaptidões() end function selecionar() cruzar() mutar() substituir() geração++; return melhoresindividuos() Um ponto que merece ser destacado, consiste no fato de que, em cada geração, os subconjuntos MelhoresIndTC e MelhoresInd (Figura 4.1) são atualizados com os genes não repetidos do melhor indivíduo de cada população. Tais subconjuntos têm a funcionalidade de uma memória com as melhores informações genéticas visando a evolução da população por meio dos melhores indivíduos. Espera-se que ao final da execução do AGC sejam encontradas boas soluções, um subconjunto de casos de teste que mate o maior número de mutantes e um subconjunto de programas mutantes que evite ser morto pelo maior número de casos de teste, não contendo nenhum mutante equivalente.

62 4.2 A Representação de Indivíduo e a Classificação Genética (CG) 59 Figura 4.1: Fluxograma do ambiente coevolucionário do AGC. Nas seções seguintes, estão descritas a representação dos indivíduos das populações, as funções de aptidão e os operadores desenvolvidos que integram o funcionamento do AGC proposto. 4.2 A Representação de Indivíduo e a Classificação Genética (CG) Um mapeamento de possibilidades genotípicas de indivíduos foi criado no contexto do Teste de Mutação com o objetivo de desenvolver uma Classificação Genética (CG). Para tal, este trabalho adota o indivíduo como sendo um subconjunto de casos de teste, na população de casos de teste, ou um subconjunto de programas mutantes, na população de mutantes. Além disso, foram estabelecidas características genotípicas para ambas populações. Um indivíduo da população de casos de teste pode conter as seguintes características em seus genes: Gene (GE): é um caso de teste de um subconjunto (o indivíduo); Gene Efetivo (GEF): é o caso de teste que mata no mínimo um programa mutante que outro caso de teste, contido no mesmo subconjunto, não mata. Em outras

63 4.2 A Representação de Indivíduo e a Classificação Genética (CG) 60 palavras, consiste no caso de teste que contribui para o aumento da aptidão do indivíduo (aumento do escore de mutação do subconjunto); Gene Não-Efetivo (NEF): é o caso de teste que não consegue matar nenhum mutante. Ou seja, é o caso de teste que não contribui no escore de mutação em nenhum subconjunto; Gene Redundante (GRE): é o caso de teste que mata somente mutantes que, no mínimo, um caso de teste, contido no mesmo subconjunto, já conseguiu matar. Ou seja, é o caso de teste que não contribui no escore de mutação no indivíduo. Já um indivíduo da população de programas mutantes, pode conter as seguintes características: Gene (GE): é um programa mutante de um subconjunto (o indivíduo); Gene Efetivo (GEF): é o programa mutante que evita ser morto por no mínimo um caso de teste que outro programa mutante, contido no mesmo subconjunto, não evitou ser morto. Em outras palavras, consiste no mutante que contribui para o aumento da aptidão no indivíduo; Gene Não-Efetivo (NEF): é o programa mutante que morre com todos os casos de teste. Ou seja, não contribuirá no aumento da aptidão de nenhum indivíduo da população de mutantes; Gene Redundante (GRE): é o programa mutante que somente evita ser morto por casos de teste que um outro programa mutante, contido no mesmo subconjunto, já evitou ser morto. Ou seja, é o mutante que não contribui para o aumento da aptidão no indivíduo; Gene Possivelmente Equivalente (GEQ): é o programa mutante que evita ser morto por todos os casos de teste. Essas características genotípicas apresentadas configuram o conceito de Efetividade Genética. Considerando essa definição, o AGC proposto realiza a CG por meio dos seguintes passos: 1. Classificação do gene mais efetivo: para cada indivíduo da população de casos de teste, atribui-se GEF para o gene que mata o maior número de mutantes. Para cada indivíduo da população de programas mutantes, atribui-se GEF para o gene que evitar ser morto pelo maior número de casos de teste; 2. Classificação do próximo gene efetivo: para cada indivíduo da população de casos de teste, atribui-se GEF para o alelo que mata o maior número de mutantes não mortos pelo grupo já classificado como GEF. Para cada indivíduo da população de programas mutantes, atribui-se GEF para o gene que evitar ser morto pelo maior número de casos de teste não evitados pelo grupo já classificado como GEF. Este passo se repete até que não haja mais genes efetivos;

64 4.2 A Representação de Indivíduo e a Classificação Genética (CG) Classificação dos outros tipos de genes: para cada indivíduo das populações, atribui-se os genes GRE, NEF e GEQ, caso se aplique. Figura 4.2: A) Indivíduo da população de casos de teste (IndTC) e B) indivíduo da população de programas mutantes (IndMT). A Figura 4.2 apresenta um exemplo de indivíduos com integrantes das duas populações: IndTC é o indivíduo da população de casos de teste com tamanho igual a 4, sendo apenas o segundo gene, de alelo 91, um gene efetivo (GEF); IndMT é o indivíduo da população de programas mutantes com tamanho igual a 5, sendo os genes com alelos 167 e 856 considerados genes efetivos (GEF). Além disso, o gene com alelo 975 é um gene possível equivalente (GEQ). A Classificação Genética incorporada à representação de indivíduo, descrita acima, define o conceito Efetividade Genética para o Teste de Mutação no contexto de Algoritmos Evolucionários. Em termos práticos, o objetivo da Efetividade Genética consiste na formação de boas seleções de subconjuntos para o emprego do Teste de Mutação. O objetivo consiste em formar indivíduos que sejam efetivos a fim de cada gene possa contribuir para o aumento da aptidão do indivíduo. Pode-se ilustrar o conceito da Efetividade Genética da seguinte forma: seja, s um subconjunto de casos de teste que constitui os genes de um indivíduo da população de casos de teste. Um caso de teste i s se e somente se mut i MUT > MUT, tal que mut i é o conjunto de mutantes mortos pelo caso de teste i e MUT é conjunto de mutantes mortos pelos casos de teste contidos em s.

65 4.2 A Representação de Indivíduo e a Classificação Genética (CG) 62 Figura 4.3: Exemplos de seleções com o emprego do conceito de Efetividade Genética pelo AGC. O IndTC é selecionado considerando um conjunto de casos de teste. Por sua vez, o IndMT é selecionado considerando um conjunto de programas mutantes. Espera-se que o AGC selecione um IndTC que tenha escore máximo. O papel da Classificação Genética consiste em selecionar um subconjunto em que cada caso de teste seja capaz de matar mutantes diferenciados no conjunto total de mutantes. Por exemplo, selecionar somente os casos de teste do tipo GEF (19, 23, 34, 88 e 91), conforme ilustrado na Figura 4.3. Não interessa a seleção dos casos de teste do tipo GRE (67 e 92) e NEF (21), pois esses não contribuem no escore do indivíduo. De forma análoga, espera-se que o AGC selecione um IndMT que tenha escore máximo, considerando o escore como a capacidade de um mutante em evitar ser morto por casos de teste. Nesse caso, o papel da Classificação Genética consiste em selecionar um subconjunto em que cada mutante seja capaz de evitar ser morto por casos de teste diferenciados no conjunto total de casos de teste. Por exemplo, selecionar somente os mutantes do tipo GEF (12, 27, 29 e 65), conforme ilustrado na Figura 4.3. Não interessa a seleção dos mutantes do tipo GEQ (02), GRE (04) e NEF (87 e 93). Dessa forma, a Efetividade Genética está em conformidade com a função de maximização para seleção de casos de teste (descrita no Capítulo 2), pois atende à restrição em que um caso de teste somente pode pertencer ao subconjunto s, se e somente se, esse elemento matar mutantes diferenciados dos já mortos por s. Tal característica, também pode ser transferida para os mutantes de um subconjunto de mutantes, porém, no sentido de evitar casos de teste.

66 4.3 Funções de Aptidão Funções de Aptidão Considerando IndTC um indivíduo da população de casos de teste e IndMT um indivíduo da população de programas mutantes, sendo que Stc e Smt são as medidas de aptidão de IndTC e IndMT, respectivamente, o cálculo de Stc e Smt estão descritos nas Equações 4-1 e 4-2. Onde: Stc = QMT M(P) QMT : quantidade de mutantes mortos pelos genes efetivos de IndTC; M(P): total de mutantes gerados a partir do programa P. (4-1) Onde: Smt = { QTC T (P) i f p i GEQCC p i CIndMT 0 otherwise. (4-2) QTC: quantidade de casos de teste evitados pelos genes efetivos de IndMT ; T (P): total de casos de teste gerados para testar o programa P. A interação (realização dos testes) da coevolução proposta é realizada entre os melhores indivíduos e a população oposta. Diante disso, observa-se que a quantidade total possível de mutantes mortos pelos genes efetivos de IndTC será o tamanho do subconjunto de mutantes contidos na lista MelhoresIndMT. De forma análoga, a quantidade total possível de casos de teste evitados pelos genes efetivos de IndMT será o tamanho do subconjunto de caos de teste contidos na lista MelhoresIndTC. Entretanto, para um indivíduo da população de casos de teste, espera-se que se um indivíduo conseguiu matar os melhores, ele conseguirá ter um escore elevado, quando for considerado todo o conjunto de programas mutantes. Analogamente, caso um indivíduo da população de mutantes consiga evitar os melhores casos de teste, ele conseguirá evitar todos os outros do conjunto total de casos de teste. Além disso, a penalização proposta na Equação 4-2, realiza-se quando o gene é classificado como do tipo GEQ. Ou seja, a Equação 4-2 emprega uma penalização por gene e não por indivíduo 2. Em termos práticos, é possível descobrir se um indivíduo contém um gene do tipo GEQ quando se satisfaz duas características: 1. a quantidade de genes efetivos do indivíduo é igual a 1 e; 2 A interação bem como a penalização da abordagem da presente pesquisa, difere-se da abordagem proposta por Adamopoulos, Harman e Hierons [1], que será mais detalhada na Seção

67 4.4 Operadores Genéticos o gene não foi morto por nenhum caso de teste. Quando o gene do indivíduo possui essas duas características, entende-se que ele tem grandes chances de ser equivalente. Sendo assim, esse gene não vai ser considerado na seleção do indivíduo e vai ser penalizado pelo operador de mutação Muta Gene (MG), conforme descrito na Seção Operadores Genéticos Foram desenvolvidos dois operadores genéticos: o operador de cruzamento Filho Efetivo (FE), e o operador de mutação Muta Gene (MG). Espera-se que os operadores propostos melhorem a busca coevolucionária por boas soluções Operador de Cruzamento Filho Efetivo (FE): (FE). A Figura 4.4 ilustra o funcionamento do operador de cruzamento Filho Efetivo Figura 4.4: Exemplo de fucionamento do operador de cruzamento Filho Efetivo (FE). O operador FE utiliza o código genético das soluções a fim de construir soluções genéticas mais efetivas e pode ser descrito por meio de dois passos: 1. Dois indivíduos são selecionados como pais, por meio do operador de seleção, e formam um único filho;

68 4.5 A Classificação Genética Controlada (CGC) Uma nova Classificação Genética é aplicada sobre os genes dos pais, gerando um filho com efetividade superior ou igual a de seus pais. Conforme Figura 4.4, somente os genes do tipo GEF são considerados na Classificação Genética no operador ES. Dentre os genes do pai, foram considerados os genes 2 e 78. Dentre os genes da mãe, foram considerados os genes 27, 53 e 93. Foi gerado somente um filho com os seguintes genes: 2, 78, 27 e 93. Por definição, a aptidão desse filho gerado é superior às aptidões dos seus pais Operador de Mutação Muta Genes (MG): A Figura 4.5 ilustra o funcionamento do operador de mutação Muta Gene (MG). Figura 4.5: Exemplo de fucionamento do operador de mutação Muta Gene (MG). O operador de mutação Muta Gene (MG) objetiva estabelecer uma mutação com menor taxa nos genes do tipo GEF, e uma maior taxa nos outros tipos de genes. Foi fixada, para este operador, uma taxa mutação de 100% nos genes do tipo NEF, GRE e GEQ (para os indivíduos da população de mutantes). Por outro lado, a mutação nos genes do tipo GEF obedeceu a taxa de mutação estabelecida nos parâmetros (5%). Contudo, o objetivo do operador de mutação MG consiste em favorecer a permanência das boas informações nas gerações posteriores. 4.5 A Classificação Genética Controlada (CGC) A Classificação Genética (CG) implementa o conceito de Efetividade Genética, descrita na Seção 4.2. Um aspecto positivo do AGC, consiste na sua alta capacidade de selecionar subconjuntos de casos e mutantes com alto escore de mutação por meio da CG, conforme [54] (Seção 5.4). Entretanto, a CG consiste em um passo a mais que o AGC (Seção 4.1) realiza quando comparado, por exemplo, ao AG canônico (Figura 3.1 da Seção 3.1.1). Por isso,

69 4.5 A Classificação Genética Controlada (CGC) 66 embora seja mais eficaz [54]), o AGC emprega um maior tempo de execução do que a abordagem de Adamopoulos, Harman e Hierons [1]. Por outro lado, apesar do algoritmo proposto por Adamopoulos, Harman e Hierons [1] (algoritmo A1 - Seção 5.2.1) ser ineficiente na seleção de subconjuntos de casos de teste [54] (Seções: 5.4 e 5.5), é um método eficaz na seleção de subconjuntos de mutantes difíceis de matar. Considera-se tal característica como positiva para abordagem de Adamopoulos, Harman e Hierons [1], pois essa classe de mutantes pode conduzir a seleção de um bom subconjunto de casos de teste [50], conforme explicado na Seção O Algoritmo Genético Coevolucionário com Classificação Genética Controlada (AGC CGC op ) [51] 3 foi concebido nesse contexto levando em consideração os aspectos positivos do algoritmo AGC [54] e do algoritmo A1 [1]. Dessa forma, a concepção do AGC CGC op aconteceu posteriormente à realização de um estudo mais aprofundado sobre os algoritmos A1 e AGC. Em termos práticos, as análises da Seção 5.4 e as três primeiras análises da Seção 5.5 subsidiaram o desenvolvimento do AGC CGC op, uma vez que percebeu-se a necessidade de tornar o emprego da CG do AGC mais eficiente. O AGC CGC op emprega a coevolução considerando: uma população de casos de teste e uma população de programas mutantes. A Figura 4.6 ilustra o ambiente coevolucionário empregado pelo AGC CGC op que pode ser descrito pelos seguintes passos: 1. Inicialização das populações: as populações de casos de teste e mutantes são iniciadas aleatoriamente. Cada população tem um tamanho fixo para formar os indivíduos, conforme estabelecido nos parâmetros; 2. Calculo das aptidões: População de mutantes: os indivíduos da população de casos de testes executam o teste sobre os indivíduos da população de programas mutantes. A partir dessa interação, calcula-se a aptidão dos indivíduos da população de mutantes, conforme a Equação 5-4; População de casos de teste: os indivíduos da população de casos de testes executam o teste sobre os indivíduos da população de programas mutantes. A partir dessa interação, calcula-se o aptidão dos indivíduos da população de casos de teste, conforme a Equação 2-1; 3 São recentes os estudos para a melhoria da Classificação Genética. Inicialmente, foram realizados estudos preliminares acerca da Classificação Genética (CG) [53, 52]. Em seguida, a abordagem foi aprimorada com o desenvolvimento de outro trabalho [51] que consiste no AGC CGC op. Todavia, apesar das contribuições geradas, os estudos realizados considerando o AGC CGC op ainda são iniciais.

70 4.5 A Classificação Genética Controlada (CGC) 67 Figura 4.6: Ambiente Coevolucionário do AGC CGC op. 3. Condição de parada dos algoritmos: a quantidade de gerações é a condição de parada do AG. 4. Operador de seleção: seleciona os pais para o cruzamento utilizando o operador de seleção Torneio; 5. Operador de cruzamento: População de mutantes: o operador de cruzamento utilizado para os indivíduos dessa população é a máscara uniforme; População de casos de teste: População de casos de teste: aplica-se a Classificação Genética Controlada (CGC); 6. Operador de mutação: aplica-se o operador de mutação conforme Classificação Genética Controlada (CGC); 7. Substituição: os filhos substitui a população corrente, com elitismo de um indivíduo para cada população. A Figura 4.6 apresenta o AGC CGC 4 op como hibridização de duas abordagens: 4 A aplicação da Classifição Genética pelo AGC CGC op é aplicada somente na população de casos de teste. Além disso, é realizada de forma controlada. Por isso, incorpora-se ao nome do AGC a nomenclatura CGC (Classificação Genética Controlada). Uma vez que a CGC é utiliza-se os operadores genéticos de cruzamento e mutação (FE e MG, respectivamente) para o emprego da CG, incorpora-se op ao nome AGC- CGC.

71 4.5 A Classificação Genética Controlada (CGC) 68 algoritmo A1 (Seção 5.2.1), proposto por Adamopoulos, Harman e Hierons [1] e; o algoritmo AGC [54], apresentado na Seção 4.1. A evolução da população de mutantes segue a abordagem de Adamopoulos, Harman e Hierons [1]. Já a evolução da população de casos de teste emprega o conceito de Efetividade Genética [54] com a aplicação da CG nos operadores genéticos do AGC [54] (Seção 4.4). Conforme Figura 4.7, o AGC CGC op utiliza FE e MG, de maneira diferente do AGC. Figura 4.7: Utilização dos operadores genéticos FE e GM pelo AGC CGC op. No contexto do AGC CGC op, a CG é empregada pelos operadores FE e MG da seguinte forma: 1. Geração do filho 1: o operador de cruzamento FE recebe o pai e a mãe do Operador de Seleção. Em seguida, o filho 1 é formado pela CG dos genes do pai e da mãe; 2. Geração do filho 2: o operador de cruzamento FE recebe o melhor indivíduo da população considerado como pai no cruzamento. Em seguida, recebe o filho 1, gerado no cruzamento anterior e o considera como mãe no segundo cruzamento. Na sequencia, o filho 2 é formado pela GC dos genes do melhor indivíduo e do filho 1; 3. Mutação dos filhos 1 e 2: o operador de mutação MG recebe o filho 1 e o filho 2 do operador de cruzamento FE. Em seguida, insere uma taxa de 100% de mutação nos genes dos filhos 1 e 2 que não foram classificados como efetivos (GEF). Destaca-se uma diferença entre a utilização do operador de cruzamento FE entre AGC CGC op e o AGC. No AGC o operador FE gera apenas um filho, no caso, o filho

72 4.6 Considerações Finais Já o algoritmo AGC CGC op, além de controlar a aplicação do operador FE ele gera um segundo filho, obtido entre o filho 1 e o melhor indivíduo encontrado na população de casos de teste. Pretende-se, alcançar com esse segundo filho gerado, uma evolução na melhor solução encontrada. O controle para aplicação da CG baseia-se na Taxa de Classificação Genética (TCG) e no Percentual Máximo de Classificação (PMC). O PMC é estabelecido como parâmetro de entrada do AGC CGC op. Já a TCG varia em função da geração corrente (Gc) e da quantidade total de gerações (Gt). A TCG é calculada conforme Equação 4-3. TCG = Gc PMC Gt (4-3) Como exemplo, considere Gt = 500 e PMC = Na primeira geração (Gc = 1) então TCG = Na geração corrente de número 200 (GC = 200) tem-se TCG = Por fim, na última geração (Gc = 500) tem-se a TCG = Logo, a medida que a Gc aumenta, o valor de TCG também aumenta, sendo sempre TCG = PMC na última geração. O valor TCG define quais operadores genéticos serão utilizados durante a coevolução das populações. Para cada cruzamento a ser realizado, o controle da CG funciona da seguinte forma: Gera-se, aleatoriamente, um número real AL com valor compreendido entre 0 e 1; Calcula-se o valor atual para TCG; Caso TCG <= AL, aplica-se o operador de genéticos de [54]. Caso contrário, aplicase o operador de cruzamento e mutação uniforme. Controlando CG com base na TCG espera-se: a) diminuir o tempo de execução do AGC CGC op em relação ao algoritmo AGC e; b) aplicar a CG em informações genética mais evoluídas, a fim de que o AGC CGC op aumente o escore de mutação em relação ao algoritmo A Considerações Finais Esse Capítulo apresentou a abordagem coevolucionária proposta. A definição formal do problema do Teste de Mutação foi descrita e um destaque especial foi dado à caracterização do problema como multiobjetivo e conflitante. Uma nova representação e dois novos operadores genéticos foram descritos, integrados ao AGC. O conceito de Efetividade Genética é implementado pelo AGC através de uma Classificação Genética empregada antes da avaliação das soluções. Tal classificação é possível porque a representação criada propicia um mapeamento genotípico das contibuições de cada gene à aptidão do indivíduo.

73 4.6 Considerações Finais 70 O objetivo do conceito de Efetividade Genética consiste na construção de indivíduos por genes que alcancem grupos diferenciados das populações opostas, pois, à medida que as soluções interagem entre si ao longo das gerações com este conceito, a busca é conduzida em direção a individuos mais aptos, formados nas duas populações. Nesse capítulo o algoritmo AGC CGC op foi apresentado como uma abordagem que aprimora a utilização da Classificação Genética para que o seu emprego seja mais eficiente. O Capítulo 5 descreve a experimentação realizada na pesquisa, na qual o AGC é comparado com outros cinco métodos. Por fim, na Seção 5.5, o AGC CGC op é analisado e comparado com as outras abordagens em termos de eficácia e eficiência.

74 Estudos Experimentais CAPÍTULO 5 Os experimentos realizados estão descritos neste capítulo. O AGC é comparado com outros métodos considerando três classes de benchmarks: a) o benchmark simulado; b) os benchmarks com mutantes obtidos pela ferramenta Mujava e; c) os benchmarks com mutantes obtidos pela ferramenta Proteum. Diante disso, este Capítulo está dividido em 5 seções. Na Seção (5.2), os algoritmos de comparação utilizados são apresentados. A Seção 5.3, descreve uma fase de experimentação inicial da pesquisa. Por isso, a análise é realizada em um benchmark simulado centrando-se somente na comparação dos escores de mutação alcançados pelos algoritmos. A Seção 5.4 apresenta uma experimentação considerando benchmarks escritos em linguagem Java. Realiza-se uma análise com um número maior de critérios, pois, além do escore de mutação, leva-se em consideração quais algoritmos selecionaram mutantes equivalentes e quais algoritmos exercem um menor custo computacional em termos de quantidade de testes realizados. Na Seção 5.5, realiza-se uma experimentação com benchmarks escritos em linguagem C. A análise dessa seção, ultrapassa as anteriores. Além de analisar os escores de mutação obtidos sobre benchmarks que se constituem em aplicações reais com conjuntos maiores, entre programas mutantes e casos de teste, a Seção 5.5 apresenta as seguintes análises: a) compara os algoritmos por escore de mutação em relação às variações dos parâmetros que configuraram os experimentos; b) analisa os subconjuntos selecionados de casos de teste (perspectiva dos casos de teste fortes e perspectiva dos mutantes difíceis de matar); c) verifica, em termos de mutantes difíceis de matar, o quanto cada metaheurísticas conseguiu ir além da abordagem aleatória; e) compara os algoritmos em termos de eficácia e eficiência, apresentando o algoritmo AGC CGC op e; f) realiza uma análise na perspectiva de operadores de mutação. A Seção 5.6 descreve algumas limitações da pesquisa realizada e, por fim, a Seção 5.7 apresenta as considerações finais do capítulo de experimentação.

75 5.1 Modelagem do Problema Modelagem do Problema Conforme descrito na Seção 2.4.5, a seleção de um bom subconjunto de casos de teste e bom subconjunto de mutantes é importante para redução de custos no Teste de Mutação. A métrica que define a qualidade de um caso de teste é o escore de mutação, conforme Equação 2-1 descrita na Seção 2.4. Com base no escore de mutação, pode-se definir uma função genérica de maximização para seleção de casos de teste no Teste de Mutação: Onde: MaximizartestetesteMst(P, s) = DM(P, s) M(P) EM(P) (5-1) DM(P,s): número de mutantes mortos pelo conjunto de teste em T ; M(P): número total de mutantes gerados; EM(P): número de mutantes gerados equivalentes a P; L: é o tamanho do subconjunto s (L = s ); Ms: é o escore de mutação de mutação do subconjunto s. Sujeito a: s T, se e somente se, s = L; i s, se e somente se, i s = /0 Seja P o conjunto de programas mutantes do programa original P, mortos i o total de mutantes mortos por s e totalequivs a quantidade total de equivalentes, s é factível, se e somente se, mortos i <= P totalequivs Por outro lado, conforme Seção 2.4.5, quanto mais difícil de matar for um mutante, mais ele contribuirá na seleção de um bom caso de teste. Ou seja, um mutante com melhor qualidade é que tem maior capacidade em evitar ser morto casos de teste. Dessa forma, pode-se definir essa capacidade como escore de mutação para um programa mutante. A Equação 5-2, define o escore de mutação para um mutante. MS(P,T ) = AT (P,T ) T (P) (5-2) Onde: AT (P,T ): número de casos de teste evitados pelo conjunto de mutantes P ; T (P): número total de casos de teste.

76 5.1 Modelagem do Problema 73 Com base no escore de mutação do mutante (Equação 5-2), pode-se definir uma função genérica de maximização para seleção de Mutantes: Onde: MaximizartestetesteMsm(P,k) = AT (P,k) EM(P) T (P) (5-3) AT (P,T ): número de casos de teste evitados pelo conjunto de mutantes P ; T (P): número total de casos de teste. EM(P): número de mutantes gerados equivalentes a P; W: é o tamanho do subconjunto k (W = k ); Msm: é o escore de mutação de mutação do subconjunto k. Sujeito a: k P, se e somente se, k = W; j k, se e somente se, j k = /0 Seja T o conjunto de casos de teste do programa P, evitados j o total de casos de teste evitados por k, k é factível, se e somente se, evitados j <= T. Dadas as métricas que definem a qualidade de casos de teste e mutantes (Equações 2-1 e 5-2), bem como as funções de maximização para selecionar bons subconjuntos de casos de teste e mutantes (Equações 5-1 e 5-3), o problema consiste em estabelecer uma busca por dois subconjuntos ótimos t e p, conforme definições abaixo: Indivíduo da População de casos de teste (IndTC): IndTC é um indivíduo (cromossomo) da população de casos de teste expresso como um conjunto de números inteiros t, sendo que t T, e o valor de cada inteiro t é um alelo de IndTC. Logo, t i é uma possível característica para um gene; Indivíduo da População de mutantes (IndMT): IndMT é um indivíduo (cromossomo) da população de mutantes expresso como um conjunto de números inteiros p, sendo que p P, e o valor de cada inteiro p é um alelo de IndMT. Logo, p i é uma possível característica para um gene. Entende-se como subconjunto ótimo de casos de teste aquele com elementos que, juntos, conseguem matar todos os mutantes não equivalentes. Por outro lado, entende-se como subconjunto ótimo de mutantes aquele formado por mutantes mais difíceis de serem mortos pelos casos de teste, ou seja, aqueles que conduzem a seleção de um subconjunto dos testes capaz de matar todos os mutantes não equivalentes. Portanto, o problema pode ser caracterizado como multiobjetivo e conflitante.

77 5.2 Algoritmos de Comparação Algoritmos de Comparação Algoritmo A1 O algoritmo proposto por Adamopoulos, Harman e Hierons [1] consiste no primeiro algoritmo de comparação da pesquisa. Por isso, a fim de facilitar sua referenciação no texto, foi nomeado de A1. Existem diversas diferenças entre o algoritmo A1 e o AGC (algoritmo proposto pela pesquisa - Capítulo 3). A representação; Função objetivo; Operadores Genéticos; Realização dos testes entre as populações. Na abordagem de Adamopoulos, Harman e Hierons [1] um indivíduo é um subconjunto de casos de teste ou programas mutantes. Na representação proposta para o AGC, cada indivíduo também é um subconjunto, no entanto, cada gene carrega informações das contribuições à aptidão do indivíduo. O algoritmo trata essas informações pelo conceito de Efetividade Genética (4) no mapeamento dos genes. As funções de aptidão propostas por Adamopoulos, Harman e Hierons [1] são descritas pelas Equações 5-4 (indivíduos da população de casos de teste) e 5-5 (indivíduos da população de mutantes). (5-4) Onde: { L T f = i=1 Stc i L Tf : é a aptidão de um indivíduo da população de casos de teste; Stc: o escore de mutação do subconjunto de casos de teste; L: tamanho do indivíduo da população de casos de teste; M f = { n i=1 Smt i W se i Smt,Smt i 1, 0 caso contrário. (5-5) Onde: Mf : é a aptidão de um indivíduo da população de mutantes; Smt: o escore de mutação do subconjunto de mutantes;

78 5.2 Algoritmos de Comparação 75 W: tamanho do indivíduo da população mutantes; Na abordagem de Adamopoulos, Harman e Hierons [1] as funções objetivos, descritas pelas Equações 5-4 e 5-5 é a razão do somatório dos escores de mutação dos genes pelo tamanho do indivíduo. O AGC tem uma forma diferente de cacular as funções de aptidões dos indivíduos. O AGC iguala a aptidão do mutante ao escore de mutação, conforme descrito na Seção 4.3. Por exemplo, para um indivíduo da população de casos de teste, a função de aptidão é a razão do total de mutantes mortos pela quantidade total de mutante existentes. A função de aptidão para os indivíduos da população de mutantes é análoga, sendo a razão da quantidade de casos de teste evitados pela quantidade total de casos de teste. Vale observar na Equação 5-5 que a penalização empregada por A1 para evitar mutantes equivalentes difere-se da empregada pelo AGC. Em A1, caso o escore S i de algum mutantes seja igual a 1, o algoritmo atribui aptidão 0 a esse indivíduo, para eliminar a possibilidade de selecionar algum indivíduo que contenha um mutante possivelmente equivalente. Já a penalização empregada pelo AGC é realizada por gene e não por indivíduo, conforme Seção 4.3. Adamopoulos, Harman e Hierons [1] utilizam operadores de cruzamento e mutação propostos pela literatura. A presente dissertação propõe dois novos operadores apropriados à representação: o operador de cruzamento Filho Efetivo (FE) e o operador de mutação Muta Genes (MG), conforme Seção 4.4. Adamopoulos, Harman e Hierons [1] propõem uma estratégia de coeovolução com interação entre os indivíduos das populações de casos de teste e programas mutantes. Diferentemente, a presente pesquisa propõe uma interação que ocorre entre os genes dos melhores indivíduos de uma população contra a população oposta. O Algoritmo 5.1 representa os passos de A1. As populações de casos de teste e programas mutantes são iniciadas aleatoriamente. Em seguida, a avaliação dos indivíduos é realizada por meio da interação entre as populações, representada pela função interarpopmtxpoptc() 1 no Algoritmo 5.1. Com base nas informações dessa interação, A1 calcula as aptidões dos indivíduos. Em seguida, A1 realiza a seleção, o cruzamento, a mutação e a substituição. A coevolução para quando se atinge a quantidade de gerações estabelecida nos parâmetros e, ao final, as seleções dos melhores indivíduos (subconjuntos) da população de casos de teste e programas mutantes são retornados como saída do algoritmo. 1 A interação é o processo em que os casos de teste dos indivíduos da população de casos de teste executam sobre o programa original e os programas mutantes dos indivíduos da população de mutantes, verificando se os casos de teste mataram ou não os programas mutantes.

79 5.2 Algoritmos de Comparação 76 Algoritmo 5.1: Algoritmo proposto por Adamopoulos, Harman e Hierons [1] (A1). inicializarpopulações() geração=1; while geração <= limitegerações do function AVALIARAPTIDÕES interarpopmtxpoptc() calcularaptidões() end function selecionar() cruzar() mutar() substituir() geração++; return melhoresindividuos() A interação empregada por A1 realiza-se entre todos os indivíduos das duas populações, diferindo-se do AGC que acontece entre o melhor indivíduo de uma população contra os indivíduos da população oposta, conforme descrita na Seção Algoritmo A2 O Algoritmo A2 surgiu na percepção de que as funções de aptidão do Algoritmo A1 poderiam ser otimizadas pela aproximação das aptidões à forma de cálculo do escore de mutação. Dessa forma, o Algoritmo A2 consiste numa versão modificada do Algoritmo A1. Os passos de A2 estão descritos no Algoritmo 5.2.

80 5.2 Algoritmos de Comparação 77 Algoritmo 5.2: Algoritmo A1 com modificação na função de aptidão (A2). inicializepopulações() geração=1; while (geração <=limitegerações) do function AVALIEAPTIDÕES interaçãopopmtxpoptc() calculeaptidões() end function seleção() cruzamento() mutação() substituição() geração++; return melhoresindividuos() O Algoritmo A2 tem a mesma representação e funcionamento do Algoritmo A1. Entretanto, o que diferencia A2 de A1 são suas funções de aptidão. A funções de aptidão de A2 são calculadas conforme os escores de mutação dos casos de teste e mutantes. Por exemplo, a função de aptidão de um indivíduo da população de casos de teste é definido pela Equação 2-1. Da mesma forma, a função de aptidão um indivíduo da população de mutantes é descrita pela Equação 5-2. Na, as aptidões de A2 são as mesmas das empregadas pelo AGC (4.3), entretanto, os algoritmos apresentam as seguintes diferenças: 1. A2 não possui a Classificação Genética; 2. A forma de penalização do Algoritmo A2 é igual a penalização empregada por A1. Ou seja, caso exista um mutante que não morra com pelo menos um caso de teste testado, o indivíduo recebe uma aptidão igual a zero. 3. A interação empregada por A2 realiza-se entre todos os indivíduos das populações, da mesma forma que a interação empregada por A Algoritmo A3 O Algoritmo A3 consiste numa abordagem aleatória para seleção das soluções. O Algoritmo 5.3 descreve os passos de A3.

81 5.2 Algoritmos de Comparação 78 Algoritmo 5.3: Algoritmo de seleção aleatória (A3). geração=1; while (geração <= limitegerações) do inicializeindivíduos() calculeescoremutação() armazenamelhores() geração++; return melhoresindivíduos() O funcionamento de A3, pode ser descrito em três passos: 1. Gera-se, aleatoriamente, dois subconjuntos: está representado pela função inicializeindivíduos() no Algoritmo 5.3. Um subconjunto de casos de teste e outro de mutantes são formados; 2. Calcula-se o escore real dos subconjuntos: está representado pela função calcule- EscoreMutação() no Algoritmo 5.3. Vale observar que escore de mutação para um mutante é a sua capacidade de evitar ser morto por casos de teste. 3. Armazena os melhores subconjuntos: está representada pela função armazenamelhores() do Algoritmo Retorna melhores: gera como saída o melhor subconjunto de mutantes e o melhor subconjunto de casos de teste de todas as gerações. O Algoritmo A3 representa uma abordagem aleatória de seleção e serve de base para comparação com outras abordagens Algoritmo AGC-GE Consiste numa versão mais elitista do AGC. Ao longo das gerações, esse algoritmo seleciona um grupo de indivíduos para sobreviver para a próxima geração, ao invés de selecionar apenas um indivíduo. A esse grupo, deu-se o nome de Grupo dos Eleitos (GE). O Algoritmo 5.4 descreve os passos de AGC-GE.

82 5.2 Algoritmos de Comparação 79 Algoritmo 5.4: Algoritmo AGC com o Grupo dos Eleitos (AGC-GE). inicializarpopulações() geração=1; while (limitegerações) do function AVALIEAPTIDÕES selecionarmelhorindmt() interarindmtxpoptc() selecionarmelhorindtc() interarindtcxpopmt() classificargeneticamente() calcularaptidões() selecionargrupoeleitos() end function selecionar() cruzar() mutar() substituir() matergrupoeleitos() geração++; classificargeneticamentegrupoeleitos() return melhoresindividuos() O Algoritmo AGC-GE tem o mesmo funcionamento do AGC. A diferença está no GE que se aplica as duas populações durante a coevolução. Somente entra nesse grupo os indivíduos com genes que geram contribuição no escore de mutação entre os indivíduos do grupo [54]. A seleção desses indivíduos é realizada pela função selecionargrupoeleitos() do Algoritmo 5.4. Ao final de cada geração, o GE é mantido na população seguinte (matergrupoeleitos()). Após a última geração, uma Classificação Genética é realizada nos genes desses indivíduos formando um só indivíduo (classificargeneticamentegrupo- Eleitos()) obtido pelo GE da população de casos de teste e um só indivíduo obtido pelo GE da população de mutantes. Espera-se que tais subconjuntos tenham um escore maior Algoritmo A2-GE O Algoritmo A2-GE consiste numa versão mais elitista do Algoritmo A2. O Algoritmo 5.5 descreve os passos de A2.

83 5.3 Um benchmark simulado 80 Algoritmo 5.5: Algoritmo A2 com o Grupo dos Eleitos (A2-GE). inicializarpopulações() geração=1; while (limitegerações) do function AVALIARAPTIDÕES interarpopmtxpoptc() calcularaptidões() selecionargrupoeleitos() end function selecionar() cruzar() mutar() substituir() matergrupoeleitos() geração++; classificargeneticamentegrupoeleitos() return melhoresindividuos() Basicamente, o Algoritmo A2-GE tem o mesmo funcionamento do Algoritmo A2. A diferença está no Grupo dos Eleitos (GE) que se aplica as duas populações durante a coevolução. Ao longo das gerações, esse algoritmo seleciona um grupo de indivíduos GE para sobreviver para a próxima geração, ao invés de selecionar apenas um indivíduo. Diferentemente, do Algoritmo AGC-GE, os indivíduos que entram no GE do Algoritmo A2-GE são aqueles de maior escore de mutação entre a população corrente. Isso é realizado pelo método selecionargrupoeleitos() do Algoritmo 5.5. Após a última geração, o melhor indivíduo da população de casos de teste e o melhor indivíduo da população de mutantes são selecionados 5.3 Um benchmark simulado Descrição Foi simulado um benchmark considerando conjuntos de programas mutantes e casos de teste. Dessa forma, a quantidade de pontos no espaço de busca depende dos tamanhos dos indivíduos das populações, aumentando conforme se aumenta o tamanho dos indivíduos.

84 5.3 Um benchmark simulado 81 No Teste de Mutação, um caso de teste pode detectar um defeito por meio da comparação de sua execução sobre o programa original e sobre o programa mutante. Conforme já descrito na Seção 2.4, quando há divergências nessas execuções, o defeito é detectado e diz-se que o mutante foi morto pelo caso de teste. Caso contrário, diz-se que o mutante está vivo, pois o caso de teste não foi capaz de revelar o defeito. Para simular os estados dos mutantes (morto ou vivo), considerando um conjunto de 2000 casos de teste e 2000 mutantes, foram gerados de números por meio do método de Kirkpatrick e Stoll [39]. Tal método gera números aleatórios sendo eficaz em distribuição [39]. Este mesmo espaço de busca pode ser simulado e utilizado em outras pesquisas, permitindo comparações e evoluções do método proposto, bem como a inserção artificial de mutantes equivalentes. Esses números foram armazenados em uma lista L sendo que cada posição em L é correspondente ao resultado da execução de um caso de teste sobre um programa mutante. Ou seja, se o caso de teste matou ou não matou o mutante. A interpretação dos números gerados como resultado do teste é a que segue: os números pares foram considerados como 0 (zero - caso de teste não matou o mutante) e os números ímpares foram considerados como 1 (um - caso de teste matou o mutante). Portanto, sendo ntc o número do caso de teste TC e nmt o número do programa mutante MT, o teste pode ser simulado por meio de uma consulta com o par (ntc, nmt) em L que retorna o resultado do teste (ou 0 ou 1). Considerando o conjunto de total de mutantes, na lista L simulou-se uma taxa de 10% de mutantes equivalentes, o que representa um número de 200 mutantes Parâmetros Os algoritmos AGC, A1, A2 e A3 foram os experimentados no benchmark simulado. Os algoritmos AGC-GE e A2-GE foram desenvolvidos após à realização dos experimentos com o benchmark simulado. Por esse motivo, não são apresentados resultados desses algoritmos considerando esse benchmark. Após diversas execuções sob parâmetros variados, percebeu-se que o tamanho do indivíduo (subconjunto) foi o parâmetro que provovou uma maior mudança nas aptidões encontradas. Por isso, a Seção 5.3.3, correspondente à análise, apresenta resultados obtidos com variações nos tamanhos dos indivíduos das populações de casos de teste e mutantes. Por outro lado, foram fixados os seguintes parâmetros: 1. elitismo: 1 ; 2. tamanho da população: 30; 3. número de gerações: 300; 4. operador de seleção: torneio; 5. taxa de cruzamento: 100% ;

85 5.3 Um benchmark simulado operador de cruzamento: máscara uniforme taxa de mutação: 5%; 8. operador de mutação: mutação uniforme; Análise dos Resultados A análise dos resultados objetiva avaliar os escores de mutação alcançados pelos algoritmos sobre o benchmark simulado. O Teste T de Student foi o método estatístico adotado para análisar o nível de significância dos escores alcançados. Acerca do escore de mutação, estudos experimentais revelam que um bom escore de mutação alcançado por um conjunto de teste é o igual ou superior a 95% [9, 27]. Por isso, assume-se como um bom resultado no escore de mutação aqueles iguais ou maiores que 95%. O nível de significância considerado foi o de 99% e a seguinte hipótese nula foi formulada para os indivíduos da população de casos de teste: H 0 : µ < Dessa forma, H 0 pode ser rejeitada com a seguinte hipótese alternativa: H 1 : µ Logo, um bom resultado acontece quando H 1 é uma proposição verdadeira, pois t > p value. Nesse caso, será evidenciado que os escores de mutação alcançados pelos indivíduos da população de casos de teste foram significativamente maiores que 0.95%. Além disso, há mais certeza nessa afirmação de significância quanto maior for o valor de t. É importante destacar que o número 0.95 de H 0 é correspondente ao valor de 95% do escore de mutação possível de ser alcançado por um caso de teste, uma vez que o benchmark simulado contem 10% de mutantes equivalentes. Por exemplo, no caso do benchmark simulado, os escores iguais ou maiores que são considerados bons, pois representa 95% do escore máximo possível de se alcançar que é 0.90, considerando os 10% de mutantes equivalentes. Por outro lado, as mesmas hipóteses valem para os escores dos indivíduos da população de programas mutantes, com a diferença que para esses, não existem essas retrições. Em outras palavras, para os indivíduos da população de mutantes, 0.95 de escore siginifica, verdadeiramente, 95% de escore. Os resultados das excuções dos algoritmos são apresentados na Tabela 5.1. Cada resultado obtido considera 10 execuções por parâmetro. Legendas da Tabela 5.1: IndTC: melhor indivíduo da população de casos de teste; IndTC: melhor indivíduo da população de programas mutantes; P: tamanhos L e K dos indivíduos das populações de casos de teste e mutantes, respectivamente; 2 Exceto para o algoritmo AGC que contém operadores de cruzamento e de mutação, desenvolvidos para adequar à representação proposta, conforme Capítulo 4.

86 5.3 Um benchmark simulado 83 Tabela 5.1: Resultados Benchmark Simulado P AL CV IndTC IndMT MAX MED t p-value MAX MED t p-value AGC 68 0,900 0, ,3E-20 1,000 0, ,4E-24 A ,452 0, ,5E-22 0,504 0, ,0E-21 A ,900 0, ,6E-18 1,000 0, ,4E-24 A ,442 0, ,4E-25 0,613 0, ,5E-12 AGC 91 0,900 0, ,3E-20 1,000 0, ,3E-15 A ,410 0, ,6E-21 0,509 0, ,9E-17 A ,828 0, ,2E-08 1,000 0, ,4E-24 A ,338 0, ,9E-19 0,552 0, ,5E-12 AGC 144 0,900 0, ,3E-20 0,975 0, ,6E-13 A ,311 0, ,4E-20 0,502 0, ,6E-18 A ,641 0, ,7E-13 0,974 0, ,2E-15 A ,224 0, ,4E-22 0,443 0, ,9E-11 AGC 127 0,900 0, ,1E-18 1,000 0, ,6E-06 A ,455 0, ,4E-19 0,501 0, ,3E-23 A ,899 0, ,3E-17 1,000 0, ,4E-24 A ,369 0, ,9E-17 0,457 0, ,4E-14 AGC 255 0,900 0, ,4E-16 1,000 0, ,8E-19 A ,416 0, ,3E-19 0,507 0, ,4E-19 A ,822 0, ,4E-09 1,000 0, ,3E-25 A ,197 0, ,0E-20 0,293 0, ,7E-14 AGC 201 0,900 0, ,9E-18 1,000 0, ,2E-14 A ,315 0, ,6E-19 0,507 0, ,4E-19 A ,623 0, ,8E-15 1,000 0, ,5E-11 A ,124 0, ,1E-20 0,243 0, ,3E-12 AGC 40 0,876 0, ,4E-10 1,000 0, ,4E-24 A ,461 0, ,0E-19 0,504 0, ,0E-21 A ,876 0, ,3E-08 1,000 0, ,4E-24 A ,440 0, ,2E-23 0,649 0, ,3E-10 AGC 300 0,877 0, ,1E-08 1,000 0, ,3E-10 A ,413 0, ,3E-18 0,549 0, ,4E-13 A ,793 0, ,9E-10 1,000 0, ,6E-15 A ,146 0, ,5E-17 0,161 0, ,8E-18 AGC 289 0,879 0, ,5E-07 0,976 0, ,9E-13 A ,310 0, ,5E-20 0,505 0, ,8E-19 A ,601 0, ,2E-15 0,999 0, ,5E-11 A ,087 0, ,2E-20 0,117 0, ,1E-17 CCL:30 K:30 CCL:30 K:10 CCL:30 K:05 CCL:10 K:30 CCL:10 K:10 CCL:10 K:05 CCL:05 K:30 CCL:05 K:10 CCL:05 K:05

87 5.3 Um benchmark simulado 84 AL: algoritmo utilizado; CV: quantidade de gerações para convergência do melhor indivíduo da população de casos de teste e da população de mutantes; MAX: escore máximo; MED: média dos melhores escores obtidos considerando 10 execuções por parâmetro P; t: métrica do Teste T de Student; p-value: métrica do teste T de Student; Cada linha da Tabela 5.1 representa o resultado de um algoritmo sobre uma variação P dos tamanhos dos indivíduos. Por exemplo, na primeira linha, a coluna P expressa os tamanhos L=30 e K=30 para os indivíduos (subconjuntos) das populações de casos de teste e mutantes, respectivamente. A coluna AL apresenta o algoritmo AGC que obteve uma média de convergência (CV) de 68 gerações 3. Além disso, considerando as 10 execuções do AGC com os parâmetros L=30 e K=30, para os melhores indivíduos da população de casos de teste (IndTC) foram obtidos os seguintes resultados: a) máxima solução alcançada (MAX) no escore de mutação foi igual a 0.90, o que representa 100 % no escore possível de se alcançar; b) a média dos escores de mutação (MED) foi de 0.89; c) o valor t obtido foi o de 336 e; d) o p-value obtido foi o de 9,3E-20. Considerando as mesmas 10 execuções do AGC com os parâmetros L=30 e K=30, para os melhores indivíduos da população de mutantes (IndMT) foram obtidos os seguintes resultados: a) a máxima solução alcançada (MAX) no escore de mutação foi igual a 1.0, o que representa 100 % no escore possível de se alcançar; b) a média dos escores de mutação (MED) foi de 0.999; c) o valor t obtido foi o de 1046 e; d) o p-value obtido foi o de 2,4E-24. Conforme Tabela 5.1, o algoritmo AGC teve um desempenho melhor no escore de mutação do que os outros algoritmos em todas as variações nos tamanhos L e K dos indivíduos das populações de casos de teste e mutantes, respectivamente. Nos cenários em que L > 5, o AGC selecionou um subconjunto de casos de teste que matou todos os programas mutantes, alcançando escore máximo de 0.90 (100%). Nos outros cenários, quando L < 5 alcançou escore superior a (95%). De forma análoga, também selecionou um subconjunto de programas mutantes não equivalentes com escore máximo de 1.0 (100%), nas variações dos valores de K. Em termos estatísticos, pode-se afirmar que o AGC obteve resultados mais significativos que todos os algoritmos de comparação. Isso pode ser visualizado pelos valores de t maiores que zero da Tabela 5.1, pois rejeitou a hipótese nula alcançando escores superiores a 95% do escore possível de se alcançar no benchmark simulado. 3 CV corresponde à média de convergência do algoritmo. É um número que define a quantidade de gerações que o algoritmo levou para o alcance da melhor solução.

88 5.4 Benchmarks escritos em linguagem Java 85 Depois do AGC, o algoritmo A2 foi o melhor, conseguiu selecionar indivíduos da população de mutantes com escore máximo de 1.0 (100%), na maioria dos casos. Entretanto, considerando o melhor indivíduo da população de casos de teste, quando L 10 e K 10 alcançou escores inferiores a 95%, por exemplo, quando L = 5 e K = 5, A2 alcançou escore de (67%) enquanto o algoritmo AGC alcançou (98%). Por outro lado, o fato do algoritmo A2 ter sido superior ao algoritmo A1, evidencia que a função de aptidão do algoritmo A1 não favorece a uma busca global para a realização do teste. Já o algoritmo A3, que implementa uma estratégia aleatória, teve o pior desempenho entre os algoritmos analisados, reforçando a importância de se utilizar uma metaheurística que guia o processo de busca por soluções. 5.4 Benchmarks escritos em linguagem Java Descrição Foram utilizados cinco programas escritos em linguagem Java. Tais programas realizam as seguintes funções: 1. Bisect: calcula a raiz quadrada de um número n utilizando o método da bissetriz; 2. BubCorrecto (Bub): realiza a ordenação de um vetor através do método bubble- Sort; 3. Fourballs: calcula o peso relativo de um corpo; 4. Mid: calcula o valor central a partir de três valores; 5. Trityp: realiza a classificação de triângulos, dadas as dimensões dos seus lados. Esses benchmarks foram obtidos por meio da pesquisa de Polo, Mario e García [55] cujo o material experimental está disponibilizado na seguinte página web: " Nessa pesquisa, os mutantes foram gerados por meio da ferramenta MuJava [41]. Optou-se pelos benchmarks dessa pesquisa por dois motivos: a) são benchmarks conhecidos; b) contêm dados importantes para replicação de experimentações com outras técnicas, por exemplo, a quantidade de casos de teste que matam todos os programas mutantes e a relação dos mutantes equivalentes. Tais informações possibilitam a verificação da eficácia dos métodos na seleção do melhor subconjunto de casos de teste e mutantes, bem como a capacidade em evitar mutantes equivalentes. A Tabela 5.2 descreve a quantidade de casos de teste; a quantidade de mutantes e; a quantidade de mutantes equivalentes. Tais informações são importantes para a realização da análise dos resultados. Essa Tabela também descreve o máximo de escore de mutação

89 5.4 Benchmarks escritos em linguagem Java 86 possível de ser alcançado por um caso de teste (100% no Escore de Mutação (ct)) para cada benchmark, bem como, o percentual de 95% (95% no Escore de Mutação (ct)), para realização da análise estatística. Além disso, a Tabela 5.2, apresenta uma linha nomeada como "No. de casos de teste (reduzidos)"que define a quantidade mínima de casos de teste para se alcançar o maior escore de mutação em cada benchmark. Tabela 5.2: Informações sobre os Benchmarks de Polo, Mario e García [55] Bisect Bub Fourballs Mid Trityp No. de Mutantes No. de Equivalentes % no Escore de Mutação (ct) 0,698 0,850 0,792 0,762 0,777 95% no Escore de Mutação (ct) 0,663 0,807 0,752 0,723 0,734 No. de casos de teste No. de casos de teste (reduzidos) Parâmetros Na Tabela estão descritos os parâmetros utilizados. Para cada benchmark, existe uma quantidade de casos de teste reduzidos que alcançam escore de mutação de 100% sobre os mutantes não equivalentes, conforme descrito na Tabela 5.2. Com a finalidade de dificultar a busca, foi definido que o tamanho dos indivíduos das populações de casos de teste (IndTC) e mutantes (IndMT) seguem o mesmo tamanho da quantidade dos casos de teste reduzidos do seu respectivo benchmark, com exceção do benchmark Bub onde definiu-se um tamanho 2 para os indivíduos das duas populações. Isso pode ser observado pela comparação das linhas 2 e 3 da Tabela 5.3 com a última linha da Tabela 5.2. Realizada uma série de experimentos em que se testou a variação de diversos parâmetros, constatou-se que, após o tamanho do indivíduo, o parâmetro que gera uma maior alteração nos resultados consiste no parâmetro que define o tamanho da população. Por esse motivo, foram extraídos dois grupos de dados: população reduzida e população expandida. Além dos parâmetros descritos na Tabela 5.3 foram utilizados os seguintes parâmetros, comuns ao experimentos de população reduzida e de população expandida: 1. número de gerações: 400; 4 Vale observar que não existe uma correlação entre os parâmetros para definição dos seus respectivos valores para cada benchmark.

90 5.4 Benchmarks escritos em linguagem Java 87 Tabela 5.3: Parâmetros por Benchmark Bisect Bub Fourballs Mid Trytip Tamanho IndTC Tamanho IndMT Tamanho população (reduzida) Tamanho população (expandida) Elitismo para o Grupo dos Eleitos taxa de cruzamento: 100% ; 3. taxa de mutação: 5% ; 4. elitismo: 1 5 ; 5. operador de seleção: torneio; 6. operador de cruzamento: máscara uniforme operador de mutação: mutação uniforme Análise dos Resultados A análise desta Seção objetiva comparar os algoritmos por meio dos seguintes critérios: a) escore de mutação; b) capacidade em evitar mutantes equivalentes e; c) redução da quantidade de testes. Dessa forma, todos os casos de teste gerados 7 bem como os mutantes equivalentes e não equivalentes, foram considerados nos experimentos dessa Seção. As Tabelas 5.4 e 5.5, apresentam os resultados dos algoritmos AGC, A1, A2, A3, AGC-EG e A2-EG sobre os parâmetros descritos na Seção 5.4.2, considerando o tamanho de população expandida (linha 4 da Tabela 5.3). Já As Tabelas 5.6 e 5.7 apresentam os resultados dos algoritmos AGC, A1, A2, A3, AGC-EG e A2-EG sobre os parâmetros descritos na Seção 5.4.2, considerando o tamanho de população reduzida (linha 3 da Tabela 5.3). Os resultados apresentados em todas as Tabelas foram obtidos por meio de 30 execuções. Legendas das Tabelas 5.6, 5.7, 5.4 e 5.5: IndTC: melhor indivíduo da população de casos de teste; IndMT: melhor indivíduo da população de mutantes; 5 Exceto para os algoritmos AGC-GE e A2-GE que utilizam o elitismo definido na Tabela Exceto para o algoritmo AGC que contém operadores genéticos específicos desenvolvidos, conforme Capítulo 4. 7 Todos os casos de teste e mutantes gerados, bem como as informações das ferramentas geradoras, estão disponíveis no site "

91 5.4 Benchmarks escritos em linguagem Java 88 M: escore máximo obtido; A: média do escore; pv: p-valor (métrica do teste T de Student); t: p-valor (métrica do teste T de Student); MM: solução ótima para o benchmark; SS: mesma solução selecionada em todas as execuções. Quando o mesmo resultado é selecionado em todas as execuções, não ocorre desvio padrão, fator que não possibilita a extração das métricas do teste de hipótese T de Student.; EM: seleção de um mutante equivalente na solução. Nas Tabelas 5.4, 5.5, 5.6 e 5.7, onde aparecer EM significa que o escore de mutação do IndMT é igual a 1.0, pois é um mutante equivalente; Escore de Mutação Em termos gerais, no quesito escore de mutação, o algoritmo AGC teve um melhor desempenho que os demais algoritmos. Após o AGC, o mais competitivo nesse quesito foi o algoritmo AGC-EG. O terceiro mais competitivo foi o algoritmo A2 e o quarto foi o algoritmo A2-GE. Considerando que cada algoritmo foi executado 30 vezes, as Figuras 5.1 e 5.2 apresentam uma comparação entre os algoritmos no alcance das soluções ótimas sobre cada benchmark. Figura 5.1: Experimentos: tamanhos de população expandida (Tabelas: 5.4 e 5.5) - Número de Soluções Ótimas X Algoritmos

92 5.4 Benchmarks escritos em linguagem Java 89 Tabela 5.4: Resultados AGC, A1, A2 e A3 - população expandida Algorithms Bisect Bub Fourballs Mid Trytip M 0,698 0,85 0,792 0,762 0,773 MM MM MM MM MM A 0,697 0,85 0,792 0,762 0,773 MM MM MM MM pv 1,10E-03 SS SS SS SS t 38,25 SS SS SS SS M MM MM MM MM MM A ,958 MM MM MM MM pv SS 1,80E-02 SS SS SS t SS 2,18 SS SS SS M 0,651 0,85 MM 0,302 0,345 0,19 A 0,651 0,849 0,295 0,331 0,179 pv SS 2,50E-04 2,90E-03 1,00E+00 1,00E+00 t SS ,7 M 1 MM 0,854 0,907 0,916 0,992 A 1 MM 0,854 0,907 0,916 0,991 pv SS SS SS SS -5,80E-06 t SS SS SS SS 588 AGC A1 A2 A3 IndTC IndMT IndTC IndMT IndTC IndMT IndTC IndMT M 0,698 0,85 0,792 0,762 MM MM MM MM 0,744 A 0,698 0,792 0,849 MM MM 0,757 0,726 pv SS 9,70E-04 SS 5,60E-03 1,00E+00 t SS 93 SS 42-7,1 M MM MM MM MM MM A MM MM MM MM MM pv SS SS SS SS SS t SS SS SS SS SS M 0,651 0,85 MM 0,303 0,34 0,195 A 0,651 0,849 0,296 0,33 0,179 pv SS 4,50E-04 1,00E+00 1,00E+00 1,00E+00 t SS ,7-406 M EM EM EM EM EM A EM EM EM EM EM pv EM EM EM EM EM t EM EM EM EM EM

93 5.4 Benchmarks escritos em linguagem Java 90 AGC-GE IndTC IndMT Tabela 5.5: Resultados AGC-GE e A2-GE - populacao expandida Algorithms Bisect Bub Fourballs Mid Trytip M 0,698 0,85 0,792 0,762 0,773 MM MM MM MM MM A 0,635 0,85 0,792 0,762 0,773 MM MM MM MM pv 9,90E-01 SS SS SS SS t -2,46 SS SS SS SS M MM MM MM MM MM A 0,998 0, MM MM MM pv 4,30E-03 4,30E-03 SS SS SS t 36,5 36,5 SS SS SS A2-EG IndTC IndMT M 0,698 0,85 0,792 0,762 MM MM MM MM 0,738 A 0,698 0,792 0,849 MM MM 0,756 0,727 pv SS 9,70E-04 SS 7,50E-03 1,00E+00 t SS 93 SS 62,8-5,47 M MM MM MM MM MM A MM MM MM MM MM pv SS SS SS SS SS t SS SS SS SS SS Figura 5.2: Experimentos: tamanhos de população reduzida (Tabelas: 5.6 e 5.7) - Número de Soluções Ótimas X Algoritmos

94 5.4 Benchmarks escritos em linguagem Java 91 Tabela 5.6: Resultados AGC, A1, A2 e A3 - experimentos: população reduzida Algorithms Bisect Bub Fourballs Mid Trytip M 0,698 0,85 0,792 0,762 0,773 MM MM MM MM MM A 0,682 0,842 0,792 0,762 0,773 MM MM MM pv 6,00E-06 6,10E-06 SS SS SS t 5,268 8,761 SS SS SS M MM MM MM MM MM A 0,985 0, MM MM MM pv 3,10E-05 1,00E+00 SS SS SS t 4,682-3,507 SS SS SS M 0,651 0,788 0,302 0,334 0,19 A 0,594 0,735 0,289 0,322 0,163 pv 1,00E+00 1,00E+00 1,00E+00 1,00E+00 1,00E+00 t M 0,896 0,855 0,907 0,916 0,991 A 0,881 0,836 0,895 0,915 0,99 pv 1,00E+00 5,50E-06 1,00E+00 1,00E+00 1,20E-01 t ,18 M 0,698 0,792 0,813 MM MM 0,757 0,731 A 0,65 0,762 0,787 0,749 0,714 pv 1,00E+00 1,00E+00 3,10E-25 1,10E-20 1,00E+00 t M MM MM MM MM MM A ,989 MM MM MM 0,995 pv SS SS 1,10E-05 SS 1,00E+00 t SS SS 5 SS 22 M 0,651 0,85 0,302 0,341 0,192 A 0,651 0,846 0,292 0,325 0,172 pv SS 7,60E-33 1,00E+00 1,00E+00 1,00E+00 t SS M EM EM EM EM EM A EM EM EM EM EM pv EM EM EM EM EM t EM EM EM EM EM AGC A1 A2 A3 IndTC IndMT IndTC IndMT IndTC IndMT IndTC IndMT

95 5.4 Benchmarks escritos em linguagem Java 92 Tabela 5.7: Resultados AGC-EG e A2-EG - experimentos: população reduzida Algorithms Bisect Bub Fourballs Mid Trytip 0,698 0,85 0,792 0,762 0,773 M MM MM MM MM MM 0,792 0,762 0,773 A 0,688 0,84 MM MM MM pv 1,70E-09 1,00E-13 SS SS SS t 8,33 12,75 SS SS SS M MM MM MM MM MM A 0,992 0,929 MM MM MM pv 1,20E-08 9,80E-01 SS SS SS t 7,55-2,22 SS SS SS 0,792 M 0,683 0,8 0,757 0,738 MM A 0,65 0,748 0,788 0,749 0,717 pv 9,90E-01 1,00E+00 1,50E-28 7,60E-20 1,00E+00 t -2,44-13,18 44,52 21,82 9, M 1 MM MM MM MM 1 1 A 1 0,997 0,993 MM MM pv SS 5,10E-16 SS SS 1,50E-17 t SS 15,69 SS SS 17,9 AGC-GE A2-EG IndTC IndMT IndTC IndMT Os algoritmos AGC e A2 obtiveram melhores escore de mutação que suas versões elitistas: AGC-GE e A2-EG, respectivamente. Entretanto, a busca por melhores soluções, desempenhada pelas versões elitistas, tornou-se melhor no contexto dos experimentos de tamanho de populações expandidas (Tabela 5.5), em que os tamanhos das populações são maiores. Este fato evidencia que as estratégias mais elitistas podem obter melhores escores em cenários com maior diversidade genética. O fato de A2 ter sido mais competitivo que A1 no quesito escore de mutação (considerando os resultados dos experimentos de população reduzida e expandida), evidencia que as funções de aptidão de A1 foram otimizadas e serviram como um melhor guia no processo coevolucionário. Seleção de Mutantes Equivalentes Em termos gerais, encontrar subconjuntos de programas mutantes que evitam todos os casos de teste foi uma tarefa menos difícil do que encontrar o melhor subconjunto de casos de teste. Além disso, constatou-se que os algoritmos coevolucionários não

96 5.4 Benchmarks escritos em linguagem Java 93 selecionaram mutantes equivalentes. Entretanto, o algoritmo A3 selecionou mutantes equivalentes para todos os benchmarks. Isso pode ser visto nas Tabelas 5.4 e 5.6 em que para todos os benchmarks, na seleção de IndMT houve a marcação EM sinalizando a seleção de um mutante equivalente na solução. Portanto, onde há marcação de EM, significa que o IndMT obteve escore de mutação igual a 1, pois foi selecionado um mutante equivalente no subconjunto. Esse resultado leva a entender que a penalização empregada nas funções objetivo pelas metaheurísticas coevolucionárias evitam os mutantes equivalentes. Redução dos testes No Teste de Mutação, um caso de teste pode detectar um defeito por meio da comparação de sua execução sobre o programa original e sobre o programa mutante. Nesta Seção, definiu-se por um teste essas duas comparações que o caso de teste realiza para detectar defeitos. Dessa forma, pode-se contar a quantidade de testes que cada algoritmo realizou durante a interação entre as populações para o alcance das melhores soluções. O objetivo dessa contagem, consiste em visualizar o quanto as metaheurísticas podem reduzir a quantidade de testes comparadas ao teste exaustivo 8. Espera-se que as metaheurísticas reduzam a quantidade de testes e, consequentemente, reduzam o custo computacional exercido. As Figuras 5.3 e 5.4 apresentam a redução do custo computacional 9 realizada por cada algoritmo acerca da quantidade de testes realizados para convergência da solução. Todos os algoritmos, comparados ao teste exaustivo. 8 No presente Capítulo, o termo "teste exaustivo"se refere ao teste realizado considerando a execução de todos os casos de teste do conjunto sobre todos os programas mutantes gerados e a respectiva comparação com o resultado da execução sobre o programa original. O objetivo dos algoritmos consiste em selecionar um subconjunto de casos de teste para reduzir os conjuntos de casos de teste considerado para cada benchmark. 9 Nessa seção, o custo computacional refere-se à quantidade de testes (comparação dos resultados das execuções de um caso de teste sobre o programa original e sobre o programa mutante) e não ao tempo de execução.

97 5.4 Benchmarks escritos em linguagem Java 94 Figura 5.3: Experimentos Tamanho População Expandida - Redução do Custo Computacional X Algoritmos Figura 5.4: Experimentos Tamanho População Reduzida - Redução do Custo Computacional X Algoritmos No geral, os algoritmos AGC a AGC-GE, tiveram um melhor desempenho que os outros algoritmos na redução do custo computacional quando comparado ao teste exaustivo. Duas características desses algoritmos podem ter contribuído para esse resultado: 1. A boa utilização das informações existentes por meio da Classificação Genética; 2. A realização dos testes efetuada entre os melhores indivíduos (subconjunto) de uma população contra a população oposta. Percebe-se uma redução menor nos algoritmos A1, A2 e A2-GE cujos os testes efetuaram-se por meio da interação entre uma população contra a outra população.