Teste de Software X Métodos Formais

Apresentação em tema: "Teste de Software X Métodos Formais"— Transcrição da apresentação:

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 White-box Grey-box
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 Cobertura de “caminho”
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 Cobertura de caminho/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
verdade falso x = x -1

28 Testes Withe-box Cobertura de statements Cobertura de caminho
{x=2, y=2, z=4, w=3} Cobertura de caminho {x=3, y=3, z=5, w=7} Cobertura de condição {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=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