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 Apenas a estrutura externa do sistema é
conhecida White-box
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 + 1se x = y e z > w
x = x –1
y = y + 1
x = y e z > w
x = x -1
verdade falso
Testes Withe-box Cobertura de statements
{x=2, y=2, z=4, w=3} Cobertura de caminho
{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, y=2, z=4, w=3} {x=3, y=3, z=5, w=7} {x=3, y=4, z=7, w=5} {x=3, y=4, 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
ConformidadeNecessitamos 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
Conformidadeconforms-to 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
ConformidadeAssumimos 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
Hipóteses de testePermite 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 testeIUT IMPS é dita correta com relação a s SPECS (IUT conforms-to s), sss Iiut MODS de IUT é imp-relacionada com s
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 TestesSeu significado:
Para 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 erradovt: 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 testesEntã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