Uma Abordagem Evolucionária para o Teste de Instruções SELECT SQL com o uso da Análise de Mutantes

Transcrição

1 Universidade Federal de Goiás Instituto de Informática Ana Claudia Bastos Loureiro Monção Uma Abordagem Evolucionária para o Teste de Instruções SELECT SQL com o uso da Análise de Mutantes Goiânia 2013

2

3 Ana Claudia Bastos Loureiro Monção Uma Abordagem Evolucionária para o Teste de Instruções SELECT SQL com o uso da Análise de Mutantes Dissertação apresentada ao Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás, como requisito parcial para obtenção do título de Mestre em Computação. Área de concentração: Ciência da Computação. Orientador: Prof. Celso Gonçalves Camilo Júnior Co-Orientador: Prof. Cássio Leonardo Rodrigues Goiânia 2013

4 Dados Internacionais de Catalogação na Publicação (CIP) GPT/BC/UFG M751a Monção, Ana Claudia Bastos Loureiro Uma Abordagem Evolucionária para o Teste de Instruções SELECT SQL com o uso da Análise de Mutantes [manuscrito] / Ana Claudia Bastos Loureiro Monção f. : il. Orientador: Prof. Dr. Celso Gonçalves Camilo Júnior; Coorientador: Prof. Dr. Cássio Leonardo Rodrigues. Dissertação (Mestrado) Universidade Federal de Goiás, Instituto de Informática, Bibliografia. Inclui lista de figuras e tabelas. Apêndice. 1. Teste de software. 2. Algoritmos genéticos. I. Título. CDU:

5

6

7 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador(a). Ana Claudia Bastos Loureiro Monção Graduou-se em Tecnólogo em Processamento de Dados pela Pontifícia Universidade Católica do Rio de Janeiro - PUC/RJ. Especializou-se em Engenharia Econômica e Administração da Produção pela Universidade Federal do Rio de Janeiro - UFRJ e em Governança de Tecnologia de Informação pela Pontifícia Universidade Católica de Goiás - PUC/GO. Atuou como Analista de Sistemas, na área de desenvolvimento, em empresas como IBM Brasil, Banco Brasileiro Comercial e Telecomunicações do Estado de Goiás e atualmente atua como Analista de Sistema, Administradora de Dados e Gerente de Projetos de desenvolvimento de software no Tribunal de Justiça do Estado de Goiás.

8 Dedico este trabalho: Ao meu marido Vinícius Monção e aos meus filhos Vitor e Luiza, que se privaram da minha presença em vários momentos durante esta pesquisa.

9 Agradecimentos Agradeço primeiramente à Deus que me deu mais uma grande oportunidade na vida de desenvolver este trabalho e conseguir concluir o mestrado. Agradeço à minha família pelo apoio e pela compreensão nos momentos em que estive ausente. Agradeço ao meu orientador Celso Gonçalves Camilo Júnior que soube conduzir as atividades de orientação possibilitando o alcance dos objetivos definidos, assim como motivar-me em relação ao objetivo final deste trabalho. Agradeço também aos professores Cássio Leonardo Rodrigues e Plínio de Sá Leitão Júnior que acompanharam e contribuíram no desenvolvimento deste trabalho, e aos demais professores do mestrado que me auxiliaram nos momentos em que precisei. Agradeço ainda aos alunos deste programa de pós-graduação com quem tive a oportunidade de estudar, pelo suporte que direta ou indiretamente deram-me durante este período. Agradeço aos meus colegas de trabalho que entenderam a minha ausência, me apoiaram e me motivaram em todos os momentos.

10 Ninguém é tão grande que não possa aprender, nem tão pequeno que não possa ensinar. Esopo.

11 Resumo Monção, Ana Claudia Bastos Loureiro. Uma Abordagem Evolucionária para o Teste de Instruções SELECT SQL com o uso da Análise de Mutantes. Goiânia, p. Dissertação de Mestrado. Instituto de Informática, Universidade Federal de Goiás. Teste de Software é uma área da Engenharia de Software de fundamental importância para a garantia da qualidade do software. São atividades que envolvem tempo e custos elevados, mas que precisam ser realizadas durante todo o processo de construção de um software. Assim como em outra áreas da Engenharia de Software, existem problemas nas atividades de Teste de Software cuja solução não é trivial. Para esses problemas, têm sido exploradas várias técnicas de busca e otimização tentando encontrar uma solução ótima ou perto da ótima, dando origem às linhas de pesquisa Search-Based Software Engineering (SBSE) e Search-Based Software Testing (SBST). O presente trabalho está inserido neste contexto e tem como objetivo solucionar o problema de seleção de dados de teste para execução de testes em instruções SQL. Dada a quantidade de soluções possíveis para este problema, a abordagem proposta combina técnicas de Análise de Mutantes SQL com Computação Evolucionária para encontrar um conjunto de dados reduzido que seja capaz de detectar uma grande quantidade de defeitos em instruções SQL de uma determinada aplicação. Baseada em uma perspectiva heurística, a proposta utiliza Algoritmos Genéticos (AG) para selecionar tuplas de um banco de dados existente (de produção) tentando reduzi-lo em um conjunto de dados relevante e efetivo. Durante o processo evolucionário, a Análise de Mutantes é utilizada para avaliação de cada conjunto de dados de teste selecionado pelo AG. Os resultados obtidos com a realização dos experimentos revelaram um bom desempenho utilizando a metaheurística dos Algoritmos Genéticos e suas variações. Palavras chave Teste de Software, Análise de Mutantes, Algoritmos Genéticos, Search- Based Software Testing, Search-Based Software Engineering.

12 Abstract Monção, Ana Claudia Bastos Loureiro. S. Goiânia, p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás. oftware Testing is an important area of Software Engineering to ensuring the software quality. It consists of activities that involve long time and high costs, but need to be made throughout the process of building software. As in other areas of software engineering, there are problems in the activities of Software Testing whose solution is not trivial. For these problems, several techniques of optimization and search have been explored trying to find an optimal solution or near optimal, giving rise to lines of research textit Search-Based Software Engineering (SBSE) and textit Search-Based Software Testing (SBST). This work is part of this context and aims to solve the problem of selecting test data for test execution in SQL statements. Given the number of potential solutions to this problem, the proposed approach combines techniques Mutation Analysis for SQL with Evolutionary Computation to find a reduced data set, that be able to detect a large number of defects in SQL statements of a particular application. Based on a heuristic perspective, the proposal uses Genetic Algorithms (GA) to select tuples from a existing database (from production environment) trying to reduce it to a set of data relevant and effective. During the evolutionary process, Mutation Analysis is used to evaluate each set of test data selected by the AG. The results obtained from the experiments showed a good performance using meta-heuristic of Genetic Algorithms, and its variations. Keywords Software testing, Mutation Analisys, Genetic Algorithms, Search-Based Software Testing, Search-Based Software Engineering.

