Existem v´arias t´ecnicas para teste e an´alise de programas baseadas em teste estrutural. A primeira abordagem de teste estrutural em programas com mecanismo de tratamento de exce¸c˜oes foi proposta por Sinha e Harrold (1999), e os seus principais conceitos s˜ao apresentados nesta se¸c˜ao.
Exce¸c˜oes s˜ao definidas nas seguintes condi¸c˜oes: • Um valor ´e associado a uma vari´avel de exce¸c˜ao,
Ex: Exception e = new Exception();
• Em um bloco catch no qual um valor ´e associado a uma vari´avel de exce¸c˜ao e a vari´avel tempor´aria de exce¸c˜ao ´e associada a null,
Ex: catch(Exception e)
• Em um n´o throw que utiliza uma vari´avel tempor´aria de exce¸c˜ao, Ex: throw new Exception();
• Em um n´o throw no qual ´e estabelecida uma associa¸c˜ao com a vari´avel tempor´aria de exce¸c˜ao.
Ex: throw e;
Exce¸c˜oes s˜ao utilizadas nas seguintes condi¸c˜oes:; • O valor de uma vari´avel de exce¸c˜ao ´e acessada,
Ex: System.out.println(e);
• Em um bloco catch, o valor da vari´avel tempor´aria de exce¸c˜ao ´e acessado, Ex: catch(Exception e);
• Em um n´o throw com uma vari´avel tempor´aria de exce¸c˜ao, Ex: throw new Exception().
Um conjunto defini¸c˜ao-uso para uma exce¸c˜ao (e-du) ´e uma tripla ( v, i, j ), em que i ´e a linha onde a vari´avel v foi definida e j onde foi usada. Al´em das defini¸c˜oes e uso, exce¸c˜oes apresentam outro conceito associado `a ativa¸c˜ao e desativa¸c˜ao, ou seja, quando um objeto de exce¸c˜ao ´e associado ou desassociado de uma vari´avel tempor´aria de exce¸c˜ao. Uma cl´ausula throw ativa uma exce¸c˜ao e uma cl´ausula catch desativa uma exce¸c˜ao. Al´em disso, uma exce¸c˜ao pode ser desativada dentro de uma cl´ausula finally com o uso dos comandos return, break, continue ou outra cl´ausula throw. Um conjunto ativa¸c˜ao-desativa¸c˜ao para uma exce¸c˜ao ( e-ad ) ´e uma tripla ( v, i, j ), onde i ´e a linha na qual v foi ativada e j a linha em que foi desativada.
A abordagem apresentada define os seguintes crit´erios de teste: • all-throw: deve-se executar todos os n´os throw,
• all-catch: deve-se executar todos os n´os catch,
• all-e-defs: deve-se executar os caminhos do programa com o objetivo de cobrir todas as defini¸c˜oes de exce¸c˜oes e pelo menos um uso de cada uma (´e semelhante ao crit´erio todas-def-use de testes baseados em fluxo de dados),
• all-e-use: deve-se executar todas as triplas defini¸c˜oes-uso das exce¸c˜oes.
• all-e-act: deve-se executar os caminhos do programa de forma a cobrir todas as ativa¸c˜oes e pelo menos uma desativa¸c˜ao de cada exce¸c˜ao. Ou seja, ´e semelhante ao crit´erio all-e-defs, trocando as defini¸c˜oes e usos por ativa¸c˜oes e desativa¸c˜oes,
• all-e-deact: deve-se exercitar todas as triplas ativa¸c˜ao-desativa¸c˜ao das exce¸c˜oes. Para analisar essa abordagem considere o programa 2.7, a partir do qual foi gerado o CFG integrado. Nesse grafo, cada n´o corresponde a um conjunto de instru¸c˜oes e para identificar a que conjunto de instru¸c˜oes o n´o representa basta verificar seu identificador, que corresponde ao n´umero da linha no c´odigo fonte no qual o conjunto de instru¸c˜oes come¸ca. No grafo tamb´em pode-se observar quatro tipos diferentes de setas, cada uma re- presentando um tipo de fluxo: a de linha continua representa o fluxo normal intra-m´etodo, a tracejada o fluxo normal inter-m´etodos e as linhas pontilhada e tracejada-pontilhada re- presentam o fluxo excepcional intra-m´etodo e inter-m´etodos respectivamente. Usando-se o grafo mostrado na figura 2.7 ´e poss´ıvel gerar os requisitos para cada um dos crit´erios propostos por Sinha e Harrold (1999), como na tabela 2.1.
Figura 2.7: Exemplo de programa e GFC integrado constru´ıdo com a utiliza¸c˜ao da abor- dagem de Sinha e Harrold (2000)
Crit´erio Requisitos all-throw 30; 32; 33 all-catch 2; 10; 33; 38 all-e-defs 2,7; 10,10; 16,30; 16,32; 33,33; 38,38 all-e-use 2,7; 2,5; 10,10; 16,30; 16,32; 33,33; 38,38 all-e-act 30,33; 32,38; 33,2 all-e-deact 2,7; 10,10; 16,30; 16,32; 30,33; 32,38 33,33; ; 33,2; 38,38;
Tabela 2.1: Requisitos de teste para os crit´erios propostos por Sinha e Harrold (1999)
2.4
Considera¸c˜oes Finais
Neste cap´ıtulo foi apresentada uma vis˜ao geral sobre o tratamento de exce¸c˜oes e a atividade de teste de software. Primeiramente foram apresentados os principais conceitos referentes ao tratamento de exce¸c˜oes e teste de software e em seguida foi apresentada uma vis˜ao geral sobre teste estrutural para tratamento de exce¸c˜oes. As informa¸c˜oes apresentadas neste cap´ıtulo servem como base para a compreens˜ao dos cap´ıtulos seguintes. No pr´oximo cap´ıtulo ´e apresentada uma s´ıntese da revis˜ao sistem´atica realizada sobre o teste estrutural de tratamento de exce¸c˜oes e ´e feita uma an´alise sucinta dos principais artigos relacionados ao tema desta disserta¸c˜ao.
3
Teste e verifica¸c˜ao de tratamento de
exce¸c˜oes em programas OO e OA: uma
revis˜ao da literatura
3.1
Considera¸c˜oes Iniciais
Este cap´ıtulo apresenta um resumo das informa¸c˜oes mais importante de uma revis˜ao bibliogr´afica sobre teste e verifica¸c˜ao de tratamento de exce¸c˜oes. O principal objetivo dessa revis˜ao foi a identifica¸c˜ao de trabalhos que apresentam abordagens para teste estrutural de tratamento de exce¸c˜oes. Al´em disso, tamb´em visou identificar ferramentas de apoio para as abordagens e modelos de defeitos, padr˜oes de defeitos e estudos emp´ıricos realizados para avaliar as abordagens identificadas.
O restante deste cap´ıtulo est´a organizado como segue. Na Se¸c˜ao 3.2 ´e apresentado o planejamento desta revis˜ao bibliogr´afica. Na Se¸c˜ao 3.3 s˜ao apresentados trabalhos refe- rentes ao teste estrutural de tratamento de exce¸c˜oes. Na se¸c˜ao 3.4 s˜ao apresentadas outras abordagens de teste e verifica¸c˜ao do fluxo de exce¸c˜ao. Na se¸c˜ao 3.5 s˜ao apresentadas as ferramentas encontradas nesta revis˜ao que d˜ao suporte ao teste do fluxo de exce¸c˜ao. Na se¸c˜ao 3.6 s˜ao apresentados padr˜oes de erros e modelos de defeitos. Na se¸c˜ao 3.7 s˜ao apre- sentados estudos emp´ıricos realizados para avaliar algumas das abordagens identificadas. Por fim, na Se¸c˜ao 3.8 s˜ao apresentadas as considera¸c˜oes finais do cap´ıtulo.
3.2
Revis˜ao da literatura
O planejamento da revis˜ao apresentado neste cap´ıtulo foi inspirado pela proposta de Kitchenham (2004). As atividades referentes ao planejamento e condu¸c˜ao da revis˜ao foram acompanhadas por um especialista (orientador de mestrado do revisor) que ofereceu o suporte te´orico e pr´atico necess´ario para a condu¸c˜ao da revis˜ao.
3.2.1
Planejamento de Revis˜ao
A primeira fase da revis˜ao ´e o seu planejamento. Nessa fase devem ser definidos os objetivos da pesquisa e a forma como a revis˜ao ser´a conduzida. Algumas das informa¸c˜oes mais relevantes do planejamento da revis˜ao realizada s˜ao apresentadas a seguir.
Quatro quest˜oes de pesquisa foram elaboradas para satisfazer os objetivos desta revi- s˜ao:
• Quais abordagens existem para teste de tratamento de exce¸c˜oes em programas OA e OO ?
• Quais estudos tˆem sido realizados para avaliar as abordagens propostas para teste estrutural de tratamento de exce¸c˜oes?
• Quais s˜ao as ferramentas existentes para teste de tratamento de exce¸c˜oes em pro- gramas OA e OO?
• Quais s˜ao os principais tipos de defeitos em rela¸c˜ao ao tratamento de exce¸c˜oes em programas OA e OO?
3.2.2
Recursos para Busca e Sele¸c˜ao de Estudos
Os recursos e estrat´egias para busca e sele¸c˜ao de estudos preliminares foram definidos com base em trˆes itens fundamentais para o sucesso da pesquisa: a identifica¸c˜ao de boas fontes de busca, defini¸c˜ao dos idiomas das obras e defini¸c˜ao dos termos relacionados ao tema de pesquisa:
• Identifica¸c˜ao de fontes de busca: As fontes escolhidas foram algumas das prin- cipais bases da ´area de computa¸c˜ao, tais como IEEE, ACM, Scopus, SciELO, Sci- ence Direct e tamb´em uma busca manual exaustiva nas ´ultimas dez edi¸c˜oes da
ACM International Conference on Aspect-oriented Software Development e em to-
das as edi¸c˜oes do Lecture Notes in Computer Science Transactions on AOSD, que ´e parte da serie Lecture Notes in Computer Science e por fim consultas a especialistas (ICMC-USP).
• Idiomas dos trabalhos: O inglˆes, por ser a l´ıngua internacionalmente usada para escrever trabalhos cient´ıficos e o portuguˆes, pela ´area ter muitos pesquisadores no Brasil;
• Termos Relacionados: Teste estrutural, tratamento de exce¸c˜oes, Programas Ori- entados a Objetos, Programas Orientados a Aspectos, Ferramentas.
Para busca optou-se pela op¸c˜ao de pesquisar nos textos completos ao inv´es de apenas no resumo. A string de busca n˜ao cont´em os termos referentes `a OO ou OA, pois os retornos em sua maioria s˜ao referentes a estes tipos de programas possivelmente porque o mecanismo de tratamento de exce¸c˜oes come¸cou com os programas OO, e tamb´em optou-se por restringir a busca somente trabalhos posteriores ao ano 2000 pois foi a partir desse ano que come¸caram os trabalhos com Aspectos. Para realizar a busca dos estudos, a string de busca foi adaptada para pesquisa em cada uma das fontes de busca, mas a string gen´erica ficou defina da seguinte forma: (”structural test”OR ”structural testing”) AND (”Exception
Handling”OR ”exceptional behavior”).
Para sele¸c˜ao dos estudos foram definidos 7 crit´erios de inclus˜ao e exclus˜ao. Os cri- t´erios de inclus˜ao foram propostos em dois grupos o prim´ario e o secund´ario dentre eles o prim´ario ´e o grupo com os crit´erios mais relevantes. Assim os crit´erios de inclus˜ao e exclus˜ao foram definidos da seguinte forma:
• Crit´erios de inclus˜ao prim´arios
1. Estudos emp´ıricos avaliando efic´acia/custo de abordagens de teste de trata- mento de exce¸c˜oes;
2. Abordagens de teste de tratamento de exce¸c˜oes;
3. Ferramentas que apoiam teste de tratamento de exce¸c˜oes; • Crit´erios de inclus˜ao secund´arios
1. Modelo de falhas de tratamento de exce¸c˜oes em programas OO e OA; 2. Abordagens de VV&T de tratamento de exce¸c˜oes;
3. Abordagens de gera¸c˜ao de dados de teste de tratamento de exce¸c˜oes;
4. Estudo, modelo , abordagem ou ferramenta interessante e vi´avel de ser adap- tado para o teste de tratamento de exce¸c˜oes;
• Crit´erios de Exclus˜ao
2. N˜ao se trata de teste estrutural; 3. N˜ao se trata de teste de software;
4. N˜ao se trata de Tratamento de exce¸c˜oes;
5. N˜ao se encontra redigido em inglˆes ou portuguˆes; 6. N˜ao corresponde a pesquisa ou publica¸c˜ao; 7. Vers˜ao completa n˜ao est´a dispon´ıvel.
O resultado da busca e sele¸c˜ao pode ser visualizado na tabela 3.1 que informa os trabalhos inclu´ıdos, exclu´ıdos e repetidos para cada uma das fontes de pesquisa. No total foram retornados quatrocentos e cinquenta e oito trabalhos que passaram pela sele¸c˜ao preliminar, em que foi realizada a leitura dos resumos, e depois da sele¸c˜ao final. Ap´os a sele¸c˜ao foram inclu´ıdos trinta e oito trabalhos e exclu´ıdos quatrocentos e vinte trabalhos, e ent˜ao foi realizada a leitura completa dos trabalhos. Dentre os trabalhos selecionados dezenove deles s˜ao mais relevantes no contexto deste trabalho. Sobre eles uma an´alise e uma s´ıntese das suas principais contribui¸c˜oes s˜ao apresentadas nas se¸c˜oes seguintes.
IEEE ACM Scopus Science SciELO LNCS AOSD Cons. Σ
Direct a Esp. Trab. Inc. 13 10 5 5 0 0 4 1 38 Trab. Exc. 43 73 7 9 0 75 202 0 409 Trab. Rep. 0 1 5 0 0 0 0 5 11 Total/ Fonte 56 84 17 14 0 75 206 6 458
Tabela 3.1: Resultados da revis˜ao bibliogr´afica por fonte de pesquisa.
3.3
Teste Estrutural de tratamento de exce¸c˜oes
A primeira abordagem de teste estrutural para tratamento de exce¸c˜oes discutida nesta revis˜ao foi proposta por Sinha e Harrold (1999), na qual s˜ao propostos seis crit´erios de teste de tratamento de exce¸c˜oes para programas Java, os quais est˜ao descritos no Cap´ıtulo 2. Esses crit´erios apoiam o teste de integra¸c˜ao, sendo que, quatro s˜ao de fluxo de controle e dois de fluxo de dados. Esse trabalho discute a hierarquia entre os crit´erios e seus relacionamentos e tamb´em apresenta um m´etodo para sua aplica¸c˜ao em testes de unidade e de integra¸c˜ao. Uma continua¸c˜ao desse trabalho prop˜oe representa¸c˜oes para programas OO em Java contendo a tratamento de exce¸c˜oes por meio de um grafo de integra¸c˜ao,
assim como algoritmos para constru¸c˜ao desses grafos. A t´ecnica para a cria¸c˜ao do grafo denominado GFC interprocedural (GFCI) com fluxo de exce¸c˜oes pode ser descrita nos seguintes passos (Sinha e Harrold, 2000):
1. Numeram-se todas as linhas do programa;
2. Cada bloco indivis´ıvel do programa ´e representado por um n´o com seu respectivo n´umero;
3. Os n´os s˜ao interligados por arestas;
4. Para cada ponto onde ´e feita uma chamada a um m´etodo divide-se o n´o em um ponto de sa´ıda para o retorno do m´etodo. As arestas de fluxo entre m´etodos s˜ao representadas em linhas pontilhadas;
5. Cada m´etodo tem um n´o de entrada e um n´o de sa´ıda;
6. Cada lan¸camento de exce¸c˜ao (throw) gera uma aresta de sa´ıda com a identifica¸c˜ao da exce¸c˜ao que est´a sendo gerada;
7. Caso a exce¸c˜ao seja capturada por uma cl´ausula catch no mesmo m´etodo, esta aresta ser´a conectada ao n´o correspondente, caso contr´ario ser´a criado um n´o de sa´ıda excepcional para retorno ao m´etodo chamador. Este n´o de sa´ıda identifica o tipo de exce¸c˜ao que o gerou;
8. Cada n´o de bloco catch ´e representado por um n´o com um r´otulo referente ao tipo de exce¸c˜ao que trata, al´em do n´umero da linha;
9. Blocos finally s˜ao tratados como se fossem m´etodos, possuindo n´os de entrada e de sa´ıda.
Um exemplo de c´odigo e seu respectivo IGFC, de acordo com a proposta de Sinha e Harrold (2000) pode ser visualizado na figura 2.7.
Ainda nessa linha de trabalho, Mao e Lu (2005) prop˜oem uma nova abordagem para teste de integra¸c˜ao voltada para a linguagem C++. Uma das principais contribui¸c˜oes que se destaca nessa abordagem ´e a apresenta¸c˜ao de um m´etodo para tratar exce¸c˜oes impl´ıcitas, pois alguns trabalhos, tratam apenas de exce¸c˜oes expl´ıcitas. Nessa abordagem, al´em dos lan¸camentos de exce¸c˜oes que ocorrem quando uma instru¸c˜ao gera uma exce¸c˜ao usando o comando throw, tamb´em s˜ao tratados os potenciais lan¸camentos de exce¸c˜oes que ocorrem se uma instru¸c˜ao n˜ao cont´em explicitamente um lan¸camento de exce¸c˜ao usando um comando throw, mas tem grandes chances de lan¸car uma exce¸c˜ao. Mao e Lu (2005) prop˜oem algumas maneiras de se identificar um potencial para lan¸camento de exce¸c˜ao (PES), que s˜ao:
• Conhecer os tipos b´asicos de exce¸c˜oes definidos na linguagem, e descobrir quais co- mandos (mecanismos da linguagem) podem gerar exce¸c˜oes para os tipos de exce¸c˜ao definidos na linguagem;
• Programadores experientes podem definir o tipo de instru¸c˜ao que ´e prov´avel ser ter PES;
• Identificar as categorias e causas de PES, com base em resultados de testes anteri- ores.
A discuss˜ao sobre exce¸c˜oes impl´ıcitas aborda quais tipos s˜ao mais relevantes. Dessa forma, sugere-se que somente as exce¸c˜oes impl´ıcitas com alta chance de ocorrˆencia s˜ao relevantes para a atividade de teste na abordagem proposta. Eles tamb´em prop˜oem uma representa¸c˜ao na forma de um grafo para programas OO em C++ contendo o fluxo de exce¸c˜oes impl´ıcitas e exce¸c˜oes expl´ıcitas, assim como um algoritmo para cria¸c˜ao do grafo proposto. A figura 3.1 mostra um exemplo de um GFCI criado por essa abordagem.
A figura 2.7, representa o mesmo exemplo em Java e a abordagem de Sinha e Harrold (2000) permitindo comparar as duas abordagens. Na representa¸c˜ao proposta por Sinha e Harrold (2000) s´o ´e poss´ıvel identificar trˆes lan¸camentos de exce¸c˜ao nos n´os 30, 32 e 33 e que n˜ao existe uma aresta que leve at´e o n´o 10 que corresponde ao segundo catch do m´etodo function2. Na representa¸c˜ao proposta por Mao e Lu (2005) identificam-se seis lan¸camentos de exce¸c˜ao nos n´os 14, 15 e 18 que correspondem aos n´os 30, 32 e 33 do outro grafo e mais trˆes poss´ıveis lan¸camentos de exce¸c˜ao nos n´os 8 e 9 que correspondem a lan¸camentos impl´ıcitos. A partir desses lan¸camentos passam a existir caminhos que podem exercitar o segundo catch do m´etodo function2 que corresponde ao n´o 27 e que na outra representa¸c˜ao correspondia ao n´o 10, para o qual n˜ao existiam caminhos no grafo que permitiam alcan¸c´a-lo.
Alguns crit´erios de teste para programas Java foram pospostos por Vincenzi et al. (2006) para o teste de unidade. Al´em disso, ao inv´es de testar o c´odigo fonte dos programas estes crit´erios testam o bytecode da linguagem Java. Para entendimento desses crit´erios s˜ao apresentados alguns conceitos:
Considere N o conjunto de n´os e E o conjunto de arestas de um grafo de programa com informa¸c˜oes de tratamento de exce¸c˜oes.
Aresta de exce¸c˜ao: s˜ao desvios no fluxo de controle de um programa, que fazem com que ele saia de algum ponto em um bloco try e v´a para o inicio de um bloco catch ou finally. Normalmente esses desvios s˜ao gerados pelo lan¸camento de uma exce¸c˜ao. Aresta regular: s˜ao todos os desvios no fluxo de controle de um programa, que n˜ao s˜ao
Figura 3.1: GFCI constru´ıdo com utiliza¸c˜ao da abordagem de Mao e Lu (2005) Caminho livre de exce¸c˜ao: ´e alcan¸c´avel por meio de um caminho que n˜ao contenha
arestas de exce¸c˜ao.
N´os dependentes de exce¸c˜ao (Ned) : ´e um subconjunto completo de n´os que s´o po- dem ser alcan¸cados em um caminho que contenha o lan¸camento de uma exce¸c˜ao. N´os independentes de exce¸c˜ao (Nei) : ´e um subconjunto completo de n´os que podem
ser alcan¸cados por um caminho livre de exce¸c˜ao. ´E importante ressaltar que esses subconjuntos s˜ao distintos, ou seja, Nei ∩ Ned = ∅, e que juntos representam o conjunto completo de n´os de um grafo de programa, ou seja,Nei∪ Ned = N .
Arestas dependentes de exce¸c˜ao (Eed) : ´e um subconjunto completo de arestas que s´o podem ser alcan¸cadas em um caminho que contenha o lan¸camento de uma exce- ¸c˜ao. ´E importante ressaltar que arestas regulares podem fazer parte de Eed. Isso ocorre quando uma aresta regular s´o puder ser alcan¸cada em um caminho onde ocorre o lan¸camento de uma exce¸c˜ao.
Arestas independentes de exce¸c˜ao (Eei) : ´e um subconjunto completo de arestas que podem ser alcan¸cadas por um caminho livre de exce¸c˜ao. ´E importante ressaltar que esses subconjuntos s˜ao distintos, ou seja, Eei∩ Eed = ∅, e que juntos representam o conjunto completo de n´os de um grafo de programa, ou seja, Eei∪ Eed = E.
Com base nos conceitos apresentados, os crit´erios de teste propostos por Vincenzi et al. (2006) s˜ao:
• todos-n´os-independentes-de-exce¸c˜ao (Todos-N´osei): requer que cada n´o al- can¸c´avel por meio de pelo menos um caminho livre de exce¸c˜ao seja exercitado ao menos uma vez;
• todos-n´os-dependentes-de-exce¸c˜ao (Todos-N´osed): requer que cada n´o n˜ao alcan¸c´avel por meio de pelo menos um caminho livre de exce¸c˜ao seja exercitado ao menos uma vez;
• todas-arestas-independentes-de-exce¸c˜ao (Todos-Arestasei): requer que cada aresta alcan¸c´avel por meio de pelo menos um caminho livre de exce¸c˜ao seja execu- tada ao menos uma vez;
• todas-arestas-dependentes-de-exce¸c˜ao (Todos-Arestased): requer que cada aresta que n˜ao ´e alcan¸c´avel por meio de pelo menos um caminho livre de exce¸c˜ao seja exercitada ao menos uma vez;
• todos-usos-independentes-de-exce¸c˜ao (Todos-Usosei): requer que toda as- socia¸c˜ao defini¸c˜ao-uso independente de exce¸c˜ao seja exercitada ao menos uma vez; • todos-usos-dependentes-de-exce¸c˜ao (Todos-Usosed): requer que toda asso-
cia¸c˜ao defini¸c˜ao-uso dependente de exce¸c˜ao seja exercitada ao menos uma vez;