Teste Estrutural de Integração Nível 1 de Programas Orientados a Objetos e a Aspectos

Transcrição

1 Teste Estrutural de Integração Nível 1 de Programas Orientados a Objetos e a Aspectos Vânia de Oliveira Neves, Otávio Augusto Lazzarini Lemos, Paulo Cesar Masiero Departamento de Sistemas de Computação Universidade de São Paulo ICMC/USP São Carlos, SP, Brasil {vaniaon,oall,masiero}@icmc.usp.br Resumo Este artigo apresenta uma abordagem para o teste estrutural de integração nível 1 para programas OO e OA escritos em Java e AspectJ. Por meio dessa abordagem é possível revelar defeitos que podem ocorrer nas interfaces entre uma determinada unidade (método ou adendo) e todas as outras que interagem diretamente com ela, bem como revelar defeitos que podem ocorrer na sequência de chamadas dessas unidades. Abstract This paper presents an approach for integration testing of object oriented and aspect oriented programs. The first level of integration is considered and the target languages are Java and AspectJ. The proposed model and criteria support revealing faults that occur at the interfaces between a specific unit of implementation (method or advice) and each unit that interacts with it. Moreover, the presented criteria can also help revealing faults related to call sequences at the target unit. Keywords software testing; aspect oriented programming; object oriented programming;structural testing; integration testing; testing criteria; testing aspect oriented programs; testing object oriented programs; Java, AspectJ I. INTRODUÇÃO O surgimento da programação orientada a aspectos (POA) contribuiu para que os interesses transversais, que ficam espalhados e entrelaçados ao longo código, pudessem ser implementados e localizados em módulos específicos e, dessa forma, contribuiu para que seja possível projetar código com melhor estrutura modular [1]. Isso, entretanto, não evita que erros sejam introduzidos no código, inclusive pelos novos mecanismos de programação oferecidos pela POA. Com o objetivo de apoiar o teste de programas orientados a aspectos, diferentes propostas de modelos de falhas, técnicas, estratégias e ferramentas de teste vem sendo publicadas há alguns anos [2], [3], [4]. Nosso grupo tem trabalhado com o teste estrutural de programas OO e OA e nesse sentido foram feitas propostas e desenvolvidas ferramentas para apoiar o teste de unidades (métodos e adendos) [5] e para apoiar o teste de integração par a par entre métodos e adendos [6]. O teste estrutural é baseado em uma representação em que a estrutura do programa é requerida. O grafo de fluxo de controle (GFC) é usado para representar o fluxo de controle do programa, no qual cada nó representa uma sentença ou um bloco de sentenças executado sequencialmente e cada aresta representa o fluxo de controle de uma sentença ou bloco para outro bloco. Além disso, esse grafo pode ser estendido com informações a respeito das definições e usos das variáveis dos programas em cada nó e aresta do GFC [7] para permitir a definição de critérios de teste baseados em fluxo de dados. Embora o teste de integração par a par seja capaz de encontrar erros que ocorrem nas interfaces entre o método chamador e o método chamado, ele não é capaz de revelar defeitos que podem ocorrer, por exemplo, nas sequências de chamadas que envolvem mais de um método (ou adendo) chamado. O objetivo deste artigo é apresentar uma proposta de teste estrutural de integração de programas OO e OA que resolve esse problema, permitindo que uma unidade, seja ela um método ou adendo, seja testada pela técnica estrutural de forma integrada com todas as unidades com as quais ela interage diretamente, seja a chamada de um método ou o entrecorte e execução de um adendo. Isso envolve definir formalmente o grafo que integra o grafo da unidade chamadora com os grafos das unidades chamadas, propor critérios de teste para esta abordagem e realizar a implementação como uma extensão da ferramenta JaBUTi/AJ (ver seção II). Tratase, portanto, de um conjunto de integração com nível de profundidade um (1) em relação à hierarquia de chamadas. Para o problema aqui relatado não foi encontrada nenhuma outra proposta na literatura. Para melhor ilustrar, considere a Figura 1 onde U 0, U 1,, U n são unidades em um programa OO ou OA. U 0 representa a unidade sob teste (chamadora) e U 1,, U n as unidades chamadas diretamente por U 0 ou que afetam U 0 (no caso de adendos). Uma variável de referência x é passada como parâmetro para U 1 (onde ocorre uma definição dessa variável) e para U 2 (onde ocorre um uso). No teste de unidade seria testada cada uma dessas unidades individualmente. No teste par a par seria testado cada par de unidades que interagem diretamente, ou seja, os pares {(U 0, U 1 ), (U 0, U 2 ), (U 0, ), (U 0, U n )}. Como as unidades U 1 e U 2 não se relacionam diretamente (U 1 não é chamado (ou afetado) por U 2 e vice versa), nesse teste não seria considerado o par (U 1, U2). No entanto, pode ocorrer um de 31