13 Conteúdo Lista de Figuras 11 Lista de Tabelas 12 1 Introdução Motivação e Objetivos Trabalhos Relacionados Organização da Dissertação 19 2 Teste de Software Conceitos Análise de Mutantes Exemplos de Mutação Análise de Mutantes SQL Search-Based Software Engineering Meta-Heurísticas Hill Climbing Simulated Annealing Algoritmos Genéticos Meta-heurística aplicada na área de Teste de Software Considerações Finais 40 3 Computação Evolucionária Conceitos e Histórico Algoritmos Evolucionários Representação População Inicial Função Objetivo Operadores Genéticos 46 Seleção 46 Cruzamento (Crossover) 47 Mutação Condição de Parada Algoritmos Genéticos Algoritmo Genético Elitista In Vitro Fertilization Genetic Algorithm - IVF/GA Considerações Finais 57

14 4 Aplicação da Abordagem Utilizando Algoritmos Genéticos na Seleção de Dados de Teste para Instruções SQL Modelo de Representação 62 Modelo de Mapeamento Cartesiano Direto 64 Modelo de Mapeamento Cartesiano por Intervalos 67 Modelo de Mapeamento Direto Projeto dos Algoritmos Algoritmo Genético Canônico - AGCA Algoritmo Genético com Grupo de Eleitos - AGGE INVITRO Considerações Finais 72 5 Experimentos e Resultados Ambiente Instruções Experimentos Aleatórios Experimentos com AGCA Experimentos com AGGE Experimentos com INVITRO Considerações Finais 98 6 Conclusões e Trabalhos Futuros Contribuições Trabalhos Futuros 102 Bibliografia 103 A Implementação do AGCA 109 B Implementação do AGGE 130 C Implementação do INVITRO 132

