FERRAMENTA PARA GERAÇÃO DE TESTES AUTOMATIZADOS EM JAVA

Transcrição

1 Universidade do Estado de Santa Catarina Centro de Educação Superior do Alto Vale do Itajaí Departamento de Engenharia de Software FERRAMENTA PARA GERAÇÃO DE TESTES AUTOMATIZADOS EM JAVA Samuel Yuri Deschamps UDESC Resumo Este documento apresenta o desenvolvimento de uma ferramenta para geração de testes automatizados de regressão em formato JUnit. São explicadas três técnicas de testes implementadas neste gerador: análise de cobertura de código, execução simbólica e particionamento por equivalência. É apresentado também o CodePro Analytix, software correlato que foi utilizado como comparação, e uma ferramenta para geração de valores de testes que foi utilizada de forma integrada. É revelada a estrutura estática da ferramenta desenvolvida através de diagrama de classes, explicando os componentes mais importantes e o princípio de funcionamento. São apresentados os resultados obtidos a partir de testes de geração realizados com códigos fonte alvo hipotéticos, alcançando cobertura mais alta quando comparados com o Analytix. Por fim, são apresentadas possibilidades de extensão. Palavras-chave: Testes Automatizados. JUnit. Testes de Regressão. Técnicas de Testes. Abstract This document presents the development of a software tool for automated regression tests generation in JUnit format. It explains three test techniques that are implemented by this generator: code coverage analysis, symbolic execution and equivalence partitioning. It s also shown CodePro Analytix, a related software that was used as comparison source, and a tool for test values generation that was integrated to the software. It s revealed the tool s static structure through a class diagram, explaining the main components and how they work. Then, are presented the results reached through generation tests done with hypothetical target source code, achieving higher coverage percentages when comparing the developed tool with Analytix. At the end, are show the extension possibilities. Keywords: Automated Tests. JUnit. Regression Tests. Test Techniques. 1. Introdução Os testes automatizados ganharam bastante notoriedade depois do surgimento de ferramentas como JUnit (BECK e GAMMA, 2014). Antes disto, poucas empresas tinham a prática de automatizar testes de software. Mesmo nos dias atuais, nem todas as empresas aplicam esta prática, e mesmo as que aplicam, dificilmente a utilizam em todos os projetos de software por questões de tempo e custo de desenvolvimento. A consequência disto é um grande volume de código legado sem cobertura de testes automatizados. Este código legado muitas vezes sofre manutenção e até novas implementações após estar em produção, gerando um risco de incluir novos defeitos. Uma maneira de mitigar estes defeitos é realizar testes manuais a cada liberação, outra maneira é implementar testes automatizados de regressão para o código existente (HUSTON, 2014). Porém esta última opção pode gerar um custo de desenvolvimento desproporcional que é difícil de ser diluído no ciclo de desenvolvimento do software. Trabalho apresentado como requisito para obtenção da titulação de especialista no curso de Pós Graduação lato sensu em Engenharia de Software, sob orientação do Prof. Fernando dos Santos, em Novembro de 2014.

2 É possível, entretanto, automatizar a própria geração dos testes automatizados, utilizando como partida o código fonte existente e assumindo a premissa de que o comportamento atual deste código está correto. Este artigo aborda algumas técnicas que podem ser utilizadas para este fim, e apresenta um protótipo de ferramenta para geração de casos de teste de regressão em linguagem Java. A finalidade desta ferramenta é minimizar o esforço manual de desenvolvimento de testes, diminuindo desta forma o custo do projeto. Ela pode ser utilizada para aumentar a cobertura de testes em projetos já finalizados, e também para aumentar a assertividade e cobertura de testes de projetos que estão em desenvolvimento. Este artigo está dividido nas seguintes seções: a seção 2 aborda os assuntos JUnit e testes e regressão para delimitar o contexto do trabalho; a seção 3 explica algumas das técnicas de testes utilizadas na ferramenta: análise de cobertura de código, execução simbólica e particionamento por equivalência; a seção 4 apresenta dois trabalhos correlatos e suas características principais: CodePro Analytix (GOOGLE DEVELOPERS, 2014) e o artigo e protótipo intitulado Covering User-Defined Data-flow Test Requirements Using Symbolic Execution (ELER, ENDO e DURELLI, 2014); a seção 5 revela a estrutura da ferramenta através de diagrama de classes, explicando os componentes principais e como eles colaboram entre si; a seção 6 apresenta os resultados obtidos com testes de geração realizados, submetendo o mesmo código fonte alvo a duas ferramentas diferentes e comparando os resultados; e a seção 7 dá as considerações finais desse artigo e apresenta algumas possibilidades de extensão deste trabalho. 2. JUnit e Testes de Regressão Conforme Tahchiev et al (2011), JUnit é um framework de código fonte aberto criado por Kent Beck e Erich Gamma em 1995 para criação de testes automatizados na linguagem de programação Java. Desde lá, a sua popularidade vem crescendo, e atualmente é o padrão de facto para testes unitários em aplicações Java. Ele é distribuído juntamente com ambientes de desenvolvimento como o Eclipse (ECLIPSE FOUNDATION, 2014) e Netbeans (ORACLE, 2014) e está em evolução até os dias atuais. O JUnit facilita a criação de código para a automação de testes com apresentação dos resultados. Com ele, pode ser verificado através de assertivas se cada método de uma classe funciona da forma esperada, exibindo possíveis erros ou falhas. É possível utilizar o executor de testes do JUnit como um plug-in do próprio ambiente de desenvolvimento, ou então gerando os resultados em relatórios integrando-se com, por exemplo, ambientes de integração contínua como o Hudson (ORACLE, 2013). Quando utilizado na forma de plug-in, o programador pode com alguns cliques disparar a execução de um caso de teste específico ou de uma suíte inteira de testes e verificar o resultado da execução de cada caso de teste através das cores verde (teste ok), azul (houve falha, valores inválidos) ou vermelho (exceção na execução do teste). Os casos de teste, porém, precisam ser implementados manualmente pelos programadores, realizando chamadas ao código fonte alvo com parâmetros específicos e realizando assertivas com os valores esperados. Conforme Huston (2014), teste de regressão é nome que se dá ao teste que é executado após uma alteração feita em um programa, a fim de certificar-se que esta alteração não quebrou nenhuma funcionalidade já existente do programa. Ou seja, para garantir que o software não regrediu. Seu propósito é encontrar defeitos que podem ter sido acidentalmente introduzidos em uma nova release do programa, e assegurar-se que os defeitos já erradicados não voltem. Ao reexecutar casos de teste que foram originalmente criados quando os problemas conhecidos foram corrigidos, pode-se garantir que qualquer nova mudança não tenha resultado em regressão. Estes testes podem ser executados manualmente em projetos pequenos, mas na maioria dos casos repetir uma bateria de testes a cada vez que é feita uma mudança no código é algo que consome muito tempo. Portanto automatização de testes é geralmente requerida neste processo.

