Teste estrutural de tratamento de exceções em programas OA: representação, critérios...

(1)

Teste estrutural de tratamento de exceções em

programas OA: representação, critérios e

avaliação

(2)

(3)

Teste estrutural de tratamento de exceções em

programas OA: representação, critérios e avaliação

Luciano Augusto Fernandes Carvalho

Orientador: Prof. Dr. Paulo Cesar Masiero

Dissertação apresentada ao Instituto de Ciências Matemáticas e de Computação - ICMC-USP, como parte dos requisitos para obtenção do título de Mestre em Ciências - Ciências de Computação e Matemática Computacional. VERSÃO REVISADA

USP – São Carlos

SERVIÇO DE PÓS-GRADUAÇÃO DO ICMC-USP

Data de Depósito:

(4)

CCC33l tt

Carvalho, Luciano Augusto Fernandes

Teste estrutural de tratamento de exceções em programas OA: representação, critérios e avaliação / Luciano Augusto Fernandes Carvalho; orientador Paulo Cesar Masiero. -- São Carlos, 2013.

112 p.

Tese (Doutorado - Programa de Pós-Graduação em Ciências de Computação e Matemática Computacional) Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, 2013.

(5)

Primeiramente agrade¸co a Deus, que vem proporcionando e realizando tudo na vida com que Ele presenteou-me.

Agrade¸co a toda minha fam´ılia, amigos e namorada por toda a convivˆencia, amizade e confian¸ca ao longo da minha vida.

Agrade¸co ao Prof. Dr. Paulo Cesar Masiero pela dedica¸c˜ao e profissionalismo excep-cional.

Agrade¸co tamb´em a todos os seres do planeta terra, pois todos de maneira direta ou indireta foram importantes para conclus˜ao deste trabalho.

(6)

(7)

(8)

(9)

(10)

(11)

Abstract 9

1 Introdu¸c˜ao 1

1.1 Contextualiza¸c˜ao . . . 1

1.2 Motiva¸c˜ao . . . 2

1.3 Objetivos . . . 4

1.4 Organiza¸c˜ao . . . 4

2 Introdu¸c˜ao ao teste de software 5 2.1 Considera¸c˜oes Iniciais . . . 5

2.2 Teste de Software . . . 5

2.2.1 Teste funcional . . . 9

2.2.2 Teste estrutural . . . 9

2.2.2.1 Crit´erios baseados em complexidade . . . 11

2.2.2.2 Crit´erios baseados em fluxo de controle . . . 11

2.2.2.3 Crit´erios baseados em fluxo de dados . . . 12

2.2.3 Teste baseado em defeitos . . . 13

2.3 Tratamento de exce¸c˜oes . . . 14

2.3.1 Tratamento de exce¸c˜oes em C++ . . . 15

2.3.2 Tratamento de exce¸c˜oes em Java . . . 16

2.3.3 Teste Estrutural de Tratamento de Exce¸c˜oes . . . 19

2.4 Considera¸c˜oes Finais . . . 21

3 Teste e verifica¸cão de tratamento de exce¸cões em programas OO e OA: uma revisão da literatura 23 3.1 Considera¸cões Iniciais . . . 23

3.2 Revis˜ao da literatura . . . 24

3.2.1 Planejamento de Revis˜ao . . . 24

3.2.2 Recursos para Busca e Sele¸c˜ao de Estudos . . . 24

3.3 Teste Estrutural de tratamento de exce¸c˜oes . . . 26

3.4 Outras abordagens para teste e verifica¸c˜ao do fluxo de exce¸c˜ao . . . 35

3.5 Ferramentas . . . 39

(12)

4 Abordagem de teste para o tratamento de exce¸c˜oes 47

4.1 Considera¸c˜oes Iniciais . . . 47

4.2 Teste estrutural de unidade . . . 48

4.3 Teste estrutural de integra¸c˜ao . . . 49

4.4 Extensão da JaBUTi/AJ para adequa¸cão ao teste estrutural de tratamento de exce¸cões . . . 53

4.5 Estrat´egia de teste . . . 63

4.6 Vers˜ao da JaBUTi/AJ integrada com a VITTAE . . . 65

4.7 Esfor¸co de implementa¸c˜ao . . . 68

4.8 Considera¸c˜oes finais . . . 68

5 Valida¸c˜ao 69 5.1 Considera¸c˜oes Iniciais . . . 69

5.2 Estudo de caso . . . 70

5.3 Experimento . . . 73

5.3.1 Hip´oteses . . . 75

5.3.2 Sujeitos e objetos experimentais . . . 76

5.3.3 Instrumenta¸c˜ao . . . 76

5.3.4 Opera¸c˜ao do experimento . . . 76

