Primeiro Estudo de Caso: Adventure Builder

O site da Sun Microsystems© descreve o software “Adventure Builder” (AB) como uma aplicação de referência da plataforma J2EE™ versão 1.4. O código fonte completo da aplicação pode ser obtido no site do programa BluePrints™ que tem o objetivo de prover padrões, orientação e código para as aplicações reais. Entre padrões utilizados neste exemplo estão Java Server Pages ("JSP"), Java Servlets e Enterprise JavaBeans ("EJB"), tecnologias que vêm sendo adotadas em diversos projetos reais, incluindo o SIGEP, abordado no segundo estudo de caso.

O AB é um website de venda de pacotes pela internet e suas principais funcionalidades compreendem permitir ao cliente:

• navegar no catálogo de pacotes disponíveis e escolhe um pacote desejado, definindo as opções do pacote, como o número de pessoas, data da viagem, transporte aéreo e hospedagem;

• criar uma conta de usuário, com identificação e senha e informando dados pessoais, como endereço, por exemplo;

• finalizar o processo de compra do pacote escolhido, definindo a forma de pagamento;

• acompanhar a situação da compra realizada, com relação à confirmação de reservas e aprovação de crédito, por exemplo.

A documentação do sistema é composta de guias de uso, compilação, instalação e um guia de arquitetura, que tem mais foco em descrever as tecnologias envolvidas e as decisões de projeto internas ao produto, do que em explicar as funcionalidades disponíveis. Com relação à especificação de funcionalidades, o guia de arquitetura do sistema trás um diagrama de casos de uso, sem nenhum detalhe adicional. O guia de uso acaba sendo a melhor fonte de informação sobre os cenários de uso do AB, mas, ele não é tão detalhado e estruturado como devem ser as especificações de caso de uso.

A imprecisão dos casos de uso e a documentação superficial fornecida aproximam a situação do “Adventure Builder” daquela que normalmente se encontra em sistemas reais

Figura 14 – Modelo de Casos de Uso do “Adventure Builder”

A aplicação prática da técnica exigiu então, uma etapa inicial para cumprir o pré- requisito de obter os casos de uso (Figura 14) e permitir a condução dos passos estabelecidos pela proposta.

7.2.1. Criação dos Casos de Uso

A elaboração dos casos de uso do AB foi realizada com base no guia de uso e na exploração da própria aplicação em funcionamento. Como não havia nenhum usuário real, não houve nenhuma entrevista e os casos de uso criados não puderam ser validados. Os casos de uso definidos foram: Escolher Pacote, Comprar Pacote, Criar Conta de Usuário e Rastrear Pedido – que correspondem às funcionalidades descritas anteriormente.

O formato utilizado na especificação dos fluxos de eventos foi o de tabela de duas colunas de Wirfs-Broks (WIRFS-BROCKS e SCHWARTZ, 2007). Este formato é bom para a localização de casos de uso, pois separa totalmente as ações do usuário das respostas do sistema, o que facilita a definição das ações que devem ser executadas pelo testador, nos casos de testes.

7.2.2. Criação dos Casos de Teste

Definidos os casos de uso a criação dos casos de teste se mostrou um processo bastante simples. Após selecionar alguns cenários, que cobrissem todos os fluxos de eventos de cada caso de uso, foi definido um caso de teste para cada cenário. Outros casos de testes poderiam ter sido definidos, mas como o AB é um sistema razoavelmente simples não foi identificada nenhuma situação em que isso parecesse necessário.

A Tabela 12 apresenta os cenários identificados no caso de uso Escolher Pacote. O conjunto dos cenários apresenta diversas redundâncias, de forma que não foi necessário utilizar todos eles para cobrir a totalidade dos fluxos de eventos e ações do caso de uso. Um subconjunto destes cenários foi selecionado para que fossem definidos os casos de testes.

Tabela 12 – Cenários do Caso de Uso “Escolher Pacote”

Cenário Fluxos

1: Escolhe um pacote Fluxo Básico

