Executando o Teste

A execução dos testes gerados pela ferramenta SPACES é feita pelo Testador de Com- ponentes, uma aplicação baseada no framework JUnit. Para tanto, é preciso que o pacote contendo os artefatos de teste gerados esteja presente no CLASSPATH da aplicação. Na Figura 5.17, vemos a tela de execução dos testes gerados para todas as funcionalidades do componente Gerenciador de Hotéis. Nesta execução, testamos uma implementação da es- pecificação do componente na qual a funcionalidade Cancelar Reserva foi incorretamente codificada. A implementação da funcionalidade deveria lançar uma exceção correspondente à mensagem de saída do cenário Reserva Já Cancelada e, no cenário Sucesso, deveria alterar

5.3 Aplicando o Método AFCT 94

o estado do objeto Reserva correspondente aos dados de entrada, indicando o seu cancela- mento. Ambos os comportamentos foram omitidos para que pudéssemos observar esses defeitos durante a execução dos testes. O testador executou todos os 10 casos de teste e iden- tificou com um X na cor preta, os cenários falhos da funcionalidade Cancelar Reserva. Além disso, três testes tiveram resultado indefinido em função de inconsistências no conjunto de dados selecionados para os respectivos cenários (Quarto Nao Disponivel e Sucesso da fun- cionalidade Alterar Reserva e Sucesso da funcionalidade Fazer Reserva). Esses cenários foram marcados com um X na cor amarela. Os demais cenários foram marcados com o sím-

bolo√na cor verde, indicando que foram executados com sucesso. Como houve pelo menos

uma falha na execução dos testes, a barra de progresso assumiu a cor vermelha ao final da execução.

5.3 Aplicando o Método AFCT 95

Após a correção dos defeitos de implementação da funcionalidade Cancelar Reserva, os testes foram novamente executados e os resultados obtidos podem ser vistos na Figura 5.19. Desta vez, os testes dos cenários que falharam na execução anterior foram bem sucedidos. No entanto, os cenários com dados inconsistentes ainda permaneceram com o resultado dos testes indefinido. Em função disso, a barra de progresso assumiu a cor amarela. Neste momento, acessamos os dados que foram selecionados para cada cenário, através do botão Test Data do testador e, na tela de edição de dados que é exibida, confrontamos os dados selecionados com a restrição de pré-condição OCL do respectivo cenário com o objetivo de detectar e alterar os dados inválidos.

Figura 5.18: Execução dos Testes: Revisando os Dados de Teste

Por fim, após a alteração dos dados inválidos, os testes foram executados uma terceira vez e, como pode ser visto na Figura 5.19, a barra de progresso assumiu a cor verde em sinal

5.4 Considerações Finais 96

da ausência de falhas.

Figura 5.19: Execução dos Testes: Testes Ok

5.4

Considerações Finais

Neste capítulo, apresentamos a aplicação do método AFCT e da ferramenta SPACES na especificação e teste de um componente de um sistema de reservas de hoteis. A especificação do componente foi construída passo-a-passo, de acordo com as diretrizes do método AFCT. Foi feito um levantamento das funcionalidades e cenários de uso do componente a partir dos quais foi realizada a etapa de planejamento do método. Em seguida, já com o auxílio da ferramenta SPACES, foi construída a especificação dos testes a partir da seleção de casos de teste, da geração de oráculos e da seleção de dados de teste. Após a especificação dos

5.4 Considerações Finais 97

testes, as informações geradas foram utilizadas pela ferramenta para realizar a construção dos artefatos de teste. Neste momento foram geradas as classes de teste e os arquivos XML de dados, necessários à execução dos testes do componente. Estes artefatos foram empacotados na forma de um arquivo JAR para possibilitar a execução dos testes por parte da aplicação Testador de Componentes. Durante a execução, utilizamos inicialmente uma implementação na qual uma das funcionalidades do componente havia sido incorretamente codificada em relação à sua especificação. Ao executar os testes, o testador de componentes identificou as falhas existentes nesta funcionalidade. Além das falhas, também foram obtidos resultados indefinidos para alguns testes em função de uma limitação da atividade de seleção de dados de teste da ferramenta SPACES. Após a correção das falhas de implementação e a alteração dos dados incorretos, os testes foram novamente executados e todos obtiveram êxito.

