Teste de Software X
Métodos Formais
José Amancio
Introdução

Discussão sobre testes

Testes formais

Ferramenta
Introdução


Teste é uma forma operacional de checar a
corretude de um sistema através de
experimentos
Realizar execuções de um sistema com base
em determinados critérios



Linhas de execuções, valores de dados,
funcionalidades, etc.
Comparar os resultados das execuções com
uma especificação
Veredito: ok ou não
Introdução
Discussão: onde está a ligação entre
testes e métodos formais ?
 Alguns autores não consideram o uso
de testes como sendo aplicação de
métodos formais
 Não é uma técnica exaustiva que
garanta cobrir todos os possíveis erros

Introdução
Provê menos garantias do que
verificação de modelos, por exemplo
 Não é possível testar todas as linhas de
execução
 Com testes é possível detectar a
existência, mas não é possível garantir
a ausência de erros

Vantagens

Técnicas mais “precisas” custam caro






Inserção de novas linguagens
Difícil sincronização de modelos com código
Requerem mais especialização por parte dos
projetistas/programadores
Testes são aplicados diretamente sobre o
programa
Simples e prático: pode-se usar uma
heurística simples para definir o que testar
Apresenta a melhor relação custo/benefício
na busca pela melhoria da qualidade de um
software
Tipos de Testes

Existem diferentes formas de classificar
testes

Considerando características do sistema


Comportamento, nível de abstração
Considerando estratégia do teste

Teste caixa-preta, white-box
Tipos de Testes

Diferentes níveis de abstração



Teste de unidade: o mais baixo nível de
teste. Pequenas partes do código são
testadas separadamente
Teste de integração: testa se diferentes
partes do código trabalham bem juntas
Teste de sistema: testa o sistema como um
todo
Tipos de Testes

Diferentes níveis de abstração


Teste de aceitação: usualmente feito pelo
cliente para checar se o sistema está de
acordo
Teste de regressão: aplicação de testes
depois de alguma alteração para verificar
se o sistema continua funcionando
corretamente
Tipos de Testes

Diferentes aspectos do comportamento


Teste funcional ou de conformidade: o
sistema faz o que deveria fazer ? Ou seja,
está de acordo com a especificação ?
Teste de performance: o sistema executa
em tempo aceitável ?
Tipos de Testes

Diferentes aspectos do comportamento


Teste de robustez: como o sistema reage
se seu ambiente apresentar
comportamento estranho ou indesejado ?
Teste de stress: como o sistema reage em
condições extremas ? Com um número
grande de usuários ou com grande
quantidade de dados ?
Tipos de Testes

Diferentes aspectos do comportamento


Teste de confiabilidade: quanto podemos
contar com o correto funcionamento do
sistema ?
Teste de disponibilidade: qual a
disponibilidade do sistema ?
Tipos de Testes

Estratégias de teste

Caixa-preta


White-box


Apenas a estrutura externa do sistema é
conhecida
A estrutura interna (código) do sistema é
conhecida e usada pelo testador
Grey-box

Quando parte do código é conhecido
O Processo de Teste

Duas fases principais

Geração de teste




Envolve análise da especificação e determinação de que
funcionalidade será testada
Determinação de como será executado o teste
Especificação de scripts de teste
Execução de teste



Desenvolvimento de um ambiente de teste em que o
script pode ser executado
Execução do script de teste
Análise dos resultados
O Processo de Teste

Outras fases

Gerenciamento e manutenção
Objetivo de possibilitar aplicação de testes
durante a existência do sistema
 Manter scripts, controle de versões de
especificações de testes, ferramentas para
teste

Automação
Necessário uso de ferramentas de
suporte
 Tipos de ferramentas de teste


Record & Play
Registram ações de usuários na interface
(através de mouse e teclado) e permitem
repetir as operações
 Para testes de aceitação, por exemplo


Geração de grandes quantidades de dados

Para testes de stress
Automação

Tipos de ferramentas de teste

Geração de casos de testes baseados em
uma especificação formal


Para testes funcionais
Cobertura de código

Calculam o percentual do código executado
durante o teste com base em critérios