3 3. Técnicas de Testes 3.1 Análise de Cobertura de Código Segundo Atollic (2014), a análise de cobertura de código é uma técnica utilizada para medir a qualidade dos testes de um software, geralmente utilizando análise do fluxo da execução dinâmica do programa. Existem várias formas diferentes de se analisar a cobertura do código. Para explicar estas variações, considere-se o código fonte mostrado na figura 1. Figura 1 Análise de Cobertura de Código (Adaptado de Atollic, 2014) Este código possui um bloco em cor vermelha que é sempre executado, um código em cor verde que é executado ou não dependendo do resultado da condição testada ( if") e um terceiro bloco azul que é sempre executado. Isto pode ser visualizado na forma de um grafo, conforme mostrado ao lado do código. O gráfico da execução deixa claro que este código fonte contém dois caminhos de execução diferentes (vermelho-azul e vermelho-verde-azul). Dependendo de como está o estado do sistema durante uma determinada execução (ou seja, o estado das variáveis), o fluxo será executado por um caminho ou outro. Baseado neste gráfico pode-se extrair relatórios de cobertura de uma determinada execução. Algumas das formas de relatórios são: a) Cobertura por Instrução: Aponta quais instruções de progama foram executadas ou não durante a execução. Uma variação deste modelo é a cobertura pro bloco, onde o bloco é um conjunto de instruções que são executados do início ao fim sem desvios, como os três blocos do exemplo; b) Cobertura por Função: Aponta quais funções do programa foram chamadas durante a execução, porém sem dar detalhes inteiros de como a função foi executada, quem a chamou nem quais parâmetros foram passados. Existe uma variação que é medir quais diferentes chamadas de uma função foram realizadas; c) Cobertura por Ramificação: É um modelo mais avançado que entra em um nível de detalhe além das instruções, analisando as expressões condicionais independentemente. No código de exemplo, este modelo aponta quantas diferentes variações do teste condicional if" foram executadas (Ex: se entrou ou não entrou no if"). Além disto, é possível medir quais diferentes combinações foram testadas neste condicional if". Como são três variáveis booleanas, existem oito combinações possíveis. Embora seja possível extrair relatórios de cobertura gerados por uma simples execução manual de um programa, geralmente elas são utilizadas de forma integrada com testes automatizados como JUnit (BECK e GAMMA, 2014) como forma de medir a cobertura dos testes.

4 Segundo Cornett (2014), o uso da análise de cobertura de código como ferramenta de otimização de testes consiste em três etapas principais: a) Encontrar áreas de um programa não exercitadas por um conjunto de casos de teste; b) Criar casos de teste para aumentar a cobertura; c) Determinar uma medição quantitativa da cobertura de código, que é uma medição indireta da qualidade do software. Outro aspecto opcional desta técnica é identificar casos de teste redundantes, ou seja, que não incrementam a cobertura. Um analisador de cobertura de código automatiza este processo. Existem algumas ferramentas para medição de cobertura, como TrueAnalyser (ATOLLIC, 2014), Eclemma (MOUNTAINMINDS, 2014), Clover (ATLASSIAN, 2014), entre outras. Embora a análise de cobertura de código seja uma boa técnica para medir a qualidade dos testes, Fowler (2012) aponta algumas considerações importantes para que ela não se torne um falso indicador. Quando aplicada como meta para os desenvolvedores atingirem um determinado percentual de cobertura do código, podem começar a surgir casos de teste de baixa qualidade cujo objetivo é apenas aumentar a cobertura dos testes. O nível mais extremo desta má prática são testes sem assertivas, que podem acabar ocultando defeitos. Portando, o mais correto é utilizar a cobertura como métrica principalmente pra descobrir partes do código que ainda não estão sendo testadas. Além disto, a cobertura de código é uma ferramenta que sozinha não garante a qualidade dos testes, sendo necessário combiná-la com outras técnicas de testes. 3.2 Execução Simbólica Segundo King (1976) e Cadar e Sem (2013), a ideia geral por trás da execução simbólica é representar os valores das variáveis ao longo da execução de um programa ou função, a partir de valores de entrada simbólicos. Considere-se, por exemplo, o código fonte do quadro 1. 1 public static int factorial(int v) { // Nó 1 2 int f = 1; // Nó 1 3 int i = 2; // Nó 1 4 while (i <= v) { // arestas 5 f = f * i; // Nó 2 6 i = i + 1; // Nó return f; // Nó 4 9 Quadro 1- Exemplo de código fonte (Adaptado de Eler, Endo e Durelli, 2014). Conforme Eler, Endo e Durelli (2014), é comum adotar-se uma abstração chamada Grafo de Fluxo de Controle (CFG Control-Flow Graph) para representar a estrutura interna do programa sujeito a teste. Ela serve como ponto de partida para a análise de critérios estruturais de teste. CFGs são grafos dirigidos onde cada nó representa um bloco básico de instruções (sem desvios de fluxo internos nem dependências internas) e as arestas representam as transições entre os blocos no fluxo de controle. A figura 2 mostra o grafo de fluxo de controle do código em questão. Note-se que as linhas 5 e 6 do código fonte formaram dois nós distintos: 2 e 3. Isto acontece porque neste caso a ordem de execução é importante (a linha 6 precisa necessariamente ser executada depois da linha 5, caso contrário o programa teria outro comportamento), diferente do que acontece nas linhas 2 e 3.

5 Figura 2 - Grafo de Fluxo de Controle (Adaptado de Eler, Endo e Durelli, 2014). Diferentes critérios podem ser adotados para gerar dados de testes a partir de um CFG. Alguns critérios comuns são all-nodes (cobrir todos os nós do grafo), all-edges (todas as arestas) e all-paths (todos os caminhos possíveis, incluindo todas as possibilidades de loops. Geralmente em uma função que possui loops, o critério all-paths tende a formar combinações infinitas. Neste caso pode-se parametrizar a quantidade máxima de loops desejados, conforme a necessidade dos testes. Eler, Endo e Durelli (2014) explicam que, considerando o critério all-paths, cada caminho de execução do programa pode ser representado como uma sequência de restrições, expressas como uma função sobre os valores simbólicos de entrada. Considere, por exemplo, o seguinte caminho de execução do método factorial : Para mover-se do nó 1 para o 2, I precisa atender à restrição (I <= V). A execução simbólica substitui I pelo seu valor inicial (neste caso, o valor 2, conforme segunda linha do código fonte). Este processo é repetido sucessivas vezes até que se obtenha uma sequência de restrições que compõe um determinado fluxo de execução. O fluxo , por exemplo, pode ser representado pela sequência {2 <= V ^ {3 > V. Um solucionador de restrições é então utilizado para produzir uma solução que satisfaça a todas as restrições da sequência. Neste caso, uma possível solução seria o valor 2. Ou seja, o valor 2, quando informado como entrada para o parâmetro V, faz o programa exercitar o caminho Com esta técnica é possível determinar valores de entrada para casos de testes. Se for possível gerar soluções simbólicas para todos os caminhos possíveis de um programa, é possível gerar um conjunto de casos de teste que atinjam cobertura total sobre o programa. É importante ressaltar que um programa pode ter caminhos inatingíveis. Isto pode ser detectado quando uma sequência de restrições não tiver solução, simplificando-se a uma restrição como {0!= 0, por exemplo. 3.3 Particionamento por Equivalência Segundo Pressman (2006), Particionamento por Equivalência é um método de teste caixa-preta que divide o domínio de entrada de um programa em classes de dados, das quais os casos de teste podem ser derivados. O objetivo principal desta técnica é reduzir o número total de casos de

6 teste necessários para encontrar uma mesma quantidade de erros distintos, evitando assim casos de teste redundantes. Por exemplo, se uma determinada função falha com a entrada de um número negativo de tal forma que qualquer número negativo gera esta mesma falha, basta um caso de teste com número negativo. Neste caso, todos os números negativos formam uma única classe de dados para esta função. Sommerville (2007) explica que pode haver classes válidas e classes válidas. Por exemplo, uma função pode se comportar de uma forma para entradas de 1 a 100 e de outra forma para entradas acima de 100. Esta análise pode ser feita comparando os valores de entrada com os valores de saída de um determinado caso de teste, conforme exemplificado na figura 3. Figura 3 Classes de Entrada versus Classes de Saída (Adaptado de Sommerville, 2007). Conforme Pressman (2006), o projeto de casos de teste para particionamento por equivalência é baseado em uma avaliação das classes de equivalência para uma condição de entrada. Se o conjunto de objetos puder ser ligado por relações simétricas, transitivas e reflexivas, uma classe de equivalência estará presente. Tipicamente uma condição de entrada é um valor numérico específico, um intervalo de valores, um conjunto de valores relacionados ou uma condição booleana. As classes podem ser definidas de acordo com as diretrizes mostradas no quadro 2. Condição de entrada especificada Um intervalo Um valor específico O membro de um conjunto Um valor booleano Quais classes de equivalência existem 1 válida (dentro do intervalo); 2 inválidas (abaixo do intervalo, acima do intervalo). 1 válida (o valor); 2 inválidas (abaixo e acima do valor). 1 válida (valor pertencente ao conjunto); 1 inválida (valor fora do conjunto). 1 válida, 1 inválida (Falso e verdadeiro). Quadro 2 - Condições de Entrada versus Classes (Adaptado de Pressman, 2006). 3.4 Outras Técnicas de Testes Existem mais técnicas de testes além das que foram comentadas anteriormente. Algumas delas se aplicam a geradores de dados para testes ou geradores de testes automatizados. Segundo Micskei (2013), algumas técnicas que podem ser utilizadas para geração de testes baseados em código são: a) Seleção randômica: geração randômica ou randômico-adaptativa de dados pode produzir bons resultados. Além disto, são mais flexíveis que outras técnicas pois suportam vários tipos de dados; b) Anotações de código: Se o código fonte for anotado com pré-condições ou pós-condições, elas podem direcionar a geração e seleção dos dados de entrada;

7 c) Técnicas de busca: Algoritmos de busca (como algoritmos genéticos) podem ser utilizados, guiados por uma função de adaptação representando algum tipo de cobertura; 4. Trabalhos correlatos 4.1. Google CodePro Analytix Conforme Google Developers (2014), CodePro Analytix é uma suíte de ferramentas de teste para desenvolvimento em Java com Eclipse, voltadas para melhoria da qualidade do software e redução de custo de desenvolvimento. É composta pelas seguintes ferramentas: a) Code Analysis: Ferramenta extensível e dinâmica que detecta, reporta e corrige desvios ou não-conformidades como padrões de codificacões pré-definidas e convencões de estilo e segurança; b) JUnit Test Case Generation: Ferramenta que utiliza técnicas de análise de fluxos de caminho para automatizar a criação de testes de regressão compreensíveis em JUnit; c) JUnit Test Edit: Ambiente de edição de casos de teste que permite criação, modificação e execução de JUnits utilizando uma interface gráfica de usuário; d) Similar Code Analysis: Ferramenta que encontra segmentos de código duplicado e os exibe de forma analítica com cores para facilitar a leitura; e) Metrics: Ferramenta de medição que calcula itens como quantidades de linhas de códigos, quantidades de métodos por visibilidade, complexidade ciclomática, média de linhas por método, comentários, entre outros; f) Code Coverage: Ferramenta de coleta de cobertura de código a partir de uma execução do software. g) Dependency Analysis: Ferramenta que mostra graficamente as dependências entre pacotes Java ou classes Java, como forma de analisar acoplamento. Do leque de ferramentas do CodePro, a ferramenta relacionada com este trabalho é a JUnit Test Case Generation. Esta ferramenta, assim como as demais, é distribuída na forma de um plugin do Eclipse. Segundo Google Developers (2014), a partir de uma classe Java, ela gera uma classe de teste correspondente contendo vários métodos de teste para cada método de entrada. A ferramenta analisa cada método com seus parâmetros de entrada, com a meta de gerar casos de teste que exercitem cada linha de código. Ou seja, atingir cobertura de código dos métodos alvo próxima a 100%. Como parte da análise para geração dos testes, a ferramenta executa o código alvo. Neste processo, podem ser encontradas exceções. A ferramenta é configurável com três opções possíveis de tratar exceções: sempre ignorar casos de teste que geram exceção, sempre considerar casos de teste que gerem exceção, ou considerar apenas casos de teste que geram exceção caso a exceção disparada esteja declarada na cláusula throws do método. A ferramenta também suporta geração de fixtures. Fixture é um objeto utilizado para invocar um método de instância da classe. Este recurso é utilizado para testes de métodos não estáticos, onde a fixture pode ser gerada como um atributo na classe de teste, ou como uma variável local dentro do próprio método de teste. A geração dos métodos de teste, que é a funcionalidade principal da ferramenta, consiste nas seguintes etapas: a) Gerar uma lista de valores possíveis para a fixture (caso o método não seja estático) e para cada um dos parâmetros. b) Determinar quais combinações utilizar para invocar o método; c) Computar o resultado invocando o método; d) Descobrir como validar o resultado; e) Gerar um método de teste para cada combinação de valores gerados.

