Conforme discutido nos cap´ıtulos anteriores, a atividade de teste ´e dividida em trˆes fases: (1) Teste de Unidade, (2) Teste de Integra¸c˜ao e (3) Teste de Sistema (Bertolino, 2007). Seguindo a divis˜ao apresentada, a aplica¸c˜ao dos crit´erios de teste estrutural de integra¸c˜ao contextual claramente se encaixam na fase de teste de integra¸c˜ao, sendo aplicados ap´os o teste de unidade do sistema. Assim, a estrat´egia sugerida nesse contexto seria: (1) realizar o teste de cada unidade do sistema em isolamento (utilizando, por exemplo os crit´erios propostos anteriormente por Vincenzi (2004) e Lemos (2005)); (2) testar a intera¸c˜ao entre todas as unidades pertencentes a um fluxo de execu¸c˜ao de uma unidade utilizando os cri- t´erios propostos nesta disserta¸c˜ao; e (3) enfatizar os interesses transversais testando cada adendo em cada um dos ponto de jun¸c˜ao afetados, utilizando os crit´erios propostos por Lemos e Masiero (2011). Vale ressaltar que no passo (2) ´e recomendado testar, de forma incremental, a integra¸c˜ao de todas as unidades que disparam um fluxo de execu¸c˜ao com sua chamada/entrecorte, e em todos os n´ıveis de profundidade, para facilitar a detec¸c˜ao de poss´ıveis erros, bem como a cria¸c˜ao de casos de testes espec´ıficos para a cobertura de um determinado requisito.
Para exemplificar o passo (2), considere as unidades mostradas no fluxo de execu- ¸c˜ao da Figura 5.2, e repetida na Figura 5.19(d), como sendo as ´unicas unidades de todo o programa Shape. Analisando as intera¸c˜oes entre as unidades ´e poss´ıvel obser- var que apenas a unidade aspects.Trace.printIdent n˜ao chama ou ´e entrecortada por nenhuma outra unidade. Ou seja, todas as unidades, com exce¸c˜ao da unidade as- pects.Trace.printIdent, devem ser testadas por meio da abordagem proposta. Al´em disso, as unidades devem ser testadas de forma incremental com rela¸c˜ao `a sua profundi- dade.
Portanto, para testar as unidades aspects.Trace.printEntering e aspects.Trace.printExiting, que possuem profundidade 1, devemos considerar as in- tegra¸c˜oes entre as unidades mostradas nas Figuras 5.13(a) e 5.13(b), respectivamente.
(aspects.Trace) printEntering()
(aspects.Trace) printIndent()
(a) Fluxo de execu¸c˜ao da unidade
printEnteringno n´ıvel 1 de profundidade.
(aspects.Trace) printExiting()
(aspects.Trace) printIndent()
(b) Fluxo de execu¸c˜ao da unidade
printExitingno n´ıvel 1 de profundidade.
Figura 5.13: Intera¸c˜oes dos m´etodos printEntering e printExiting no n´ıvel 1 de pro- fundidade.
Para testar as unidades aspects.Trace.traceEntry e aspects.Trace.traceExit, que possuem profundidade 2, devemos considerar primeiramente as integra¸c˜oes no n´ıvel 1 de profundidade, como mostrado nas Figuras 5.14(a) e 5.14(b) e, ap´os o teste no n´ıvel
PROGRAMAS OO E OA 1 de profundidade, o n´ıvel 2 de profundidade de intera¸c˜ao deve ser considerado, como mostrado nas Figuras 5.15(a) e 5.15(b).
(aspects.Trace) traceEntry()
(aspects.Trace) printEntering()
(a) Fluxo de execu¸c˜ao da unidade
traceEntryno n´ıvel 1 de profundidade.
(aspects.Trace) traceExit()
(aspects.Trace) printExiting()
(b) Fluxo de execu¸c˜ao da unidade
traceExitno n´ıvel 1 de profundidade.
Figura 5.14: Intera¸c˜oes dos m´etodos traceEntry e traceExit no n´ıvel 1 de profundi- dade. (aspects.Trace) traceEntry() (aspects.Trace) printEntering() (aspects.Trace) printIndent()
(a) Fluxo de execu¸c˜ao da unidade traceEntry no n´ıvel 2 de profundidade.
(aspects.Trace) traceExit() (aspects.Trace) printExiting() (aspects.Trace) printIndent()
(b) Fluxo de execu¸c˜ao da unidade traceExit no n´ıvel 2 de profundidade.
Figura 5.15: Intera¸c˜oes dos m´etodos traceEntry e traceExit no n´ıvel 2 de profundi- dade.
O teste dos adendos aspects.Trace.before():MyMethod e aspects.Trace.after() returning():MyMethod, que possuem profundidade 3, devem considerar primeiramente a integra¸c˜ao das unidades na profundidade 1 (Figuras 5.16(a) e 5.16(b)), depois na pro- fundidade 2 ((Figuras 5.17(a) e 5.17(b))) e, por fim, na profundidade 3 (Figuras 5.18(a) e 5.18(b)).
(aspects.Trace) before(): MyMethod()
(aspects.Trace) traceEntry()
(a) Fluxo de execu¸c˜ao do adendo do tipo before no n´ıvel 1 de profundidade. (aspects.Trace) after() returning(): MyMethod() (aspects.Trace) traceExit()
(b) Fluxo de execu¸c˜ao do adendo do tipo after no
n´ıvel 1 de profundidade.
PROGRAMAS OO E OA (aspects.Trace) before(): MyMethod() (aspects.Trace) traceEntry() (aspects.Trace) printEntering()
(a) Fluxo de execu¸c˜ao do adendo do tipo before no n´ıvel 2 de profundidade.
(aspects.Trace) after() returning(): MyMethod() (aspects.Trace) traceExit() (aspects.Trace) printExiting()
(b) Fluxo de execu¸c˜ao do adendo do tipo after no n´ıvel 2 de profundidade.
Figura 5.17: Intera¸c˜oes dos adendos before e after no n´ıvel 2 de profundidade.
(aspects.Trace) before(): MyMethod() (aspects.Trace) traceEntry() (aspects.Trace) printEntering() (aspects.Trace) printIndent()
(a) Fluxo de execu¸c˜ao do adendo do tipo before no n´ıvel 3 de profundidade.
(aspects.Trace) after() returning(): MyMethod() (aspects.Trace) traceExit() (aspects.Trace) printExiting() (aspects.Trace) printIndent()
(b) Fluxo de execu¸c˜ao do adendo do tipo after no n´ıvel 3 de profundidade.
Figura 5.18: Intera¸c˜oes dos adendos before e after no n´ıvel 3 de profundidade. Finalmente, o teste da unidade shape.Circle.area deve considerar, na profundidade 1 de intera¸c˜ao, o fluxo de execu¸c˜ao das unidades mostradas na Figura 5.19(a). Posteri- ormente, deve-se considerar as unidades at´e a profundidade 2, como mostrado na Figura 5.19(b). Depois disso, o m´etodo shape.Circle.area deve ser testado na profundidade 3 com as unidades mostradas na Figura 5.19(c). Por fim, o m´etodo deve ser testado em sua profundidade m´axima de intera¸c˜ao (profundidade 4), como mostrado na Figura 5.19(d).
Portanto, o teste das sete unidades envolvidas no fluxo de execu¸c˜ao do m´etodo shape.Circle.areaenvolve 16 configura¸c˜oes diferentes se considerarmos o teste em todas as profundidades de intera¸c˜ao.
Al´em disso, como existe uma hierarquia de inclus˜ao entre os crit´erios de teste es- trutural de integra¸c˜ao contextual, desconsiderando os caminhos n˜ao execut´aveis, den- tro do passo (2) da estrat´egia apresentada ainda pode ser imposta uma ordem de apli- ca¸c˜ao dos crit´erios come¸cando pelo crit´erio todos-n´os-integrados-Nd, depois o crit´erio
todas-arestas-integradas-Nd e, por fim, o crit´erio todos-usos-integrados-Nd. A ordem de
aplica¸c˜ao adotada sugere iniciar o teste com a aplica¸c˜ao do crit´erio mais fraco e incremen- tar os casos de teste em dire¸c˜ao `a adequa¸c˜ao dos crit´erios mais fortes.
PROGRAMAS OO E OA (shape.Circle) area() (aspects.Trace) before(): MyMethod() (aspects.Trace) after() returning(): MyMethod()
(a) Fluxo de execu¸c˜ao do m´etodo
areano n´ıvel 1 de profundidade.
(shape.Circle) area() (aspects.Trace) before(): MyMethod() (aspects.Trace) traceEntry() (aspects.Trace) after() returning(): MyMethod() (aspects.Trace) traceExit()
(b) Fluxo de execu¸c˜ao do m´etodo area no n´ıvel
2 de profundidade. (shape.Circle) area() (aspects.Trace) before(): MyMethod() (aspects.Trace) traceEntry() (aspects.Trace) printEntering() (aspects.Trace) after() returning(): MyMethod() (aspects.Trace) traceExit() (aspects.Trace) printExiting()
(c) Fluxo de execu¸c˜ao do m´etodo area no n´ıvel 3 de profundidade.
(shape.Circle) area() (aspects.Trace) before(): MyMethod() (aspects.Trace) traceEntry() (aspects.Trace) printEntering() (aspects.Trace) after() returning(): MyMethod() (aspects.Trace) traceExit() (aspects.Trace) printExiting() (aspects.Trace) printIndent()
(d) Fluxo de execu¸c˜ao do m´etodo area no n´ıvel 4 de profundidade.
Figura 5.19: Intera¸c˜oes do m´etodo area em todos os n´ıveis de profundidade.
5.7
Considera¸c˜oes Finais
Neste cap´ıtulo foi apresentada uma abordagem de teste estrutural de integra¸c˜ao contextual para programas OO e OA. A abordagem inclui um modelo para a representa¸c˜ao de todo o fluxo de execu¸c˜ao no contexto de um m´etodo sob teste. Com base no modelo, foi definida uma fam´ılia com trˆes crit´erios de teste – dois baseados no fluxo de controle e um baseado
PROGRAMAS OO E OA no fluxo de dados – e foi apresentado o modelo de fluxo de dados utilizado para identificar o que caracteriza uma defini¸c˜ao ou o uso de uma vari´avel em uma senten¸ca ou instru¸c˜ao. Com a abordagem de teste definida, ´e necess´ario implement´a-la em uma ferramenta para viabilizar o seu uso. No Cap´ıtulo 6 ´e mostrado o processo de cria¸c˜ao da extens˜ao da ferramenta JaBUTi/AJ que possibilita o teste estrutural de integra¸c˜ao contextual. Para ilustrar a aplicabilidade da abordagem ´e apresentado um exemplo de aplica¸c˜ao no teste de um programa OA.
6
Automa¸c˜ao do Teste Estrutural de
Integra¸c˜ao Contextual
6.1
Considera¸c˜oes Iniciais
As t´ecnicas e crit´erios de teste fornecem ao desenvolvedor uma abordagem sistem´atica e teoricamente fundamentada, al´em de constitu´ırem um mecanismo que pode auxiliar a avaliar a qualidade e a adequa¸c˜ao da atividade de teste. Com isso, ´e fundamental o desenvolvimento de ferramentas de teste para o suporte `a atividade de teste propriamente dita, uma vez que essa atividade ´e muito propensa a erros, al´em de menos produtiva, se aplicada manualmente. Assim, a disponibilidade de ferramentas de teste propicia maior qualidade e produtividade para as atividades de teste (Maldonado et al., 2004).
Deste modo, ´e importante implementar a abordagem de teste estrutural de integra¸c˜ao contextual proposta em uma ferramenta de teste. Para isso, a ferramenta JaBUTi/AJ , que ´e uma ferramenta para apoiar o teste estrutural de programas OO e OA escritos em Java e AspectJ, foi estendida para possibilitar a aplica¸c˜ao automatizada da abordagem proposta neste trabalho.
Na Se¸c˜ao 6.2 ´e descrita a extens˜ao da ferramenta JaBUTi/AJ para o teste estrutural de integra¸c˜ao contextual. Na Se¸c˜ao 6.3 ´e apresentado o modo de utiliza¸c˜ao da JaBUTi/AJ por meio da utiliza¸c˜ao de um exemplo de uso. Por fim, na Se¸c˜ao 6.4 s˜ao apresentadas as considera¸c˜oes finais do cap´ıtulo.
CONTEXTUAL