Teste Baseado em Modelos

Notas de Teste de Software - Parte 4 Teste Baseado em Modelos

O principal objetivo do software é cumprir os requisitos para o qual foi construído, por conta de diversos erros na fase de elicitação é muito comum encontrar requisitos ambíguos, incompletos e vagos, o que aumenta o custo de reparo nas fases seguintes do seu processo de construção. Neste caso, um modelo pode expressar diversas características de um software, desde os seus conceitos, propriedades, relações e restrições. Também, a partir de um modelo é possível melhorar o entendimento sobre os requisitos e automatizar a geração de código.

No âmbito das atividades de teste de software, que geralmente custam 45% do total do projeto, criar testes baseados em modelos pode ser bastante interessante. A partir da especificação é criado um modelo (representação do funcionamento de um software) que pode ser externalizado através de uma MEF (Máquina de Estados Finitos). 

As vantagens da abordagem é que a geração de testes começa mais cedo no ciclo do desenvolvimento e pode-se criar casos de teste automaticamente a partir do modelo. Os casos de teste podem ser representados através de árvores de decisão, statecharts, ontologias de domínio ou diagramas de casos de uso e/ou estados da UML (Unified Modeling Language). 

Um modelo é composto por estados, transições e ações. Os estados armazenam informações sobre o passado, as transições indicam mudanças de estado e as ações representam as atividades que podem ser realizadas em um determinado momento. Dessa forma, com um conjunto de estados finito é possível responder a quase todas as perguntas sobre um sistema e a geração de casos de teste é baseada em sequências (e.g. sequência de sincronização e distinção) para verificar a consistência dos estados. 

Figura 1- Sequência de Sincronização.

De acordo com a Figura 1 é possível vislumbrar como seria uma atividade típica de teste baseado em modelo:  Para chegar ao estado S2 aplique a sequência a/x- a/x;  Aplique a entrada b; Verifique a saída y; Verifique se a máquina está no estado S3;

No caso da Figura 1, para perfazer a cobertura de todos os estados pode-se derivar os casos de teste a partir da sequência : a/x – a/x – b/y – b/x.  A sequência de sincronização pode ser utilizada para garantir que a MEF vá para um estado particular, neste caso, se ocorrer divergência, possivelmente há um defeito. A sequência de distinção serve para identificar uma saída diferente para cada estado. A Tabela 1 demonstra através de uma tabela como seriam as saídas através de uma sequência de distinção. É possível observar que as saídas são distintas para cada estados. 

Estado	Saída
S0	x _
S1	x y
S2	_y
S3	_ x

Tabela 1 – Exempo de Sequência de Distinção.

Diversos métodos podem ser utilizados para criar casos de testes, incluindo: método TT, método UIO, método DS, método W. O método TT (Transition Tour) parte do estado inicial e atravessa todas as transições pelo menos uma vez e retorna ao estado inicial, pode ser utilizado para detectar erros de saída. O método UIO (Unique Input e Output) identifica o estado e uma sequência de entrada que pode levar a uma determinada saída (exemplo ao lado da Figura 1). 

Uma desvantagem deste método é que não garante a cobertura de todas as transições como no método anterior. O método DS (Distinct Sequence) utiliza sequências distintas como dados de teste para verificar as saídas de cada estado, conforme visto na Tabela 1. O problema é que uma sequência distinta nem sempre pode ser encontrada em uma MEF. Já o método W pode ser utilizado para encontrar defeitos estruturais sempre que uma MEF for completa, mínima e fortemente conectada. 

Em relação ao métodos vistos é possível realizar uma rápida comparação para conhecer os requisitos de uma MEF para empregá-los (Tabela 2):

	TT	UIO	DS	W
MEF Mínima		X	X	X
Completamente Especificada		X	X	X
Fortemente Conectada		X	X	X
Máquina Mealy		X	X	X
Determinismo	X	X	X	X
Sequências de Sincronização			X
Sequências de Distinção			X
Sequências Únicas de Entrada e Saída		X
Conjunto de Caracterização				X

Tabela 2 – Comparação do Métodos.

Conforme a Tabela 2 todos os métodos vistos necessitam que a MEF seja mínima, completamente especificada, fortemente conectada, seja um modelo derivado da máquina de Mealy e que sempre haja determinísmo. Por conta desses requisitos estritos, o teste baseado em modelo, por ter em sua essência a representação baseada em MEF, não é muito utilizado. 

Se houvesse outras abordagem que facilitassem a representação, verificação e validação do modelo diante da especificação (e.g. ontologia de domínio e inferências usando dedução automática) o teste baseado em modelos poderia ser largamente utilizado na indústria, pois entre as diversas vantagens da abordagem, é possível corrigir ambiguidades e incompletudes dos requisitos na fase de análise, principal motivo dos fracassos dos projetos de software. Também, a dificuldade da geração automática de casos e dados de teste consonante com o domínio da aplicação é um grande entrave para redução dos custos no processo de desenvolvimento de softwares modernos quando da utilização de outros critérios, a exemplo dos critérios funcionais e estruturais.