Caminhos percorridos, variáveis percorridas,
comandos percorridos, etc.
Para testes white-box
Utilização de Testes

Em muitos casos, na prática, testes têm
sido utilizados de maneira intuitiva



Os casos de teste não são definidos com
base em uma metodologia rigorosa
Programadores definem e executam os
testes
Porém existem muitas pesquisas na
área a fim de possibilitar o retorno de
resultados mais confiáveis
Utilização de Testes

Há um custo associado à aplicação de
testes de forma sistemática



Equipe de testadores
Utilização de ferramentas
Tempo para implementação/execução de
testes
Testes X Métodos Formais

Apesar dos custos, teste é a mais
“barata” e mais utilizada técnica de
validação de sistemas


“Sempre” é utilizada
Além disso, a prática de
desenvolvimento de software
atualmente exige processos confiáveis
Testes X Métodos Formais
É precisamos de melhorar a qualidade
do software
 Isso acontece através da aplicação de
técnicas de validação com certo nível de
rigor
 Testes + base matemática

Testes X Métodos Formais

Testes formais

Geração de casos de testes a partir de
especificações formais



Inserir especificações formais para utilizarmos testes
Adotar especificações formais utilizadas em outras
técnicas de verificação formal que estejam sendo
aplicadas
Análise de cobertura de código

Avaliação do percentual de código executado fornece
maior confiabilidade com base em argumentos formais
Testes Withe-box



Em testes de unidade, um caso de teste
corresponde a um caminho de execução
Quase nunca é possível checar todas as
situações com todos os valores possíveis
Testes são feitos com base em critérios de
cobertura

Permite executar menos casos de testes com
maior probabilidade de encontrar erros
Testes Withe-box

Cobertura de statements


Cada comando executável (atribuição,
entrada, saída, etc) aparece em pelo
menos um caso de teste
Cobertura de “caminho”

Cada caminho executável aparece em
algum caso de teste
Testes Withe-box

Cobertura de condição


Cada predicado aparece em um caso de
teste avaliado para true
Cobertura de caminho/condição

Requer que, tanto os caminhos como a
condição sejam cobertas
Testes Withe-box

Cobertura de condição múltipla


Cada combinação de predicados deve
aparecer no conjunto de casos de teste
Cobertura de caminhos executáveis

Requer que todos os caminhos executáveis
sejam considerados nos casos de teste
Testes Withe-box

Exemplo
y=y+1
y=y+1
se x = y e z > w
x = x –1
x=yez>w
verdade
x = x -1
falso
Testes Withe-box

Cobertura de statements


Cobertura de caminho



{x=2, y=2, z=4, w=3}
{x=2, y=2, z=4, w=3}
{x=3, y=3, z=5, w=7}
Cobertura de condição


{x=3, y=3, z=5, w=7}
{x=3, y=4, z=7, w=5}
Testes Withe-box

Cobertura de caminho/condição




{x=2, y=2, z=4, w=3}
{x=3, y=3, z=5, w=7}
{x=3, y=4, z=7, w=5}
Cobertura de condição múltipla




{x=2,
{x=3,
{x=3,
{x=3,
y=2,
y=3,
y=4,
y=4,
z=4, w=3}
z=5, w=7}
z=7, w=5}
z=5, w=6}
Testes Withe-box

Determinados critérios englobam incorporam
outros



Cobertura de caminho engloba cobertura de
statements
Cobertura de caminho/condição engloba cobertura
de caminho
Temos agora formas de medir cobertura e
inferir confiabilidade dos casos de testes


Chances de implementar um conjunto menor de
casos de testes com maior probabilidade de
encontrar erros
Pelo menos temos uma chance de avaliar o nível
de confiabilidade dos casos de teste
Testes Caixa-preta
Comumente chamado de teste funcional
ou teste de conformidade
 Não há conhecimento da estrutura
interna do sistema




Temos apenas o sistema
E esperamos dele um determinado
comportamento
Como associar estratégias deste tipo a
métodos formais ?
Testes Caixa-preta




