• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Apresentacao teste

on

  • 499 views

 

Statistics

Views

Total Views
499
Views on SlideShare
499
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Apresentacao teste Apresentacao teste Presentation Transcript

    • 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 + 1
      • se 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
    • 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
      • 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
    • 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
    • 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
      • 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
    • 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:
        • o bs: TESTS X MODS  P(OBS)
        • obs(t, Iiut) modela formalmente a execução do teste real EXEC(t, IUT)
    • 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
    • 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