8 4.2. Gerador de Dados de Testes através de Execução Simbólica O Segundo trabalho correlato é o artigo e protótipo intitulado Covering User-Defined Data-flow Test Requirements Using Symbolic Execution (ELER, ENDO e DURELLI, 2014). Este artigo foi apresentado no Simpósio Brasileiro de Qualidade de Software em 2014, em Blumenau (SC). Além de apresentar a técnica de execução simbólica para geração de dados de entrada para casos de testes, os autores desenvolveram um protótipo que serviu como prova de conceito de geração de valores para testes. O protótipo desenvolvido interpreta código Java em formato bytecode (arquivos.class ), analisa os métodos utilizando a técnica de execução simbólica e fornece como saída o conjunto de valores para os parâmetros do método de tal forma a cobrir o máximo dos fluxos de execução do método de forma não redundante. Este protótipo possui a limitação de suportar apenas parâmetros do tipo int. O protótipo utiliza internamente uma estrutura chamada Grafo de Definição e Uso (DUG Def-Use Graph, em inglês), que é uma extensão do CFG comentado na seção 3.2 deste artigo. O DUG foi uma estrutura proposta por Rapps e Weyuker (1985). A figura 4 mostra de forma resumida a arquitetura do protótipo, que possui quatro partes principais. Figura 4 Arquitetura do protótipo (Eler, Endo e Durelli, 2014). A seguir é explicada a função de cada um destes componentes: a) Instrumenter: instrumenta as classes Java recebidas e gera o DUG para cada método. O DUG é utilizado para identificar as expressões simbólicas e as restrições. b) Path Analyzer: recebe o DUG e identifica todos os caminhos possíveis. Cada caminho selecionado é enviado para o componente Constraint Analyzer. c) Constraint Analyzer: gera uma sequência de restrições e identifica restrições que não podem ser resolvidas. d) Constraint Solver: recebe a sequência de restrições e produz os dados de teste para cobrir cada sequência. Para a resolução das restrições, este componente utiliza a biblioteca Choco (TEAM, 2008), uma ferramenta Java para programação com restrições. 5. Desenvolvimento da Ferramenta Foi desenvolvida uma ferramenta capaz de gerar casos de testes automatizados a partir de classes Java. As próximas seções deste artigo explicam o desenvolvimento desta ferramenta, detalhando os requisitos, o princípio de funcionamento, as técnicas implementadas, o modelo das classes, os resultados obtidos comparando-a com o CodePro Analytix e por fim as considerações finais Requisitos Funcionais e Não Funcionais O quadro 3 apresenta os requisitos funcionais e não-funcionais desta ferramenta.