15 Lista de Figuras 2.1 Processo de Análise de Mutantes Elementos de uma solução de otimização na geração de dados de teste (adaptada de Harman et al. (2009) Representação de um indivíduo - Codificação binária Estrutura básica de um Algoritmo Genético Roleta para Seleção dos Indivíduos da tabela Operação de Cruzamento com 1 ponto de corte Operação de Cruzamento com 2 pontos de corte Operação de Cruzamento Uniforme Operação de Mutação em um gene do cromossomo Acoplamento do IVF/GA ao AG Etapas do processo evolucionário do AGCA Diagrama de Classes do AG Modelo de Dados do Banco de Dados COMPANY Modelo de Dados do Banco de Dados de Experimentos Cromossomo que mapeia um indivíduo de tamanho 100 do Banco de Dados COMPANY Avaliação da Instrução 11 com AGCA Avaliação da Instrução 11 com AGGE Avaliação da Instrução 6 com INVITRO Avaliação da Instrução 10 com INVITRO Avaliação da Instrução 11 com INVITRO 96

16 Lista de Tabelas 2.1 Tabela de Operadores proposta por Tuya et al. (2007) Exemplo de Indivíduos e Aptidões Tabela Usuario Tabela Local Tabela Grupo Tabela ProdutoCartesiano-Usuario X Local X Grupo Cromossomo - Modelo Mapeamento Cartesiano Direto Tabela Usuario BDT Tabela Local BDT Tabela Grupo BDT Cromossomo - Modelo Mapeamento Cartesiano por Intervalos Cromossomo - Modelo Mapeamento Direto Configuração do Banco de Dados COMPANY Instruções Iniciais Tabela de Instruções com a Cobertura de Operadores e Categorias Resultados Iniciais de Experimentos Aleatórios (escores) Novas Instruções Derivadas Resultados Iniciais de Experimentos Aleatórios das Instruções Derivadas (Escores) Instruções Finais para os Experimentos usando AG Parâmetros AGCA Resultados dos Experimentos AGCA das Instruções Finais Selecionadas (Escores) Conjunto de resultados (AGCA) Resultados do AGCA com Variação de Tamanho de Cromossomo - Instrução Parâmetros AGGE Experimentos Aleatórios e usando AGGE Resultados do AGGE com Variação de Tamanho de Cromossomo - Instrução Resultados do INVITRO com Variação de Tamanho de Cromossomo Resultados Aleatórios, AGCA, AGGE, INVITRO 97

17 Introdução CAPÍTULO 1 Qualidade é uma característica importante na produção de um software, sendo requerida no processo e no produto relacionado. A norma ISO9126 (ISO/IEC, 2001) define qualidade como a totalidade de características e critérios de um produto ou serviço que exercem suas habilidades para satisfazer às necessidades declaradas ou envolvidas. Pressman (2009) define a qualidade de software como conformidade com requisitos funcionais e de desempenho explicitamente declarados, normas de desenvolvimento explicitamente documentadas e características implícitas, que são esperadas em todo software desenvolvido profissionalmente. Conforme Pressman (2009), a Engenharia de Software é uma disciplina de engenharia relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção. Teste de Software é uma das áreas da Engenharia de Software em que se busca a garantia da qualidade do software. Segundo Delamaro et al. (2007), o Teste de Software está inserido no contexto das atividades, coletivamente chamadas de Validação, Verificação e Teste, ou VV&T, que devem ser executadas durante a construção do software, com a finalidade de garantir que tanto o modo pelo qual o software está sendo construído quanto o produto que será entregue estejam em conformidade com o especificado. Dentre estas atividades, o teste é a mais utilizada e é considerada fundamental para a melhoria dos processos e produtos. Entretanto, é uma das atividades mais onerosas do processo de desenvolvimento de software (SOMMERVILLE, 2010). A qualidade dos testes é determinada pelos casos de teste utilizados. Para garantir um software livre de erros, ele deveria ser testado com todos os valores possíveis do domínio de entrada, porém, a realização de testes desta forma (exaustivo) é inviável em razão do grande número de valores de entradas possíveis (MCMINN, 2004). Diante dessa limitação, foram criadas as técnicas e os critérios de teste, que contribuem para geração, seleção e avaliação sistemática de um conjunto de casos de testes, garantindo que partes específicas de um programa sejam exercitadas. Segundo Delamaro et al. (2007), a atividade de teste deve ser conduzida de maneira

18 17 sistemática, aplicando essas técnicas e critérios para aumentar as chances de revelar defeitos e reduzir os custos. As técnicas mais comuns são: Técnica Estrutural: que utiliza o código fonte para estabelecer os casos de teste; Técnica Funcional: que estabelece os casos de teste baseados nos requisitos funcionais; Técnica Baseada em Erros: onde os elementos requeridos para caracterizar a atividade de teste são baseados em erros comuns que podem ocorrer durante a construção do software. Cada uma dessas técnicas possui um conjunto de critérios de teste, cuja diferença entre eles está na origem da informação utilizada para estabelecer os subdomínios e construir os casos de teste. Entre eles, o critério da Análise de Mutantes, da técnica de teste baseados em erros que, segundo Vincenzi (1998), tem se mostrado, através de estudos teóricos e empíricos, altamente eficaz em revelar a presença de erros, e com isso, avaliar o quanto um conjunto de casos de teste está adequado a um código em teste. A aplicação dessas técnicas e critérios é fundamental para uma seleção cuidadosa de dados de teste, porém, esta tarefa é muitas vezes difícil, demorada e propensa a erros. Assim, a necessidade de diminuir o tempo e os custos dos testes de software, e ao mesmo tempo aumentar a sua eficácia tem motivado a pesquisa de técnicas avançadas onde dados de teste são gerados automaticamente. É uma área de pesquisa ativa onde existem vários trabalhos com diferentes abordagens, como apresentados em McMinn (2004), Ali et al. (2010), Freitas et al. (2010) e McMinn (2011). Assim como qualquer código, instruções de consulta SQL (Structured Query Language) precisam ser testadas para garantir a qualidade do produto a ser entregue. Elas são amplamente utilizadas em aplicações que fazem uso de bancos de dados objeto-relacionais, sendo componentes importantes do software por tratar justamente da interface entre a aplicação e o repositório de dados. Para a realização de testes em instruções de consultas SQL é necessário a existência de um conjunto de tuplas que atenda aos requisitos da instrução, visto que o domínio de entrada para as consultas são as tuplas de um banco de dados. Encontrar um conjunto de tuplas otimizado, ou seja, pequeno e que consiga revelar grande parte dos erros, não é uma tarefa trivial. Pode ser considerada uma tarefa de otimização, onde estão envolvidos aspectos combinatórios que manualmente são inviáveis de serem tratados. Vários pesquisadores têm aplicado diferentes técnicas de busca e otimização tentando encontrar soluções para problemas deste tipo, ou seja, problemas pertinen-

19 1.1 Motivação e Objetivos 18 tes ao processo de construção de software, difíceis de serem resolvidos através das normas e metodologias convencionais. Normalmente são problemas envolvendo a seleção de uma solução em um conjunto muito grande de possibilidades (VERGILIO et al., 2012). Podem ser encontrados vários trabalhos com esse foco na literatura, onde os problemas da Engenharia de Software são reformulados como problemas de otimização e busca, linha de pesquisa referida, a partir de 2001, como Search-Based Software Engineering (SBSE), de acordo com Harman e Jones (2001). E também para problemas específicos da área de Teste de Software, linha de pesquisa conhecida como Search-Based Software Testing (SBST ). 1.1 Motivação e Objetivos Mesmo sendo uma linguagem relativamente simples e bem consolidada, é muito comum cometer erros durante a definição e/ou escrita de instruções SQL. Sejam erros sintáticos, que são aqueles que as regras da linguagem são infligidas e o próprio SGBD (Sistema de Gerenciamento de Banco de Dados) já consegue identificá-los, ou erros semânticos, que são aqueles que sintaticamente a instrução está correta porém o resultado gerado é diferente do esperado. Por serem um importante conjunto de componentes de softwares que utilizam bancos de dados objeto-relacional, as instruções SQL precisam passar por atividades de teste tentando garantir a qualidade do software antes de ser entregue. No contexto de testes de instruções SQL, o domínio de entrada para a execução dos testes possui um ou mais bancos de dados. O uso do banco de dados de produção para os testes, mesmo em um ambiente separado, pode ter um custo computacional muito elevado considerando a existência de bancos de dados gigantescos e a complexidade de algumas instruções SQL. Além disso, de acordo com as boas práticas da Engenharia de Software, testes devem ser executados em ambientes próprios, sendo que o uso do mesmo ambiente de produção para a realização dos testes representa um sério risco, podendo comprometer o funcionamento das aplicações em produção. Nesse cenário, é pertinente o emprego de bancos de dados de teste que sejam adequados ao teste das instruções SQL, com respeito à detecção de potenciais defeitos nessas instruções e à redução do custo associado ao teste. Estes bancos de dados podem ser gerados, através de alguma abordagem específica ou selecionados, ou seja, extraídos de um banco de dados existente. Considerando que exista um banco de dados real no ambiente de produção, o problema atribuído a esta pesquisa é encontrar um banco de dados reduzido,

20 1.2 Trabalhos Relacionados 19 que tenha a mesma capacidade, ou muito próxima, do banco de produção no que diz respeito à revelar defeitos. Para isso, foi escolhida uma abordagem heurística para seleção de um conjunto de tuplas desse banco de dados, que consiga revelar o maior número de defeitos possível, ou seja, uma quantidade de defeitos igual ou bem próxima a que o banco de produção revelaria se fosse usado como dado de entrada para os testes. E para a avaliação da adequação dos dados selecionados às instruções em teste, foi utilizado o critério de Análise de Mutantes, da técnica de teste baseada em erros. O objetivo dessa dissertação é resolver o problema de seleção de dados de teste para execução dos testes em instruções SQL. Selecionar, dentro do domínio de tuplas de um banco de dados existente, um conjunto de tuplas de qualidade, que consiga auxiliar na detecção da maioria de defeitos das instruções SQL de uma aplicação. Para isso, foram utilizados os princípios da Computação Evolucionária, para o processo de seleção e evolução dos dados de teste, através de três algoritmos evolucionários, e a Análise de Mutantes SQL para a avaliação. 1.2 Trabalhos Relacionados Foram avaliados trabalhos relacionados à geração de dados de teste utilizando meta-heurísticas, aplicação de Análise de Mutantes com meta-heurísticas e geração de dados de testes para testes de instruções SQL, principalmente utilizando a Análise de Mutantes. Não foram encontrados trabalhos, na literatura, seguindo a mesma ideia desta dissertação, ou seja, seleção de dados de teste para testes de instruções SQL usando Algoritmos Evolucionários no processo de seleção e a Análise de Mutantes como método de avaliação dos dados selecionados. Como detalhado a seguir, foram encontrados alguns trabalhos relacionados com os seguintes aspectos: geração de dados de teste utilizando meta-heurísticas mas nenhum deles para instruções SQL; geração de dados de testes utilizando meta-heurísticas para matar mutantes, mas não relacionados com mutação de instruções SQL; geração de bancos de dados para teste de instruções SQL mas sem a utilização de meta-heurísticas; e redução de bancos de dados para aplicação de teste também sem a utilização de meta-heurísticas. Com relação à geração de dados de teste utilizando meta-heurísticas, foram encontrados vários trabalhos. Korel (1990) propõe um gerador de dados de teste para o qual o programa a ser testado é a entrada. O gráfico de controle de fluxo do programa é gerado, os caminhos possíveis são percorridos, e então os dados necessários para percorrer os caminhos possíveis são gerados. Mansour et al. (2001) utilizam meta-heurísticas para seleção de casos de teste e fazem uma comparação

21 1.2 Trabalhos Relacionados 20 entre cinco algoritmos: Simulated Annealing, Reduction, Slicing, Dataflow, e Firewall, tendo como função de avaliação a cobertura de código obtida pelos casos de teste. A comparação foi baseada em oito critérios quantitativos e qualitativos: número de casos de teste, tempo de execução, precisão, inclusividade (o quanto a técnica seleciona casos que cobrem falhas na nova versão), processamento dos requisitos, tipo de manutenção, nível de teste e tipo de abordagem. Os resultados mostraram que as técnicas apresentam resultados diferentes dependendo do critério utilizado. Em relação ao algoritmo Simulated Annealing, por exemplo, os resultados indicaram boas soluções nos critérios de número de casos de teste e precisão (FREITAS et al., 2010). Michael et al. (2001) apresentam uma proposta de geração e evolução de dados de teste através de Algoritmos Genéticos. Bottaci (2001) descreve uma nova abordagem evolucionária, baseada na otimização de colônia de formigas, para geração automática de dados de testes no contexto de teste de mutação, com o objetivo de redução do custo desta técnica de teste. Hermadi (2003) mostra um gerador de dados de teste baseado em Algoritmos Genéticos. Khor e Grogono (2004) também aplicam esta mesma meta-heurística na geração de dados de teste para determinada cobertura, e Louzada et al. (2012) fazem uso de um algoritmo genético com uma abordagem elitista para geração de dados de testes para programas desenvolvidos em linguagem java, cujo domínio de entrada são números reais. Também utilizam a Análise de Mutantes como método de avaliação dos dados gerados. O artigo de Ali et al. (2010) apresenta uma revisão sistemática de trabalhos na área de Search-Based Software Testing visando a avaliação de estudos empíricos, da aplicação de meta-heurísticas na geração de casos de teste, principalmente quanto ao custo e efetividade. Além desses, o survey de McMinn (2004) e o review elaborado por Vergilio et al. (2012) citam vários trabalhos realizados em geração de dados de teste usando meta-heurísticas. Entretanto, nenhum dos trabalhos encontrados, relacionados à otimização na geração de dados de teste usando meta-heurísticas, foi aplicado à instruções SQL, ou seja, à geração de instâncias de banco de dados. Com relação à geração de dados de teste, usando meta-heurísticas, e aplicação da Análise de Mutantes, foram encontrados os seguintes artigos relevantes: Masud et al. (2005), que trabalha com a divisão do programa em unidades menores e utiliza Algoritmos Genéticos para geração de dados de teste simples para matar mutantes, não tendo referência com bancos de dados; e May et al. (2007), que compara o Algoritmo Genético canônico com um algoritmo de bactérias (Immune Inspired) na geração de dados de teste, mostrando que este segundo trabalha com indivíduos especialistas que matam mutantes não mortos por um conjunto de

22 1.2 Trabalhos Relacionados 21 indivíduos, apresentando assim melhores resultados. Nenhum deles fez referência a banco de dados, apenas geração de dados de teste simples. Com relação a testes de bancos de dados, o artigo de Mannila e Raiha (1986) propõe a geração automática de um banco de dados adequado para testes de determinada instrução SQL, mas sem a utilização de meta-heurísticas. O mesmo acontece como o artigo de Chays et al. (2004), que propõe uma ferramenta para geração de casos de testes para aplicações com bancos de dados relacionais, baseados no esquema e nas restrições do banco de dados, usando instruções SQL simples. Gupta et al. (2010) trabalham a geração de dados de teste para matar mutantes SQL considerando as mutações nas cláusulas JOIN e nos operadores relacionais. Shah et al. (2011), além dos JOINS e dos operadores relacionais, acrescentam a geração de dados de teste para matar os mutantes dos comandos de agregação. Esses dois últimos trabalhos apresentam técnicas de geração de dados de teste, para avaliar a corretude de instruções SQL, baseada nos mutantes gerados pelas instruções, com o objetivo de matar a maior quantidade de mutantes usando os dados gerados. Os resultados foram considerados eficientes para as classes de mutantes envolvidas, porém não utilizam meta-heurísticas nem evolução dos dados de testes. Os dados são gerados seguindo as regras das instruções SQL e dos mutantes a serem mortos. Outro trabalho muito interessante é o de Tuya et al. (2009), onde apresentam uma estratégia de redução de um banco de dados de produção para realização de testes, através de regras de cobertura de algumas instruções SQL e usando a Análise de Mutantes como método de avaliação. Cria também uma ferramenta chamada QAShrink para automatizar a redução. Os resultados obtidos mostraram uma grande redução mantendo a cobertura bem próxima à do banco de dados de produção. Este trabalho está relacionado à ideia de redução do banco de dados, porém não utiliza meta-heurísticas, faz a redução em cima de regras das instruções SQL. Gupta et al. (2010) e Shah et al. (2011) são trabalhos muito semelhantes que tratam de geração de bancos de dados de teste, baseados em mutantes de determinadas cláusulas SQL. Já Tuya et al. (2009) consideram um banco de dados existente e trabalham com a redução deste, similar à proposta desta dissertação, mas sem a utilização de meta-heurísticas. Não utilizam seleção seguida de evolução dos dados, selecionam as tuplas de acordo com regras de cobertura das instruções SQL. Todos os trabalhos encontrados usando meta-heurísticas tratam de geração de dados de teste simples como valores numéricos, decimais, caracteres, etc, onde os programas testados não são relacionados a banco de dados. Como mencionado no Capítulo 2, Seção 2.3, e nos parágrafos anteriores, existem vários trabalhos

23 1.3 Organização da Dissertação 22 relacionados à geração de dados de teste para instruções SQL mas nenhum deles utilizando meta-heurísticas. Todos foram baseados em alguma regra de cobertura ou com o objetivo de matar tipos de mutantes. Não aplicaram evolução dos dados, ou seja, não utilizaram um processo evolucionário baseado em alguma meta-heurística como é a proposta deste trabalho. Já para redução de bancos de dados, ou seja, seleção de tuplas de um banco de dados existente, os trabalhos avaliados utilizam métodos determinísticos que, dependendo do conjunto de soluções possíveis para o problema, podem ser inviáveis. Como este trabalho trata deste assunto, e considerando que o banco de dados de produção pode ter uma dimensão muito grande, justifica-se o uso de meta-heurísticas para a seleção das tuplas. 1.3 Organização da Dissertação De acordo com a motivação e metodologia definida e visando a alcançar os objetivos, esta dissertação foi organizada da seguinte forma: o Capítulo 2 apresenta alguns conceitos da área de Teste de Software, um estudo detalhado sobre Análise de Mutantes e sobre a Análise de Mutantes aplicada para SQL. Descreve também a aplicação de técnicas de otimização em teste de software, apresentando a linha de pesquisa Search-Based Software Engineering - SBSE, conceitos de meta-heurísticas e a aplicação destas na área de teste de software, conhecida como Search-Based Software Testing - SBST ; o Capítulo 3 apresenta algumas definições sobre Computação Evolucionária, Algoritmos Evolucionários e Algoritmos Genéticos; o Capítulo 4 define o problema, o ambiente criado e a abordagem proposta; o Capítulo 5 apresenta os experimentos realizados e os resultados obtidos; o Capítulo 6 apresenta as considerações finais, destacando as contribuições advindas deste trabalho à atividade de teste e os possíveis desdobramentos em novos trabalhos futuros. o Apêndice A apresenta o Algoritmo Genético Canônico (AGCA) implementado; o Apêndice B apresenta as alterações realizadas para a implementação do Algoritmo Genético com Grupo de Eleitos (AGGE); o Apêndice C apresenta as alterações realizadas para a implementação do Algoritmo Auxiliar Paralelo (INVITRO).

24 Teste de Software CAPÍTULO 2 Este capítulo apresenta uma breve introdução sobre conceitos inerentes ao Teste de Software, principalmente no que diz respeito ao Teste de Mutação. É apresentada a importância desta atividade dentro da Engenharia de Software, os objetivos, os tipos de teste, e as técnicas e critérios existentes para aplicação de teste de forma sistematizada. Aborda em maiores detalhes o critério de Análise de Mutantes da técnica de teste baseado em defeitos, principalmente no contexto de instruções SQL. Posteriormente descreve a aplicação de técnicas de busca e otimização na área de Teste de Software. Apresenta a Search-Based Software Engineering (SBSE), área onde métodos de pesquisa (algoritmos de busca) são utilizadas para a solução de problemas de Engenharia de Software. Apresenta conceitos de meta-heurísticas e o funcionamento de algumas, consideradas as mais utilizadas nesta área (HARMAN et al., 2009). Finalizando, aborda a aplicação dessas meta-heurísticas em problemas de Teste de Software, área de pesquisa conhecida como Search-Based Software Testing (SBST ). 2.1 Conceitos A complexidade no desenvolvimento de software tende a aumentar com a diversidade de ambientes tecnológicos e a necessidade de informação cada vez maior e mais rápida do ser humano. Por isso, e tentando garantir a qualidade do produto a ser entregue, as organizações têm investido na melhoria de processos e métodos de desenvolvimento, principalmente no que diz respeito a Verificação, Validação e Teste de Software que muitas vezes são atividades ignoradas durante o processo de software. Softwares são encontrados na maioria das atividades do nosso dia-a-dia, e o seu funcionamento correto é uma necessidade real. Uma falha pode ocasionar desde perdas de menor escala até danos muito relevantes, tais como, prejuízo financeiro e risco de vida.

25 2.1 Conceitos 24 A construção de software não é uma tarefa simples, pelo contrário, pode ser bastante complexa dependendo das características e dimensões do sistema a ser criado. Como na maioria das atividades de engenharia, a construção de software depende, principalmente, da habilidade, da interpretação e da execução das pessoas que o constroem. Por isso, erros acabam surgindo, mesmo com a utilização de métodos e ferramentas de Engenharia de Software, afirma Delamaro et al. (2007). Segundo Pressman (2009), a Engenharia de Software é uma disciplina de engenharia relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção. Ela introduz várias atividades de garantia de qualidade no processo de desenvolvimento de software buscando minimizar os problemas. De acordo com Delamaro et al. (2007), para que os erros sejam descobertos antes do software ser liberado para utilização, existe uma série de atividades, coletivamente chamadas de Validação, Verificação e Teste, ou VV&T, com a finalidade de garantir que tanto o modo pelo qual o software está sendo construído quanto o produto que será entregue estejam em conformidade com o especificado. Atividades de VV&T, segundo Delamaro et al. (2007), podem ser divididas em estáticas e dinâmicas. As estáticas são aquelas que não requerem execução ou existência de um programa executável, já as dinâmicas são aquelas que se baseiam na execução de um programa ou modelo. Teste de Software é uma das áreas da Engenharia de Software em que se busca a garantia da qualidade do software, contribuindo continuamente para a melhoria dos processos e produtos. De acordo com Myers (1979), teste é o processo de executar um programa com a intenção de encontrar defeitos ; e segundo Delamaro et al. (2007), se enquadram na categoria de atividades de VV&T dinâmicas pois executam um programa ou modelo com objetivo de verificar se o comportamento está de acordo com o esperado. Estas atividades não se restringem ao produto final, podem e devem ser conduzidas durante todo o processo de desenvolvimento do software, desde a sua concepção, e englobam diferentes técnicas. As atividades de testes são dividida, de uma forma geral, nas seguintes fases com objetivos distintos (DELAMARO et al., 2007): Teste de unidade, aplicado nas menores unidades de um programa separadamente; Teste de integração, realizado após serem testadas todas as unidades individualmente, com ênfase na construção da estrutura do sistema e integração entre as diversas partes do sistema;

26 2.1 Conceitos 25 Teste de sistema, realizado após a integração de todas as partes do sistema com o objetivo de verificar se as funcionalidades especificadas foram corretamente implementadas. Além dessas três fases, destaca-se também o que se chama de teste de regressão. Esse tipo de teste não se realiza durante o processo normal de desenvolvimento, mas sim durante a manutenção do software, com o objetivo de verificar se os novos requisitos estão corretos e se os requisitos testados anteriormente continuam válidos (DELAMARO et al., 2007). O principal objetivo do teste é revelar a presença de defeitos no software para que possam ser corrigidos antes que causem algum dano, o que aumenta a confiabilidade do software. Idealmente, a atividade de teste deve ser conduzida de maneira sistemática, aplicando-se técnicas para balancear a redução de custo e o aumento das chances em revelar defeitos, caso existam. Tais técnicas definem elementos requeridos, que representam requisitos a serem cobertos durante o teste. Delamaro et al. (2007) identifica três técnicas para o teste de software: Estrutural, também conhecida como teste caixa-branca, em que os elementos requeridos são derivados da estrutura do software; Funcional, também conhecida como teste caixa-preta, em que os elementos requeridos são derivados da especificação funcional do software; Baseado em Erros, que consiste na utilização de erros típicos do processo de implementação de software para que sejam derivados os requisitos de teste. Cada uma dessas técnicas possui critérios de teste, que podem ser usados na geração, seleção e avaliação de um conjunto de casos de testes. A utilização das técnicas ocorre por meio da aplicação de um desses critérios, que estabelece os elementos requeridos a serem exercitados no teste (GOODENOUGH; GERHART, 1975). A diferença entre eles está na origem da informação utilizada para estabelecer os subdomínios e construir os casos de teste. Alguns exemplos são: (i) o critério estrutural Todos-comandos, que requer que cada comando do programa seja executado pelo menos uma vez durante o teste; (ii) o critério funcional Análise do valor limite, que divide o domínio de entrada do software em partições e requer que os limites de cada partição sejam testados pelo menos uma vez durante o teste; (iii) o critério Análise de Mutantes ou Teste de Mutação que consiste em semear erros no programa original gerando programas mutantes e avaliar o comportamento dos mutantes com relação ao original. Uma grande dificuldade é encontrar casos de testes adequados, que garantam uma cobertura significativa, ou seja, que consigam abranger a maioria das situações

27 2.2 Análise de Mutantes 26 existentes no contexto e identificar grande parte dos defeitos. A utilização de abordagens e técnicas de testes procura atingir esse objetivo com custos computacional e operacional aceitáveis. A Análise de Mutantes é uma dessas abordagens, que funciona como uma maneira de mensurar o quanto um conjunto de testes está adequado e, consequentemente, ajuda a orientar na evolução e definição de novos casos de teste (DEMILLO et al., 1978). 2.2 Análise de Mutantes O sucesso da atividade de testes em revelar defeitos de um programa está diretamente relacionado com a qualidade do conjunto de casos de teste usado para testar o programa. Avaliar os casos de teste é um ponto crucial na atividade de teste. O objetivo é conseguir identificar e projetar casos de teste com maior poder em revelar uma grande quantidade de defeitos com o menor tempo e esforço possível (BARBOSA et al., ). Para atingir este objetivo, é necessário aplicar técnicas e critérios de teste visando sistematizar a atividade de teste e auxiliar na geração dos casos de teste, bem como na avaliação da qualidade desses casos de teste. A Análise de Mutantes ou Teste de Mutação é um dos critérios usados para este fim. De acordo com DeMillo et al. (1978), o teste baseado na Análise de Mutantes, ou Teste de Mutação, é um critério da técnica de testes baseada em defeitos que tem como ideia básica a de que defeitos considerados no teste representam enganos que programadores cometem frequentemente. Sendo assim, tais defeitos são propositalmente inseridos no software original por meio de uma mudança sintática simples, feitas para criar um conjunto de programas defeituosos. Cada um desses programas chamados de Mutantes contém uma mudança sintática distinta. Para avaliar a qualidade de um conjunto de dados de teste, esses mutantes são executados com os mesmos dados de teste executados pelo programa original, verificando se os defeitos semeados podem ser detectados. Vários trabalhos relacionados a teste de mutação foram publicados por Jeff Offutt 1, e análises atuais de trabalhos nesta área podem ser encontradas em Delamaro et al. (2007) e em Jia e Harman (2011), onde fazem uma revisão geral sobre o desenvolvimento da Análise de Mutantes. A figura 2.1 representa um processo de teste de um programa P usando a Análise de Mutantes. Esse processo é realizado da seguinte forma: 1

28 2.2 Análise de Mutantes 27 Figura 2.1: Processo de Análise de Mutantes Pequenas mudanças sintáticas no programa original P são efetuadas, a partir de operadores de mutação definidos de acordo com a sintaxe da linguagem. Com essas mudanças, é gerado um conjunto de programas mutantes P. Após a geração dos programas mutantes, um conjunto de dados de teste T é executado no programa original P e as saídas produzidas são checadas em relação ao esperado. Cada mutante P é então executado com cada dado de teste t do conjunto T. Se o resultado da execução de P é diferente do resultado da execução de P para algum dado de teste t, então o mutante P é considerado morto, caso contrário, P continua vivo (BARBOSA et al., ). O nível de adequação de um conjunto de dados de teste, sob a perspectiva da Análise de Mutantes, é dado pelo chamado escore de mutação, que é uma medida de cobertura do critério de Análise de Mutantes. Em Demillo (1980) e Andrews et al. (2005), destaca-se a capacidade que a Análise de Mutantes tem em fornecer uma medida objetiva do nível de confiança da adequação dos casos de teste analisados através da definição de um escore de mutação, que relaciona o número de mutantes mortos com o número de mutantes não equivalentes gerados. Um mutante é considerado equivalente quando sua modificação não influencia no comportamento do programa. Dado um programa P e um conjunto de dados de teste T, o cálculo do escore de mutação MS(P,T) é feito da seguinte forma: Sendo: MS(P,T ) = DM(P,T ) M(P) EM(P) DM(P,T ) : quantidade de mutantes mortos pelos casos de teste em T M(P) : quantidade total de mutantes gerados. EM(P) : número de mutantes equivalentes a P.

29 2.2 Análise de Mutantes 28 O valor de MS(P,T ) varia entre 0 e 1, sendo que quanto maior este valor, mais adequado é o conjunto de casos de teste T para o programa sendo testado. Ou seja, quanto maior este valor, maior o número de programas mutantes (P ) mortos significando que o conjunto de casos de teste T conseguiu detectar uma grande quantidade de defeitos inseridos no programa. Segundo Jia e Harman (2011), a teoria da Análise de Mutantes é baseada em duas hipóteses fundamentais: a hipótese do programador competente e a hipótese do efeito de acoplamento. A primeira hipótese estabelece que os programadores são competentes e, portanto, tendem a desenvolver programas que são próximos da versão correta. Deste modo, embora os programas possam conter defeitos, assume-se que esses defeitos são simples e podem ser corrigidos com pequenas alterações sintáticas. Com base nesta hipótese a Análise de Mutantes aplica apenas mudanças sintáticas simples, simulando defeitos inseridos por programadores competentes. A hipótese do efeito de acoplamento estabelece que dados de teste que distinguem todos os programas diferentes do programa correto apenas por erros simples são tão sensíveis, que eles também distinguem erros mais complexos. Portanto, defeitos complexos estão acoplados a defeitos simples de uma maneira tal que dados de teste que detectam os defeitos simples também irão detectar um alto percentual de defeitos complexos Exemplos de Mutação Operadores de Mutação são regras que definem as alterações que serão aplicadas em um programa P, dando origem aos programas mutantes. A seleção dos operadores a serem usados no processo depende, entre outros fatores, da sintaxe da linguagem, da abrangência do teste e do custo. Quanto maior o número de operadores utilizados, maior o número de mutantes gerados. Segundo Richard et al. (1989), para a linguagem C, por exemplo, foram definidos 75 operadores de mutação, divididos em 4 categorias : Mutação de Comandos; Mutação de Operadores; Mutação de Variáveis; Mutação de Constantes. Considerando o código na linguagem C, a seguir: while (a < 10) {

30 2.3 Análise de Mutantes SQL 29 c[a] = a+b; a++; c[a] = 0; Um exemplo de um mutante gerado com um operador da categoria de mutação de comandos pode ser a alteração da posição de uma linha do código, como mostrado a seguir: while (a < 10) { c[a] = a+b; a++; c[a] = 0; Outro exemplo usando um operador da categoria de mutação de operadores é a troca de operadores relacionais, como a troca do < pelo =, mostrado logo abaixo: while (a = 10) { c[a] = a+b; a++; c[a] = 0; Assim como essas, várias outras alterações são realizadas de acordo com os operadores selecionados. 2.3 Análise de Mutantes SQL A Análise de Mutantes foi proposta inicialmente para ser usada em linguagens de programação como o Fortran e Ada. Posteriormente a técnica começou a ser aplicada em outras linguagens, interfaces, especificações e modelos. Para cada novo contexto, novos e específicos operadores de mutação eram criados para adequação da técnica. Em tese, tendo definidos os operadores de mutação, o processo da Análise de Mutantes continua o mesmo independente da linguagem. Desta forma, existindo operadores específicos, a técnica pode ser utilizada para testes de instruções SQL, e com isso avaliar a qualidade de casos de teste específicos para aplicações de banco de dados.

31 2.3 Análise de Mutantes SQL 30 Chan et al. (2005) projetaram sete operadores de mutação para a linguagem SQL. Depois foi proposto um outro conjunto de operadores por Tuya et al. (2007). Este conjunto foi organizado em quatro categorias, sendo elas: SC - Mutação das principais cláusulas SQL; OR - Mutação dos operadores que estão presentes em condições e expressões; NL - Mutação relacionada a manipulação de valores nulos; IR - Mutações de identificadores: colunas, constantes e parâmetros; Cada categoria define vários operadores de mutação, classificados em tipos e subtipos, sendo que cada um refere-se a um determinado tipo de alteração aplicada nas instruções SQL. A tabela 2.1 apresenta os operadores, por categoria, propostos por Tuya et al. (2007).

32 2.3 Análise de Mutantes SQL 31 Num Categoria Operador Descrição 1 SEL Troca do comando SELECT por SELECT DISTINCT 2 JOI Troca entre comando de JOIN (INNER JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN, FULL OUTER JOIN, CROSS JOIN) 3 SUB Mutação de predicados das subqueries 4 SC GRU Remoção da expressão GROUP BY 5 AGR Troca entre as funções de agregação (MIN, MAX, AVG, AVG(DISTINCT), SUM, SUM(DISTINCT), COUNT, COUNT(DISTINCT)) 6 UNI Troca entre os comandos UNION e UNION ALL ou remoção de queries com UNION 7 ORD Troca de parâmetros da ordenação ASC, DESC ou remoção da expressão de ordenação 8 ROR Troca entre operadores relacionais (=,<>,<,<=,>,=>) ou troca da expressão falso ou verdadeiro 9 LCR Troca entre operadores lógicos (AND, OR), troca a expressão pelos valores falso ou verdadeiro, troca a expressão para retornar o operando da direita ou da esquerda 10 OR UOI Cada expressão aritmética ou referência para um número n é trocada para -n,n+1 en-1 11 ABS Cada expressão aritmética ou referência para um número n é trocada por ABS(n) e -ABS(n) 12 AOR Troca entre operadores aritméticos (+,-,*,/,%) ou troca pelo retorno no operando da esquerda ou da direira 13 BTW Troca das expressões z BETWEEN x AND y por z>x AND z<=y e por z>=x AND z<y 14 LKE Alterações nas condições usando LIKE (removendo, trocando e adicionando coringas) 15 NLF Troca entre os predicados IS NULL e IS NOT NULL 16 NLS Troca cada coluna c da lista de seleção por um valor fora do domínio de c quando o valor de c é nulo NL 17 NLI Força um valor verdadeiro da condição quando existe um valor nulo, cada atributo a em uma condição C é trocado por C OR a IS NULL 18 NLO Cada atributo a em uma condição C é trocado por NOT C OR a IS NULL, a IS NULL, a IS NOT NULL 19 IRC Troca de cada coluna da cláusula SELECT por outra coluna, constante ou parâmetro de tipo compatível 20 IRT Troca de cada constante da cláusula SELECT por outra coluna, constante ou parâmetro de tipo compatível IR 21 IRP Troca de cada parâmetro da cláusula SELECT por outra coluna, constante ou parâmetro de tipo compatível 22 IRH Troca de cada referência a uma coluna por outra coluna da mesma tabela Tabela 2.1: Tabela de Operadores proposta por Tuya et al. (2007)

33 2.3 Análise de Mutantes SQL 32 Para ilustrar a geração de mutantes em instruções SQL, será apresentada, a seguir, uma instrução SQL original e alguns exemplos de mutantes de cada categoria: Instrução SQL original: SELECT * FROM EMPLOYEE WHERE (SALARY BETWEEN 1000 AND 1500) AND DNO=5 Exemplos de mutantes: Categoria SC - Operador SEL SELECT DISTINCT * FROM EMPLOYEE WHERE (SALARY BETWEEN 1000 AND 1500) AND DNO=5 Categoria OR - Operador ABS SELECT * FROM EMPLOYEE WHERE (ABS(SALARY) BETWEEN 1000 AND 1500) AND DNO=5 Categoria NL - Operador NLO SELECT * FROM EMPLOYEE WHERE ((SALARY IS NULL)) AND DNO=5 Categoria IR - Operador IRT SELECT * FROM EMPLOYEE WHERE (SALARY BETWEEN 5 AND 1500) AND DNO=5 Em 2006, no artigo de Tuya et al. (2006), foi criada uma ferramenta de geração de mutantes para instruções SQL, a SQLMutation, que implementa todos estes operadores. No mesmo artigo, também foi realizada uma avaliação dos resultados do uso desta ferramenta. Ela pode ser encontrada e utilizada no site do grupo de pesquisa de Engenharia de Software da Universidade de Oviedo 2 através de uma interface Web. O artigo de Derezinska (2009) mostra uma avaliação desses operadores de mutação com relação à quantidade de mutantes gerados, à quantidade de mutantes mortos e ao escore de mutação para determinadas instruções SQL de um banco de dados de uma companhia de seguros. Vários outros estudos usando Análise de Mutação para instruções SQL foram encontrados, entre eles: Suárez-Cabal e Tuya (2009), que mostra um critério de cobertura estrutural para avaliação um conjunto de instruções SQL em teste e usa o escore de mutação como o método de avaliação; Tuya et al. (2009), que mostra a redução de uma base de dados direcionada a encontrar os requisitos para testar um determinado conjunto de instruções SQL; e Blanco et al. (2012), que propõe uma abordagem para geração de dados de teste para aplicações de bancos de dados, considerando não apenas instruções SQL, mas também as interfaces com os usuários. 2

34 2.3 Análise de Mutantes SQL 33 Casos de Teste para Análise de Mutantes SQL Além dos operadores de mutação, outro aspecto importante para a análise de mutantes SQL são os casos de teste. Cabeca et al. (2010) definem que no contexto de aplicações de banco de dados, um caso de teste é formado por: Dados de entrada para o programa; Conjunto de instâncias de bancos de dados; Saída esperada e instância do banco de dados esperada. A qualidade das instâncias dos bancos de dados utilizadas nos teste é determinante para permitir uma maior revelação de defeitos. Os dados destas instâncias (dados de teste) podem ser gerados ou selecionados de bancos de dados existentes. Com relação à geração de dados de teste para instruções SQL, pode-se encontrar vários trabalhos na literatura. O artigo de Mannila e Raiha (1986) propõe a geração automática de um banco de dados adequado para testes de determinada instrução SQL. Uma ferramenta para geração de casos de testes para aplicações com bancos de dados relacionais foi proposta no artigo Chays et al. (2004). O artigo Gupta et al. (2010) trabalha a geração de dados de teste para matar mutantes SQL, considerando as mutações nas cláusulas JOIN e nos operadores relacionais. O artigo Shah et al. (2011), além dos JOINS e dos operadores relacionais, acrescenta a geração de dados de teste para matar os mutantes dos comandos de agregação. Os dois trabalhos consideraram os resultados eficientes para as classes de mutantes envolvidas. A seleção de dados de teste para instruções SQL, a partir de um banco de dados existente, seria a extração de tuplas deste banco de dados. Procura-se extrair um subconjunto de dados adequado que consiga garantir uma maior cobertura dos defeitos, com a menor quantidade de tuplas possível. Nesse contexto, trabalhando com bancos de dados de grande escala, o espaço de busca para seleção dos dados pode ser considerado muito grande. Sendo assim, este problema pode ser caracterizado como um problema de otimização. Neste caso, o uso de métodos que buscam uma solução ótima é muitas vezes impraticável. Duas opções para realizar a seleção seriam: 1. Selecionar aleatoriamente um subconjunto de dados; 2. Realizar a seleção através de um processo, com critérios específicos, que busque fazer a escolha de um bom subconjunto de dados. De acordo com nossos estudos, em muitos casos uma simples seleção aleatória é suficiente para proporcionar um bom subconjunto de dados. Porém, algumas