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.

Read More

Teste de Mutação

Notas de Teste de Software - Parte 3 Teste de Mutação

O teste de mutação é uma técnica baseada em defeitos, cuja vantagem diante das técnicas de teste funcional e estrutural é a possibilidade de se estabelecer uma relação direta entre um subdomínio e a possibilidade de se encontrar defeitos. Apesar dessa relação direta, ainda podem existir casos de testes correspondentes que levem ou não o programa a falhar, como consequência, um defeito pode não ser revelado. Com o uso da técnica de teste baseada em defeitos utiliza-se os defeitos típicos do processo de desenvolvimento cometidos por desenvolvedores, onde o objetivo é injetar defeitos e verificar se os casos de teste são capazes de descobrí-los. Uma das abordagens é a aplicação do teste de mutação. 

O teste de mutação requer a criação de diversos programas (mutantes) derivados a partir de um programa original relativamente correto. Segundo Howden, a definição de correção pode ser dada por: "Um programa P é correto em relação a uma função F se P computa F". 

Para provar a correção é criado então um conjunto de casos de testes confiável, sendo: "Um conjunto de teste T confiável para um programa P e uma função F, dada a existência coincidente de P e F em T e se P computa F, caso contrário, deve haver um ponto t tal que F(t) seja ≠ P(t)".

Outra definição pragmática é derivar programas alternativos a partir de P formando um conjunto M={M1, M2, M3...Mn} denominados mutantes. Os programas mutantes contém defeitos introduzidos através de pequenas alterações (operadores de mutação) para serem testados. O testador verifica os programas mutantes em relação a execução dos testes, eliminado-os progressivamente ao detectar o comportamento incorreto, o que é o esperado.  

Em geral, os passos para execução podem ser dividos em:

• Execução de um conjunto de testes T no programa original P, se ocorrer uma falha o teste termina.
• São gerados os programas mutantes com operadores de mutação a partir de um P correto.
• Os mutantes são executados com o mesmo conjunto de testes T.
• Através de uma análise, é possível quantificar os mutantes vivos, mortos, equivalentes e reveladores de defeito.

Os mutantes mortos possuem os resultados dos testes diferentes de P e os vivos devem ser equivalentes a P, se não forem, podem ajudar a expor a fraqueza dos casos de teste. Se para algum caso de teste t tal que P(t) ≠ M(t), pode-se concluir que P(t) não está de acordo com a especificação, neste caso a presença de um defeito pode ter sido revelada. Uma forma de medir a adequação de T em relação ao teste de mutação é o escore de mutação:

DM(P,T) -  Número de mutantes mortos por T; M(P) – Total de mutantes gerados; EM(P) – Número de mutantes equivalentes a P;

Uma desvantagem da análise de mutantes é que são gerados muitos mutantes. Também, estes precisam ser compilados e executados, assim há também a necessidade de se conhecer o código-fonte do programa. Apesar das desvantagens, é um dos critérios mais eficazes para encontrar defeitos.

Read More

Teste Estrutural

Notas de Teste de Software - Parte 2 Teste Estrutural

Benefícios:

• Os critérios de teste em geral possuem uma abordagem sistemática e teoricamente fundamentada para conduzir uma atividade de teste. Aumentam a garantia de que os casos de testes irão revelar defeitos. Cada técnica depende da origem dos dados para criar os casos de testes. A técnica estrutural tem como base a implementação. 
• Complementa outras técnicas: depuração, manutenção e avaliação da confiabilidade.

Limitações:

• Não existe um procedimento de teste de proprósito geral para provar a correção de um programa. É indecidível se dois ou mais programas computam a mesma função; se dois caminhos de um mesmo programa, ou de programas diferentes, computam a mesma função; e se um dado caminho é executável e se existe um conjunto de dados de entrada que leve à execução desse caminho.
• Caminhos ausentes durante a execução do teste e correção coincidente.

Geralmente o teste estrutural é representado utilizando um Grafo de Fluxo de Controle (GFC).

Diretrizes
Caminho	seqüência de vértices conectados por arestas.
Caminho Simples	Caminho em que um nó não se repete, exceto o primeiro e último.
Caminho Livre de Laço	Caminho em que um nó não se repete.
Caminho Completo	caminho que inicia no nó de entrada e termina em um nó de saída.
Caminho não executável	Se existe algum nó ou vertice não executado de acordo com um dado de entrada.
Caminho Livre de Definição	Não contém redefinição uma varíavel ao longo do caminho
Definição Global	Ou contém um caminho livre de definição para um nó ou existe C-USO ou P-USO da varíavel em um arco.

Definições

C-USO – uso computacional

P-USO – uso predicativo

USO- quando a referência não define valor a uma variável

Indefinição – Quando variável não tem referência à memória.

(2,3,4,5,6,7) caminho simples e livre de laços. (1,2,3,4,5,7,4,8,9,11) caminho completo. (1,3,4,8,9) caminho não executável.

• Todos-Nós  exige que a execução do programa passe, ao menos uma vez, em cada vértice do grafo de fluxo, ou seja, que cada comando do programa seja executado pelo menos uma vez.

• Todos-Arcos requer que cada aresta do grafo, ou seja, cada desvio de fluxo de controle do programa, seja exercitada pelo menos uma vez.

• Todos-Caminhos requer que todos os caminhos possíveis do programa sejam executados. 

• Todas-Definições: requer que cada definição de variável seja exercitada pelo menos uma vez, não importa se por um c-uso ou por um p-uso.