9 Requisitos Funcionais RF01: A ferramenta deve gerar uma classe Java de testes para cada classe alvo informada. As classes devem ser geradas em um diretório de saída parametrizável. RF02: A ferramenta deve suportar geração de testes para métodos estáticos públicos que recebem parâmetros dos seguintes tipos: boolean, byte, char, short, int, float, double, long, BigDecimal, BigInteger, String e arrays destes tipos. (Observação: Esta limitação foi criada para reduzir o escopo deste projeto em um período curto de desenvolvimento: 180 horas). RF03: A ferramenta deve gerar um ou mais casos de teste para cada método alvo informado. Quando não for informado um método alvo específico (ou seja, informar apenas uma ou mais classes alvo sem informar métodos), devem ser considerados todos os métodos públicos e estáticos das classes informadas. RF04: Cada caso de teste gerado deve fornecer um valor fixo (estático) como entrada para cada um dos parâmetros do método alvo, salvo em métodos que não possuem parâmetros. RF05: A ferramenta deve gerar assertivas fixas baseadas nos retornos das invocações aos métodos alvo que forem sucedidas (ou seja, casos onde a chamada não causou exceção nem loop infinito). Para estes casos, os testes gerados, quando executados pelo JUnit com o código alvo atual, devem estar todos passando e ao mesmo tempo garantindo os valores retornados. RF06: A ferramenta deve permitir parametrizar uma lista de classes de exceção a serem consideradas como falhas do software ao gerar os testes. RF07: Para os casos de exceção encontrados pela ferramenta ao gerar os testes, deve ser geradas assertivas fixas que garantam a ocorrência de tal exceção para tais valores de entrada, podendo também verificar a mensagem da exceção quando houver. Exceto para os casos onde a exceção ocorrida é de uma das classes consideradas como falhas (RF05). RF08: Nos casos de exceções que são consideradas como falhas (RF05), a ferramenta deve gerar um caso de teste que falhe (sem assertivas) para evidenciar a falha do código alvo, adicionando também um comentário do tipo FIXME sobre o método. RF09: Para situações de loop infinito encontradas, deve ser gerado um caso de teste sem assertivas, adicionando um comentário do tipo FIXME: Infinite loop detected! sobre o método. Para a detecção do loop infinito, a ferramenta deve considerar um tempo máximo de execução (timeout) parametrizável. RF10: Os fontes de testes gerados pela ferramenta deverão ser baseados na biblioteca JUnit 4 (BECK e GAMMA, 2014), utilizando as classes desta biblioteca para realizar assertivas e anotações para execução como.

