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

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

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

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 verdade falso x = x -1

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}

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}

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: obs: 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