• Todos-Usos: requer que todas as associações entre uma definição de variável e seus subseqüentes usos (c-usos e p-usos) sejam exercitadas pelos casos de teste, através de pelo menos um caminho livre de definição, ou seja, um caminho onde a variável não é redefinida.

Teste estrutural pode ser aplicado para teste de unidade pelo próprio desenvolvedor entre as fases e caminhos dentro das unidades, entre as unidades, subsistemas e sistemas.

Teste Estrutural – Teste de Fluxo de Dados

• Teste de fluxo de dados possui intenção de revelar defeitos em decorrência de valores incorretos na codificação.

• Princípio da definição dos critérios: sequência das ações realizadas sobre as variáveis mais onde elas são definidas e utilizadas.

Anomalias do Fluxo de Dados

Uso de variável não inicializada.

Atribuição de valor a uma variável mais de uma vez sem que tenha havido uma referência a essa variável entre essas atribuições.

Liberação ou reinicialização de uma variável antes que ela tenha sido criada ou inicializada.

Liberação ou reinicialização de uma variável antes que ela tenha sido usada.

Atribuir novo valor a um ponteiro sem que a variável tenha sido liberada.

Notação	Significado
~	Não existe variável
d	Definição da variável
u	Uso da variável
K	Destruição da variável
~d	Variável não existe e é definida (correto)
~u	Variável não existe e é usada (incorreto)
~k	Variávelnão existe e é destruída
dd	Definida e redefinida (incorreto se global)
du	Definida e usada (correto)
dk	Definida e destruída (incorreto)
ud	Usada e definida (aceitável)
uu	Usada e reusada (aceitável)
uk	Usada e destruída (aceitável)
kd	Destruída e redefinida (aceitável)
ku	Destruída e usada (incorreto)
Kk	Destruída e destruída novamente (incorreto)

Diretrizes
c-use(i)	Variáveis com uso global no bloco i
def(i)	Variáveis com definição global no bloco i
p-use(i,j)	Variáveis com p-usos no arco i,j
dcu(x,i)	Existe um caminho livre de definição do nó i até nó j
dpu(x,i)	Existe um caminho livre de definição do nó i até arco j
du-caminho(x)	Existe uma definição global de x, (tem um c-uso e existe um caminho simples livre de definição) ou (existe um p-uso e existe um caminho livre de definição e livre de laço.
Associação definição c-uso	é uma tripla (i,j,x) onde i é um nó que contém uma definição global de x e j pertence a dcu(x,i)
Associação definição p-uso	é uma tripla (i,(j,k),x) onde i é um nó que contém uma definição global de x e j pertence a dpu(x,i)
TodasDefinições	requer que cada definição de variável seja exercitada pelo menos uma vez, não importa se por um c-uso ou por um p-uso.
TodosUsos	requer que todas as associações entre uma definição de variável e seus subsequentes usos (c-usos e p-usos) sejam exercitadas pelos casos de teste, através de pelo menos um caminho livre de definição, ou seja, um caminho onde a variável não é redefinida.
TodosDuCaminhos	requer que toda associação entre uma definição de variável e subsequentes p-usos ou c-usos dessa variável seja exercitada por todos os caminhos livres de definição e livres de laço que cubram essa associação.
Associação definição-uso	é uma tripla (var,def,uso) onde var é uma variável com a definição-uso, def é um nó que contém uma definição de var e uso contém um nó ou arco com c-uso ou p-uso de var.
Potencial-associação	Associações são estabelecidas sem a necessidade de um uso explícito.
Potencial definição-uso	é uma tripla (var,def,uso) onde var é uma variável com a definição-uso, def é um nó que contém uma definição de var e uso c-uso ou p-uso possível de var em um nó ou arco.

               

Preenchem a lacuna entre os critérios GFC todos os nós e todos os arcos, porque considera a inclusão de todos os usos (c-usos e p-usos) das variáveis.

Read More

Aluno, subproduto acadêmico

É muito triste o que venho acompanhando desde os alunos de graduação, mestrado, doutorado e pesquisadores nos últimos anos. Antes eu olhava professores com toc, depressivos, isolados socialmente e não entendia muito bem a causa, mas acompanhando de perto percebo que o sistema pode acabar com as suas vidas e isso é muito sério.

Olha o que houve no ITA - Instituto Tecnológico de Aeronáutica dois dias atrás

Já tive contato direto com professores completamente equivocados da sua vocação, fechados em seu mundo de publicações e extremamente arrogantes. Também já observei alunos sendo influenciados para competir uns com os outros, além de completamente anti-sociais. Um caso chamou muito a minha atenção, um aluno de doutorado com excelentes publicações e apresentava muito bem, só que magérrimo, com toc e mal conseguia falar com as pessoas, parecia realmente nunca ter tido uma namorada.

Eu sempre me perguntava porque a vida acadêmica molda tantos os alunos, isolando-os da sociedade e interferindo muito na sua vida pessoal. É como se existisse um outro mundo, onde os alunos são acreditados por valores que sobrepõe até as necessidades mais básicas do ser humano. Pelo que tenho visto o próprio sistema implantado nas universidades federais realiza essa perversidade, uma vez que muitos professores nem se reconhecem reféns em seu modo de pensar e agir e repetem todo o ritual por gerações.

É uma questão muito séria, porque de um certo modo as universidades estão transformando os adolescentes cheios de vida, com muitas perspectivas e sonhos em pessoas doentes, o que influencia diretamente a sua vida e as pessoas a sua volta. O aluno é moldado a se tornar um subproduto acadêmico e não um indivíduo mais completo do ponto de vista social. É preciso chamar atenção dos educadores para essa situação nas universidades urgentemente.

Read More