10 RF11: A ferramenta deve selecionar e ordenar os casos de teste pelo grau de cobertura atingido. Deve haver parâmetros para configurar a meta de percentual de cobertura para o método alvo e meta de cobertura indireta (métodos filhos, chamados pelo método alvo), que devem ser utilizados como critério de satisfação dos testes. Requisitos Não-Funcionais RNF01: A ferramenta pode ser executada em modo console. RNF02: A ferramenta deve utilizar ao menos 3 técnicas de testes: Análise de cobertura de código, execução simbólica e particionamento por equivalência. RNF03: As classes de teste devem ser geradas de forma que possam ser entendidas e mantidas por humanos (código Java legível). RNF04: Para qualquer classe alvo, a ferramenta deve gerar a classe de teste em menos de 30 minutos. (Hardware de referência: Intel Core i5 2,6 GHz, 8GB RAM). Quadro 3 - Requisitos funcionais e não-funcionais da ferramenta desenvolvida Princípio de Funcionamento O princípio de funcionamento desta ferramenta resume-se a dois componentes principais: os geradores de valores e os validadores de casos de teste. Os geradores de valores são componentes que geram os valores de entrada para os testes, podendo utilizar para isto várias técnicas diferentes que podem ser de caixa preta (sem analisar o código fonte alvo, atendo-se somente aos tipos dos parâmetros) ou caixa branca (analisando o código alvo). Os validadores são componentes que validam, ordenam e removem redundâncias dos casos de teste gerados pelos geradores, podendo utilizar para isto técnicas diferentes (uma delas é análise da cobertura, por exemplo). Ambos os componentes foram declarados na forma de interfaces para se fosse possível estendê-los implementando técnicas diferentes. Com isto, a ferramenta tornou-se amplamente configurável, podendo ser estendida de várias formas para direcionar e otimizar a forma como os casos de teste são gerados. Algumas das técnicas de testes explicadas neste artigo são suportadas pela ferramenta. O quadro 4 mostra quais técnicas de testes foram implementadas, destacando qual dos componentes resolve cada técnica. Componente Descrição Técnicas implementadas Geradores de Geram os valores de entrada para os 1. Geração randômica; Valores testes. Especializam uma interface da ferramenta para cada tipo de dado versus técnica desejada. 2. Execução simbólica; 3. Valores limites. Validadores de Casos de Teste Verificam se os casos de teste gerados atendem a determinados parâmetros, priorizando os casos de maior importância e removendo casos redundantes. Especializam uma interface da ferramenta para cada técnica desejada. Quadro 4 Técnicas implementadas pela ferramenta. 4. Análise de cobertura de código; 5. Particionamento por Equivalência (parcial).

11 5.3. Técnicas Implementadas A ferramenta conta com 35 implementações diferentes (classes) de geradores de valores. Há geradores de valores randômicos para todos os tipos de dados suportados pela ferramenta, além de geradores de valores limites para tipos numéricos, geradores de valores comuns, geradores que analisam o código alvo para determinar valores (exemplo: busca de strings contidas dentro do código) e também gerador a partir de execução simbólica. A técnica de execução simbólica foi implementada através de integração com o protótipo de Eler, Endo e Durelli (2014), explicado na seção 3.2. A partir do bytecode da classe alvo, a ferramenta solicita a execução simbólica do método e coleta os resultados gerados para cada parâmetro. Por limitação deste protótipo, são suportados apenas geradores do tipo int para esta técnica. Para a técnica de análise de cobertura de código, é utilizada internamente a ferramenta Jacoco (Java Code Coverage Library), que faz parte do plugin Eclemma (MOUNTAINMINDS, 2014). Para cada caso de teste gerado pelos geradores de valores, a ferramenta executa o código alvo com os valores gerados, coletando as seguintes informações: o valor de retorno (pode também ser exceção ou loop infinito), a cobertura de cada instrução do método alvo e a cobertura das instruções dos métodos que são chamados pelo método alvo. Para buscar os métodos chamados por cada método é utilizada uma extensão da ferramenta Javaparser (GESSER, 2010). O validador de cobertura, além de ordenar os casos de teste por percentual de cobertura, possui um critério de satisfação configurável. Pode-se configurá-lo, por exemplo, de forma a parar de gerar novos testes quando chegar ao percentual de cobertura de 100% do método alvo e 80% dos métodos indiretos de primeiro nível. Este percentual é a mescla da cobertura atingida pelos casos de teste gerados para este método. Este validador também induz o gerador a ignorar casos de teste redundantes. Por exemplo, casos que, embora tenham uma cobertura razoável, estejam totalmente cobertos por outro caso de teste mais abrangente. Para a técnica de particionamento por equivalência, foi implementado um validador que é satisfeito somente quando foi gerado ao menos um caso de teste para cada retorno possível do método. Para métodos boolean, deve existir ao menos um caso que retorne true e outro false. Para enumerações, deve existir um caso de teste para cada constante da enumeração. A ferramenta suporta apenas estes dois tipos de dados, visto que outros tipos de retorno podem nunca ser atingíveis (como int e String). Para estes casos as partições deveriam ser extraídas utilizando análise do código fonte ou outras técnicas. A técnica de anotações de código não foi implementada porque o objetivo da ferramenta é gerar testes de regressão a partir de código legado, e esta técnica depende de alteração manual no código alvo adicionando as anotações específicas Modelo das Classes A figura 5 apresenta um diagrama contendo as principais classes da ferramenta. O fluxo principal de processamento começa com a classe JUnitGenerator, que utiliza TestCaseGenerator para gerar os casos de teste e CodeGenerator para gerar o código Java resultante. A classe TestCaseGenerator, por sua vez, utiliza ParamValuesGenerator para gerar os valores de entrada, CaseExecutor para executar o método alvo coletando os resultados e cobertura (que são encapsulados em objetos TestCaseData), e TestCaseValidator para validar os casos de teste gerados, selecionando os mais importantes e removendo os redundantes. A ferramenta pode ser customizada criando-se novas classes filhas de ValueGenerator e de TestCaseValidator. A ferramenta trabalha com conjuntos de ValueGenerators e conjuntos de TestCaseValidators, portanto é possível combinar várias implementações destas interfaces.