2 feito relacionado à variável x passada como parâmetro nessas unidades e que a abordagem par a par não revelaria. A abordagem proposta neste artigo consiste em testar conjuntamente a interação entre todas essas unidades no contexto da unidade chamadora (U 0 ), ou seja {(U 0, U 1, U 2,, U n )}. Dessa forma, ela criaria um requisito de teste em que a sequência < U 0, U 1, U 2 > seja executada, passando pelos nós do grafo de fluxo de controle e/ou de dados desses métodos de tal forma que os nós em que x foi definido em U 1 e usado em U 2 são executados. Vale ressaltar que poderiam ter sido criadas outras sequências, como < U 0, U 1, U 1, U 2 >, < U 0, U 2, U 1, U 2 >, etc. Assim, a abordagem pode revelar um defeito que só seria apresentado caso fosse executada uma determinada sequência de chamadas. Figura 1. ou OA Exemplo de uma sequência de chamadas em um programa OO Este artigo está organizado da seguinte forma: na seção II são discutidos trabalhos relacionados a este. Na seção III é apresentado um exemplo motivacional; na seção IV apresenta se a abordagem para teste estrutural de integração nível 1 para programas OO e OA escritos em Java/AspectJ; na seção V é apresentada uma demonstração de uso da ferramenta Jabuti/AJ; na seção VI são discutidas algumas decisões tomadas para determinadas situações mais complexas; e, por fim, a seção VII contém as conclusões e trabalhos futuros. II. TRABALHOS RELACIONADOS Harrold e Rothermel [8] propuseram a primeira abordagem de teste para o teste de integração estrutural para programas orientados a objetos em que foram definidos os tipos de teste intramétodo, intermétodos, intraclasse e interclasses, mas sem propor uma ferramenta de apoio. Como eles consideram que a classe é a menor unidade a ser testada, apenas o teste interclasses é considerado como teste de integração nesse contexto; os demais são considerados teste de unidade. Vincenzi et al. [9] exploraram o teste estrutural de unidades para programas OO desenvolvidos em Java, considerando o método como a menor unidade a ser testada. Nesse trabalho foi desenvolvida a ferramenta JaBUTi, que deriva as informações de fluxo de dados sobre as definições e os usos das variáveis a partir do bytecode. Zhao [10] apresentou a primeira proposta de teste estrutural de programas orientados a aspectos (AspectJ). Ele considera a classe e o aspecto como sendo as menores unidades de um programa OA e sua proposta envolve a integração entre métodos e adendos. Lemos et al. [5] também apresentaram uma proposta para dar suporte ao teste estrutural de unidades de programas OO e OA escritos em AspectJ (considerando métodos e adendos como as menores unidades). Para isso foi definido um grafo de fluxo para programas orientados a aspectos (AODU Grafo Aspect Oriented Def Use) que explicita onde ocorre a interação com aspectos. Em seguida, Lemos et al. [6] estenderam esse grafo para dar apoio ao teste de integração par a par entre métodos e adendos. Como parte desse trabalho definiu se o grafo PWDU (PairWise Def Use). A ferramenta JaBUTi foi estendida nesses dois trabalhos para dar apoio ao teste de unidades e de integração par a par, criando se uma versão denominada JaBUTi/AJ. Vários trabalhos sobre teste de programas orientados a aspectos foram publicados nos últimos anos envolvendo outras técnicas e abordagens de teste. Assim, por exemplo, modelos de defeitos para programas orientados a objetos foram propostos [2], bem como algumas abordagens de teste baseado em estados [3], em erros (análise de mutantes) [4], em diagramas de comunicação [11] e na estrutura do programa. III. EXEMPLO MOTIVACIONAL Considere o código Java para o algoritmo heapsort apresentado na Figura 2. O código é composto por uma classe (HeapSort) e um aspecto (Change). A classe, por sua vez, é composta de três métodos (heapsort, buildmaxheap e swap) e o aspecto é composto por um adendo do tipo around (pcswap). O método heapsort tem como entrada um vetor v qualquer e a saída esperada é esse vetor ordenado. Para isso, ele chama os métodos buildmaxheap, swap e maxheapify. O método buildmaxheap recebe como parâmetro esse mesmo vetor e o retorna rearranjado com as propriedades de heap máximo. O método swap recebe um vetor v como parâmetro e dois índices desse vetor. A saída esperada é o vetor com os elementos dos índices dos parâmetros trocados de posição. Com os elementos trocados o vetor não atende às propriedades de heap máximo, por isso é chamado o método maxheapify para rearranjá lo. Ele recebe como entrada o vetor v, o índice da raiz e o tamanho do vetor. A saída esperada é o subvetor com as propriedades de heap máximo. Para exemplificar o uso de aspectos, a chamada ao método swap foi entrecortada pelo adendo around. A finalidade desse adendo é de apenas executar o método entrecortado (o swap), por meio do comando proceed. No entanto, foi inserido um defeito nesse adendo: quando o elemento de 32

