Inicialmente, os requisitos de desenvolvimento da StateMutest eram simplesmente exe- cutar um modelo de estados contra um conjunto de casos de teste, observar as saídas, e registrá-las em um arquivo o qual pudesse ser posteriormente consultado (requisitos mínimos).
Durante as primeiras execuções aplicando a análise de mutantes, observou-se que o tempo gasto em um projeto de teste pequeno ultrapassava duas horas de duração em execução dos testes (estimava-se menos de uma hora de duração), assim, a ferramenta passou a incluir a implementação de algumas das técnicas de redução de custos.
Além destas, a organização do projeto de teste, a edição (na própria ferramenta) de todos os arquivos de teste, a adição de extensões, a simulação do modelo, a importação de casos de teste, e a programação dos testes, são exemplos de funcionalidades adicionadas
ao projeto ao longo do ciclo de desenvolvimento incremental.
A seguir, a lista das funcionalidades principais da ferramenta, funcionais e não funci- onais, e o escopo simpli cado.
5.1.1 Requisitos Funcionais
RF1. A ferramenta deve executar um modelo de máquina de estados (clássica, e esten- dida) contra um conjunto de casos de teste.
RF2. A ferramenta deve realizar mutações nos modelos de máquina de estados (clássica, e estendida) através de uma lista de operadores de mutação.
RF3. A ferramenta deve executar um mutante (um modelo de máquina de estados com apenas 1 alteração sintática) contra um conjunto de casos de teste.
RF4. A ferramenta deve capturar as saídas obtidas através da execução de um modelo e armazená-las em um arquivo, o qual possa ser posteriormente consultado. Das informações mais importantes devem constar: estado ativo, último estado ativo, transição ativa, última transição ativa, saída padrão (stdout), saída de erro (stderr). RF5. A ferramenta deve calcular o escore de mutação baseado nas informações das saídas
produzidas pelos mutantes e pelo modelo original.
RF6. A ferramenta deve apresentar um relatório da análise de mutantes, com as seguintes informações: quantos mutantes mortos, quantos mutantes vivos, escore de mutação, quais os mutantes mortos, quais os mutantes vivos.
RF7. A ferramenta deve apresentar os mutantes mortos por um determinado caso de teste (por exemplo, seleciona-se um caso de teste e em seguida são apresentados quais os mutantes que foram mortos pelo caso de teste).
RF8. A ferramenta deve apresentar os casos de teste que mataram um mesmo mutante (por exemplo, seleciona-se um mutante e em seguida é apresentado quais os casos de teste que o matou).
RF9. A ferramenta deve executar a análise de mutantes: gerar mutantes, executar os mutantes e o modelo original, computar as saídas, e gerar os relatórios da análise de mutantes.
RF10. A ferramenta deve permitir a importação dos casos de teste gerados por outras ferramentas de geração de casos de teste (por exemplo, do MOST).
RF11. A ferramenta deve permitir a edição do modelo em modo grá co e modo texto. RF12. A ferramenta deve permitir a edição dos casos de teste.
RF13. A ferramenta deve organizar um teste como um projeto de teste, através de dire- tórios e arquivos.
de nida pelo SMC, na edição textual de modelo.
RF15. O editor grá co da ferramenta deve opcionalmente apresentar a numeração (iden- ti cação) das transições do modelo.
RF16. A ferramenta deve permitir ao usuário escolher dentre os mutantes já gerados quais os mutantes que serão utilizados durante o processo da análise de mutantes. RF17. A ferramenta deve permitir ao usuário escolher dentre os casos de teste quais os
casos de teste que serão utilizados durante o processo da análise de mutantes. RF18. A ferramenta deve permitir a geração de casos de teste através do MOST. RF19. A ferramenta deve permitir total controle do projeto ao usuário, no que diz res-
peito à: criar, excluir, mover e renomear arquivos.
RF20. A ferramenta deve permitir simulação do modelo através da execução dos casos de teste, apresentando o caminho percorrido por determinado caso de teste.
RF21. O editor grá co da ferramenta deve opcionalmente auto organizar o posiciona- mento dos elementos do modelo.
RF22. A ferramenta deve permitir a programação dos testes através de roteiros (por exemplo, ser possível programar a escolha dos casos de teste e dos mutantes, executar e processar as saídas, nalizando com a geração de relatórios de teste).
RF23. A ferramenta deve permitir interromper a execução da análise de mutantes a qualquer momento.
RF24. A ferramenta deve permitir interromper a geração de casos de teste pelo MOST a qualquer momento.
RF25. A ferramenta deve permitir interromper a execução de uma extensão a qualquer momento.
RF26. A ferramenta deve permitir o paralelismo durante as execuções dos modelos, du- rante o processo da análise de mutantes.
RF27. A ferramenta deve permitir o paralelismo durante as execuções dos modelos, du- rante as avaliações realizadas pelo MOST.
RF28. A ferramenta deve apresentar as informações básicas do modelo: quantidade de estados, quantidade de transições, quantidade de transições com guarda, etc.
5.1.2 Requisitos Não Funcionais
RNF1. A ferramenta deve manter o usuário sempre informado das ações que estão sendo realizadas.
RFN2. A ferramenta deve manter os arquivos consistentes em caso de interrupção de alguma tarefa.
RFN3. A ferramenta deve ser independente de plataforma ou de sistema operacional. RFN4. Os projetos devem ser portáveis (por exemplo, um projeto iniciado na ferramenta
executando em um determinado local pode ser aberto na ferramenta executando em outro local).
RFN5. A ferramenta deve manter o usuário informado do tempo esperado para naliza- ção da tarefa de geração de casos de teste.
RFN6. Os arquivos devem estar em um formato texto de fácil entendimento para que possam ser editados também através de outros editores externos.
RFN7. O processo da análise de mutantes deve ser transparente ao usuário (por exemplo, o usuário não precisa saber o que está acontecendo internamente durante a geração, execução e análise).
5.1.3 Escopo Simpli cado
Através da StateMutest é possível criar modelos de máquina de estados, gerar casos de teste para eles, avaliar os conjuntos de casos de teste baseado no critério análise de mutantes, e aplicar os casos de teste gerados contra um modelo.
Depois de con gurados os objetivos de um teste, a execução e análise de mutantes é totalmente automatizada. Todos os mutantes são gerados, compilados e executados automaticamente contra o conjunto de casos de teste.
O processo da análise de mutantes pode demorar dependendo do tamanho do pro- jeto de teste, o qual pode levar um signi cante período de tempo para ser concluído e pode consumir muito dos recursos da máquina, tais como: memória primária, memória secundária, e processador.
Ao término da execução, um relatório contendo informações sobre o teste é gerado e salvo no diretório de resultados do projeto de teste. Um resultado consiste do arquivo de registro de todas as operações realizadas durante o teste, do tempo gasto durante cada tarefa, e dos resultados da análise de mutantes.
A StateMutest lida com projetos de teste, os quais são estruturados em diretórios e arquivos. O projeto pode ser facilmente portado para outros locais, por exemplo, um projeto iniciado no sistema operacional X pode ser portado para o sistema operacional Y, dado que X e Y comportem a execução da máquina virtual Java. Além disso, os arquivos podem ser editados em qualquer editor de texto exigindo apenas da habilidade e do conhecimento do testador em respeitar a estrutura dos arquivos. A organização do teste baseado em projeto de teste foi inspirada nos projetos criados em ambientes
Figura 5.1: Arquitetura Geral da StateMutest.
de desenvolvimento de software, tal como NetBeans (https://netbeans.org/) e Eclipse (https://eclipse.org/).