12 Figura 5 Diagrama de classes da ferramenta. 6. Resultados obtidos A ferramenta foi testada com vários métodos alvo hipotéticos, cobrindo os tipos de dados suportados e explorando situações variadas. Foram testados também métodos rotineiros como validação de CPF ou CNPJ, verificação de números primos, divisão de valores em parcelas, entre outros. O quadro 5 apresenta um exemplo de código que foi submetido à ferramenta a fim de verificar os resultados. Foi realizada uma execução dos testes informando esta classe Java como código alvo, parametrizando a meta de cobertura para 100%. O tempo de execução foi de aproximadamente 33 segundos em um notebook Core i5 2.6 GHz. A ferramenta é executada programaticamente, através de um objeto da classe JUnitGenerator. Após atribuir os parâmetros desejados (entre eles, a classe Java alvo), chama-se o método execute que dispara a execução. package com.generator.core.res.input; public class ValidaCPF { public static boolean iscpfvalido(string cpf) { if (cpf == null cpf.length()!= 11) { return false; char dig10, dig11; int sm, i, r, num, peso; sm = 0; peso = 10; for (i = 0; i < 9; i++) { num = (int) (cpf.charat(i) - 48); sm = sm + (num * peso); peso = peso - 1; r = 11 - (sm % 11); if ((r == 10) (r == 11)) { dig10 = '0'; else { dig10 = (char) (r + 48); sm = 0;

13 peso = 11; for (i = 0; i < 10; i++) { num = (int) (cpf.charat(i) - 48); sm = sm + (num * peso); peso = peso - 1; r = 11 - (sm % 11); if ((r == 10) (r == 11)) { dig11 = '0'; else { dig11 = (char) (r + 48); return (dig10 == cpf.charat(9)) && (dig11 == cpf.charat(10)); Quadro 5 Exemplo de código alvo submetido ao gerador de testes. O quadro 6 mostra o código de teste gerado pela ferramenta nesta situação. Pode-se ver que a ferramenta gerou cinco casos de teste para que cobrisse todo o método alvo. Cada caso de teste cobre uma porção do código do método alvo que não é coberta pelos demais, e os casos de teste foram ordenados de acordo com a cobertura atingida por cada um. A cobertura total atingida foi de 98,2% das instruções do código alvo. É importante ressaltar que estas medições de cobertura são feitas por instrução Java (razão entre quantidade de instruções cobertas e quantidade total de instruções do código alvo). package com.generator.core.res.expected; import org.junit.assert; import org.junit.test; import com.generator.core.res.input.validacpf; public class ValidaCPFTest { // Coverage: 89,29% public void testiscpfvalido_1() { boolean actual = ValidaCPF.isCpfValido(" "); Assert.assertEquals(false, actual); // Coverage: 84,82% public void testiscpfvalido_2() { boolean actual = ValidaCPF.isCpfValido(" "); Assert.assertEquals(true, actual); // Coverage: 83,04% public void testiscpfvalido_3() { boolean actual = ValidaCPF.isCpfValido(" "); Assert.assertEquals(false, actual); // Coverage: 7,14% public void testiscpfvalido_4() { boolean actual = ValidaCPF.isCpfValido(""); Assert.assertEquals(false, actual); // Coverage: 3,57% public void testiscpfvalido_5() { boolean actual = ValidaCPF.isCpfValido(null); Assert.assertEquals(false, actual); Quadro 6 Código de teste gerado pela ferramenta.

14 Para comparação, o quadro 7 mostra o código de teste gerado pela ferramenta CodePro Analytix para o mesmo método alvo. Foram omitidos alguns comentários gerados em cada método para simplificar a leitura. O tempo de execução foi de aproximadamente 1 segundo no mesmo computador dos testes anteriores. A execução é disparada por um plug-in instalado no Eclipse, acionando-se o menu de contexto: CodePro Tools Generate Test Cases. A cobertura atingida foi de 62,0% das instruções do código alvo. Pode-se ver que nenhum dos casos de teste cobriu a situação em que a função retorna o valor true. /** * The class <code>validacpftest</code> contains tests for the class <code>{@link ValidaCPF</code>. * CodePro at 21/10/14 21:57 Samuel $Revision: 1.0 $ */ public class ValidaCPFTest { public void testiscpfvalido_1() throws Exception { String cpf = null; boolean result = ValidaCPF.isCpfValido(cpf); // add additional test code here assertequals(false, result); public void testiscpfvalido_2() throws Exception { String cpf = ""; boolean result = ValidaCPF.isCpfValido(cpf); // add additional test code here assertequals(false, result); public void testiscpfvalido_3() throws Exception { String cpf = ""; boolean result = ValidaCPF.isCpfValido(cpf); // add additional test code here assertequals(false, result); public void testiscpfvalido_4() throws Exception { String cpf = "aaaaaaaaaaa"; boolean result = ValidaCPF.isCpfValido(cpf); // add additional test code here assertequals(false, result); Quadro 7 Casos de teste gerados pelo CodePro Analytix. Comparando-se os dois resultados, pode-se ver que os testes gerados pela ferramenta desenvolvida proporcionam um ganho maior ao serem utilizados como testes de regressão, pois testam dois casos importantes: a) String contendo um CPF válido. Este é talvez o caso de teste mais importante de todos, pois testa o caminho feliz deste método (embora caminho feliz seja um conceito completamente subjetivo e nenhuma das duas ferramentas é capaz de determiná-lo). O que levou a ferramenta a gerar este caso de teste foi a aplicação da técnica de particionamento por equivalência. Com isto, para cada método do tipo boolean, o TestCaseValidator que implementa esta técnica somente é satisfeito quando tiver gerado ao menos um caso de teste que retorne false e outro que retorne true (as duas classes possíveis para o tipo boolean).

15 b) String contendo um CPF inválido que é composto por números, e com o mesmo tamanho da String de CPF válido. Este é um valor que poderia ser um CPF válido mas não é, devido à validação dos dígitos de verificação. O que levou a ferramenta a gerar este caso de teste é que foi o caso que atingiu o maior percentual de cobertura (maior fluxo de execução, passando pelo método inteiro até chegar na parte final da validação dos dígitos). A ferramenta ordena os casos de teste gerados antes de gerar o código final utilizando o percentual de cobertura e a complexidade dos valores de entrada como critério de ordenação. Além disto, casos redundantes (que cobrem exatamente as mesmas instruções de outro caso já gerado) são removidos. Para que seja capaz de gerar estes valores como entradas, a ferramenta contém um grande conjunto de geradores de valores randômicos. Um subconjunto são os geradores randômicos para Strings. Este conjunto contém uma classe para gerar Strings de caracteres aleatórios, outra para gerar apenas Strings numéricas aleatórias, outra para gerar apenas Strings alfabéticas aleatórias, entre outras. Os números de CPF gerados como entrada para os testes foram gerados pelo gerador de Strings numéricas, embora a ferramenta tenha tentado gerar outros tipos de Strings com outros geradores - mas estes casos de teste foram ignoradas. Os geradores de Strings são utilizados alternadamente em ciclo, e a ferramenta acaba retendo os casos de teste que geraram alta cobertura e removendo os casos de teste de cobetura nula ou muito baixa. Com isto, os valores escolhidos acabam sendo os que mais se adaptaram ao comportamento esperado pelo método: por terem atingido cobertura mais alta, exercitaram um fluxo maior de execução dentro do código fonte. O quadro 8 mostra mais um exemplo de código alvo que foi submetido a geração de testes, desta vez com parâmetros do tipo int e utilizando como gerador de valores uma classe adaptadora para a ferramenta de execução simbólica de Eler, Endo e Durelli (2014). package com.generator.core.res.input; public class IntOperationsSymbolic { public static String avaliatriangulo(int a, int b, int c) { if (a < b + c && b < a + c && c < a + b) { if (a > 0 && b > 0 && c > 0) { if (a == b && b == c && c == a) { return "Equilátero"; else if (a!= b && b!= c && c!= a) { return "Escaleno"; else { return "Isósceles"; return "Não é triângulo"; Quadro 8 Exemplo de código alvo: função de verificação de triângulos. Para este código alvo, a ferramenta desenvolvida gerou os casos de teste apresentados no quadro 9. Nesta situação, o gerador de execução simbólica proporcionou bom desempenho (geração em 3 segundos em um notebook Core i5 2.6GHz) por não utilizar valores randômicos e sim diretamente os valores estratégicos para exercitar os diversos fluxos de execução. Além disto, a cobertura atingida foi de 100% do método alvo. package com.generator.core.res.expected; import org.junit.assert; import org.junit.test; import com.generator.core.res.input.intoperationssymbolic; public class IntOperationsSymbolicTest {

16 /** * Coverage: 74,47% */ public void testavaliatriangulo_1() { String actual = IntOperationsSymbolic.avaliaTriangulo(2, 1, 2); Assert.assertEquals("Isósceles", actual); /** * Coverage: 74,47% */ public void testavaliatriangulo_2() { String actual = IntOperationsSymbolic.avaliaTriangulo(2, 4, 3); Assert.assertEquals("Escaleno", actual); /** * Coverage: 68,09% */ public void testavaliatriangulo_3() { String actual = IntOperationsSymbolic.avaliaTriangulo(1, 1, 1); Assert.assertEquals("Equilátero", actual); /** * Coverage: 36,17% */ public void testavaliatriangulo_4() { String actual = IntOperationsSymbolic.avaliaTriangulo(1, 1, 2); Assert.assertEquals("Não é triângulo", actual); Quadro 9 Casos de teste gerados para a função de verificação de triângulos. O quadro 10 mostra o código gerado pelo CodePro Analytix para o mesmo código alvo. Novamente o tempo de geração foi de 1 segundo no mesmo hardware. A cobertura atingida foi de 72,3% do código alvo. Pode-se ver que foram gerados 7 casos de teste redundantes (mesmos valores de entrada) enquanto 2 dos 4 retornos possíveis não foram testados ( Escaleno e Isóceles ). package com.generator.core.res.input; import org.junit.*; import static org.junit.assert.*; public class IntOperationsSymbolicTest { public void testavaliatriangulo_1() throws Exception { int a = 1; int b = 1; int c = 1; assertequals("equilátero", result); public void testavaliatriangulo_2() throws Exception { int a = 1; int b = 1; int c = 1; assertequals("equilátero", result);

17 public void testavaliatriangulo_3() throws Exception { int a = 1; int b = 1; int c = 1; assertequals("equilátero", result); public void testavaliatriangulo_4() throws Exception { int a = 1; int b = 1; int c = 1; assertequals("equilátero", result); public void testavaliatriangulo_5() throws Exception { int a = 1; int b = 1; int c = 1; assertequals("equilátero", result); public void testavaliatriangulo_6() throws Exception { int a = 0; int b = 1; int c = 1; assertequals("não é triângulo", result); public void testavaliatriangulo_7() throws Exception { int a = 1; int b = 0; int c = 1; assertequals("não é triângulo", result); public void testavaliatriangulo_8() throws Exception { int a = 1; int b = 1; int c = 0; assertequals("não é triângulo", result); public void testavaliatriangulo_9() throws Exception { int a = 1; int b = 1; int c = 1; assertequals("equilátero", result); public void testavaliatriangulo_10() throws Exception { int a = 1; int b = 1; int c = 1; assertequals("equilátero", result); public void testavaliatriangulo_11() throws Exception {

18 int a = 1; int b = 1; int c = 1; assertequals("equilátero", result); Quadro 10 Testes gerados para a função de triângulos pelo CodePro Analytix. É importante citar que a distribuição correta da cobertura dos casos de teste ao gerar os testes automatizados faz diferença no custo final de execução de testes. A prática da geração e/ou implementação manual de testes automatizados geralmente leva à construção de suítes de testes que podem chegar a ter milhares de casos de testes, dependendo do tamanho do programa. Sendo assim, a geração de testes redundantes pode ocasionar em maior tempo total de execução de testes, maior consumo de recursos de hardware e maior custo de manutenção do código de teste. Por outro lado, suítes de testes otimizadas são capazes de testar mais código (maior cobertura) em menos tempo. Uma situação não mostrada nos testes acima são casos de teste onde o método alvo gera exceção. Ambas as ferramentas realizam detecção de exceções em tempo de execução. É possível configurar a ferramenta para que: a) crie um caso de teste como exceção esperada (ou seja, considere que a exceção faz parte do contrato do método e teste-a com assertivas para que garanta que tais entradas geram esta exceção); b) crie um caso de teste como exceção não esperada (ou seja, tratar como um bug encontrado, gerando o teste de tal forma que falhe); c) ignore o caso de teste que gerou exceção (ou seja, simplesmente não teste a situação). d) considere a exceção como esperada apenas quando a classe da exceção esteja declarada na cláusula throws do método alvo. Esta é a opção padrão. A ferramenta mantém também uma lista configurável de classes de exceção para serem tratadas sempre como bug. Exemplos são IllegalStateException, NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException, entre outras. Para finalizar os resultados obtidos, o quadro 11 mostra o resumo dos testes realizados, comparando a ferramenta desenvolvida com o CodePro Analytix. Para o levantamento da cobertura destes testes, foi utilizada a ferramenta Eclemma (MOUNTAINMINDS, 2014). Atendendo ao requisito não-funcional RNF03 da ferramenta, em todas estas situações a ferramenta gerou os casos de teste em menos de 30 minutos. Observação: nos testes da função weekdaytostr, a cobertura máxima possível da função é de 90,5% por conta de um trecho de código morto (inatingível) deixado propositalmente dentro da função. Caso de código alvo Qtd. casos de teste gerados Cobertura atingida (%) Ferramenta CodePro Ferramenta CodePro Validação CPF ,2% 62,0% Verificação Triângulos % 72,3% Verificação Números Primos % 58,8% Divisão de valores em parcelas % 46,5% (usa BigDecimal e arrays) Operação com arrays: Max % 82,1% Operação com arrays: Sum % 62,5% Operação com arrays: Concat % 18,9% Enumerações: weekdaytostr ,5% 90,5% Enumerações: strtoweekday ,0% 100,0% Quadro 11 Resumo dos resultados obtidos, comparando a ferramenta com o CodePro Analytix.

19 7. Considerações Finais Este artigo apresentou algumas técnicas de testes automatizados, bem como o desenvolvimento de uma ferramenta de geração de testes de regressão que utiliza tais técnicas. Nos resultados exibidos a ferramenta apresentou em média ganho maior que o CodePro Analytix, ao gerar testes de métodos públicos estáticos com os seguintes tipos de parâmetros: String, arrays, enumerações, BigDecimal e os tipos primitivos do Java (byte, char, short, int, long, boolean). Métodos não estáticos e outros tipos de dados não fizeram parte do escopo deste trabalho, então não se pode afirmar o mesmo para estas situações. Além disto, o CodePro Analytix permite utilizar a técnica de Anotações de Código para melhorar os resultados gerados, podendo mudar o cenário dos testes realizados. Conforme explicado na seção 5, decidiu-se não utilizar esta técnica na ferramenta desenvolvida porque o objetivo é aplicá-la em testes de regressão de código legado, e esta técnica dependeria de alterar o código legado incluindo as anotações. As seguintes sugestões de melhoria são indicadas para esta ferramenta: a) Suporte a geração de fixtures para suportar testes de métodos não estáticos de forma semelhante ao CodePro Analytix; b) Suporte a geração de valores para tipos de dados mais complexos como objetos POJO (Plain Old Java Object), listas, sets, mapas e outros tipos de estruturas de dados; c) Melhorias no analisador de execução simbólica para suportar mais tipos de dados como byte, short, long, float, double, boolean, char e outros. d) Suporte a testes de código alvo que interage com bancos de dados, tratando isolamento dos dados entre os casos de teste; e) Permitir geração dos testes diretamente a partir do ambiente de desenvolvimento. Neste caso, através plug-in do Eclipse. Referências ATLASSIAN. Clover: Java and Groovy code coverage. Disponível em: Acesso em: 26/09/2014. ATOLLIC. Trueanalyzer. Disponível em: Acesso em: 26/09/2014. BECK. K, GAMMA, E. Junit Framework. Disponível em: Acesso em: 26/09/2014. CORNETT, S. Code Coverage Analysis Disponível em: Acesso em: 26/09/2014. CADAR, C, SEM, K. (2013). Symbolic execution for software testing: three decades later. Communications of the ACM, ECLIPSE FOUNDATION. Eclipse IDE. Disponível em: Acesso em: 26/09/2014. ELER, M. M.; ENDO, A. T.; DURELLI, V. Covering User-Defined Data-flow Test Requirements Using Symbolic Execution. XIII Simpósio Brasileiro de Qualidade de Software. Blumenau, 2014.

20 FOWLER, M.. Test Coverage. Disponível em: Acesso em: 26/09/2014. GESSER, J. Javaparser. Disponível em: Acesso em 06/10/2014. GOOGLE DEVELOPERS. Codepro Analytix. Disponível em: Acesso em: 26/09/2014. Acesso em: 06/10/2014. HUSTON, T. What Is Regression Testing Disponível em: Acesso em: 26/09/2014. KING, J. C. Symbolic Execution and Program Testing. Communications of the ACM, MICSKEI, Z. Code-based test generation. Disponível em: Acesso em 06/10/2014. MOUNTAINMINDS GmbH & Co. KG and Contributors. Eclemma Java Code Coverage for Eclipse. Disponível em: Acesso em: 26/09/2014. ORACLE. Netbeans, Disponível em: Acesso em 07/10/2014. ORACLE. Hudson Extensible Continuous Integration Server, Disponível em: Acesso em: 07/10/2014. PFLEEGER, S. L. Engenharia de software: teoria e prática. 2 ed. São Paulo, SP: Prentice Hall, PRESSMAN, Roger. S. Engenharia de software. 6 ed. São Paulo: SP: McGraw-Hill, RAPPS, S, WEYUKER, E. J.. Selecting Software Test Data Using Data Flow Information. IEEE Transaction on Software Engineering, SOMMERVILLE, I. Engenharia de software. 8 ed. São Paulo, SP: Addison Wesley, TAHCHIEV. et al. JUnit in Action. Manning publications TEAM, T. C.. Choco: An Open Source Java Constraint Programming Library. Workshop on Open-Source Software for Integer and Contraint Programming. ACM, 2008.