Apresentacao teste

536 visualizações

Publicada em

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
536
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
15
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Apresentacao teste

  1. 1. Teste de Software X Métodos Formais José Amancio
  2. 2. Introdução  Discussão sobre testes  Testes formais  Ferramenta
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 33. Conceitos abordados no Framework  Conformidade  Observações e testes  Testes de conformidade  Suas extensões
  34. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 47. Testes de Conformidade
  48. 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. 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. 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

×