3ª Parte Técnicas de Teste

Transcrição

1 3ª Parte Técnicas de Teste ü Técnicas de Teste Técnicas de Teste Ø Têm como objetivo auxiliar a detecção do maior número de falhas. Ø Devem ser sistemáticas para tentar identificar um conjunto representativo de comportamento do programa. Ø É muito difícil classificar as técnicas de forma homogênea. Ø Utilizamos um classificação baseada em como testes são gerados: Intuição e experiência dos engenheiros de software Especificações Estrutura do código Falhas a serem descobertas Campo de uso Natureza da aplicação ü Técnicas de Teste Técnicas de Teste Ø Caixa Branca Testes são criados com base em como o software foi projetado ou codificado. Também chamado de teste de caixa de vidro. Objetivo de derivar casos de teste que garantam:» Exercício de todos os caminhos independentes de um módulo» Exercício de todas as decisões lógicas (verdadeiro e falso)» Exercício de todos os ciclos em seus limites e dentro de seus intervalos operacionais» Exercício das estrutura de dados internas ü Técnicas de Teste Técnicas de Teste Ø Caixa Preta Casos de teste são criados usando apenas o comportamento de entrada e saída do SUT (Software Under Test). Não é uma alternativa aos testes de caixa branca, é uma abordagem complementar que deve descobrir uma classe diferentes de erros. Encontra erros nas seguintes categorias:» Funções incorretas ou omitidas» Erros de interface» Erros de estrutura de dados ou de acesso a base de dados externas» Erros de comportamento ou desempenho» Erros de iniciação e de término ü Técnicas de Teste Técnicas de Teste Ø Caixa Preta Questões a serem verificadas:» As funções são realizadas?» As entradas produzem resultados esperados?» Integridade das informações externas é mantida Métodos para determinação de dados de teste» Particionamento em Classes de Equivalência» Análise de Valores Limites do Domínio» Grafos Causa-Efeito ü Técnicas de Teste Baseadas na Experiência e Intuição dos Engenheiros de Software Testes Ad Hoc Ø Testes são gerados unicamente com base na intuição, habilidade e experiência do engenheiro de software com programas similares. Ø Útil para a identificação de testes especiais, que não podem ser facilmente capturado por técnicas formalizadas.

2 ü Técnicas de Teste Baseadas na Experiência e Intuição dos Engenheiros de Software Testes Exploratório Ø Simultaneamente entende-se o SUT, projeta-se casos de teste e os executa. Ø São dinamicamente projetados, executados e modificados. Ø Efetividade depende do conhecimento do engenheiro de software, que pode derivar de muitos fatores: Funcionamento do SUT durante dos testes Familiaridade com a aplicação Plataforma utilizada Processo de falha Tipo de possíveis faltas e falhas Risco associado a um produto particular Ø Identificação de classes de equivalência sobre o domínio dos dados de entrada Ø Domínio de entrada é subdividido em sub-domínios Ø Selecionar dados para cada sub-domínio Ø Exemplo: domínio: datas sub-domínios: dias úteis e feriados Ø Passos: Decompor o programa em funções Identificar as variáveis que determinam o comportamento de cada função Particionar os valores de cada variável em classes de equivalência (válidas e inválidas) Especificar os casos de teste:» eliminar as classes impossíveis ou os casos desinteressantes» selecionar casos de testes cobrindo as classes válidas das diferentes variáveis» para cada classe inválida escolha um caso de teste que cubra e somente de cada vez Ø Classes de Equivalência podem ser definidas de acordo com as seguintes diretivas: Intervalo, uma válida e duas inválidas Um valor, uma válida e duas inválidas Membro de um conjunto, uma válida e uma inválida Booleana, uma válida e uma inválida Ø Exemplo: Considere uma função que aceita como entradas de 4 a 6 valores inteiros de dígitos. Identificação das variáveis de entrada e das condições que estas devem satisfazer:» nro_entradas [ 4, 6 ]» valor [ 0, 99 ]