Framework para testes baseado em
especificações formais (Jan Tretmans)
É apresentado um framework para uso de
métodos formais em testes de conformidade
Testar o comportamento com relação à
especificação formal do sistema
O mais importante é que liga o mundo
informal das implementações, testes e
experimentações com o mundo formal das
especificações e modelos
Conceitos abordados no
Framework
Conformidade
 Observações e testes
 Testes de conformidade
 Suas extensões

Conformidade
Necessitamos
de implementações e
especificações
As especificações são formais. Universo
de especificações é denotado por
SPECS
Implementações são os sistemas que
iremos testar. Denotamos por IUT
IMPS é o conjunto de todos os IUTs
Conformidade
 IMPS X SPECS, assim
IUT conforms-to s expressa que IUT é
uma correta implementação da
especificação s.
Implementações são objetos físicos,
diferente das especificações. Não
possibilitam argumentação formal:
dificulta definir conforms-to
conforms-to
Conformidade
que todo IUT  IMPS pode
ser modelado por um objeto formal Iiut
 MODS, onde MODS é o universo de
modelos
Isso é chamado como hipóteses de teste
Observação:a hipótese de teste apenas
assume que um modelo Iiut existe, mas
não que ele é conhecido a priori
Assumimos
Hipóteses de teste
 Permite
argumentar sobre implementações
como se elas fossem objetos formais
 Assim podemos expressar conformidade
através de uma relação formal entre modelos
de implementações e especificações
 A relação de implementação será chamada de
imp  MODS X SPECS
Hipóteses de teste
 IMPS é dita correta com relação
a s  SPECS (IUT conforms-to s), sss
Iiut  MODS de IUT é imprelacionada com s
IUT

Iiut imp s
Observações e Testes
O comportamento de uma IUT é
investigado fazendo experimentos na
implementação e observando as suas
reações
 A especificação do experimento é um
caso de teste e a implementação é
chamada de execução de teste

Casos de Testes e Execução
de Testes
Considere
casos de testes formalmente
pertencentes a um domínio TESTS
Requer um procedimento para executar um
caso de teste t a uma IUT
Denotada por EXEC(t,IUT)
Casos de Testes e Execução
de Testes
O
que acontece durante a execução ?
A execução de um teste irá levar em um
conjunto de observações, subconjunto de
OBS
Função de observação:
obs: TESTS X MODS  P(OBS)
 obs(t, Iiut) modela formalmente a execução
do teste real EXEC(t, IUT)

Hipóteses de Testes
 Seu
 Para
significado:
todas as implementações reais que
estamos testando, assume-se que existe um
modelo, tal que se colocássemos a
implementação e o modelo em caixas pretas
e fizéssemos todos os experimentos possíveis
em TESTS, não conseguiríamos distinguir
entre a implementação real e o modelo
Funções de Veredito vt

Usualmente interpretamos observações de
testes em termos de certo ou errado
vt: P(OBS)  {fail, pass}

Podemos então introduzir a abreviação
Funções de Veredito vt


Isso é extendido como uma suíte de testes:
Uma implementação falha em uma suíte de
testes se ela não passa:
Testes de Conformidade

Envolve saber se uma implementação
está conforme com respeito a uma
relação de implementação imp com sua
especificação

Uma suíte de testes com essa
propriedade é chamada completa
Testes de Conformidade




É possível distinguir entre as implementações
conformes e não-conformes
É um requerimento muito forte para Testes
práticos
Precisamos enfraquecer esta declaração
Sound (parece completa) – toda
implementação correta, e possivelmente
alguma implementação incorreta será aceita
Testes de Conformidade
Testes de Conformidade

Se a propriedade de completude for
provada no nível dos modelos, e se
assumimos que as hipóteses de testes
valem:

a conformidade de uma implementação
com respeito a sua especificação pode ser
decidida por meio de um procedimento de
testes
Derivação de testes
Então,
uma atividade importante passa
a ser construir algoritmos que produzem
suítes de testes sound e/ou completos a
partir de uma especificação e de uma
relação de implementação
Extensões
Arquitetura de testes: define o
ambiente no qual uma implementação é
testada
 Introdução da técnica de cobertura: a
cada implementação errônea detectada
por uma suíte de testes, é atribuído um
valor e depois esses valores são
integrados