3 1 public class Heapsort { 2 public static Integer[] 3 heapsort(integer v[]){ 4 buildmaxheap(v); 5 int n = v.length 1; 6 for (int i = n; i > 0; i ){ 7 swap(v, i, 0); 8 maxheapify(v, 0, i); 9 } 10 return v; 11 } 12 private static void 13 buildmaxheap(integer v[]){ 14 for (int i = v.length/2 1; 15 i >= 0; i ) 16 maxheapify(v, i, v.length); 17 } 18 private static void maxheapify 19 (Integer v[], int pos, int n){ 20 int max = 2 * pos + 1, right = 21 max + 1; 22 if (max < n){ 23 if ( right < n && v[max] < v[right]) 24 max = right; 25 if (v[max] > v[pos]){ 26 int aux = 0; 27 aux = v [max]; 28 v[max] = v[pos]; 29 v[pos] = aux; 30 maxheapify(v, max, n); 31 } 32 } 33 } 34 public static void 35 swap (Integer[] v, int j, int aposj ){ 36 int aux = 0; 37 aux = v[j]; 38 v [j] = v [ aposj ]; 39 v [ aposj ] = aux; 40 } 41 } public aspect Change { 44 pointcut 45 pcswap(integer[] v, 46 int j, int aposj): 47 call(* *.swap(..)) && 48 args(v, j, aposj); void around (Integer[] v, 51 int j, int aposj): 52 pcswap(v, j, aposj) { 53 if (v[j]!= v[aposj]){ 54 proceed(v, j, aposj); 55 } else { 56 Integer aux; 57 aux = v[v.length 1]; 58 v[v.length 1] = v[0]; 59 v[0] = aux; 60 } 61 } 62 } Figura 2. Código fonte do algoritmo heapsort. índice j for igual ao de índice aposj, no lugar de executar o método swap, o último elemento do vetor troca de posição com o primeiro elemento. Um exemplo de conjunto de casos de teste para o teste de unidade e para o teste par a par é descrito na Tabela I. Analisando esse conjunto e utilizando a ferramenta JaBU Ti/AJ para o teste de unidade e para o teste par a par, podese verificar que atinge 100% de cobertura para os critérios todos nós, todas arestas e todos usos dessas abordagens. No entanto, esses critérios não são capazes de revelar o defeito presente no adendo around, pois para revelá lo seria necessário encontrar uma sequência (ou sequências) de chamadas que executasse o bloco {56 59} (correspondente ao adendo around, onde ocorreu uma definição de v) e depois a linha {25} (correspondente ao método maxheapify, onde ocorreu um uso de v). Da mesma forma explicada na seção I, considerando a Figura 1 e tomando o método heapsort como sendo U 0, around como sendo U 1 e maxheapify como sendo U 2, o teste par a par não testaria o par (around,maxheapify), necessário para encontrar o defeito. Na próxima seção é apresentada uma abordagem que pode ajudar a revelar tal falha. IV. TESTE ESTRUTURAL DE INTEGRAÇÃO DE PROGRAMAS ORIENTADOS A OBJETOS E A ASPECTOS NO NÍVEL 1 DE PROFUNDIDADE Para representar adequadamente o fluxo de execução dos dados que ocorre entre uma determinada unidade e todas as unidades que interagem com ela diretamente, definiu se o grafo IN1P que estende o grafo PWDU. O grafo IN1P das unidades u 0, u 1,, u n (com u 0 como unidade chamadora e u 1,, u n como unidades chamadas) é definido como um grafo dirigido IN1P(u 0, u 1,, u n ) = (N, E, s, T, I, I s, R) tal que: N representa o conjunto completo de nós; E é o conjunto completo de arestas; s é o nó de entrada; T é o conjunto de nós de saída; I é o conjunto completo de nós de interação (nós transversais e de chamada); I s é o conjunto dos nós de interação que serão expandidos (ou seja, todos os nós de interação que não pertencem às chamadas a métodos de biblioteca); R é o conjunto dos nós de retorno das chamadas a 33

