Testcomplete
Uma ferramenta baseada em aspectos para o teste funcional de programas Java André Dantas Rocha* Adenilso da Silva Simão, José Carlos Maldonado, Paulo Cesar Masiero Laboratório de Engenharia de Software Instituto de Ciências Matemáticas e de Computação da Universidade de São Paulo Av. do Trabalhador São-Carlense, 400 – Centro – Cx. Postal 668 sao carlos – sao paul Abstract. Availability more productivity for present a tool for fun to view better quality and this paper, we of programs Java.
The too’, denominated J-FuT, supports various functional testing criteria and offers coverage analysis based in hose criteria. Aspect-oriented Programming is used in the phases of instrumentation and execution of the testing criteria. The use of this technique allows a clear separation between the testlng code and the program code and is an effective and elegant solution for this type of tool. Furthermore, it makes easy adding and removing the aspects that implement the tests. Keywords.
Aspect Oriented Programming, Functional Testing, Test Coverage. Resumo. A disponibilidade de ferramentas de teste de software Aspectos é utilizada pela ferramenta nas etapas de instrumentação e execução dos critérios de este. O uso dessa técnica permite a separação clara entre o código de teste e o código do programa, assim como torna mais fácil a adição e remoção dos aspectos que implementam o teste. Palavras-chave. Programação Orientada a Aspectos, Teste Funcional, Análise de Cobertura. 1.
Introdução Teste de software é uma etapa fundamental do ciclo de desenvolvimento e representa uma importante premissa para alcançar padrões de qualidade no produto criado. O teste diz respeito à análise dinâmica do programa e consiste na execução do produto com o intuito de revelar a presença de erros. Essa atividade envolve quatro etapas que geralmente devem ser executadas durante o processo de desenvolvimento de software: planejamento de testes, projeto de casos de teste, execução de testes (e coleta dos resultados) e avaliação dos resultados coletados.
A aplicação de testes segue diversas técnicas, que oferecem perspectivas diferentes e abordam diferentes classes de erros, e que portanto devem ser utilizadas de forma complementar. As várias técnicas propostas diferenciam-se pela origem das informações utilizadas para estabelecer os Financiado pelo CNPq – Processo 132110/03-2 equisitos e critérios de teste odendo-se citar as técnicas funcional, estrutural e bas PAGF 30 Com a crescente complexidade dos softwares, torna-se fundamental a utilização de ferramentas de teste visando a automatização dessa atividade.
O teste de software é, em geral, custoso e propenso a erros e ferramentas que apóiem essa atividade são essenciais. Atualmente encontram-se disponíveis diversas ferramentas que buscam atender a esse propósito, no entanto a maioria oferece suporte apenas ao teste estrutural. Além disso, as poucas ferramentas que implementam a técnica funcional desconsideram seus principais critérios e não ermitem análise de cobertura apropriada. Neste artigo é analisada a técnica funcional e apresentada uma ferramenta para teste funcional de programas Java.
Ao contrário das abordagens atuais, a ferramenta oferece suporte aos principais critérios dessa técnica e permite análise de cobertura funcional. Na implementação da ferramenta utilizou-se a Programação Orientada a Aspectos — POA [1 3] nas etapas de instrumentação e aplicação dos critérios funcionais, pois essa técnica de programação apresenta características que facilitam o teste funcional. O artigo encontra-se organizado da seguinte forma: na Seção 2. escreve-se a técnica funcional e seus principais critérios.
Na Seção 3. são apresentados alguns conceitos pertinentes às ferramentas de teste, enfatizando-se a técnica funcional. A Seção 4. é dedicada ao AspectJ – uma linguagem orientada a aspectos para Java — e a algumas propostas existentes para aplicação da POA para o teste de software. Na Seção 5. aborda-se o projeto da ferramenta J-FuT e na Seção 6. um exemplo de seu uso. Por fim, na Seção 7. , são apresentadas as considerações finais. 2. Teste funcional Na técn Por fim, na Seção 7. são apresentadas as 2. Teste funclonal Na técnica funcional (caixa-preta) os requisitos de teste são estabelecidos a partir da especificação do software, e sua estrutura nao é necessariamente considerada. De acordo com Ostrand e galcer [19], o objetivo do teste funcional é encontrar discrepâncias entre o comportamento atual do sistema e o descrito em sua especificação. Assim, consideram-se apenas as entradas e saídas e o testador não tem necessariamente acesso ao código fonte do software.
Nesse tipo de teste procura-se descobrir erros relacionados a cinco categorias [22]: (i) funções incorretas ou omitidas; (ii) erros de interface; (iii) erros de strutura de dados ou de acesso a dados externos; (iv) erros de comportamento ou desempenho e, por fim, (v) erros de iniciação e término. No teste caixa-preta destacam-se três critérios: Particionamento de Equivalência, Análise de Valor-Limite e Teste Funcional Sistemático, descritos a seguir. 2. 1. Particionamento de Equivalência Neste critério divide-se o domínio de entrada do programa em classes de dados, dos quais os casos de teste são derivados [221.
A divisão é feita em classes de equivalência válidas e inválidas e busca-se produzir casos de teste que cubram diversas classes de erro e que ao esmo tempo reduzam o total de casos necessários. O particionamento do domínio de entrada deve ser feito de forma que para cada classe de equivalência, qualquer um dos seus elementos seja representativo de toda a classe e dessa forma o programa em teste se com Orte da mesma maneira, independentemente do el mesma maneira, independentemente do elemento escolhido na classe.
Idealmente se um caso de teste de uma determinada classe de equivalência revela um erro, qualquer outro caso de teste nessa classe deve revelar o mesmo erro. Segundo Myers [1 81, a definição das classes de equivalência é um processo heurístico o critério exige que seja derivado um conjunto mínimo de casos de teste para exercitar as classes de equivalência válidas e um caso de teste individual para cada classe inválida.
A exigência de um caso de teste específico por classe de equivalência inválida se faz necessário pois a verificação de algumas condições de entrada pode mascarar ou anular a verificação de outras. 2. 2. Análise de Valor-Limite A partir da aplicação do Particionamento de Equivalência, nota-se que grande parte dos erros tende a ocorrer nas fronteiras do domínio de entrada [18, 22]. O critério de Análise de
Valor-limite complementa o partlcionamento de Equivalência por meio de casos de teste que exercitam os valores limítrofes. Valores-limite referem-se a situações que ocorrem dentro de uma classe de equivalência, diretamente acima ou abaixo dela. Nesse critério, o domínio de saída do programa também é particionado e auxilia na derivação dos casos de teste, que por sua vez devem ser escolhidos em cada um dos limites das classes. 2. 3.
Teste Funcional Sistemático O Teste Funcional Sistemático [141 é uma variante mais forte do Particionamento de Equivalência que leva em consideração os omínios de entrada e saída se undo um conjunto bem definido de regras. Uma v ionamento da entrada e PAGF s 0 particionamento da entrada e saída é efetuado, esse critério exige que sejam exercitados ao menos dois casos de teste em cada partição, uma vez que a utilização de apenas um valor pode mascarar erros coincidentes.
Além disso, o Teste Funcional Sistemático exige a avaliação dos valores limites e de suas proximidades, e oferece regras para facilitar a identificação dos casos de teste. Nessas regras são descritos que tipos de dados devem ser selecionados para variados tipos de função, omínios de entrada e de sarda, o que pode conduzir à seleção de um ou mais casos de teste, de acordo com o programa que está sendo testado. 3. Ferramentas de teste funcional A utilização de ferramentas de teste desempenha papel fundamental na aplicação de critérios de teste.
Sem o apoio de uma ferramenta, a atividade de teste torna-se trabalhosa, propensa a erros e limitada a programas simples. Além disso, como descreve Binder [3], a automatização permite a verificação rápida e eficiente das correções de defeitos, agiliza o processo de depuração, permite a captura e análise dos resultados de teste de orma consistente e facilita a execução de testes de regressão, nos quais os casos de teste podem ser reutilizados para revalidação do software após modificação.
Em geral as ferramentas utilizam o conceito de cobertura para medir o quanto um critério foi satisfeito em relação aos seus requisitos. Coberturas de nós, arcos e definiçõesuso constituem alguns exemplos utilizados pelas ferramentas [5, 26]. A análise de cobertura permite identificar áreas do programa não exercitadas por um conjunto de casos de teste e dessa forma avaliar a qualidade desse conjunto. Além disso PAGF 6 30 xercitadas por um conjunto de casos de teste e dessa forma avaliar a qualidade desse conjunto.
Além disso, por meio da análise de cobertura é possivel medlr o progresso do teste e decidir quando finalizar essa atividade. Embora a maioria das ferramentas existentes ofereça apoio apenas ao teste estrutural, algumas ferramentas especificas para teste funcional encontram- se dispon[veis, podendo-se citar TestComplete [1], SPACES [2], Jtest [20], XDE Tester [24] e o frameworkJUnit [10] que, apesar de não apoiar nenhuma técnica de teste específica, pode ser utilizado para especlflcação e execução dos casos de este.
Tabela 1 . Comparativo entre ferramentas de teste funcional Característica JUnit Jtest TestComplete XDE Tester Geração de casos de teste Execução de casos de teste Especificação de classes de equivalência Especificação de valores-limite Especificação de pré e pós-condições Análise de cobertura Teste de interface SPACES Na Tabela 1 é exibida uma comparação entre essas ferramentas de teste, na qual enfatizase características importantes do teste funcional.
Nota-se que nenhuma das ferramentas mostradas contempla todas as características desejáveis, e as características Especificação de classes de equivalência e Especificação de valores-limite nao têm suporte. A incapacidade de especificar esses dois tipo s funcionais (classes de PAGF 7 0 enfatizado. No entanto, ainda que possuam características semelhantes, é importante salientar que a ferramenta SPACES implementa as características segundo a ótica do teste funcional, enquanto a Jtest apresenta uma abordagem semelhante ? técnica estrutural.
De forma geral, nenhuma das ferramentas analisadas utiliza as técnicas ou critérios difundidos pela comunidade de teste de software e muitas vezes o teste funcional é tratado penas como teste de Interface. Além disso, nessas ferramentas a quantificação da atividade de teste é feita apenas em termos de cobertura de comandos ou funções. Cabe ao testador analisar, a partir da cobertura dos comandos executados e da especificação do software, a cobertura funcional alcançada.
A maioria das ferramentas analisadas também exige a disponibilidade do código fonte, característica muitas vezes não desejável no teste funcional. Assim, a técnica funcional muitas vezes é relegada em razão da falta de ferramentas que forneçam apoio direto à aplicação dos seus cntérios. . AspectJ e teste de software A Programação Orientada a Aspectos [1 3] baseia-se no conceito de separação de interesses e busca identificar interesses que estão espalhados pelo código da aplicação e implementá-los como módulos separados (denominados aspectos).
Essa abordagem permite que o projeto e a codificação sejam executados de maneira estruturada, refletindo a forma como o sistema é imaginado pelos seus projetistas O AspectJ [1 2] é a linguagem orientada a aspectos mais difundida atualmente e constituise de uma extensão orientada a aspectos para a linguagem Java. Est escenta para a linguagem Java. Esta extensão acrescenta novas construções à linguagem, permitindo a implementação de interesses entrecortantes de forma modular. or meio do AspectJ, o usuário pode definir pontos específicos no fluxo de execução do programa (pontos de junção (joinpoints)), como chamadas a métodos e criação de objetos. Os pontos de junção podem ser agrupados em conjuntos (conjuntos de junção (pointcuts)), facilitando a sua referência. Quando os pontos de junção são alcançados é possível executar procedimentos específicos (adendos (advices)), cuja strutura é semelhante à de um método. Os adendas podem ser executados antes, depois ou em substituição ao ponto de junção interceptado e permitem a alteração do comportamento do programa.
Informações de runtime referentes ao ponto de junção interceptado podem ser acessadas por meio de elementos específicos da linguagem e utilizadas no interior dos adendos. As novas construções do AspectJ são definidas em estruturas denominadas aspectos (aspects), que possuem formato semelhante ao das classes e são codificadas separadamente. Os aspectos e classes são compilados por um compilador special, que une os elementos e gera bytecode compatível com a linguagem Java. 4 6 7 interceptar chamadas a qualquer método de qualquer classe.
Sempre que uma chamada ocorrer, e antes da execução do método correspondente, o nome do método interceptado será impresso, como descrito pelo adendo anterior (especificado pela palavra before). 4. 1. Abordagens existentes para teste de software Apesar da POA ser uma abordagem recente, já existem iniciativas do seu uso para o apoio ao teste de software, utilizando principalmente a linguagem AspectJ. A separação entre código uncional e código de teste auxilia o manuseio de ambos, e a facllidade de inserir e remover aspectos na aplicação pode levar à criação de cenários de teste de forma mais rápida.
Além disso, os aspectos podem ser facilmente removidos quando a atividade de teste é finalizada, conservando intacto o programa original. Uma aplicação desse conceito é o uso de imitações virtuais de objetos, como uma alternativa aos objetos imitadores tradicionais no teste de unidade (objetos mock). Nessa técnica, proposta por Monk e Hall [1 7], nenhum objeto imitador é criado e, ao invés disso, o Aspect] é utilizado para interceptar chamadas aos métodos que estão sendo testados e retornar o valor desejado.
O uso de objetos imitadores virtuais permite que os dados de teste sejam definidos no próprio teste, e que testes diferentes atribuam valores imitadores distintos para o mesmo método. Além disso, com o uso dessa técnlca apenas os componentes de interesse são testados, e não é necessário instanciar objetos imitadores. Em outra abordagem, o AspectJ foi utilizado por Bruel et al. [4] para embutir testabilidade em com onentes de software. Segundo os autores, testa ser vista como