3 Ø Exemplo: Determinação das classes de equivalência: Variável Classes Válidas Classes Inválidas nro_entradas C. 4 nro_entradas 6 C3. nro_entradas < 4 C4. nro_entradas > 6 valor C. 0 valor 99 C5. valor < 0 C6. valor > 99 Ø Exemplo: Casos de teste:» selecionar casos de testes cobrindo as classes válidas das diferentes variáveis Ø Exemplo: Casos de teste:» para cada classe inválida escolha um caso de teste que cubra e somente de cada vez Ø Exemplo: Ø Considere o teste do procedimento: validarsenha que recebe como entrada uma senha e valida-a conforme as seguintes regras: uma senha deve ter de 6 a 0 caracteres o primeiro caracter deve ser alfabético, numérico ou um? os outros caracteres podem ser quaisquer, desde que não sejam caracteres de controle a senha não pode existir em um dicionário Ø Partições de Equivalência Tamanho» Válido: 6 a 0 (C)» Inválido: < 6 (C7) ou > 0 (C8) Primeiro Caracter» Válido: é alfabético (C), é número (C3), é? (C4)» Inválido: {caract. controle} (C9), {letras, dígitos,?} (C0) Outros Caracteres» Válido: {caracteres de controle} (C5)» Inválido: {caracteres de controle} (C) Status» Válido: {dicionário} (C6)» Inválido: {dicionário} (C) 3