Embora tenha sido realizada em um estudo de caso simples, a aplicação do método AFCT provou ser, de fato, bastante fácil uma vez que os artefatos que foram desenvolvidos são semelhantes aos que já são normalmente produzidos pelos processos de desenvolvimento. Além disso, a utilização da ferramenta SPACES para a realização automática de tarefas mais complexas e/ou sistemáticas do método fez com que estas atividades pudessem ser realizadas rapidamente e, em que pese o fato de em alguns momentos precisarmos realizar manualmente parte da atividade de seleção dos dados de teste, em função da limitação exis- tente na ferramenta, ainda assim o processo de teste pode ser aplicado de maneira bastante prática mesmo em sistemas mais complexos, evitando a necessidade de alocação de grande parte dos recursos organizacionais. Por fim, vimos que o conjunto de testes gerado pela ferramenta SPACES aliado ao Testador de Componentes facilita o trabalho do fornecedor do componente no que diz respeiro à execução e análise de resultado dos testes. Com a distribuição de ambos para os clientes, os testes produzidos e a infraestrutura de execução podem auxiliar a verificação dos componentes do ponto de vista de integração, no momento da composição das aplicações.

A aplicação do método AFCT nos permite ainda avaliar o quanto da especificação do componente foi coberta. Caso optássemos pela seleção de todos os casos de teste, obteríamos uma cobertura de 100% da especificação, o que nem sempre é possível em função dos recur- sos disponíveis para a realização dos testes. No entanto, uma vez que foram selecionados os cenários de uso mais críticos das funcionalidades, a cobertura obtida pode ser considerada

5.4 Considerações Finais 98

satisfatória e nos dá uma certa margem segurança a cerca da confiabilidade do componente. É importante salientar que a cobertura da especificação é uma métrica mais adequada para o teste funcional. A cobertura de código poderia ser medida durante a execução dos testes, a

partir do uso de ferramentas extras, a exemplo da ferramenta Clover1_.

Capítulo 6

Conclusão

Apresentamos neste trabalho a proposta de um método de teste funcional automático para verificação de componentes de software a partir de especificações UML e restrições OCL. A idéia de seu desenvolvimento surgiu a partir da necessidade de realizar adaptações em um método de teste semelhante que foi desenvolvido anteriormente dentro de nosso grupo de pesquisa, o método FCT (Functional Component Testing). As adaptações precisavam ser realizadas para possibilitar o desenvolvimento de uma ferramenta de suporte que autom- atizasse as atividades do método. No entanto, essas adaptações levaram à redefinição de boa parte das atividades do método FCT, o que acabou resultando na proposta de um novo método de teste fortemente baseado no anterior, o método AFCT (Automatic Functional Component Testing). Aliado a elaboração do método AFCT, o trabalho também contemplou o desenvolvimento de uma ferramenta de suporte para a realização de suas atividades de forma automática, a ferramenta SPACES (SPecification bAsed Component tESter).

Como mostrado, o método AFCT faz uso de artefatos UML produzidos por processos de desenvolvimento durante as fases de análise e projeto. Estes artefatos, que são criados segundo um formato apresentado neste trabalho, são utilizados à medida que vão sendo de- senvolvidos, possibilitando, assim, a aplicação do processo de teste de forma paralela ao processo de desenvolvimento. A partir destes artefatos, é feito o planejamento de teste, quando são tomadas decisões relacionadas a realização das atividades de teste frente aos re- cursos disponíveis. Uma vez definidos os recursos disponíveis para as atividade de teste, é realizada a especificação dos testes. Essa fase consiste na geração de modelos de teste a par- tir dos quais são derivados os casos de teste, oráculos e dados, que constituem os pilares para