Teste de Software X 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 verdade falso x = x -1

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, ondeMODS é 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 (IUTconforms-tos), 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