O documento discute testes de software, introduzindo conceitos como testes formais, tipos de testes (unidade, integração, sistema, aceitação, regressão), aspectos do comportamento testado (funcionalidade, performance, robustez, confiabilidade, disponibilidade) e estratégias de teste (caixa-preta, white-box, grey-box). Também aborda o processo de teste, automação, utilização de testes e a relação entre testes e métodos formais.

1. Teste de Software X
Métodos Formais
José Amancio

2. Introdução
 Discussão sobre testes
 Testes formais
 Ferramenta

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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 ?

11. 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 ?

12. 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 ?

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. Testes Withe-box
 Exemplo
y = y + 1
se x = y e z > w
x = x –1
y = y + 1
x = y e z > w
x = x -1
verdade falso

28. 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}

29. 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}

30. 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

31. 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 ?

32. 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

33. Conceitos abordados no
Framework
 Conformidade
 Observações e testes
 Testes de conformidade
 Suas extensões

34. 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

35. Conformidade
conforms-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

36. Conformidade
Assumimos 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

37. 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

38. Hipóteses de teste
IUT ∈ 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

39. 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

40. 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)

41. 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)

42. Hipóteses de Testes
Seu 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

43. 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

44. 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:

45. 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

46. 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

47. Testes de Conformidade

48. 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

49. 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

50. 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