Teste de Software X Mtodos Formais Jos Amancio

Teste de Software X Métodos Formais José Amancio

Introdução n Discussão sobre testes n Testes formais n Ferramenta

Introdução n n 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 n n n 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 ? n Alguns autores não consideram o uso de testes como sendo aplicação de métodos formais n Não é uma técnica exaustiva que garanta cobrir todos os possíveis erros n

Introdução Provê menos garantias do que verificação de modelos, por exemplo n Não é possível testar todas as linhas de execução n Com testes é possível detectar a existência, mas não é possível garantir a ausência de erros n

Vantagens n Técnicas mais “precisas” custam caro n n n 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 n Existem diferentes formas de classificar testes n Considerando características do sistema n n Comportamento, nível de abstração Considerando estratégia do teste n Teste caixa-preta, white-box

Tipos de Testes n Diferentes níveis de abstração n n n 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 n Diferentes níveis de abstração n n 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 n Diferentes aspectos do comportamento n n 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 n Diferentes aspectos do comportamento n n 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 n Diferentes aspectos do comportamento n n Teste de confiabilidade: quanto podemos contar com o correto funcionamento do sistema ? Teste de disponibilidade: qual a disponibilidade do sistema ?

Tipos de Testes n Estratégias de teste n Caixa-preta n n White-box n n Apenas a estrutura externa do sistema é conhecida A estrutura interna (código) do sistema é conhecida e usada pelo testador Grey-box n Quando parte do código é conhecido

O Processo de Teste n Duas fases principais n Geração de teste n n 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 n n n 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 n Outras fases n Gerenciamento e manutenção Objetivo de possibilitar aplicação de testes durante a existência do sistema n Manter scripts, controle de versões de especificações de testes, ferramentas para teste n

Automação Necessário uso de ferramentas de suporte n Tipos de ferramentas de teste n n Record & Play Registram ações de usuários na interface (através de mouse e teclado) e permitem repetir as operações n Para testes de aceitação, por exemplo n n Geração de grandes quantidades de dados n Para testes de stress

Automação n Tipos de ferramentas de teste n Geração de casos de testes baseados em uma especificação formal n n Para testes funcionais Cobertura de código n Calculam o percentual do código executado durante o teste com base em critérios n n Caminhos percorridos, variáveis percorridas, comandos percorridos, etc. Para testes white-box

Utilização de Testes n Em muitos casos, na prática, testes têm sido utilizados de maneira intuitiva n n n 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 n Há um custo associado à aplicação de testes de forma sistemática n n n Equipe de testadores Utilização de ferramentas Tempo para implementação/execução de testes

Testes X Métodos Formais n Apesar dos custos, teste é a mais “barata” e mais utilizada técnica de validação de sistemas n n “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 n Isso acontece através da aplicação de técnicas de validação com certo nível de rigor n Testes + base matemática n

Testes X Métodos Formais n Testes formais n Geração de casos de testes a partir de especificações formais n n n 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 n Avaliação do percentual de código executado fornece maior confiabilidade com base em argumentos formais

Testes Withe-box n n n 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 n Permite executar menos casos de testes com maior probabilidade de encontrar erros

Testes Withe-box n Cobertura de statements n n Cada comando executável (atribuição, entrada, saída, etc) aparece em pelo menos um caso de teste Cobertura de “caminho” n Cada caminho executável aparece em algum caso de teste

Testes Withe-box n Cobertura de condição n n Cada predicado aparece em um caso de teste avaliado para true Cobertura de caminho/condição n Requer que, tanto os caminhos como a condição sejam cobertas

Testes Withe-box n Cobertura de condição múltipla n n Cada combinação de predicados deve aparecer no conjunto de casos de teste Cobertura de caminhos executáveis n Requer que todos os caminhos executáveis sejam considerados nos casos de teste

Testes Withe-box n Exemplo y=y+1 se x = y e z > w x = x – 1 x=yez>w verdade x = x -1 falso

Testes Withe-box n Cobertura de statements n n Cobertura de caminho n n n {x=2, y=2, z=4, w=3} {x=3, y=3, z=5, w=7} Cobertura de condição n n {x=3, y=3, z=5, w=7} {x=3, y=4, z=7, w=5}

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

Testes Withe-box n Determinados critérios englobam incorporam outros n n n 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 n n 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 Não há conhecimento da estrutura interna do sistema n n Temos apenas o sistema E esperamos dele um determinado comportamento Como associar estratégias deste tipo a métodos formais ?

Testes Caixa-preta n n 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 n Observações e testes n Testes de conformidade n Suas extensões n

Conformidade n. Necessitamos de implementações e especificações n. As especificações são formais. Universo de especificações é denotado por SPECS n. Implementações são os sistemas que iremos testar. Denotamos por IUT n. IMPS é o conjunto de todos os IUTs

Conformidade IMPS X SPECS, assim n. IUT conforms-to s expressa que IUT é uma correta implementação da especificação s. n. Implementações são objetos físicos, diferente das especificações. Não possibilitam argumentação formal: dificulta definir conforms-to nconforms-to

Conformidade que todo IUT IMPS pode ser modelado por um objeto formal Iiut MODS, onde MODS é o universo de modelos n. Isso é chamado como hipóteses de teste n. Observação: a hipótese de teste apenas assume que um modelo Iiut existe, mas não que ele é conhecido a priori n. Assumimos

Hipóteses de teste n Permite argumentar sobre implementações como se elas fossem objetos formais n Assim podemos expressar conformidade através de uma relação formal entre modelos de implementações e especificações n A relação de implementação será chamada de imp MODS X SPECS

Hipóteses de teste IMPS é dita correta com relação a s SPECS (IUT conforms-to s), sss Iiut MODS de IUT é imprelacionada com s n. IUT n Iiut imp s

Observações e Testes O comportamento de uma IUT é investigado fazendo experimentos na implementação e observando as suas reações n A especificação do experimento é um caso de teste e a implementação é chamada de execução de teste n

Casos de Testes e Execução de Testes n. Considere casos de testes formalmente pertencentes a um domínio TESTS n. Requer um procedimento para executar um caso de teste t a uma IUT n. Denotada por EXEC(t, IUT)

Casos de Testes e Execução de Testes n. O que acontece durante a execução ? n. A execução de um teste irá levar em um conjunto de observações, subconjunto de OBS n. Função de observação: obs: TESTS X MODS P(OBS) n obs(t, Iiut) modela formalmente a execução do teste real EXEC(t, IUT) n

Hipóteses de Testes n Seu significado: n 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 n Usualmente interpretamos observações de testes em termos de certo ou errado vt: P(OBS) {fail, pass} n Podemos então introduzir a abreviação

Funções de Veredito vt n Isso é extendido como uma suíte de testes: n Uma implementação falha em uma suíte de testes se ela não passa:

Testes de Conformidade n Envolve saber se uma implementação está conforme com respeito a uma relação de implementação imp com sua especificação n Uma suíte de testes com essa propriedade é chamada completa

Testes de Conformidade n n É 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 n Se a propriedade de completude for provada no nível dos modelos, e se assumimos que as hipóteses de testes valem: n 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 n. 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 n 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 n