5.3.5 Amea¸cas `a validade . . . 77

5.3.6 Resultados . . . 78

5.3.7 An´alise de dados . . . 79

5.3.7.1 An´alise de dados: cobertura . . . 80

5.3.7.2 An´alise de dados: tempo . . . 82

5.3.7.3 Análise de dados: viola¸cões no contrato de exce¸cões . . . 85

5.3.8 Teste de hip´oteses . . . 87

5.3.9 Pesquisa de opini˜ao com os sujeitos . . . 88

5.3.10 Considera¸c˜oes finais . . . 89

6 Conclus˜ao 91 6.1 Considera¸c˜oes finais . . . 91

6.2 Contribui¸c˜oes desta disserta¸c˜ao de mestrado . . . 92

6.3 Trabalhos futuros . . . 93

Referˆencias 99

A Formul´arios utilizados no experimento 101

B C´odigo fonte do programa Vending Machine 105

(13)

2.1 Defeito, erro e falha (Neto, 2008) . . . 7 2.2 Código fonte para calcular o maior entre dois números . . . 7 2.3 Exemplo de grafo GFC,(a) GFC e (b) código fonte usado para gerar o GFC. 10 2.4 Hierarquia da biblioteca de exce¸cões de C++ (Mao e Lu, 2005) . . . 15 2.5 Hierarquia de Exce¸cões em Java (Azevedo, 2011) . . . 17 2.6 Exemplo de pseudocódigo com tratamento de exce¸cões . . . 18 2.7 Exemplo de programa e GFC integrado constru´ıdo com a utiliza¸cão da

abordagem de Sinha e Harrold (2000) . . . 21

3.1 GFCI constru´ıdo com utiliza¸cão da abordagem de Mao e Lu (2005) . . . . 29 3.2 Exemplo de bytecode e grafo para o cod´ıgo da figura 2.7 . . . 33 3.3 Exemplo de código: classePoint e aspecto anAspectP . . . 33 3.4 Parte do bytecode do método affectedMethod sem a presen¸ca de aspectos 34 3.5 Grafo DUG do método affectedMethod . . . 34 3.6 Grafo AODU do métodoaffectedMethodentrecortado pelo aspecto

anAs-pect . . . 35 3.7 Codigo fonte das classes Employee, Paymentinfo, WorkInfo e do aspecto

AcessControl(Lemos e Masiero, 2011) . . . 36 3.8 Grafo AODU do m´etodoaffectedMethodentrecortado pelo aspecto

anAs-pect (Lemos e Masiero, 2011) . . . 36 3.9 Etapas da abordagem de análise estática proposta por Coelho et al. (2011) 37 3.10 Exemplo de contrato de exce¸cão. . . 38 3.11 Ferramenta OConGraX (Xavier et al., 2008) . . . 40 3.12 Ferramenta Java PathFinder Exceptions . . . 40

4.1 Exemplo do código do método Vend() e do grafo de unidade gerado pela JaBUTi/AJ. . . 50 4.2 Exemplo do código e de seu bytecode e do grafo de unidade gerado pela

JaBUTi/AJ. . . 51 4.3 Exemplo de c´odigo OA e seu respectivo bytecode e de grafo gerado pela

(14)

4.8 Inform¸cões do nó throw do nó (3).2.6 do grafo de integra¸cão do programa

p5. . . 56

4.9 Grafo de integra¸c˜ao do programa p5 gerado pelo algoritmo modificado. . . 58

4.10 Grafo para o cod´ıgo mostrado na figura 2.7 . . . 60

4.11 Grafo visualizado com op¸c˜ao de exibir somente as arestas requeridas pelo crit´erio todas-arestas-integradas-throw. . . 62

4.12 Grafo visualizado com op¸cão de não exibir as arestas de exce¸cão não exe-cutáveis. . . 63

4.13 Grafo de chamada do m´etodo Facade.vend() . . . 64

4.14 Grafo de integra¸c˜ao do m´etodo facade.vend(). . . 65

4.15 Exemplo de grafo de integra¸c˜ao da vers˜ao da JaBUTi/AJ integrada com a VITTAE. . . 67

5.1 Cobertura alcan¸cada para o critério todos-nós-integrados-de-exce¸cão na pri-meira etapa do experimento. . . 80

5.2 Cobertura alcan¸cada no critério todas-arestas-integradas-throw/todas-cláusulas-do-contrato-de-exce¸cões na primeira etapa do experimento. . . 81

5.3 N´umero de casos de teste e de contratos de exce¸c˜ao criados pelos sujeito na primeira etapa do experimento. . . 82

5.4 Tempo gasto pelos sujeitos na primeira etapa do experimento. . . 83

5.5 Tempo gasto pelos sujeitos na segunda etapa do experimento. . . 84

5.6 Tempo total. . . 85

(15)

2.1 Requisitos de teste para os crit´erios propostos por Sinha e Harrold (1999) 21

3.1 Resultados da revisão bibliográfica por fonte de pesquisa. . . 26 3.2 Requisitos de teste para os critérios propostos por Vincenzi et al. (2006) . . 32 3.3 Abordagens de teste e verifica¸cão do fluxo de exce¸cão. . . 44

4.1 Requisitos de teste para os crit´erios propostos nesta disserta¸c˜ao . . . 60

(16)

(17)

1

Introdu¸c˜

ao

1.1 Contextualiza¸c˜

ao

O desenvolvimento de software é uma atividade complexa e dif´ıcil, principalmente quando se deseja produzir software de alta qualidade e tolerante a falhas. Visando facilitar a produ¸cão de software com qualidade, algumas linguagens de programa¸cão de alto n´ıvel como o C++, Java e Ada fornecem mecanismos como os de tratamento de exce¸cões que não existem em outras linguagens como C e Pascal. O tratamento de exce¸cões é um mecanismo poderoso que permite formalizar e separar o código de tratamento de erros (fluxo de exce¸cão) do código funcional (fluxo normal) e deixar um caminho limpo para a propaga¸cão de erros de uma forma padronizada e estruturada.

(18)

tra-tar adequadamente os erros conhecidos. Segundo Antoniol (2009), projetra-tar o tratamento de exce¸cões de maneira inadequada é um dos vinte e cinco erros de programa¸cão mais propensos a gerar vulnerabilidades nos softwares.

O uso incorreto do mecanismo de tratamento de exce¸cões pode introduzir mais defeitos no código, como inconsistência entre estados de objetos e falhas de sistema. Alguns deles não podem causar evidente influência sobre o sistema, mas alguns podem causar grande dano a todo o sistema ou resultar em acidentes catastróficos. Por exemplo, o foguete Ariane-V, cuja explosão em 1996 teve como causa da catástrofe uma exce¸cão não capturada (Lions, 1996). Sem os devidos cuidados, a introdu¸cão de tratamento de exce¸cões na maior parte dos programas pode diminuir a confiabilidade geral e põe em risco o processo de desenvolvimento de software com alta qualidade. Assim, se torna necessário analisar as estruturas de exce¸cão e testar as condi¸cões de exce¸cão no código. Com atividades de análise e testes é poss´ıvel tentar detectar as falhas introduzidas por mecanismos de tratamento de exce¸cões.

O desenvolvimento de software está em constante evolu¸cão e com isso surgem novos paradigmas, linguagens e técnicas de programa¸cão com o propósito de facilitar a sua evolu-¸cão. Um desses paradigmas que surgiu foi o desenvolvimento Orientado a Aspectos (OA), que permite separar o código-base do programa do código dos interesses transversais por meio de um novo conceito denominado aspecto (Kiczales et al., 1997). Um dos interesses transversais que pode ser implementado com aspectos é o tratamento de exce¸cões. Coelho et al. (2008) realizaram um estudo que investigou os padrões de defeitos que podem ser introduzidos com a utiliza¸cão inadequada dos mecanismos da OA para o tratamento do fluxo de exce¸cão. Os resultados apresentaram ind´ıcios de que sistemas OA tendem a ficar mais propensos a conterem defeitos na implementa¸cão do tratamento de exce¸cões do que os programas OO.

Dessa forma, as atividades de Verifica¸cão, Valida¸cão e Teste são essenciais para me-lhorar a robustez e a confiabilidade do software. Com o aumento da complexidade dos softwares com a introdu¸cão de novas tecnologias como o tratamento de exce¸cões e OA surgem novos desafios para a busca por qualidade e confiabilidade em softwares (Mao e Lu, 2005).

1.2 Motiva¸c˜

ao

(19)

(2003) foi o primeiro pesquisador a estudar este assunto, estendendo-o para programas orientados a aspectos, e a publicar alguns resultados iniciais. Lemos et al. (2007) explora-ram o teste estrutural de unidades de software orientado a objetos e a aspectos - métodos e adendos - e de unidades aspectuais de programas AspectJ isoladamente (i.e. teste de unidade) a partir do bytecode, com o código base e os aspectos já combinados. Nesse trabalho, a ferramenta JaBUTi (Vincenzi et al., 2006) foi estendida para apoiar também o teste unitário de aspectos, criando-se uma nova versão da ferramenta, chamada de Ja-BUTi/AJ. Lemos et al. (2007) propuseram varia¸cões dos critérios todos-nós, todos-ramos e todos-def-uso para esse contexto, implementando-os na ferramenta JaBUTi/AJ.

Um problema não abordado no teste de unidade é a intera¸cão entre unidades, com respeito à corre¸cão de suas interfaces. Nesse contexto, o teste de unidade não é suficiente para dar confian¸ca de que o programa está correto, sendo necessário prosseguir com o teste de integra¸cão e o teste de sistema. Posteriormente, Lemos deu seguimento a seu trabalho inicial e definiu um conjunto de critérios de teste estruturais baseados em conjuntos de jun¸cão (pointcuts), isto é, critérios que permitem avaliar a cobertura de execu¸cão de todos os pontos de jun¸cão associados a um pointcut (Lemos e Masiero, 2008, 2011). Em continuidade a esse trabalho, foi proposto por Franchin o teste de integra¸cão de pares de unidades orientadas a objetos e aspectuais. Mesmo para pequenos sistemas pode haver um grande número de intera¸cões entre as unidades e para grandes sistemas o problema é agravado, com crescimento exponencial, o que torna o teste de integra¸cão de unidades para um número arbitrário de unidades imposs´ıvel na prática.

No trabalho de Franchin foi também estendida a ferramenta JaBUTi/AJ para dar apoio ao teste estrutural de integra¸cão par-a-par e à análise de cobertura de testes rea-lizados segundo os três critérios de teste par-a-par propostos (Lemos et al., 2009). Em seguida, o trabalho de mestrado de Neves definiu formalmente os critérios de fluxo de dados e de controle e estendendo a ferramenta JaBUTi/AJ para criar o grafo de fluxo de controle de todas as unidades envolvidas no n´ıvel 1 de profundidade, realizar e instrumen-tar o teste de integra¸cão e calcular a cobertura obtida (Neves et al., 2009).

(20)

teste do tratamento de exce¸cões, assim como para a intera¸cão entre aspectos e tratamento de exce¸cões. Este trabalho tem como principal motiva¸cão dar continuidade aos traba-lhos do grupo e investigar uma alternativa para o teste estrutural de integra¸cão no fluxo de exce¸cões de programas OO e OA, principalmente voltado para as linguagens Java e AspectJ.

1.3 Objetivos

O objetivo desta disserta¸cão de mestrado é investigar o teste de integra¸cão estrutural de tratamento de exce¸cões em programas OO e OA, em particular das linguagens Java e As-pectJ. Como parte desse objetivo, pretende-se definir como os fluxos de exce¸cão podem ser representados em um grafo de fluxo de controle e definir novos critérios de teste estrutural de integra¸cão de fluxos de exce¸cão e implementá-los na ferramenta JaBUTi/AJ. Adicio-nalmente pretende-se também avaliar os resultados dessa implementa¸cão e comparar com outras abordagens e ferramentas.

1.4 Organiza¸c˜

ao

(21)

2

Introdu¸c˜

ao ao teste de software

2.1 Considera¸c˜

oes Iniciais

Neste cap´ıtulo são apresentados conceitos básicos relacionados ao teste de software que são necessários para a compreensão dos cap´ıtulos seguintes. Uma introdu¸cão ao teste de programas com tratamento de exce¸cões também é apresentada neste cap´ıtulo para fundamentar as propostas discutidas nesta disserta¸cão.

O restante deste cap´ıtulo está organizado como segue. Na Se¸cão 2.2 são abordados os principais conceitos referentes à atividade de teste de software, incluindo uma breve apresenta¸cão sobre teste funcional, estrutural e baseado em defeitos. Na Se¸cão 2.3 é abordado o tratamento de exce¸cões e apresenta-se uma introdu¸cão sobre o funcionamento deste mecanismo nas linguagens C++ e Java e seguida de uma discussão sobre teste de tratamento de exce¸cões.

2.2 Teste de Software

(22)

a fase de testes, a ordem de execu¸cão do usuário foi diferente das que foram testadas, o usuário aplicou uma combina¸cão de entradas não testada ou ainda, no caso mais grave, o usuário poderia estar usando um programa que nunca foi testado.

Visando diminuir a ocorrência de erros nos sistemas, e em busca do aumento de quali-dade do software a Engenharia de Software incorporou ativiquali-dades de Verifica¸cão, Valida¸cão e Teste (VV&T), no processo de desenvolvimento de software que, segundo Rocha e Weber (2001), têm papel fundamental na produ¸cão de qualquer produto.

As atividades de VV&T podem ser classificadas como dinâmicas ou estáticas, as es-tat´ısticas são aquelas que não necessitam da execu¸cão do programa nem necessariamente do código ou do programa, como a atividade de inspe¸cão de software, já as dinâmicas necessitam da execu¸cão do programa, como é o caso do teste de software.

Consideerando a importˆancia das atividades de teste de software, esfor¸cos tˆem sido realizados para padronizar algumas terminologias. O IEEE (1990) definiu alguns termos e conceitos relacionados ao teste de software:

• engano (mistake): ´e uma a¸c˜ao humana capaz de produzir um resultado incorreto.

Um exemplo de engano pode ser uma a¸c˜ao incorreta tomada pelo programador.

• defeito (fault): ´e a causa de um erro em um programa que ocorre por um passo,

processo ou defini¸c˜ao de dados incorreta, como por exemplo, uma instru¸c˜ao ou comando incorreto.

• erro (error): caracteriza-se por um resultado incorreto, ou seja, quando ocorre

diferen¸ca entre o valor obtido e o valor esperado. Qualquer estado intermedi´ario incorreto ou resultado inesperado na execu¸c˜ao de um programa constitui um erro.

• falha (failure): caracteriza-se pela falta de capacidade de um sistema ou

compo-nente fornecer a funcionalidade esperada com desempenho adequado. Um ou mais erros podem causar a ocorrˆencia de uma falha assim como alguns erros podem nunca causar uma falha.

Software pode falhar eventualmente. Para que ocorra uma falha é necessário que um erro se propague até a sa´ıda do software. Erros são produzidos por defeitos que por sua vez podem ser introduzidos por enganos que são provenientes de uma a¸cão humana incorreta. A figura 2.1 fornece uma visão da diferen¸ca entre os conceitos de falhas, erros, defeitos.

(23)

Figura 2.1: Defeito, erro e falha (Neto, 2008)

e o erro nesse exemplo ocorre quando houver uma entrada com dois valores iguais para as variáveis X e Y. No ponto em que a variável Maior receber o valor de Y esta estará com um valor incorreto, gerando o erro. Este erro causa uma falha quando for enviada a mensagem informando o maior dos dois números ao invés de informar que os dois números são iguais.

FMaiorEntreDoisInteiros( int X, int Y) {

Int Maior=-9999;

if(X>Y){ Maior=X;} else if (Y >= X){

Maior=Y;}

if(Maior!= -9999){

print("O maior n´umero ´e ",Maior);} else{

print("os n´umeros s~ao iguais");}

}

Figura 2.2: C´odigo fonte para calcular o maior entre dois n´umeros

(24)

Na atividade de teste os programas são examinados para determinar o que eles fazem e o que supostamente deveriam fazer. Para saber o que o programa deve fazer é preciso dos requisitos do sistema, que são uma descri¸cão ou especifica¸cão que descreve o que o programa deve e o que ele não deve fazer. O teste examina o programa baseado em um conjunto limitado de casos de testes, porque de uma forma geral não é viável executar um conjunto de casos de teste que contenha todas as entradas poss´ıveis. A atividade de teste deve ser planejada em diferentes n´ıveis e ser aplicada em paralelo ao processo de desenvolvimento do software. Os principais n´ıveis de teste são (Rocha e Weber, 2001):

Teste de Unidade: são testes unitários que têm como objetivo explorar a menor unidade do projeto, procurando provocar falhas em cada módulo, separadamente. Alguns autores consideram fun¸cões e métodos as menores unidades e outros consideram as classes.

Teste de Integra¸cão: visa provocar falhas associadas às interfaces entre os módulos quando eles são integrados.

Teste de Sistema: avalia o software em busca de falhas por meio de sua utiliza¸cão. Para isto, os testes são executados nos mesmos ambientes, com as mesmas condi-¸cões e com os mesmos dados de entrada que um usuário utilizaria normalmente na utiliza¸cão do software. Assim verifica se o produto satisfaz seus requisitos.

Teste de Aceita¸cão: tem como objetivo verificar se o comportamento do software está de acordo com o solicitado. São realizados geralmente por um restrito grupo de usuários finais do sistema. É um tipo de teste de sistema.

Apesar da aplica¸cão de atividades de testes e mesmo com sua aplica¸cão correta não se pode afirmar que o software está completamente livre de defeitos, pois um dos desa-fios desta atividade é o fato de ser praticamente imposs´ıvel testar todas as combina¸cões de entradas poss´ıveis (conhecido como teste exaustivo) para um software, mas se pode aumentar a confiabilidade do programa com a aplica¸cão correta das atividades de teste.

Nas atividades de teste existem alguns conceitos adicionais importantes e alguns deles s˜ao os seguintes:

Caso de Teste: um caso de teste é composto por valores de entrada, restri¸cões para a sua execu¸cão e um resultado ou comportamento esperado, assim descrevendo uma condi¸cão particular a ser testada (Craig e Jaskiel, 2002).

(25)

Critério de Teste: são usados para selecionar e avaliar casos de teste com o objetivo de aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um n´ıvel elevado de confian¸ca na corre¸cão do produto (Rocha e Weber, 2001). Os critérios de teste podem ser utilizados como critérios para cobertura dos testes, adequa¸cão de casos de teste e gera¸cão de casos de teste.

Para a realiza¸cão das atividades teste utilizam-se técnicas e critérios que fornecem abordagens sistemáticas, assim com base fundamentada na teoria e se constitui como um mecanismo que pode auxiliar na garantia de qualidade dos testes, contribuindo também para aumentar da probabilidade deles revelarem defeitos (Delamaro et al., 2007).

Diferentes técnicas que podem ser utilizadas para a condu¸cão da atividade de teste são as técnicas de teste funcional, estrutural e baseada em defeitos. Os vários critérios de teste de cada técnica apoiam a explora¸cão de determinados tipos de defeitos, estabelecendo requisitos de teste para os quais valores espec´ıficos do dom´ınio de entrada do programa devem ser definidos com o intuito de exercitá-los. O que diferencia cada uma dessas técnicas é a fonte utilizada para definir os requisitos de teste.

2.2.1 Teste funcional

Os critérios da técnica funcional são baseados na especifica¸cão do software (Myers et al., 2004), uma vez que ela é indiferente à estrutura e ao comportamento interno do programa. Assim, por se basear na especifica¸cão do produto a ser testado, é fácil perceber que a qualidade desses critérios depende da existência de uma boa especifica¸cão de requisitos. Em contrapartida, como não levam em conta detalhes de implementa¸cão, esses critérios podem ser aplicados em qualquer fase de teste e em produtos desenvolvidos inclusive antes do inicio da implementa¸cão (TestFirst, por exemplo) em qualquer paradigma de programa¸cão. Alguns critérios de teste funcional são, por exemplo: particionamento em classes de equivalência e análise do valor limite.

2.2.2 Teste estrutural

(26)

de teste estrutural utiliza um ”grafo de fluxo de controle”(GFC) ou ”Grafo de Programa”. Um exemplo de GFC pode ser visto na figura 2.3.

Figura 2.3: Exemplo de grafo GFC,(a) GFC e (b) c´odigo fonte usado para gerar o GFC.

Um programa P pode ser representado na forma de um grafo de fluxo de controle G = (N,E,s). No GFC N representa o conjunto de nós, E representa o conjunto de arestas e s representa o nó de entrada. Um nó representa um bloco de comandos sequenciais que forma um bloco indivis´ıvel de comandos, de modo que, quando o primeiro comando é executado todos os outros comandos também são executados sequencialmente. As arestas representam o fluxo de controle de um programa, ou seja, um poss´ıvel desvio de um bloco de comandos para outro. Todo GFC possui nós de entrada e de sa´ıda nos quais a computa¸cão é iniciada e finalizada, respectivamente. Os nós de entrada não possuem aresta de entrada, ao contrário dos nos de sa´ıda que não possuem arestas de sa´ıda. Os critérios de teste estrutural podem ser baseados em fluxo de controle, complexidade e fluxo de dados. Algumas defini¸cões e conceitos importantes para entendimento desses critérios são apresentadas a seguir:

Defini¸cão de variável: atribui¸cão de um valor a uma variável.

Uso da variável: trata da utiliza¸cão de uma variável. Pode ser classificado de duas maneiras:

• Uso computacional (c-uso): quando ocorre o uso de uma vari´avel em uma

compu-ta¸c˜ao;

• Uso predicativo (p-uso): quando ocorre o uso de uma vari´avel para determinar o

(27)

Caminho: ´e uma sequencia finita de n´os n1, n2, ..., nk, k > 1, tal que existe uma aresta

de ni para ni+1 parai= 1,2..., k−1

Caminho Completo: é um caminho no qual o primeiro nó é o de entrada e o ultimo nó é o de sa´ıda do grafo G.

Caminho Simples: é um caminho no qual todos os nós, exceto possivelmente o primeiro e o ultimo, são distintos.

Caminho independente: ´e qualquer caminho ao longo do programa que introduz pelo menos uma nova aresta ou novo n´o.

Caminho livre-de-la¸co: é um caminho no qual nenhum dos nós aparece mais de uma vez, ou seja, são distintos.

Caminho livre-de-itera¸cão-de-la¸co: é um caminho no qual nenhum dos nós aparece mais de uma vez.

Caminho não executável: é um caminho do GFC imposs´ıvel de ser coberto para qual-quer elemento do dom´ınio de entrada.

A partir do GFC, os caminhos lógicos do software podem ser testados, para verificar condi¸cões e/ou la¸cos e defini¸cões e usos de variáveis.

2.2.2.1 Crit´erios baseados em complexidade

Os critérios baseados em complexidade utilizam informa¸cões de complexidade dos progra-mas para derivar os requisitos de teste. Uma das métricas para complexidade de software bastante conhecida é a complexidade ciclomática. Ela pode ser calculada da seguinte forma:

V(G) =E−N + 2, em que E é o número de arestas e N o número de nós do GFC G.

Entre os critérios desta categoria, um dos mais conhecidos é o critério de McCabe. Esse critério utiliza a complexidade ciclomática de um GFC para derivar os requisitos de teste. Além disso, com o uso da complexidade ciclomática, esse critério fornece um limite superior para quantidade de dados de testes necessários para garantir que todos os comandos sejam executados pelo menos uma vez (Pressman, 2005).

2.2.2.2 Crit´erios baseados em fluxo de controle

(28)

todos-nós: requer que cada vértice do grafo, isto é, cada comando do programa, seja exercitado ao menos uma vez .

todas-arestas: requer que cada aresta do grafo, isto ´e, cada desvio do fluxo de controle do programa, seja exercitado ao menos uma vez.

Todos-caminhos: requer que todos os caminhos poss´ıveis do programa sejam exercita-dos.

Segundo Delamaro et al. (2007), a cobertura do critério todos-nós e o m´ınimo esperado em uma atividade de teste. Além disso, é importante ressaltar que embora desejável, cobrir o critério Todos-Caminhos na maioria dos casos é uma tarefa impraticável uma vez que o número de caminhos pode ser muito grande ou até mesmo infinito.

2.2.2.3 Crit´erios baseados em fluxo de dados

Uma das motiva¸cões para introdu¸cão dos critérios baseados em fluxo de dados é o fato de que o critério todos-caminhos ser impraticável na maioria dos casos.

Os requisitos de satisfa¸cão dos critérios dessa categoria são baseados em informa¸cões referentes ao fluxo de dados do programa, cujo foco é na intera¸cão entre defini¸cões e usos de variáveis. Para isso pode ser utilizado uma extensão do GFC denominada Grafo Def-Uso proposta por Rapps e Weyuker (1985). Nesse grafo, além das arestas e nós criados no GFC, são inseridas também informa¸cões a respeito do fluxo de dados, como defini¸cões, c-uso e p-uso de variáveis que foram definidos anteriormente. Outros conceitos importantes, além das de defini¸cões e usos, que já foram definidos anteriormente, são o par def-uso e o de caminho livre de defini¸cão. O par def-uso se refere a uma defini¸cão subsequente de p-uso ou c-uso de uma variável. Um caminho livre de defini¸cão com rela¸cão a uma variável x é um caminho onde a variável x não é redefinida (Barbosa et al., 2000). Alguns dos principais critérios dessa classe são:

todas-defini¸cões: requer que toda defini¸cão de variável no programa seja exercita pelo menos uma vez, seja por um c-uso ou p-uso.

todos-usos: requer que todos os pares def-uso sejam exercitados pelos casos de teste por pelo menos um caminho livre de defini¸c˜ao.

todos-c-usos: requer que todos os pares def-uso em que o uso seja um c-uso sejam exercitados pelo casos de teste por pelo menos um caminho livre de defini¸c˜ao.

(29)

dodos-du-caminhos: requer que todos os pares def-uso sejam exercitados pelos casos de teste por todos os caminhos livre de defini¸c˜ao e livres de la¸co.

2.2.3 Teste baseado em defeitos

Baseiam-se na inclusão de defeitos propositais (artificiais) como forma de revelar defeitos existentes previamente (naturais) (Pressman, 2005). Um dos principais critérios baseado em defeitos é o critério análise de mutantes. Esse critério gera programas mutantes e o objetivo do critério é gerar casos de testes em que, a partir da mesma entrada, os resultados gerados pelo programa original sejam diferentes dos resultados gerados pelo programa mutante. Alguns conceitos básicos do teste de muta¸cão são definidos a seguir (Delamaro et al., 2007):

• _{Programas Mutantes:} _{são programas com pequenas modifica¸cões sintáticas que}

são realizadas sobre o código-fonte do programa original a partir da aplica¸cão de operadores de muta¸cão.

• Operadores de muta¸cão: são operadores utilizados para modelar as modifica¸cões

em um programa de forma a gerar programas mutantes. Um operador de muta¸c˜ao aplicado a um programa P transforma P em um programa similar, ou seja, um mutante.

• _{Mutante morto:} _{s˜ao programas mutantes que geram uma sa´ıda diferente do}

pro-grama original para um determinado caso de teste.

• Mutante equivalente: s˜ao programas mutantes que apresentam sempre o mesmo

resultado que o programa original para qualquer valor de entrada contido no dom´ınio de entrada do programa testado.

• Escore de muta¸c˜ao: E a medida de cobertura utilizada no teste de mutantes. O´

escore de muta¸cão varia entre 0 e 1 e é calculado como a razão entre o número de mutantes mortos e o número de mutantes não equivalentes. Fornece uma medida objetiva de quanto o conjunto de casos de teste analisado aproxima-se da adequa¸cão.

(30)

devem ser constru´ıdos para evidenciar as diferen¸cas entre o mutante e o programa original (Wong, 2001).

2.3 Tratamento de exce¸c˜

oes

O tratamento de exce¸cões é um mecanismo que permite gerenciar a manipula¸cão de erros de programa de uma forma organizada; sem um mecanismo deste tipo os programadores teriam que verificar os códigos de retorno de erro depois de cada chamada de fun¸cão. Assim, o código que implementa as fun¸cões do programa se entrela¸ca com o código que trata os erros, o que torna a atividade de teste tediosa, repetitiva, complexa e dificulta o entendimento das funcionalidades essenciais do programa, facilitando com que os desen-volvedores ignorem o tratamento de exce¸cões (deliberadamente ou acidentalmente) (Mao e Lu, 2005). Então, para apoiar a manipula¸cão de erros em programas, o mecanismo de tratamento de exce¸cões permite separar o código de tratamento de exce¸cões (fluxo de exce¸cão ou fluxo excepcional) do código funcional (fluxo normal ou regular) e deixar um caminho limpo para a propaga¸cão de erros de uma forma padronizada e estruturada.

Quando ocorrem erros, um programa bem projetado deve fornecer algumas maneiras de lidar com os erros esperados, com o objetivo de tratá-los e permitir retorná-lo a um estado coerente. Portanto, o tratamento de exce¸cões visa estruturar o fluxo excepcional de um programa, para que erros possam ser detectados, sinalizados e tratados.

Weimer e Necula (2004) citam estimavas de que entre 1% e 5% do código de sistemas de software modernos seja dedicado ao tratamento de exce¸cões e que isso tende a crescer junto com o tamanho e a idade desses sistemas. Mecanismos de tratamento de exce¸cões em diferentes linguagens de programa¸cão possuem caracter´ısticas próprias, mas basicamente seguem um mesmo processo. Sinha e Harrold (2000) realizaram dois estudos para avaliar a frequência com que os programas Java utilizam o mecanismo de tratamento de exce¸cões. O primeiro estudo revelou uma estimativa que cerca de 8,1% dos métodos contém parte código dedicado ao tratamento de exce¸cões e o segundo estudo revelou uma estimativa que 23,3% e 24,5% das classes têm os comandos trye throw, respectivamente.

(31)

2.3.1 Tratamento de exce¸c˜

oes em C++

Uma regra simples e natural é a que recomenda que o melhor tratamento é a preven¸cão. Assim o tratamento de exce¸cões usa um bloco trypara preven¸cão contra poss´ıveis erros, pois ele pode evitar alguns danos fatais, permitindo que o software fa¸ca todo o poss´ıvel para ser executado no estado normal. Além disso, o mecanismo de tratamento de exce¸cões aumenta a legibilidade do código (Mao e Lu, 2005).

Uma exce¸cão em C++ pode ser um objeto de qualquer tipo ou até mesmo de um tipo básico, mas é recomendado que as exce¸cões sejam definidas hierarquicamente nas linguagens de programa¸cão orientadas a objetos e inteiramente derivadas da biblioteca de exce¸cões. A biblioteca de exce¸cões é geralmente organizada como uma hierarquia de classes (Ellis e Stroustrup, 1993), como é mostrado na figura 2.4, na qual existe a classe abstrata exceptione todas as outras classes herdam direta ou indiretamente dela.

Figura 2.4: Hierarquia da biblioteca de exce¸c˜oes de C++ (Mao e Lu, 2005)

A organiza¸cão das exce¸cões em hierarquias pode ser benéfica para a constru¸cão de um código robusto. Durante o desenvolvimento de programas em C++ os programadores podem definir suas próprias exce¸cões ou a hierarquia e o tipo de exce¸cão de acordo com suas necessidades. Notando que embora seja uma boa prática, não é necessário que as exce¸cões definidas pelo usuário herdem da classe exception e, portanto, para capturar qualquer exce¸cão que possa ser encontrada no programa em execu¸cão, a cláusula catch (...) deve ser usada (Mao e Lu, 2005).

O fluxo de controle do programa em C++ segue da seguinte forma: após o tratamento de uma exce¸cão, o controle não retorna para o ponto no qual a exce¸cão foi levantada, mas continua na primeira declara¸cão depois do manipulador de exce¸cão. Para isso C++ registra as exce¸cões em uma estrutura de pilha e se um método lan¸ca uma exce¸cão, mas não faz o tratamento dela, ela é propagada para o seu chamador.

O tratamento de exce¸cões é também uma estrutura de controle não local, composto por três elementos básicos e um opcional:

(32)

• throw: lan¸camento de uma exce¸c˜ao;

• _catch_{: captura exce¸c˜oes;}

• finally: Um bloco opcional, em que o código dentro de um bloco é executado independentemente do fato de uma exce¸cão ser disparada ou não e se ela é capturada ou não.

Com a inclus˜ao de exce¸c˜oes, o fluxo de controle do programa pode ocorrer das seguintes maneiras:

• Se o bloco trynão lan¸car pelo menos uma exce¸cão durante a execu¸cão, o programa ignora as cláusulas catche continua a execu¸cão normal;

• Se o blocotry lan¸ca uma exce¸cão, o programa verifica os tratadores de exce¸cão até encontrar um apropriado e, em seguida, caso seja encontrado um tratamento, ele é executado;

• Se não for capturada por nenhum tratador de exce¸cão no n´ıvel da chamada a exce¸cão

sobe para o pr´oximo n´ıvel;

• _{Se todo o programa não prevê nenhum tratamento para a exce¸cão lan¸cada, o}

pro-grama chama a fun¸c˜ao terminate(), finalizando a sua execu¸c˜ao.

2.3.2 Tratamento de exce¸c˜

oes em Java

As exce¸c˜oes em Java s˜ao representadas por classes que herdam da classe

java.lang.Throwable (figura 2.5). Em Java, programadores podem criar suas próprias classes de exce¸cão, mas é importante que elas sejam criadas de acordo com a conven¸cão existente. Isto implica que a classe java.lang.Exception deve ser a classe-base para tratamento de exce¸cões verificadas (ao invés de subclasses diretas de Throwable), a di-feren¸ca entre exce¸cões verificadas e não verificadas é explicada mais adiante nesta se¸cão. As diversas subclasses da classe Exception são definidas na API para fazer o tratamento de exce¸cões espec´ıficas (Azevedo, 2011).

As exce¸c˜oes em Java s˜ao classificadas nos seguintes tipos (Xavier et al., 2008):

• Ass´ıncronas: ocorrem em pontos n˜ao determin´ısticos do programa e s˜ao geradas

da Java Virtual Machine (JVM) ou por outras threads em processos concorrentes por um comando stop();

• S´ıncronas: ocorrem em pontos determinados do programa e s˜ao geradas por

(33)

Figura 2.5: Hierarquia de Exce¸c˜oes em Java (Azevedo, 2011)

• Impl´ıcitas: s˜ao lan¸cadas por uma chamada a uma sub-rotina ou pelo ambiente de

execu¸c˜ao;

• Expl´ıcitas: s˜ao lan¸cadas por um comandothrow;

• Verificadas/Checadas: s˜ao usadas para modelar falhas previstas no projeto de um

sistema e, em geral, são contornáveis. Devem ser sempre declaradas nas interfaces dos métodos que as lan¸cam e precisam ser tratadas. São verificadas pelo compilador com o objetivo de garantir que para cada exce¸cão lan¸cada exista um tratamento de exce¸cões definido (Ferreira, 2006);

• N˜ao Verificadas/Checadas : s˜ao usadas para modelar falhas que sejam

dif´ı-ceis de determinar os pontos exatos em que podem ser levantadas do programa e, em geral, não são facilmente contornáveis. Um exemplo de exce¸cões não verifica-das são toverifica-das aquelas que são subclasses de java.lang.RuntimeException ou de

java.lang.Error. Exce¸cões não verificadas não são verificadas pelo compilador e por isso podem ser lan¸cadas no código sem que seja obrigatória a defini¸cão de um tratamento (Ferreira, 2006).

(34)

uma RunTimeException, em que a exce¸cão continuaria sendo impl´ıcita mas agora seria não verificada. Por outro lado, se ao invés de fazer uma chamada a um método nativo fosse chamado um método de outra classe e em dois pontos distintos do código houvesse um comandothrowlan¸cando umaIOExceptione umaRunTimeException, ambas seriam expl´ıcitas, mas uma seria verificada e a outra não verificada.

Além disso, assim como na linguagem C++, Java é composta por quatro elementos para tratamento de exce¸cões: três básicos,try, catch ethrow, e um opcional,finally, o que é muito semelhante aos mecanismos de C++ descritos na se¸cão anterior. Nesta se¸cão é apresentado na figura 2.6 um exemplo de um pseudocódigo e uma breve descri¸cão com o objetivo de exemplificar o tratamento de exce¸cões.

public A Metodo() {

...

File m = File.open("FileX");

try {

VAR a = m.GetA();

if (a.AlgoErrado()) throw new VARException;

a.setInfo("Tudo ok com a Variavel"); }

catch (VARException e) {

// faz tratamento para Exce¸c~ao do tipo VARException }cath (Exception e) {

// faz tratamento para Exce¸c~ao do tipo Exception } finally {

m.close(); }

MetodoForaDoBlocoTry();

}

Figura 2.6: Exemplo de pseudoc´odigo com tratamento de exce¸c˜oes

(35)

lado, caso seja lan¸cada uma exce¸cão de outro tipo como, por exemplo, uma exce¸cão não verificada do tipo NullPointerException, será executado o segundo bloco catch. Caso não seja levantada nenhuma exce¸cão no bloco try, o fluxo de execu¸cão não passará por nenhum dos blocoscatche irá diretamente para o blocofinally. É importante ressaltar que, independentemente do fluxo de execu¸cão o bloco finally será executado, exceto quando o programa for finalizado antes do bloco finally. Finalmente, se a execu¸cão do bloco try-catch-finally terminar normalmente (sem que exce¸cões sejam lan¸cadas a partir dos blocos catche finally), o código executado em seguida será MetodoForaDo-BlocoTry().

2.3.3 Teste Estrutural de Tratamento de Exce¸c˜

oes

Existem várias técnicas para teste e análise de programas baseadas em teste estrutural. A primeira abordagem de teste estrutural em programas com mecanismo de tratamento de exce¸cões foi proposta por Sinha e Harrold (1999), e os seus principais conceitos são apresentados nesta se¸cão.

Exce¸cões são definidas nas seguintes condi¸cões:

• Um valor é associado a uma variável de exce¸cão,

Ex: Exception e = new Exception();

• _{Em um bloco} _catch _{no qual um valor é associado a uma variável de exce¸cão e a}

variável temporária de exce¸cão é associada a null,

Ex: catch(Exception e)

• Em um nó throw que utiliza uma variável temporária de exce¸cão,

Ex: throw new Exception();

• Em um nó throw no qual é estabelecida uma associa¸cão com a variável temporária de exce¸cão.

Ex: throw e;

Exce¸cões são utilizadas nas seguintes condi¸cões:;

• O valor de uma variável de exce¸cão é acessada,

Ex: System.out.println(e);

• _{Em um bloco} _catch_{, o valor da variável temporária de exce¸cão é acessado,}

(36)

• Em um nó throw com uma variável temporária de exce¸cão,

Ex: throw new Exception().

Um conjunto defini¸cão-uso para uma exce¸cão (e-du) é uma tripla ( v, i, j ), em que i é a linha onde a variável v foi definida e j onde foi usada. Além das defini¸cões e uso, exce¸cões apresentam outro conceito associado à ativa¸cão e desativa¸cão, ou seja, quando um objeto de exce¸cão é associado ou desassociado de uma variável temporária de exce¸cão. Uma cláusula throw ativa uma exce¸cão e uma cláusula catch desativa uma exce¸cão. Além disso, uma exce¸cão pode ser desativada dentro de uma cláusula finally com o uso dos comandos return, break, continue ou outra cláusula throw. Um conjunto ativa¸cão-desativa¸cão para uma exce¸cão ( e-ad ) é uma tripla ( v, i, j ), onde i é 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ões de exce¸cões e pelo menos um uso de cada uma (é semelhante ao critério 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ões e pelo menos uma desativa¸cão de cada exce¸cão. Ou seja, é semelhante ao critério all-e-defs, trocando as defini¸cões e usos por ativa¸cões e desativa¸cões,

• _all-e-deact: _{deve-se exercitar todas as triplas ativa¸cão-desativa¸cão das exce¸cões.}

(37)

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

(38)

(39)

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ões mais importante de uma revisão bibliográfica sobre teste e verifica¸cão de tratamento de exce¸cões. O principal objetivo dessa revisão foi a identifica¸cão de trabalhos que apresentam abordagens para teste estrutural de tratamento de exce¸cões. Além disso, também visou identificar ferramentas de apoio para as abordagens e modelos de defeitos, padrões de defeitos e estudos emp´ıricos realizados para avaliar as abordagens identificadas.

(40)

3.2 Revis˜

ao da literatura

O planejamento da revisão apresentado neste cap´ıtulo foi inspirado pela proposta de Kitchenham (2004). As atividades referentes ao planejamento e condu¸cão da revisão foram acompanhadas por um especialista (orientador de mestrado do revisor) que ofereceu o suporte teórico e prático necessário para a condu¸cão da revisão.

3.2.1 Planejamento de Revis˜

ao

A primeira fase da revisão é o seu planejamento. Nessa fase devem ser definidos os objetivos da pesquisa e a forma como a revisão será conduzida. Algumas das informa¸cões mais relevantes do planejamento da revisão realizada são 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ão os principais tipos de defeitos em rela¸cão ao tratamento de exce¸cões em}

programas OA e OO?

3.2.2 Recursos para Busca e Sele¸c˜

ao de Estudos

Os recursos e estratégias para busca e sele¸cão de estudos preliminares foram definidos com base em três itens fundamentais para o sucesso da pesquisa: a identifica¸cão de boas fontes de busca, defini¸cão dos idiomas das obras e defini¸cão dos termos relacionados ao tema de pesquisa:

• _{Identifica¸c˜}_{ao de fontes de busca:} _{As fontes escolhidas foram algumas das}

prin-cipais bases da área de computa¸cão, tais como IEEE, ACM, Scopus, SciELO, Sci-ence Direct e também uma busca manual exaustiva nas últimas dez edi¸cões da

(41)

• 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 OriOri-entados a Aspectos, Ferramentas.

Para busca optou-se pela op¸cão de pesquisar nos textos completos ao invés de apenas no resumo. A string de busca não contém os termos referentes à OO ou OA, pois os retornos em sua maioria são referentes a estes tipos de programas possivelmente porque o mecanismo de tratamento de exce¸cões come¸cou com os programas OO, e também 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 astring genérica ficou defina da seguinte forma: (”structural test”OR ”structural testing”) AND (”Exception Handling”OR ”exceptional behavior”).

Para sele¸cão dos estudos foram definidos 7 critérios de inclusão e exclusão. Os cri-térios de inclusão foram propostos em dois grupos o primário e o secundário dentre eles o primário é o grupo com os critérios mais relevantes. Assim os critérios de inclusão e exclusão foram definidos da seguinte forma:

• _{Critérios de inclusão primários}

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érios de inclusão secundários

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}

(42)

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ão se encontra redigido em inglês ou português;

6. N˜ao corresponde a pesquisa ou publica¸c˜ao;

7. Versão completa não está dispon´ıvel.

O resultado da busca e sele¸cão 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ão preliminar, em que foi realizada a leitura dos resumos, e depois da sele¸cão final. Após a sele¸cão foram inclu´ıdos trinta e oito trabalhos e exclu´ıdos quatrocentos e vinte trabalhos, e então foi realizada a leitura completa dos trabalhos. Dentre os trabalhos selecionados dezenove deles são mais relevantes no contexto deste trabalho. Sobre eles uma análise e uma s´ıntese das suas principais contribui¸cões são apresentadas nas se¸cões 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

(43)

assim como algoritmos para constru¸cão desses grafos. A técnica para a cria¸cão do grafo denominado GFC interprocedural (GFCI) com fluxo de exce¸cões 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 é representado por um nó com seu respectivo número;

3. Os n´os s˜ao interligados por arestas;

4. Para cada ponto onde é feita uma chamada a um método divide-se o nó em um ponto de sa´ıda para o retorno do método. As arestas de fluxo entre métodos são representadas em linhas pontilhadas;

5. Cada método tem um nó de entrada e um nó de sa´ıda;

6. Cada lan¸camento de exce¸cão (throw) gera uma aresta de sa´ıda com a identifica¸cão da exce¸cão que está sendo gerada;

7. Caso a exce¸cão seja capturada por uma cláusula catch no mesmo método, esta aresta será conectada ao nó correspondente, caso contrário será criado um nó de sa´ıda excepcional para retorno ao método chamador. Este nó de sa´ıda identifica o tipo de exce¸cão que o gerou;

8. Cada nó de blococatché representado por um nó com um rótulo referente ao tipo de exce¸cão que trata, além do número da linha;

9. Blocos finallysão tratados como se fossem métodos, possuindo nós 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.

(44)

• 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ão que é provável ser ter

PES;

• Identificar as categorias e causas de PES, com base em resultados de testes

anteri-ores.

A discussão sobre exce¸cões impl´ıcitas aborda quais tipos são mais relevantes. Dessa forma, sugere-se que somente as exce¸cões impl´ıcitas com alta chance de ocorrência são relevantes para a atividade de teste na abordagem proposta. Eles também propõem uma representa¸cão na forma de um grafo para programas OO em C++ contendo o fluxo de exce¸cões impl´ıcitas e exce¸cões expl´ıcitas, assim como um algoritmo para cria¸cão 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ão proposta por Sinha e Harrold (2000) só é poss´ıvel identificar três lan¸camentos de exce¸cão nos nós 30, 32 e 33 e que não existe uma aresta que leve até o nó 10 que corresponde ao segundo catch

do método function2. Na representa¸cão proposta por Mao e Lu (2005) identificam-se seis lan¸camentos de exce¸cão nos nós 14, 15 e 18 que correspondem aos nós 30, 32 e 33 do outro grafo e mais três poss´ıveis lan¸camentos de exce¸cão nos nós 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étodo function2 que corresponde ao nó 27 e que na outra representa¸cão correspondia ao nó 10, para o qual não existiam caminhos no grafo que permitiam alcan¸cá-lo.

Alguns critérios de teste para programas Java foram pospostos por Vincenzi et al. (2006) para o teste de unidade. Além disso, ao invés de testar o código fonte dos programas estes critérios testam o bytecode da linguagem Java. Para entendimento desses critérios são apresentados alguns conceitos:

Considere N o conjunto de nós e E o conjunto de arestas de um grafo de programa com informa¸cões de tratamento de exce¸cões.

Aresta de exce¸cão: são desvios no fluxo de controle de um programa, que fazem com que ele saia de algum ponto em um blocotrye vá para o inicio de um blococatchou

finally. Normalmente esses desvios s˜ao gerados pelo lan¸camento de uma exce¸c˜ao.

(45)

Figura 3.1: GFCI constru´ıdo com utiliza¸c˜ao da abordagem de Mao e Lu (2005)

Caminho livre de exce¸cão: é alcan¸cável por meio de um caminho que não contenha arestas de exce¸cão.

Nós dependentes de exce¸cão (Ned) : é um subconjunto completo de nós que só

po-dem ser alcan¸cados em um caminho que contenha o lan¸camento de uma exce¸c˜ao.

Nós independentes de exce¸cão (Nei) : é um subconjunto completo de nós que podem ser alcan¸cados por um caminho livre de exce¸cão. É importante ressaltar que esses subconjuntos são 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ão (Eed) : é um subconjunto completo de arestas que só podem ser alcan¸cadas em um caminho que contenha o lan¸camento de uma exce-¸cão. É 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.

(46)

Com base nos conceitos apresentados, os crit´erios de teste propostos por Vincenzi et al. (2006) s˜ao:

• todos-nós-independentes-de-exce¸cão (Todos-Nósei): requer que cada nó

al-can¸c´avel por meio de pelo menos um caminho livre de exce¸c˜ao seja exercitado ao menos uma vez;

• todos-nós-dependentes-de-exce¸cão (Todos-Nósed): requer que cada nó não

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ão é alcan¸cável por meio de pelo menos um caminho livre de exce¸cão seja exercitada ao menos uma vez;

• todos-usos-independentes-de-exce¸c˜ao (Todos-Usosei): requer que toda

as-socia¸cão defini¸cão-uso independente de exce¸cão seja exercitada ao menos uma vez;

• todos-usos-dependentes-de-exce¸c˜ao (Todos-Usosed): requer que toda

asso-cia¸cão defini¸cão-uso dependente de exce¸cão seja exercitada ao menos uma vez;

• todos-potenciais-usos-independentes-de-exce¸c˜ao (Todos-Usosei): requer

que toda potencial associa¸cão defini¸cão-uso independente de exce¸cão seja exercitada ao menos uma vez;

• todos-potenciais-usos-dependentes-de-exce¸c˜ao (Todos-Usosed): requer que

toda potencial-associa¸cão defini¸cão-uso dependente de exce¸cão seja exercitada ao menos uma vez.

(47)

dele. Por essa razão, a informa¸cão de n´ıvel desse método não é mostrada. Os requisitos de teste apresentados na tabela 3.2 são derivados considerando que o grafo integrado seja uma unidade, pois esses critérios foram desenvolvidos pensando no teste de unidade.

Para analisar os critérios propostos pode-se comparar seus requisitos com os gerados pelos critérios da tabela 2.1. É poss´ıvel ver que o critério todos-nós-ed é semelhante ao critérioall-catch, mas com a diferen¸ca de que o critério todos-nós-ed inclui exercitar além dos nós catch os nós finally. O critério todos-arestas-ed também tem o objetivo de exercitar os blocos catch, mas ao invés de requerer a execu¸cão dos nós ele gera como requisito todas as arestas que levam até um nó catch. Aparentemente esse critério não tem uma rela¸cão clara com nenhum dos critérios propostos por Sinha e Harrold (2000), mas uma análise cuidadosa mostra que satisfazer esse critério pode ser semelhante a satisfazer o critérioall-e-deact pois exercitar uma tripla ativa¸cão-desativa¸cão corresponde a exercitar uma aresta de exce¸cão que sai da ativa¸cão da exce¸cão e termina em sua desativa¸cão, seja em um nó catch ou em um nó finally. O critério todos-usos-ed, mesmo que tenha sido projetado para o fluxo de exce¸cão, não parece ser muito adequado para o objetivo de exercitar o fluxo de exce¸cão. Tomando-se o exemplo da figura 3.2, se não fosse pelas impressões na tela dentro dos bloco catch por meio do comando System.out.println

esse critério não geraria nenhum requisito de teste pois, ao contrário, o requisito de teste all-e-use gera sete requisitos e aparentemente é um requisito forte quando o objetivo é exercitar o fluxo de exce¸cão. Assim pode-se concluir que o critério todos-usos-ed é útil como um complemento do critério todos-usos-ei para que juntos seja poss´ıvel exercitar todos os usos do programa, mas que não é relevante para o teste do fluxo de exce¸cão.

Para apoiar a aplica¸cão destes critérios, eles foram implementados na ferramenta Ja-BUTi, que faz a gera¸cão do grafo denominado grafo Def-Uso (DUG)(figura 3.5) a partir do seu bytecode, gera os requisitos de teste e calcula a cobertura dos testes automatica-mente. Mais informa¸cão sobre ela encontra-se na sessão de ferramentas. Seguindo essa linha do trabalho, Lemos et al. (2007) propõem uma abordagem de teste com suporte a programas OA com AspectJ. Para a representa¸cão do programa OA Lemos et al. (2007) propõem uma representa¸cão por meio de um grafo Def-Uso orientado a aspecto (AODU). Esse grafo contém informa¸cões sobre o fluxo de controle, de dados e de manipuladores de exce¸cão de uma unidade de um programa OA e também é derivado do bytecode do pro-grama. Nessa representa¸cão além dos nós e arestas do método, também são representados os nós e arestas transversais, que são os nós e arestas em que ocorre a itera¸cão de um ou mais adendos de determinados aspectos com o método. Essa abordagem representa os nós transversais por meio de elipses tracejadas com informa¸cão do tipo do adendo (before,

(48)

visualiza¸cão deles é poss´ıvel ressaltar a diferen¸ca entre a representa¸cão sem suporte OA de Vincenzi et al. (2006) e a representa¸cão com suporte OA proposta por Lemos et al. (2007).

Crit´erio Requisitos no

de requisitos Todos-n´os-ei 0; 15; 22; 28; 44; 1.0; 1.22; 1.31; 1.33; 1.72; 1.79; 1.82; 12

Todos-n´os-ed 7; 35; 1.85; 1.98 4

Todos-arestas-ei 0,1.0; 7,15; 22,44; 28,44; 35,44; 0,1.0; 1.0,1.22; 1.22,1.31; 1.31,1.33;1.33,1.72; 1.72,1.79; 1.72,1.82;1.98,44;

14

Todos-arestas-ed 0,7; 0,35; 1.72,1.85; 1.72,1.98; 1.79,1.85; 1.79,1.98; 1.82,1.85; 1.82,1.98

8

Todos-usos-ei L@1, 0,(1.33, 1.33)>; L@1, 0,(1.33, 1.72); L@2, 0,(1.33, 1.33); L@2, 0,(1.33, 1.72); L@3, 1.33,(1.33, 1.33); L@3, 1.33,(1.33, 1.72); L@4, 0,(1.33, 1.33); L@4, 0,(1.33, 1.72); L@4, 0,(1.72, 1.79); L@4, 0,(1.72, 1.82); L@5, 0,(1.33, 1.33); L@5, 0,(1.33, 1.72); L@5[], 1.33,(1.33, 1.33); L@5[], 1.33,(1.33, 1.72); L@6, 0,1.79; L@7, 0,1.82; S@.pex.cin, 0,(1.33, 1.33); S@.pex.cin, 0,(1.33, 1.72); S@.pex.cin[], 0,(1.33, 1.33); S@.pex.cin[], 0,(1.33, 1.72)

20

Todos-usos-ed S@.System.out, 0,1.85; S@.System.out, 0,1.98 2

Tabela 3.2: Requisitos de teste para os crit´erios propostos por Vincenzi et al. (2006)

Esta abordagem utiliza os critérios propostos por Vincenzi et al. (2006) e adiciona no-vos critérios afim de abranger também a cobertura dos aspectos. Os critérios adicionados são:

• _todos-n´_{os-transversais (Todos-N´}_osc): _{requer que cada n´o transversal, e por}

tanto cada execu¸c˜ao de adendo seja exercitado pelo menos uma vez;

• _{todos-arestas-transversais (Todos-Arestasc):} _{requer que cada aresta}

trans-versal seja exercitada ao menos uma vez;

• todos-usos-transversais (Todos-Usosc): requer que toda associa¸c˜ao defini¸c˜ao-uso

que contenha um n´o transversal ou uma aresta que inicie em um n´o transversal seja exercitada ao menos uma vez.

(49)

Figura 3.2: Exemplo de bytecode e grafo para o cod´ıgo da figura 2.7

Figura 3.3: Exemplo de c´odigo: classe Point e aspectoanAspectP

(50)

Figura 3.4: Parte do bytecode do m´etodo affectedMethod sem a presen¸ca de aspectos

Figura 3.5: Grafo DUG do m´etodo affectedMethod

(51)

Figura 3.6: Grafo AODU do m´etodo affectedMethodentrecortado pelo aspecto anAs-pect

fácil identificar onde ocorrem as itera¸cões adicionadas pelos adendos. Para essa abordagem Lemos e Masiero (2011) também propõem seis critérios dos quais três deles para o fluxo de exce¸cão. Os trabalhos de Lemos e Masiero (2011) e de Lemos et al. (2007) utilizam a ferramenta JaBTUi/AJ para dar suporte às abordagens propostas. Mais informa¸cões sobre a ferramenta JaBTUi/AJ serão apresentadas na se¸cão de ferramentas.

3.4 Outras abordagens para teste e verifica¸c˜

ao do fluxo

de exce¸c˜

ao

O trabalho de Coelho et al. (2011) apresenta uma abordagem de verifica¸cão com o ob-jetivo de verificar a confiabilidade do código de tratamento de exce¸cões em programas AspectJ. Essa abordagem tenta ajudar o desenvolvedor a identificar como integrar efeti-vamente os aspectos no código base, reduzindo o risco de introdu¸cão de falhas no código de tratamento de exce¸cões. Para isso a abordagem apoia o desenvolvedor a compreen-der o fluxo excepcional dos sistemas OA, descrever contratos de tratamento de exce¸cões e verificar automaticamente tais contratos. A abordagem é composta por cinco etapas principais, que podem ser visualizadas na figura 3.9; algumas são apoiadas por uma fer-ramenta denominada SAFE. Essa abordagem é complementar a algumas abordagens de teste OA.

(52)

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 affectedMethodentrecortado 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.

(53)

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 ágil para testar fluxo de exce¸cão baseada em testes funcionais. Esta abordagem pode ser usada para escrever os testes antes da implementa¸cão do sistema (”testfirst”) e também 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ões a partir dos pontos onde elas são lan¸cadas até os seu tratamento estão implementadas da maneira correta. Assim, um teste verifica o fluxo de exce¸cão com base em uma especifica¸cão e compara com o fluxo de exce¸cões que ocorre na execu¸cão. A abordagem de teste funcional proposta para teste do fluxo de exce¸cão pode ser dividida nas seguintes atividades: selecionar os principais fluxos de exce¸cão, criar casos de testes para exercitar estes caminhos, testar o conjunto de casos de teste, verificar os resultados dos testes, corre¸cão de erros, reaplica¸cão dos testes.

Sales e Coelho (2011) propuseram uma abordagem que permite definir regras de design para o tratamento de exce¸cões que podem ser checadas dinamicamente através de testes. Para a defini¸cão das regras de tratamento de exce¸cões é utilizado um arquivo de contratos de exce¸cões (um exemplo desse arquivo pode ser visto na figura 3.10). O contrato de ex-ce¸cões utiliza o formatoXMLe é formado por uma ou mais cláusulas, em que cada cláusula contém três elementos principais, que são: o sinalizador, que indica um ou mais métodos que lan¸cam um tipo de exce¸cão, a exce¸cão, que indica o tipo da exce¸cão e o tratador, que define um ou mais métodos responsáveis pelo tratamento de exce¸cões. O exemplo apresentado na 3.10 mostra três cláusulas a primeira especifica que: as exce¸cões do tipo

(54)

Figura 3.10: Exemplo de contrato de exce¸c˜ao.

Romano et al. (2011) propõem uma abordagem para gera¸cão de dados de testes com base em busca (search-based) com o objetivo de identificar automaticamente exce¸cões do tipo NullPointerException em programas Java. A primeira etapa dessa abordagem consiste em um conjunto de dados interprocessual e de análise do fluxo de controle, que identifica os caminhos entre os parâmetros de entrada e potenciasNullPointerException. A segunda é um algoritmo genético capaz de lidar com entradas complexas contendo estruturas de dados arbitrárias, que são utilizadas para evoluir a popula¸cão de dados de teste com o objetivo de abranger os caminhos identificados na etapa.

(55)

é poss´ıvel, pois a abordagem só tem suporte para linguagens compiladas, mas os autores propõe uma arquitetura para que seja poss´ıvel criar uma extensão da ferramenta que possa testar programas na linguagem Java.

3.5 Ferramentas

Os trabalhos discutidos nas subse¸cões anteriores apresentam algumas ferramentas para dar suporte aos critérios e abordagens de teste propostos. Elas são comentadas a seguir.

A ferramenta SAFE foi desenvolvida para apoiar a abordagem proposta por Coelho et al. (2011). Ela analisa o bytecode gerado de sistemas AspectJ a fim fornecer ao desen-volvedor informa¸cões referentes ao fluxo de exce¸cão da aplica¸cão. A ferramenta apoia as etapas 1, 3 e 4 da abordagem, conforme a figura 3.9.

No trabalho de Sinha e Harrold (2000) é mencionada a ferramenta JABA, que quando o artigo foi publicado ainda estava na fase de protótipo. Os autores informam que a ferramenta foi utilizada nos estudos realizados, mas não detalham o seu desenvolvimento e uso. Não foram encontradas referências posteriores a essa ferramenta.

OconGraX (Object Control-Flow Graph with eXceptions) é uma ferramenta gráfica de interface amigável desenvolvida em JAVA que tem por objetivo apoiar atividade de testes em sistemas JAVA (Nunes et al., 2009). Para isso, recebe como entrada um sistema e devolve um grafo de fluxo de controle dos objetos e das exce¸cões desse sistema além de um arquivo XML que contém os objetos e as exce¸cões do sistema. A interface da ferramenta pode ser visualizada na figura 3.11, na qual a ferramenta exibe um grafo de programa gerado nela.

Java PathFinderExceptions é uma extensão da ferramenta Java PathFinder (que é um verificador de modelo desenvolvido pelo centro de pesquisa da NASA (Team, 2005)). Ele checa propriedades referentes ao tratamento de exce¸cões em um sistema Java, além de gerar estat´ısticas de cobertura relativas aos estados varridos durante a verifica¸cão. A figura 3.12 mostra a tela de sele¸cão das propriedades que a ferramenta é capaz de verificar (Xavier et al., 2008).

(56)

Figura 3.11: Ferramenta OConGraX (Xavier et al., 2008)

Figura 3.12: Ferramenta Java PathFinder Exceptions

que da suporte ao teste estrutural para programas Java e AspectJ e tem implementados vários critérios de testes de software baseados em fluxo de controle e critérios baseados em fluxo de dados. A JaBUTi/AJ mantem as caracter´ısticas da JaBUTi original (Lemos e Masiero, 2008; Lemos et al., 2007). Esta ferramenta é usada neste trabalho e discutida no cap´ıtulo 4.