2: Escolhe diversos pacotes Fluxo Básico + Alternativo 2 (n vezes) 3: Escolhe Pacote Sem Transporte Fluxo Básico + Alternativo 1

4: Escolhe um pacote com e outro sem transporte Fluxo Básico + Alternativo 2 + Alternativo 1 5: Navega Entre as Categorias e Avalia Vários pacotes Fluxo Básico + Alternativo 4 + Alternativo 5 6: Mudança de Pacote Fluxo Básico + Alternativo 3

7: Navega e não escolhe nada Fluxo Básico + Alternativo 4 + Alternativo 5 + Alternativo 6

Os cenários 1, 4, 6 e 7 foram selecionados para dar origem aos casos de testes que seriam aplicados. Para efeitos de testes reais do sistema, possivelmente seria interessante ter mais casos de testes que avaliassem a qualidade do produto em outros contextos. Mas, como os casos de testes definidos tinham o objetivo apenas de aplicar a técnica de localização de casos de uso não havia necessidade de ir além de um conjunto que exercitasse todos os fluxos de eventos e ações do caso de uso. A Tabela 13 apresenta o conjunto dos casos de testes definidos para o caso de uso Escolher Pacotes.

A partir desta tabela foram criados scripts que carregaram, na Base de Rastros, os casos de testes com todos seus passos devidamente relacionados às ações do caso de uso. O mesmo processo foi repetido para os demais casos de uso do AB. Assim, ao fim desta etapa, todos os casos de uso, fluxos de eventos, ações e ações de caso de teste foram definidos e estavam armazenados na Base de Rastros aguardando a coleta dos rastros.

Tabela 13 – Casos de Teste do Caso de Uso “Escolher Pacote”

Caso de

Teste Cenário Condições Resultado Esperado

TC 1 1: Escolhe um pacote Carrinho = 1 pacote

TC 2 4: Escolhe um pacote com e outro sem transporte Passo 7 – Escolhe outro pacote de outra categoria Carrinho = 2 pacotes TC 3 7: Navega e não escolhe nada Passo 2 – muda de categorias Passo 3 – escolhe vários pacotes Carrinho = vazio TC 4 6: Escolhe um pacote e _{depois remove} Fluxo A3 – muda a quantidade do pacote _{escolhido para 0 (zero)} Carrinho = vazio

No total foram produzidos oito casos de testes para cobrir todos os cenários identificados nos quatro casos de uso.

7.2.3. Instrumentação do Código Fonte

A instrumentação do código fonte é realizada por um Instrumentador implementado especialmente para a linguagem Java™. O método de instrumentação é determinado mais pela linguagem de programação e pelos dados que se pretende obter na coleta dos rastros do que pelo sistema que será estudado – como descrito no tópico 6.3. Uma evidência disto é que o mesmo Instrumentador implementado para o AB foi usado para o SIGEP sem nenhum ajuste especial.

O instrumentador implementado é bastante simples e por isso gera alguns erros de compilação no código fonte instrumentado. Isto porque ele não distingue métodos de vetores declarados como atributos de classes – pois ambas as estruturas são limitadas por chaves ( “{“ e “}” ). A solução destes erros não exigiu muito esforço e em poucos minutos foi possível eliminar todos os problemas. Contudo, se o Instrumentador fosse mais sofisticado isso não seria necessário, eliminando totalmente a intervenção humana do processo.

7.2.4. Execução dos Casos de Teste

A principal diferença entre a execução normal de uma aplicação e execução de um caso de teste para a localização de casos de uso é que no caso da localização de caso de uso o executor dos testes deve utilizar a Interface do Executor para informar cada ação do teste executada, conforme descrito no capítulo anterior.

O processo, apesar de simples, na prática apresentou uma dificuldade importante. A precisão no momento de confirmar a execução de ação na Interface do Executor é um requisito fundamental da aplicação da técnica, conforme já foi citado. Acabou sendo comum o executor

