Overordnede utviklingstrekk og refleksjoner

A Tabela 3.8 apresenta um breve resumo do atendimento aos requisitos identificados por parte parte dos métodos analisados. Utilizamos três símbolos para representar o atendimento completo ao requisitos (↑), atendimento parcial (→) e o não atendimento (↓).

O TOTEM atende a poucos requisitos. Isso ocorre em virtude de tal método não possuir uma ferramenta de apoio. Muitas questões associadas ao TBM somente são identificadas du- rante a implementação de tais ferramentas. A geração de oráculos, por exemplo, é mencionada no TOTEM, porém, isso é feito de forma muito teórica e de difícil implementação. Por esse motivo, utilizamos a simbologia que o método atende parcialmente esse requisito. Da mesma forma, a teste do relacionamento entre o sistema e o armazenamento, assim como a utilização de critérios são apenas mencionados no trabalho. Apenas o requisito relacionado à geração de testes funcionais é atendido de forma satisfatório pelo método. Os demais requisitos não são sequer comentados no método.

Tabela 3.8: Resumo da análise do atendimento aos requisitos pelos métodos considerados.

O MODEST atende a vários dos requisitos identificados. No entanto, alguns são aten- didos de forma parcial. O teste da arquitetura do sistema é limitado por meio da restrição nos sistemas suportados. O teste de requisitos não-funcionais é mencionado no método mas não é efetivamente implementado. O método possui um mecanismo para avaliação dos testes por meio da integração com uma ferramenta de análise de mutantes mas essa integração não se mostrou bem sucedido na prática, devido a algumas limitações da própria ferramenta de mutação. O MODEST prescreve e implementa um mecanismo para garantir a interoperabili- dade por meio do uso de um modelo independente de tecnologia e contendo ainda geradores de teste para tecnologias específicas. Embora isso não garanta a interoperabilidade de forma genérica é um passo nessa direção. O MODEST prescreve ainda o auxílio para a geração de testes manuais, assim como o acompanhamento automático de falhas, mas não possui nada implementado nessa direção.

O AGEDIS, embora seja um projeto grande, envolvendo diversos parceiros, assim como o MODEST, não atende de forma completa todos os requisitos identificados. O teste da arquitetura está limitado a configuração de alguns parâmetros para a execução de testes en- volvendo sistemas distribuídos. A avaliação dos testes é limitada à verificação da cobertura de instruções alcançada. Embora o AGEDIS tenha definido uma linguagem para especifica- ção de modelos de teste e do próprio SST, essas definições ainda estão longe de garantir a interoperabilidade entre métodos e ferramentas. Uma grande lacuna deixada pelo AGEDIS é a avaliação efetiva do método em um experimento. A documentação do método descreve de forma muito superficial algumas aplicações do método, tornando impossível avaliar se o seu uso pode trazer ganhos efetivos no desenvolvimento de software.

Uma interessante constatação obtida a partir da elaboração do catálogo de requisitos é que nenhum dos métodos considerados focalizou nos aspectos gerenciais relacionados ao testes, aspectos esses diretamente relacionados ao planejamento dos testes, assim como nos aspectos relacionados à constante necessidade por alterações em sistemas em desenvolvimento.

Conforme representado na Tabela 3.8 nenhum dos métodos considerou esses requisitos.

3.6

Considerações finais

Neste capítulo apresentamos o método de TBM MODEST. Apresentamos o método utili- zando três níveis: conceitual, com as prescrições do método em alto nível; lógico, com um mapeamento dessas prescrições no contexto do PU e da UML; e físico, exibindo as tecnologias utilizadas para criação de uma ferramenta de apoio ao método.

No capítulo exibimos como criar um modelo UML com todos os requisitos de testabilidade exigidos pelo MODEST. Utilizando um modelo com tais características, o MODEST planeja, cria e executa testes, podendo com isso reduzir o esforço necessário nessas atividades. Uti- lizando o MODEST foi possível comprovar que a reutilização de artefatos prescritos em um processo de software pode contribuir significativamente para a automação das atividades de teste, podendo ainda aumentar, não somente a qualidade do produto final, como também a própria qualidade da especificação do software.

Neste capítulo também apresentamos alguns critérios de testes baseados no uso de mode- los, e em particular, no uso de modelos UML. Conforme descrito, o MODEST segue alguns critérios definidos em outros trabalhos, além de definir novos critérios, como o Critério de estresse, Critério de composição, Critério de desempenho e Critério de navegação.

Uma importante diferença do MODEST para alguns trabalhos discutidos no capítulo anterior é a sua especialização para uma arquitetura específica. A tentativa de ser muito genérico impõe altos custos no seu uso. A especialização do MODEST o torna mais barato, visto que a geração do oráculo, que geralmente é o aspecto que demanda mais custo e esforço nesse tipo de método, não requer um esforço tão grande quanto o exigido na maioria dos outros métodos e ferramentas aqui apresentados.

A personalização do MODEST para o PRAXIS não é complexa, visto que a extensão das atividades de desenho não gera um impacto significativo na construção de software. Além disso, a redução no esforço que pode ser obtida com o uso do método tende a ser significativa, uma vez que o MODEST pode automatizar a maioria das atividades de teste, que, de acordo com o que foi discutido na Introdução, geralmente é responsável pelo consumo de boa parte dos recursos de um projeto.

No próximo capítulo apresentamos detalhes sobre um estudo experimental realizado com o intuito de caracterizar o método. Conforme apresentado no estudo, o MODEST pode reduzir os custos relacionados ao desenvolvimento de software, ao mesmo tempo em que pode aumentar a qualidade dos testes gerados.

Um Estudo Experimental do

MODEST

Nosso estudo da literatura mostrou que a maioria dos métodos e ferramentas para automação de testes apresenta avaliações mostrando o impacto das atividades propostas, em termos de qualidade, sem demonstrar o impacto dessas atividades, em termos de custos. Isso motivou nossa investigação sobre como avaliar nosso método levando em consideração não só os pos- síveis ganhos em qualidade, mas também os custos associados ao seu uso. Neste capítulo apresentamos um estudo experimental para caracterizar o uso do MODEST, seguindo com rigor as prescrições existentes na Engenharia de Software Experimental (Wohlin et al., 2000). O estudo mostra que o uso do método pode trazer tanto redução de custos, através da redu- ção do esforço gasto nas atividades de testes, quanto aumento na capacidade de detecção de falhas.

Nas próximas seções detalhamos este estudo usando a seguinte organização: a Seção 4.1 apresenta o estudo experimental realizado; a Seção 4.1.11 apresenta algumas tentativas de es- tudos realizadas anteriormente; e a Seção 4.1.12 apresenta as considerações finais do capítulo.

4.1

Estudo experimental

Nesta seção descrevemos o estudo experimental realizado com o intuito de caracterizar o uso do MODEST no desenvolvimento de parte de um SI.