de exce¸c˜ao
O trabalho de Coelho et al. (2011) apresenta uma abordagem de verifica¸c˜ao com o ob- jetivo de verificar a confiabilidade do c´odigo de tratamento de exce¸c˜oes em programas AspectJ. Essa abordagem tenta ajudar o desenvolvedor a identificar como integrar efeti- vamente os aspectos no c´odigo base, reduzindo o risco de introdu¸c˜ao de falhas no c´odigo de tratamento de exce¸c˜oes. Para isso a abordagem apoia o desenvolvedor a compreen- der o fluxo excepcional dos sistemas OA, descrever contratos de tratamento de exce¸c˜oes e verificar automaticamente tais contratos. A abordagem ´e composta por cinco etapas principais, que podem ser visualizadas na figura 3.9; algumas s˜ao apoiadas por uma fer- ramenta denominada SAFE. Essa abordagem ´e complementar a algumas abordagens de teste OA.
Nunes et al. (2009) apresentam uma abordagem para gera¸c˜ao de dados de teste para o fluxo de exce¸c˜oes em programas Java. Para isso, s˜ao geradas informa¸c˜oes sobre o fluxo
Figura 3.7: Codigo fonte das classes Employee, Paymentinfo, WorkInfo e do aspecto AcessControl(Lemos e Masiero, 2011)
Figura 3.8: Grafo AODU do m´etodo affectedMethod entrecortado pelo aspecto anAs- pect (Lemos e Masiero, 2011)
de dados do programa e a partir delas s˜ao definidos os requisitos de teste para o fluxo de exce¸c˜oes.
Xavier et al. (2008) prop˜oem uma abordagem de verifica¸c˜ao apoiada pela ferramenta Java PathFinderExceptions com o objetivo de reduzir o espa¸co de teste. Para isso, a partir de um arquivo XML que cont´em os objetos e exce¸c˜oes do sistema, juntamente com os seus pares def-uso, ´e realizada a verifica¸c˜ao de quais pares def-uso s˜ao cobertos pela verifica¸c˜ao e quais n˜ao s˜ao cobertos. Assim, diminuindo a quantidade de testes necess´arios para a valida¸c˜ao do sistema.
Figura 3.9: Etapas da abordagem de an´alise est´atica proposta por Coelho et al. (2011) Di Bernardo et al. (2011), propuseram uma abordagem ´agil para testar fluxo de exce¸c˜ao baseada em testes funcionais. Esta abordagem pode ser usada para escrever os testes antes da implementa¸c˜ao do sistema (”testfirst”) e tamb´em pode ser aplicada nas etapas finais de desenvolvimento, para ajudar nas atividades e em sistemas existentes. Essa abordagem tem o objetivo de testar se os caminhos percorridos pelas exce¸c˜oes a partir dos pontos onde elas s˜ao lan¸cadas at´e os seu tratamento est˜ao implementadas da maneira correta. Assim, um teste verifica o fluxo de exce¸c˜ao com base em uma especifica¸c˜ao e compara com o fluxo de exce¸c˜oes que ocorre na execu¸c˜ao. A abordagem de teste funcional proposta para teste do fluxo de exce¸c˜ao pode ser dividida nas seguintes atividades: selecionar os principais fluxos de exce¸c˜ao, criar casos de testes para exercitar estes caminhos, testar o conjunto de casos de teste, verificar os resultados dos testes, corre¸c˜ao de erros, reaplica¸c˜ao dos testes.
Sales e Coelho (2011) propuseram uma abordagem que permite definir regras de design para o tratamento de exce¸c˜oes que podem ser checadas dinamicamente atrav´es de testes. Para a defini¸c˜ao das regras de tratamento de exce¸c˜oes ´e utilizado um arquivo de contratos de exce¸c˜oes (um exemplo desse arquivo pode ser visto na figura 3.10). O contrato de ex- ce¸c˜oes utiliza o formato XML e ´e formado por uma ou mais cl´ausulas, em que cada cl´ausula cont´em trˆes elementos principais, que s˜ao: o sinalizador, que indica um ou mais m´etodos que lan¸cam um tipo de exce¸c˜ao, a exce¸c˜ao, que indica o tipo da exce¸c˜ao e o tratador, que define um ou mais m´etodos respons´aveis pelo tratamento de exce¸c˜oes. O exemplo apresentado na 3.10 mostra trˆes cl´ausulas a primeira especifica que: as exce¸c˜oes do tipo exception1 podem ser lan¸cadas pelo m´etodo funcition1() e devem ser tratadas por no m´etodo function2(). Tendo definido o arquivo de contrato de exce¸c˜oes implementa-se casos de teste para exercitar os tratamentos de exce¸c˜oes para checar se eles est˜ao adequa- dos ao contrato de exce¸c˜oes, ou seja se as exce¸c˜oes foram lan¸cadas e tratadas conforme as regras especificadas no contrato de exce¸c˜oes. Para esse tipo de testes a abordagem possui suporte da ferramenta VITTAE.
Figura 3.10: Exemplo de contrato de exce¸c˜ao.
Romano et al. (2011) prop˜oem uma abordagem para gera¸c˜ao de dados de testes com base em busca (search-based ) com o objetivo de identificar automaticamente exce¸c˜oes do tipo NullPointerException em programas Java. A primeira etapa dessa abordagem consiste em um conjunto de dados interprocessual e de an´alise do fluxo de controle, que identifica os caminhos entre os parˆametros de entrada e potencias NullPointerException. A segunda ´e um algoritmo gen´etico capaz de lidar com entradas complexas contendo estruturas de dados arbitr´arias, que s˜ao utilizadas para evoluir a popula¸c˜ao de dados de teste com o objetivo de abranger os caminhos identificados na etapa.
Outra abordagem ´e a proposta por Breech et al. (2008), denominada Rugrat, que ´e diferente da maioria das outras abordagens tratadas nesta sess˜ao. Rugrat ´e independente de linguagem, n˜ao sendo necess´arias altera¸c˜oes no c´odigo para seu uso, e n˜ao utiliza grafos de fluxo de controle para an´alise. Para esta abordagem ´e necess´ario da especifica¸c˜ao do teste, do programa compilado e do conjunto de entrada para o programa, para que a partir dessas entradas Rugrat crie testes em tempo de execu¸c˜ao, que s˜ao basicamente instru¸c˜oes execut´aveis adicionadas ao programa para modificar o estado de execu¸c˜ao do programa para simular uma situa¸c˜ao incomum. Para avaliar a abordagem Rugrat (Breech et al., 2008), foram realizados testes em programas na linguagem C tentando identificar erros na manipula¸c˜ao de erro. A manipula¸c˜ao de erro ´e o mecanismo usado pela linguagem C para lidar com falhas, j´a que n˜ao possui mecanismo de tratamento de exce¸c˜oes. Esses testes d˜ao ind´ıcios de que essa abordagem pode ser usada para testar o tratamento de exce¸c˜oes do C++ e outras linguagens desde que elas sejam compiladas e possuam tratamento de exce¸c˜oes. Quanto ao suporte da abordagem Rugrat para linguagem Java, isso ainda n˜ao
´e poss´ıvel, pois a abordagem s´o tem suporte para linguagens compiladas, mas os autores prop˜oe uma arquitetura para que seja poss´ıvel criar uma extens˜ao da ferramenta que possa testar programas na linguagem Java.