se confundir ao executar um caso de teste e deixar de confirmar o envio de uma ou outra ação no momento certo. Quando isso ocorria o executor precisava interromper a execução, remover os rastros daquela execução da Base de Rastros e então começar o caso de teste do início novamente. Na prática, em sistemas com muitos casos de testes, este tipo de problema pode tornar a aplicação da técnica muito difícil ou mesmo inviável.

A solução deste problema através da automação da execução de testes já foi apontada na seção 6.4.1. Com o objetivo de validar a utilização da alternativa automatizada de execução, foram implementados cinco scripts no RFT que correspondem a casos de testes dos quatro casos de uso do AB. A adição das chamadas de envio das mensagens é simples, pois as linhas de código são sempre as mesmas e é fácil identificar os passos de caso de teste lendo os scripts.

7.2.5. Análise dos Rastros Coletados

Coletados os rastros, foram implementadas as análises citadas anteriormente: Rastros Consolidados, Execução Post-Mortem, Comparação de Casos de Uso e Comparação de Ações. A Execução Post-Mortem e o Rastro Consolidado estão exemplificados nas Figuras 11 e 12, respectivamente.

A análise de similaridade revelou relações que não estavam claras nos textos das ações dos fluxos de eventos. A Tabela 14 apresenta alguns exemplos de altos graus de similaridade identificados entre ações. Essas ações se referem principalmente a navegação e resultam na apresentação de telas muito parecidas umas com as outras. Nenhum deles está relacionado a nenhuma entrada de dados, aplicação de regra de negócio ou algo que exija do sistema muito mais do que mecanismos restritos à camada de apresentação.

O cálculo de similaridades é capaz de relacionar conceitos que podem estar separados no texto dos casos de uso, mas que têm implementações em comum. Neste caso a alta similaridade demonstra que estes passos não tratam conceitos fundamentais para o negócio, mas sim de características de funcionamento geral do sistema, que podem estar presentes em qualquer ponto de qualquer caso de uso.

Ações cuja similaridade é sempre baixa com relação às outras mostram onde estão tratados os fatores específicos do caso de uso. Por exemplo, a similaridade dos passos 4, 5, 6 e 7 do Fluxo 1 do Caso de Uso “Escolher Pacote” atingem o máximo de 26%, e na maior parte das vezes são inferiores a 20%. Como, no geral, quase todas as ações atingem similaridades

acima de 40% com relação a ações de outros casos de uso, os valores abaixo de 20% são boas indicações de que nos rastros destas ações se encontram partes específicas do caso de uso “Escolher Pacote”.

Tabela 14 – Similaridade entre Ações de “Escolher Pacote” e “Rastrear Pedido”

Ações de “Rastrear Pedido” Ações de “Escolher Pacote”

1.1 1.2

1.1: Esse caso de uso se inicia quando o Cliente acessa a tela principal do sistema pela URL 73,91% 23,40% 1.2: Cliente seleciona uma categoria de aventura. 85,00% 25,00% 1.3: Cliente seleciona um pacote de aventura, para visualização. 89,47% 25,58% 1.4: Cliente seleciona o pacote, para compra. 13,48% 26,60% 1.5: Cliente define e submete as opções do pacote. 11,11% 24,32% 1.6: Cliente escolhe as opções de transporte e submete para o sistema. 11,11% 28,00% 1.7: Cliente escolhe seu vôo de ida e de volta e submete para o sistema. 10,78% 27,18% 2.1: No passo 6, o cliente pode escolher dispensar a reserva do transporte. 13,92% 33,33% 3.1: Apos o passo 7 o cliente pode voltar ao passo 1 e reiniciar o processo de escolha de um pacote. 24,49% 51,92% 5.1: Apos o passo 3, o cliente pode retornar ao passo 2 e selecionar uma nova categoria 94,44% 26,19% 6.1: Apos o passo 3, o cliente pode selecionar outro pacote na mesma categoria. 89,47% 25,58% 7.1: Em qualquer passo o cliente pode decidir interromper a navegação e a escolha de pacotes. 13,33% 29,03%