4 Tabela I EXEMPLO DE CONJUNTO DE CASOS DE TESTE PARA O TESTE DE UNIDADE E PARA O TESTE DE INTEGRAÇÃO PAR A PAR CT Unidade/par Entrada Saída Esperada 1 heapsort 2 buildmaxheap 3 maxheapify 4 around 5 around 6 around 7 heapsort buildmaxheap 8 heapsort maxheapify < [2, 1, 4, 5, < [1, 2, 3, 4, 6, 7, 3] > 5, 6, 7] > < [2, 1, 4, 5, < [7, 6, 4, 5, 6, 7, 3] > 1, 2, 3] > < [2, 1, 4, 5, < [2, 1, 7, 5, 6, 7, 3], 2, 7 > 6, 4, 3] > < [2, 2, 2, 2, < [2, 2, 2, 2, 2, 2, 2], 1, 2 > 2, 2, 2] > < [2, 1, 4, 5], < [1, 2, 4, 5] > 0, 1 > < [2, 1, 4, 5], < [1, 2, 4, 5] > 0, 1 > < [2, 1, 4, 5, < [1, 2, 3, 4, 6, 7, 3] > 5, 6, 7] > < [2, 1, 4, 5, < [1, 2, 3, 4, 6, 7, 3] > 5, 6, 7] > 9 heapsort swap < [2, 2, 1] > < [1, 2, 2] > 10 heapsort around < [2, 2, 2, 2, < [2, 2, 2, 2, 2, 2, 2] > 2, 2, 2] > u 1,, u n. A definição formal e completa desse grafo pode ser encontrada na dissertação de mestrado de Neves [12]. De maneira informal, o grafo IN1P é criado a partir de um programa único formado pela integração (inlining) do código da unidade chamadora com o código das unidades chamadas. Três critérios de fluxo de controle e de fluxo de dados foram propostos, os quais são definidos informalmente a seguir: 1) Todos Nós Integrados N1: sensibilizar todos os nós dos grafos de fluxo de todos os métodos e adendos integrado com o método sendo testado, com nível 1 de profundidade. Isto é, sensibilizar todos os nós das unidades integradas, no contexto da unidade chamadora. 2) Todas Arestas Integradas N1: sensibilizar todas as arestas dos grafos de fluxo de todos os métodos e adendos integrados com o método sendo testado, com nível 1 de profundidade. Isto é, sensibilizar todas as arestas das unidades integradas no contexto da unidade chamadora. 3) Todos Usos Integrados N1: sensibilizar todos os pares def uso do método ou adendo integrado com profundidade 1, sendo que a definição ocorre no método sob teste e o uso ocorre em um método ou adendo integrado e vice versa e também variáveis definidas em uma unidade integrada e usadas em outras unidades integradas. O modelo de fluxo de dados utilizado para identificar o que caracteriza uma definição ou um uso de uma variável em uma sentença Java, é o mesmo utilizado por Lemos et al. [6]. Com base no grafo, nos critérios propostos e no modelo de fluxo de dados, a ferramenta JaBUTI/AJ foi estendida para dar apoio ao teste de integração com um nível de profundidade. Notar que o nome da ferramenta permaneceu o mesmo. A partir dos critérios propostos é possível derivar os requisitos de teste para o teste estrutural de integração nível 1. Retomando o problema apresentado na seção anterior, se fosse utilizado o critério todos usos integrados N1, seria derivado um requisito de teste para a variável v definida no bloco {56 59} e usada na linha 25. Dessa forma para cobrir o requisito seria necessário um caso de teste que executasse uma determinada sequência de chamadas a métodos e/ou entrecortes de adendos que revelaria o defeito. V. USO DA ABORDAGEM COM APOIO DA FERRAMENTA JABUTI/AJ Para testar uma aplicação usando a ferramenta JaBUTi/AJ primeiramente é necessário criar um projeto de teste. Nesse passo, o testador seleciona as classes e os aspectos a serem testados. Por exemplo, para testar a aplicação apresentada na seção III, é necessário selecionar a classe HeapSort e o aspecto Change. Como a aspecto contém um adendo do tipo around, também será necessário selecionar a classe HeapSort$AjcClosure1, que encapsula o fluxo normal de execução que foi interrompido por esse adendo e que foi criada por meio do processo de compilação do AspectJ, conforme discutido na seção VI. O próximo passo, então, é selecionar o ambiente de teste de integração nível 1, criado para dar suporte a abordagem proposta neste artigo. Nessa etapa, a ferramenta exibe para o testador todos as unidades que chamam (ou são afetadas) por pelo menos um método (ou adendo), que pode, então, selecionar quais unidades ele deseja testar. Considerando o exemplo da seção III, todos os métodos e adendos envolvidos nesse algoritmo poderiam ser testados da mesma forma descrita a seguir. Neste caso a unidade sob teste é o método heapsort. O teste de integração com nível de profundidade 1 do método heapsort significa testá lo de forma integrada com todas as unidades que ele usa (os métodos para os quais ele envia mensagens), dentro ou fora da classe HeapSort (interclasses) e também com os adendos que são executados como resultado de aspectos que o afetam. Então, para o teste de integração nível 1, o programa integrado contendo os métodos swap, buildmaxheap, maxheapify e o adendo definido pelo pcswap no contexto do método heapsort é que será testado. Na Figura 3 é apresentado o grafo IN1P tendo o método heapsort como ponto de partida (chamada). Os nós com um prefixo (iniciados por um número e seguidos por :") são os grafos AODU de cada uma das unidades chamadas que foram integrados ao AODU da unidade chamadora (no caso heapsort). Cada prefixo está relacionado a uma unidade 34

5 chamada. No exemplo, os nós do método buildmaxheap tem o prefixo 1, os do método maxheapify tem o prefixo 3, e assim por diante. Note que o nó 4:0 (correspondente ao método swap) não é chamado por um nó do método heapsort, mas por um nó do adendo around (pcswap) (que tem 2 como prefixo). Esse é o caso discutido na seção VI em que um adendo do tipo around chama o método entrecortado via o comando proceed. A ferramenta calcula e atribui diferentes pesos para cada requisito de teste (identificado por cores diferentes) para identificar os requisitos que, quando cobertos, aumentariam a cobertura em relação ao critério selecionado. Na Figura 4 são exibidos os requisitos de teste para os critérios todos nósintegrados N1. A ferramenta JaBUTi/AJ também oferece suporte para a importação de casos de teste do JUnit para o projeto de teste. Depois de importar os casos de teste pode se checar a cobertura para cada critério de teste de integração nível 1 para cada unidade selecionada. Após ter importado um conjunto de casos de teste, a ferramenta atualiza o grafo e os requisitos de teste na qual na Figura 3 pode se perceber que os nós que foram exercitados foram pintados de branco e na Figura 4 nota se que foi calculada a porcentagem de cobertura para o critério todos nós integrados N1. O nó 2:20, do método maxheapify, por exemplo, não foi exercitado por nenhum dos casos de teste fornecidos. Isso facilita ao testador gerar novos casos de teste focando nos requisitos não cobertos. Nas figuras 5 e 6 são apresentados o grafo IN1P e os requisitos de teste para o critério todos usos integrados N1, respectivamente, atualizados considerando o conjunto {1, 9, 10} de casos de testes apresentados na Tabela I da seção III. As notações (x, i, j) e (x, i, (j, k)) utilizadas para representar os requisitos para esse critério indicam que a variável x é definida no nó i e existe um uso computacional no nó j ou um uso predicativo de x na aresta (j, k), respectivamente. Nessa notação, para identificar x é utilizado o nome da variável de comunicação conforme declarado na unidade chamadora 1. Pode se notar que há requisitos não cobertos como, por exemplo, o que está em destaque na Figura 6. Um caso de teste que exercitasse o caminho {4:0, 2:42, 71, 3:0, 3:16, 3:41, 3:87} satisfaria esse requisito. Analisando a lógica dos métodos e do adendo nota se que o caso de teste com a entrada [2, 2, 3, 2, 3, 3] exercitaria esse caminho. Assim, ao executar esse caso de teste um erro de integração aconteceria, revelando então o defeito apontado na seção III. Ao corrigir o programa, os casos de teste são executados com sucesso e a cobertura aumenta. Nesse ponto, o testador deveria continuar cobrindo as partes remanescentes do código que não foram cobertos para garantir a confiabilidade do programa. Figura 6. Requisitos de teste para o critério todos usos integrados N1 gerados para o método heapsort A estratégia de teste estrutural recomendada com o uso Figura 4. Requisitos de teste gerados para o método heapsort para o critério todos nós integrados N1 1 A ferramenta JaBUTi/AJ leva em consideração as informações do bytecode e de estruturas JVM e, por isso, os nomes das variáveis não são iguais às declaradas no código fonte. 35

6 Figura 3. Grafo IN1P do método heapsort Figura 5. Grafo IN1P do método heapsort para o critério todos usos integrados N1 da ferramenta Jabuti/AJ seria que o desenvolvedor testasse isoladamente as unidades desenvolvidas (métodos e adendos) usando os três critérios propostos por Lemos [5] e procurando alcançar 100% de cobertura (isso nem sempre é possível, pois pode haver caminhos não executáveis). Em seguida, utilizando o conjunto de casos de testes criados para o teste de unidades como ponto de partida, faça o teste de integração com nível 1 de profundidade e prossiga acrescentando novos casos de teste até atingir a cobertura desejada. VI. SOLUÇÕES PARA POLIMORFISMO E PARA O ADENDO AROUND COM PROCEED Há duas situações mais complexas para criar o grafo IN1P que envolvem polimorfismo e o uso de around que chama o método proceed. No primeiro caso, quando um método chamado é um método polimórfico, nem sempre é possível determinar em tempo de compilação qual dos métodos polimórficos será executado. Para contornar esse problema, a solução encontrada foi dar ao usuário a opção de selecionar quais os métodos que ele pretende integrar para fazer o teste. Para isso, é exibida uma tela com todos os métodos 36

7 polimórficos possíveis, onde o usuário poderá selecionar um ou mais métodos. O grafo IN1P é então montado compondo todos os grafos dos métodos selecionados pelo usuário. Para os casos em que é possível determinar em tempo de compilação qual dos métodos polimórficos será executado, a montagem do grafo IN1P é feita normalmente, ou seja, integrando apenas o método de interesse. O polimorfismo do tipo sobrecarga (overloading) sempre pertencerá a esse caso. Já para o polimorfismo do tipo sobrescrita (overriding) isso nem sempre ocorrerá. No segundo caso, os adendos do tipo around substituem a execução do método entrecortado pela execução do próprio adendo. Esse método só será executado caso exista uma chamada a ele via método proceed" no corpo do adendo desse tipo. O processo de compilação no AspectJ para esse caso é realizado da seguinte maneira: gera se um método que capta todos os argumentos originais ao método around mais um objeto adicional, o AroundClosure, que encapsula o fluxo normal de execução que foi interrompido pelo adendo. O corpo do método proceed chamará um método no AroundClosure (o método run) para continuar com a execução, passando por todas as regiões que foram afetadas pelo adendo around [13]. Vale ressaltar que esse processo é especifico do AspectJ. Dessa forma, por meio da análise do bytecode é possível observar que não se trata de uma chamada no nível 1 e a priori determinar que esse caso não deveria ser integrado. No entanto, essa solução estaria semanticamente incorreta visto que o método entrecortado está no nível 1. Por isso decidiu se que esse caso será integrado, o que tornou a implementação do grafo e dos critérios mais complexa. VII. CONCLUSÕES E TRABALHOS FUTUROS Neste artigo foi apresentada uma abordagem para teste estrutural de integração nível 1 de programas OO e OA. Com esta proposta é possível testar a interação de uma determinada unidade com todas as outras com as quais ela se relaciona diretamente e, dessa forma, além de revelar os defeitos que acontecem nas interfaces dessas unidades revelar também os defeitos que possam ocorrer nas sequências de chamadas. Como contribuições destacam se: o desenvolvimento desta abordagem, que inclui a definição do grafo IN1P e dos critérios de teste estrutural de integração nível 1(todos nós integrados N1, todas arestas integradas N1 e todos usos integrados N1), e a extensão da ferramenta JaBUTi/AJ que oferece suporte a ela. A ferramenta está disponível sob licença GNU General Public License (GPL) em A atividade de teste utilizando esta proposta pode ser considerada prática uma vez que só é considerado um nível de profundidade. A desvantagem desta abordagem é que ela é dependente do processo de compilação do AspectJ, que pode ser modificado em novas versões. A solução adotada funciona adequadamente para as versões mais recentes do AspectJ. Para o processo de combinação utilizando LTW (Load Time Weaving), a abordagem não funciona uma vez que nesse processo a combinação dos aspectos com as classes é realizada dinamicamente à medida que eles vão sendo carregados pela JVM. Como trabalho futuro, quando um método chamado se trata de um método linear e não possui nenhuma definição e uso de uma variável, pretende se otimizar o grafo não integrando esse método. Isso facilitaria o usuário, visto que para cobrir os nós/arestas de métodos desse tipo bastaria cobrir seus nós de chamada e evitaria criar requisitos de teste desnecessários. Outro trabalho em andamento aumenta o nível de profundidade para um nível k > 1, generalizando a proposta apresentada neste artigo. AGRADECIMENTOS Os autores agradecem à FAPESP e ao CNPq pelo apoio financeiro. REFERÊNCIAS [1] G. H. Kiczales, Aspect oriented programming, Proceeding European Conference on Object Oriented Programming, pp , [2] R. A. M. Mortensen, An approach for adequate testing of aspectj programs, in 1st Workshop on Testing Aspect Oriented Programs In Conjunction with AOSD 2005, [3] D. Xu, W. Xu, and Nygard, A state based approach to testing aspect oriented programs, in SEKE 05: Proceedings of the 17th International Conference on Software Engineering and Knowledge Engineering, [4] F. C. Ferrari, J. C. Maldonado, and A. Rashid, Mutation testing for aspect oriented programs, in ICST 08: Proceedings of the 2008 International Conference on Software Testing, Verification, and Validation. Washington, DC, USA: IEEE Computer Society, 2008, pp [5] O. A. L. Lemos, A. M. R. Vincenzi, J. C. Maldonado, and P. C. Masiero, Control and data flow structural testing criteria for aspect oriented programs, J. Syst. Softw., vol. 80, no. 6, pp , [6] O. A. L. Lemos, I. G. Franchin, and P. C. Masiero, Integration testing of object oriented and aspect oriented programs: A structural pairwise approach for java, Sci. Comput. Program., vol. 74, no. 10, pp , [7] S. Rapps and E. J. Weyuker, Selecting software test data using data flow information, IEEE Trans. Softw. Eng., vol. 11, no. 4, pp , [8] M. J. Harrold and G. Rothermel, Performing data flow testing on classes, in SIGSOFT 94: Proceedings of the 2nd ACM SIGSOFT symposium on Foundations of software engineering. New York, NY, USA: ACM, 1994, pp

8 [9] A. M. R. Vincenzi, M. E. Delamaro, J. C. Maldonado, and W. E. Wong, Establishing structural testing criteria for java bytecode, Softw. Pract. Exper., vol. 36, no. 14, pp , [10] J. Zhao, Data flow based unit testing of aspect oriented programs, in COMPSAC 03: Proceedings of the 27th Annual International Conference on Computer Software and Applications. Washington, DC, USA: IEEE Computer Society, 2003, p [11] P. Massicotte, L. Badri, and M. Badri, Towards a tool supporting integration testing of aspect oriented programs, Journal of Object Technology, vol. 6, no. 1, [12] V. de Oliveira Neves, Teste de integração contextual de programas orientados a objetos e a aspectos: critérios e automação (em preparação), Master s thesis, ICMC/USP, São Carlos/SP Brasil, [13] E. Hilsdale and J. Hugunin, Advice weaving in aspectj, in AOSD 04: Proceedings of the 3rd international conference on Aspect oriented software development. New York, NY, USA: ACM, 2004, pp