4 Ø Partições de Equivalência Tam 6 a 0 Ch alfab. Ch num. 3 Ch? 4 5 {dicionário 6 Tam < 6 7 Tam > 0 8 Outros {controle} Ch {controle} Ch {letras, dígitos,?} Outros {controle} {dicionário 9 0 Casos de Teste Casos de Teste aasw3 bcdefg?!@#$%^&*( 3 maisumasenhaparateste <ENTER>aaaaaa!aaaaa aaa<ctrl>aaa amanha Análise de Valor Limite Ø Critério de seleção de dados que identifica valores nos limites das classes de equivalência Ø Completa o particionamento de equivalência Ø Exemplos: valor mínimo (máximo) igual ao mínimo (máximo) válido uma unidade abaixo do mínimo arquivo vazio arquivo maior que a capacidade de armazenamento cálculo que pode levar a overflow/underflow erro no primeiro/último registro Análise de Valor Limite Dia Mês Válidas Não Válidas < 0 < 0 > 3 > Ano < 900 > 998 Dados de Contorno Dias: 0,, 3, 3, (8, 9 e 30 para fevereiro) Mês: 0,,, 3 Ano: 899, 900, 998, 999 Análise de Valor Limite Ø Quais outros casos de teste? Tam 6 a 0 Ch alfab. Ch num. 3 Ch? 4 5 {dicionário 6 Tam < 6 7 Tam > 0 8 Outros {controle} Ch {controle} Ch {letras, dígitos,?} Outros {controle} {dicionário 9 0 Casos de Teste Casos de Teste. aaaaaa. bcdefg 3.?!@#$%^&*( 4. aaaaa 5. aaaaaaaaaaa 6. <ENTER>aaaaaa 7.!aaaaa 8. aaa<ctrl>aaa 9. amanha Análise de Valor Limite Ø As diretrizes são semelhantes às fornecidas para o particionamento de equivalência: Para intervalo a b, devem ser projetados testes com valores a, b, imediatamente acima e imediatamente abaixo. Para vários valores, devem ser desenvolvidos testes para verificar números máximos e mínimos, além de valores abaixo e acima. Fazer o mesmo para intervalos de saída, como por exemplo, uma tabela de temperatura versus pressão em um programa de engenharia. Criar testes para exercitar os limites das estruturas de dados existentes e conhecidas ( caixa preta ). Tabela de Decisão Ø Exploram combinações de condições de entrada Ø Relacionam dados/condições de entrada com resultados/efeitos Ø Apontam ambigüidades e incompleteza nas especificações Ø Passos: listar as causas (dados/condições iniciais) listar os efeitos (resultados produzidos) ligar causas a efeitos transformar o grafo numa tabela de decisão transformar a tabela num conjunto de dados de teste (número de colunas = número de casos) 4

5 Tabela de Decisão Identidade: o efeito b ocorre se a condição a é verdade a b Negação: o efeito b ocorre se a condição a não é verdade a Conjunção: x ocorre se a, b e c são verdades a c b b and x Tabela de Decisão Disjunção: o efeito x ocorre se pelo menos uma das causas a, b ou c é verdade a b c x Restrição a causas: causas Simultâneas e mutuamente Exclusivas a a S b or E b Tabela de Decisão A = B Exemplo: A, B, e C são lados de um triângulo. Imprimir o tipo do triângulo. or ESCALENO Tabela de Decisão Ø Construção da Tabela de Decisões Para cada efeito, percorra o grafo no sentido efeito-causa e selecione as combinações de causas que produzem o efeito considerado Crie uma coluna na tabela de decisões para cada combinação de causas A = C xor ISOSCELES B = C and EQUILATERO Tabela de Decisão Ø Construção da Tabela de Decisões A = B A = C B = C e q u i l a t e r o i s ó s c e l e s e s c a l e n o A = B A = C or xor ESCALENO ISOSCELES Práticas Aconselhadas Ø Uma equipe de teste precisa realizar testes de caixa preta com muita precisão Ø As técnicas de caixa preta precisam ser usadas com cuidado, principalmente no que se refere a identificação das partições de equivalências e valores limites Ø Nunca esqueça da combinação de certas condições, pois elas podem revelar erros escondidos Ø Qualquer condição envolvida deve ser considerada, por mais que seja estranha B = C and EQUILATERO 5

6 Demonstração: Criação de Testes de Caixa Preta Teste a Partir das Especificações Ø Especificações Formais Uso de uma linguagem formal Muito caro Pouco utilizado na prática Teste a Partir das Especificações UML Ø Existem muitas questões a se investigar: Como usar diagramas UML para a derivação automática de casos de teste (com entradas e saídas)? Quais as estratégias de teste que parecem ser factíveis utilizando diagramas UML (de acordo com critérios técnicos e econômicos)? Quais devem ser os requisitos de testabilidade nesses diagramas, em termos, por exemplo, de completude e nível de detalhe? Teste a Partir das Especificações UML Ø Existem muitas questões a se investigar: Quais extensões à UML melhorariam a testabilidade? Como essas extensões poderiam ser implementadas utilizando os mecanismos de extensão de UML (por exemplo, estereótipos)? Como poderíamos automatizar a geração de oráculos e de casos de teste? É vantajoso gerar os testes a partir de especificações UML, ou o custo não compensa o investimento? Teste a Partir das Especificações UML Alguns projetos estão investigando essas questões: Ø TOTEM Testing of Object-oriented software systems with the Unified Modeling Language (UML) Ø AGEDIS Automated Generation and Execution of Test Suites for DIstributed Component-based Software Teste a Partir das Especificações UML Alguns projetos estão investigando essas questões: Ø DAS-BOOT Design- and Specification-Based Object-Oriented Testing Ø Hyades Automated Software Quality for Eclipse 6

7 Teste a Partir das Especificações UML Ø MODEST MethOD to help System Testing Método para geração e execução automática de testes Utiliza as informações contidas nas especificações de desenho (desenho externo), juntamente com o mecanismo de persistência utilizado Baseado nessas especificações, gera dados, aplicando-os ao software em desenvolvimento, analisando os resultados obtidos Teste a Partir das Especificações UML Ø MODEST MethOD to help System Testing Ø Porque utilizar as especificações de desenho? A criação das especificações de desenho é uma tarefa chata A revisão dessas especificações é mais chato ainda A principal (e talvez única) função dessas especificações é servir como documentação Muitas das especificações se tornam obsoletas, devido a mudanças no decorrer do projeto Existência de processos de sucesso que não prescrevem a criação de especificações de desenho Nada melhor para justificar a criação de tais especificações a obtenção de testes automáticos Atividades no Teste Estrutural Ø Representar o programa através de grafo de fluxo Ø Escolher critério de cobertura Ø Selecionar caminhos (grafo de fluxo) Ø Determinar dados de teste Ø Determinar resultados esperados Ø Instrumentar código fonte Ø Executar o programa com os dados Ø Comparar resultados computados com esperados Ø Analisar a cobertura de caminhos Ø Nodo = comandos seqüenciais Ø Arco = desvio de controle 3 4 (if-then-else) case (sequencial) (while-do) (repeat-until) procedure potencia(x,y:integer; var z:real); var p: integer; begin p:=0; z:=0; if y>0 then p:=y else p:=-y; z:=; while p<>0 do begin p:=p-; z:=z*x; end; if y<0 then z:=/z; end; p:=0 z:=0 (x,y) y>0 3 y<=0 4 5 p:=y p:=-y 6 z:= 8 p:=p- z:=z*x 7 p<>0 p=0 y<0 z:=/z 9 0 y>=0 Ø Critérios de Cobertura - Objetivos: geração de testes: determinação dos dados de teste avaliação final: indicação de término dos testes Ø Tipos: cobertura de instruções cobertura de decisões cobertura de condições cobertura de caminhos 3 3 7

8 Ø Teste de Instruções Critério: cada instrução deve ser executada pelo menos vez. Ø Teste de Instruções procedure potencia(x,y:integer; var z:real); var p: integer; begin p:=0; z:=0; if y>0 then p:=y else p:=-y; z:=; while p<>0 do begin p:=p-; z:=z*x; end; if y<0 then z:=/z; end; 3 3 Ø Teste de Decisões 3 3 Ø Teste de decisões/condições Critério: todas as condições devem ser testadas para valores V e F em cada decisão 3 Ø Teste de caminhos Critério: todos os caminhos possíveis do grafo devem ser percorridos pelo menos vez Ø Dificuldades: executabilidade: nem todos os caminhos no grafo são executáveis pelo programa grafos com ciclos: nº de caminhos pode ser indeterminado ou infinito necessidade de critérios que permitam limitar o nº de caminhos:» testes de caminhos básicos» testes de laços 3 8

9 Ø Complexidade Ciclomática Fornece uma medida quantitativa da complexidade lógica de um programa. No contexto de teste de caminho básico indica o número de caminhos independentes Exemplos:» » » » p:=0 z:=0 (x,y) y>0 3 y<=0 4 5 p:=y p:=-y 6 z:= 8 p:=p- z:=z*x 7 p<>0 p=0 y<0 z:=/z 9 0 y>=0 Ø Complexidade Ciclomática Número de regiões do grafo» 3 regiões internas + externa = 4 Número de nós predicados +» 3 nós predicados + = 4 Arestas Nós +» = 4 p:=0 z:=0 (x,y) y>0 3 y<=0 4 5 p:=y p:=-y 6 z:= 8 p:=p- z:=z*x 7 p<>0 p=0 y<0 z:=/z 9 0 y>=0 3 3 Ø Critérios de Cobertura Cobertura de fluxo de controle:» todos-nodos (comandos)» todos-arcos (desvios)» todos-caminhos Cobertura de fluxo de dados:» todas def» todos usos» todos du» todos p-usos» todos c-usos Ø Critérios de Cobertura Todos-arcos» Todos os arcos (ou decisões) devem ser executados Todos-nodos» Todos os nodos (ou comandos) devem ser executados Todos-caminhos» Todos os caminhos possíveis do grafo de fluxo devem ser executados» Problema: grafos com ciclos representam número infinito de caminhos» Deve-se exercitar todos os caminhos independentes à complexidade ciclomática Critério Baseado no Fluxo de Controle Ø Dicas Teste de Laços pule o laço passe pelo laço vez passe pelo laço m vezes, onde m < max passe pelo laço max- vezes passe pelo laço max vezes tente passar pelo laço max+ vezes (while-do) (repeat-until) Critério Baseado no Fluxo de Controle Ø Dicas Teste de Laços Aninhados comece pelo laço mais interno. Fixe os outros nos valores mínimos realize testes para laços simples caminhe para fora, realizando testes no laço seguinte e mantendo os demais nos valores mínimos continue até que todos tenham sido testados 3 9

10 Critério Baseado no Fluxo de Dados Ø Grafo de fluxo + Tabela definição-uso de variáveis Ø Definição de variáveis: em leitura, como parâmetro de entrada lado esquerdo da atribuição Ø Uso de variáveis: referência em expressão (aritmética ou lógica) Critério Baseado no Fluxo de Dados Ø Anomalias de fluxo de dados: uso de variável não inicializada atribuição valor a uma variável mais de uma vez sem que tenha havido uma referência a essa variável entre essas atribuições liberação ou reinicialização de uma variável antes que ela tenha sido criada ou inicializada liberação ou reinicialização de uma variável antes que ela tenha sido usada atribuir novo valor a um ponteiro sem que variável tenha sido liberada Demonstração: Avaliando a Cobertura de Testes Caixa Branca Adivinhação de Erros Ø Casos de teste são gerados com base nos principais erros registrados na organização Ø É necessário um histórico dos erros Ø Pode ter um viés gerando péssimos resultados! Ø Idealmente, não deveria ser utilizado como única alternativa. Ø É uma técnica interessante para avaliação dos testes. Ø É baseada na geração de programas mutantes Ø Mutantes São na verdade uma cópia do programa que está em fase de teste com alguma modificação simples Ø Baseado em dois conceitos básicos: Hipótese do Programador Competente: programadores competentes escrevem programas muito próximos do correto Efeito de Acoplamento: erros complexos estão relacionados a erros simples 0

11 Ø Exemplo : Programa original» Media = ( a+b ) / ; Possíveis Mutantes» Media = ( a - b ) / ;» Media = ( a * b ) / ;» Media = ( a % b ) / ;» Media = ( a / b ) / ; Ø Operadores Tradicionais Comuns a todas as linguagens ABS Absolute Value Insertion AOR Arithmetic Operator Replacement LCR Logical Connector Replacement ROR Relational Operator Replacement UOI Unary Operador Insertion Ø Operadores Tradicionais Ø Outros Operadores Geralmente baseado em certas características das linguagens Programas Orientados a Objetos se diferem em muitas características dos programas que não são. POO oferece uma nova estrutura muito diferente dos programas tradicionais (não OO) como herança, polimorfismo, sobrecarga de operadores... etc Essas diferenças geraram novos paradigmas para os testes de mutação, pois os novos conceitos geraram novos tipos de erros em softwares Ø Como os mutantes auxiliam os testes? Casos de teste bons deveriam eliminar todos os mutantes! Ø Mutação é uma boa técnica? Provavelmente a melhor Ø Por que é tão pouco usada? Desempenho é o maior problema! Geração automatizada de mutantes» Sem isso seria inviável a utilização deste tipo de teste Compilação de todos os programas mutantes gerados» Outro grande gargalho

12 Ø Sucesso no uso de mutantes: Rapidez na criação e compilação dos mutantes Rapidez na execução dos testes para os mutantes Uma boa abordagem poderia ser a implementação de mutantes com base nos erros mais comuns à organização Ø Algumas ferramentas JesTer, Java e JUnit, free, open source, baseado em mutação forte, PesTer, Python e PyUnit, free, open source, baseado em mutação forte, Nester, C e Nunit, free, open source, baseado em mutação forte, nester.sourceforge.net/ insure++ (for C++ code) (produto comercial) - products/insure/papers/tech_mut.htm GCT, C, baseada em mutação fraca, tools.html The Original Mothra Tool, mut.html Plextest C++, baseado em mutação forte, produto comercial, Demonstação: Análise de Mutantes ü Técnicas Baseadas na Natureza da Aplicação Certos software possuem características bem específicas Nesses casos, é necessário o uso de técnicas e ferramentas especiais Ø Sistemas de Tempo Real Ø Aplicações Web Ø Protocolos Ø... ü Técnicas Baseadas na Natureza da Aplicação Teste de Aplicações Web Ø Verificadores de Elos (Link Checkers) Serviço para verificação de links e âncoras em páginas Web, apontando links "quebrados" e sugerindo itens de controle que você não teria sem uso de uma verificação. Demonstração: Testes de Aplicações Web

13 ü Testes: Quando Parar? Quantos testes são suficientes? Ø Quando parar de testar? Ø Critério de seleção de dados Ø Critérios de adequação Regras para paradas Graus de adequação Ø Critério para cobertura Ø Medidas objetivas da qualidade dos testes ü Testes: Quando Parar? Seleção de dados de teste Ø Quais casos de teste Critério de adequação de dados de teste Ø Quando parar os testes Exemplos Ø Cobertura de declarações Ø Cobertura de decisões Ø Cobertura de def-uso Ø Cobertura de caminho ü Testes: Quando Parar? Uso de Critérios de Adequação Ø Objetivos do teste Ø Em termos do que pode ser medido Por exemplo, cobertura de decisões Ø Usado de formas: Primeiro como regra de parada Depois como guia para testes adicionais Categorias de Critérios Ø Baseados nas especificações Ø Baseados no programa Declarações, Decisões ü Testes: Quando Parar? Categorias de Critérios Ø Randômico, Estatístico,... Classificação de acordo com a abordagem de teste Ø Estrutural Cobertura de um conjunto de elementos contidos na estrutura do programa Ø Baseados em Falhas Alguma medida envolvendo falhas, para avaliar a habilidade de detecção dos testes ü Testes: Quando Parar? Algum critério deve ser adotado Uma vez atendido, os testes podem ser finalizados Muitas das vezes, critérios estão associados à cobertura ü Testes: Quando Parar? Bons Critérios para Teste: Ø Se existe especificações de desenho, um bom critério é a criação de teste que as exercitem por completo Ø Um critério muito usado é o tempo: se existe tempo, realiza-se teste, caso contrário... Ø Outro critério muito utilizado é o custo: se ainda há orçamento, testa-se, caso contrário... Ø Taxa de falhas abaixo de um certo nível Exemplo: Em 5 dias de testes, nenhum falha descoberta 3

14 ü Testes: Quando Parar? Boas Práticas no Teste: Ø Defina um critério Ø Tente obter medidas associadas a tal critério Ø Tente fazer previsões e acompanhe sempre o estimado e o obtido Demonstração: Inserção de Falhas 4