Projetode Casosde Teste’ - homes.dcc.ufba.brhomes.dcc.ufba.br/~esa/disciplinas/pdf/aula12.pdf · • Como soluçãodo dilema, recomendaseo usode ... (outros(casosde( teste(

Projeto de Casos de Teste

Alcemir Santos

Slides baseados no Capítulo 4 do livro abaixo: Myers, Glenford J.. The Art of So1ware Tes3ng. Editora Wiley. 2004.

2ed.

Este trabalho é licensiado sobre a licensa CreaFve Commons AGribuFon-‐ShareAlike 3.0.

Brasil.

Tópicos à Estudar

•  Técnicas de Teste Caixa-‐Branca – Teste por Cobertura Lógica

•  Técnicas de Teste Caixa-‐Preta – ParFção em Classes de Equivalência – Análise de Valor Limite – Grafo de Causa-‐Efeito

•  Técnica de Teste Baseada em Erro •  Estratégia de Teste

Antes de tudo…

•  Teste não pode garanFr a ausência de todos os erros

•  Projeto de Casos de Teste é importante – Testar tudo é impossível

•  O teste de quaisquer programa é necessariamente incompleto

•  Devido a restrições de tempo e custos:

Qual subconjunto de todos os casos de teste que tem maior probabilidade de detectar a maioria dos erros?

TÉCNICAS DE TESTE CAIXA-‐BRANCA Teste por Cobertura Lógica

Cobertura de Instrução

•  Executar cada instrução do programa ao menos uma vez

•  Este é um critério ingênuo – O primeiro a vir à mente

•  Este é um critério de teste fraco – geralmente inúFl (exemplo no próximo slide)

•  Um critério mais forte é conhecido como cobertura de decisões or cobertura de ramificações

Cobertura de Instrução

Programa Foo Java Ramificação do Programa Foo

Java setando A=2, B=0, no

ponto a, todas instruções serão executadas uma

vez

Mas, talvez a primeira decisão deveria ser OR invés de AND

Talvez a segunda

decisão deveria ter Condicionado X>0

Estes erros não seriam iden3ficados.

Cobertura de Decisão

•  Também conhecida como “Cobertura de Ramificação”

•  Cada ramificação deve ser executada pelo menos uma vez. – Ou seja, escrever casos de teste suficiente para que cada decisão tenha as saídas true e false ao menos uma vez

•  Exemplos de instruções de ramificação são as instruções switch, do-‐while, e if-‐else.

Coertura de Decisão

•  Cobertura de decisão geralmente saFsfaz a cobertura de instrução

•  Entretanto, existem ao menos três exeções: 1.  Programas sem decisões 2.  Programas ou métodos com múlFplos pontos de

entrada •  Dada instrução pode ser executada somente se o

programa começa a executar de um certo ponto 3.  Instruções dentro de unidades-‐ON •  Atravessar cada ramificação não necessariamente irá

executar uma unidade-‐ON Unidades-‐ON existem em algumas linguagens para controle de fluxo.

Ajudando, por exemplo, no tratamento de exceções.

Cobertura de Condição

•  GaranFr (com casos de teste) que cada condição de uma decisão assuma todos os valores possíveis ao menos uma vez

•  O critério de cobertura de condição não saFsfaz o critério de cobertura de decisão – Ao testar a decisão IF(A && B), o critério de cobertura de condicão levaria a dois casos de teste (A = true, B = false e A = false, B = true) mas isto não causaria a execução da instrução THEN do IF

Cobertura de Condição

•  Programa Foo Java Este exemplo mostra quatro condições: A>1, B=0, A=2 e X>1

suficientes casos de teste são necessários para forçar

situações onde A>1, A≤1, B=0, B≠0, A=2,

A≠2, X>1, e X≤1

Sobre o Teste por Cobertura Lógica

•  Cobertura de Decisão e Cobertura de Condição são critérios mais fortes que a Cobertura de Instrução

•  Cobertura de Condição é as vezes mais forte que Cobertura de Decisão

•  No entanto, Cobertura de Condição não saFsfaz a Cobertura de Decisão DILEMA: Como escolher entre os critérios de cobertura de decisão or condição?

Sobre o Teste de Cobertura Lógica

•  Como solução do dilema, recomenda-‐se o uso de um critério híbrido –  Cobertura de Decisão/Condição

•  Cobertura de decisão/condição requer casos de teste suficientes para que: –  Cada condição de uma decisão assuma todas os possíveis valores ao menos uma vez

–  Cada decisão execute todos os ramos possíveis ao menos uma vez

–  Cada ponto de entrada seja invocado ao menos uma vez

Exercícios Sugeridos

Dado o método abaixo, idenFfique casos de teste com as técnicas de teste caixa-‐branca:

public String foo(int x, int y){ boolean z; if ( x<y ) z = true; else z = false; if ( z && x+y == 10 ) return “A”; else return “B”;

} Procure idenFficar casos em que as técnicas discuFdas

não foram capazes de idenFficar possíveis erros.

TÉCNICA DE TESTE CAIXA-‐PRETA ParFção em Classes de Equivalência

Par3ção em Classes de Equivalência

•  É impossível testar exausFvamente as entradas de um programa

•  O testador é limitado a tentar um conjunto limitado de entradas

Qual subconjunto escolher?

Como escolher o subconjunto para alcançar alguns objeFvos para considerar o programa

razoavelmente testado?

Par3ção em Classes de Equivalência: Propriedades de escolha de subconjunto

•  O subconjunto deve reduzir significaFvamente o número de outros casos de teste

•  O subconjunto deve cobrir um grande conjunto de outras possibilidades de casos teste

Cada caso de teste deve considerar invocar tantas entradas quanto possível para minimizar o total de casos de teste necessário

O Testador deve tentar parFcionar o domínio da entrada de um programa dentro número finito de classes de equivalência

Par3ção em Classes de Equivalência: O primeiro passo

1.  IdenFficar as classes de equivalencia: – Tomar cada condição de entrada e parFcionar em dois ou mais grupos (válidos ou inválidos)

Exemplo: Considere uma entrada de condição que especifique um intervalo de valores.

if(count >1 && count <99) -‐  Uma classe de equivalência válida é (1 < count < 99) -‐  Duas classes de equivalência inválidas são (count ≤ 1

and count ≥ 99).

Par3ção em Classes de Equivalência: O Segundo Passo

2.  Definir casos de teste: – Atribua um único número para cada classe de equivalência. •  Exemplo: count == 50 [0 < count < 100]

– Até todas as classes de equivalência válidas tenham sido cobertas por casos de teste •  Exemplo: count == 50 (valid),

– Até todas as classes de equivalência inválidas tenham sido cobertas por casos de teste •  Exemplo: count==-‐5 and count==110 (invalid)

Par3ção em Classes de Equivalência: Exemplo da mercearia (1/7)

•  Considere um módulo de soyware que deve aceitar o nome do produto e uma lista de diferentes tamanhos que o produto está disponível

•  Especificações –  Nome do produto:

•  Somente letras, com tamanho do nome entre 2 e 15 caracteres •  Deve vir primeiro, seguido por vírgula, depois pela lista de tamanhos separados por vírgula

–  Tamanhos do produto: •  Dentro do intervalo de 1 a 48, números inteiros somente. •  Em ordem ascendente (menores primeiro). •  No máximo cinco tamanhos para cada produdo.

–  Espaços (em branco) devem ser ignorados em qualquer lugar da entrada

Fonte: hGp://users.csc.calpoly.edu/~jdalbey/205/Resources/grocerystore.html

Classes de Equivalência


1.  só contem letras 2.  contém caracteres diferentes de

letras 3.  tem menos que 2 caracteres 4.  tem entre 2 e 15 caracteres 5.  tem mais que 15 caracteres 6.  é menor que 1 7.  Está entre 1 e 48 8.  É maior que 48 9.  É número inteiro 10. É número decimal 11. É um valor numérico 12. Inclui caracteres não numéricos

13. Lista em ordem ascendente 14. Lista em ordem descendentes 15. Lista de valores vazia 16. Lista contém entre 1 e 5 valores 17. Lista contem mais de cinco valores 18. Nome do produto primeiro 19. Nome do produto depois 20. Separação por uma vírgula 21. Diferente de vírgula 22. Não contém espaços em branco 23. Contém espaços em branco


• Só contem letras • Tem entre 2 e15 caracteres • Vem primeiro na entrada

válidas

•  vem depois na entrada • Tem menos de 2 caracteres • Tem mais que 15 caracteres • Contém caracteres diferentes de letras

inválidas

Classes derivadas para o nome do produto:


• É número • Está entre 1 e 48 • É número iteiro • Entrada em ordem ascendente

válidas

•  Inclui caracteres não numéricos • É decimal • É menor que 1 • É maior que 48 • Entradem em ordem descendente

inválidas

Classes derivadas do Tamanho dos Produtos:


• Entrada entre um e cinco valores válidas

• Entrada vazia • Entrada com mais de cinco valores

inválidas

Classes derivadas da QuanFdade de Valores:


•  Separado por uma vírgula • Contém espaços em branco (???) • não contém espaços em branco (???)

válidas

•  Separador diferente de vírgula inválidas

Classes derivadas das Separação da Entrada:

Classes de Equivalência


1.  só contem letras 2.  contém caracteres diferentes de

letras 3.  tem menos que 2 caracteres 4.  tem entre 2 e 15 caracteres 5.  tem mais que 15 caracteres 6.  é menor que 1 7.  Está entre 1 e 48 8.  É maior que 48 9.  É número inteiro 10. É número decimal 11. É um valor numérico 12. Inclui caracteres não numéricos

13. Lista em ordem ascendente 14. Lista em ordem descendentes 15. Lista de valores vazia 16. Lista contém entre 1 e 5 valores 17. Lista contem mais de cinco valores 18. Nome do produto primeiro 19. Nome do produto depois 20. Separação por uma vírgula 21. Diferente de vírgula 22. Não contém espaços em branco 23. Contém espaços em branco


Test data Expected outcome Covered classes

xy,1 T 1,4,7,9,11,13,16,18,20,22

AbcDefghijklmno,1,2,3 ,4,48 T 1,4,7,9,11,13,16,18,20,23

a2x,1 F 2

A,1 F 3

abcdefghijklmnop F 5

Xy,0 F 6

XY,49 F 8

Xy,2.5 F 10

xy,2,1,3,4,5 F 14

Xy F 15

XY,1,2,3,4,5,6 F 17

1,Xy,2,3,4,5 F 19

AB,2#7 F 12


Dado o método abaixo, idenFfique casos de teste com a técnica de parFção de classes de equivalência:

public String triType(int a, int b, int c){ if ( a<=0 || b<=0 || c<=0 ) return “não é triângulo”; if ( a<b+c || b<a+c || c<a+b) return “não é triângulo”; if ( a == b )

if ( a == c ) return “equilátero”; return “isósceles”; else if ( b == c ) return “isósceles”; else return “escaleno”;

}

O Programa está correto? Procure idenFficar casos em que a técnica não foi capaz de idenFficar possíveis erros.


Considere um método para validar uma nova senha. Com entrada o método recebe uma string que contendo a nova senha. A validação acontece com as seguintes regras: •  O tamanho da senha deve ser entre 6 e 15 caracteres

•  A senha deve conter letras, números e caracteres especiais

•  A senha não deve exisFr em um dicionário IdenFfique casos de teste com a técnica de parFção de classes de equivalência.

TÉCNICA DE TESTE CAIXA-‐PRETA Análise de Valor Limite

Análise de Valor Limite

Condições limite são aquelas situações incidentes, acima e abaixo das bordas dos valores das classes

de equivalência de entrada e saída.

A experiência mostra que casos de teste que exploram as condições

limite têm maior retorno.

Análise de Valor Limite

Análise de valor limite ≠ parFção de equivalência: 1.  Ao contrário de selecionar qualquer elemento na classe

de equivalência, análise de valor limite requer a seleção de um ou mais elementos das bordas de cada classe de equivalência como entrada de casos de teste

2.  Ao contrário de ter atenção nas condições de entrada, os casos de teste também são derivados considerando as classes de equivalência de saída

Análise de Valor Limite: o exemplo do triângulo

Considere um método que aceita como entrada três inteiros representando lados de um triângulo (a, b, c). O problema é determinar o Fpo de triângulo (Equilátero, Isósceles, escaleno ou se não é um triângulo). Considere o tamanho do lado entre 1 e 200. Estas condições podem determinar se os lados da

entrada formam um triângulo.

1.  1 ≤ a ≤ 200 2.  1 ≤ b ≤ 200 3.  1 ≤ c ≤ 200

4.  a < b + c. 5.  b < a + c. 6.  c < a + b.

1.  If ( a = b = c ) then Equilátero. 2.  If ( a = b || a = c || b = c ) then Isósceles. 3.  If ( a ≠ b ≠ c ) then Escaleno.

Estas condições podem determinar o Fpo do

triângulo.


Limite superior

Sobre o limite

Média

Limite inferior+1

Limite superior-‐1 Limite inferior


A B C Output

100 1 100 Isósceles


100 100 100 Equilátero


100 200 100 Não é triângulo












Dado o método abaixo, idenFfique casos de teste com a técnica de análise de valor limite:

Procure idenFficar casos em que a técnica não foi capazes de idenFficar possíveis erros.

public Double qualDesconto(int preco, int qtde){ if ( (preco >= 50 && preco < 100 )&& qtde > 5 ) return 0.05; else if ( preco >= 100 && qtde > 3 ) return 0.1;

}

TÉCNICAS DE TESTE CAIXA-‐PRETA Grafo de Causa-‐Efeito

Grafo de Causa-‐Efeito

•  Testar combinações de entrada não é trivial –  O número de combinações é astronômico

•  O testador pode selecionar um subconjunto arbitrário de condições –  Isto pode levar a um teste não efeFvo

•  Grafo de Causa-‐Efeito auxilia na seleção (de forma sistemáFca), um conjunto de casos de teste de alto redimento –  Adicionalmente, ele aponta abiguidades e não completudes na especificação

Grafo de Causa-‐Efeito

•  O processo de criação do grafo: 1.  Decoponha as unidades a serem testadas (em caso de ter

muitas funcionalidades a serem testadas) 2.  IdenFfiue causas e efeitos 3.  Estabeleça o grafo de relações entre causas e efeitos 4.  Anote o grafo com restrições entre causas e/ou efeitos 5.  Converta o grafo para uma tabela de decisão 6.  As colunas da tabela são converFdas em casos de teste.

Grafo de Causa-‐Efeito Símbolos básicos de um grafo de causa-‐efeito

IDENTIDADE NEGAÇÃO

OR AND

Grafo de Causa-‐Efeito: um exemplo

•  Especificação: O Caractere na coluna 1 deve ser um “A” ou um “B”. O caractere na coluna 2 deve

ser um dígito. Nesta situação a atualizão do arquivo é feita. Se o primeiro caractere

esFver incorreto, a mensagem X é exibida. Se o segundo caractere não for um dígito, a

mensagem Y é exibida.


•  As causas são: 1.  Caractere na coluna 1 é “A” 2.  Caractere na coluna 1 é “B” 3.  Caractere na coluna 2 é um dígito

•  Os efeitos são: 70. O arquivo é atualizado 71. A mensagem X é exibida 72. A mensagem Y é exibida


Amostra do grafo de causa-‐efeito

É impossível setar 1 para as causas 1 e 2 ao

mesmo tempo.


Símbolos de restrições

No máximo um elemento pode ser 1

Um e somente um deve ser 1

Ao menos um dos elementos

Se um elemento assumir um valor o outro também deve assumir


Amostra do grafo de causa-‐efeito com a restrição “exclusiva”


Causas Efeitos 1 2 3 70 71 72 0 0 0 0 1 1 0 0 1 0 1 0 0 1 0 0 0 1 0 1 1 1 0 0 1 0 0 0 0 1 1 0 1 1 0 0

1 = true; 0 = false;

Grafo de Causa-‐Efeito: Tabela de Decisão

Casos d

e Teste


Dado o método abaixo, idenFfique casos de teste com a técnica de grafo de causa-‐efeito:

public String triType(int a, int b, int c){ if ( a<=0 || b<=0 || c<=0 ) return “não é triângulo”; if ( a<b+c || b<a+c || c<a+b) return “não é triângulo”; if ( a == b )

if ( a == c ) return “equilátero”; return “isósceles”; else if ( b == c ) return “isósceles”; else return “escaleno”;

}

O Programa está correto? Procure idenFficar casos em que a técnica não foi capaz de idenFficar possíveis erros.

TÉCNICA DE TESTE BASEADA EM ERRO

Teste Baseado em Erro

•  Dado um programa, suponha: – Prováveis Fpos de erros e depois escreva casos de teste para expor estes erros.

•  Em outras palavras: – Enumere aqueles casos especiais que podem ter sido negligenciados na etapa de projeto do programa

Por intuição e experiência!

Teste Baseado em Erro: um exemplo

•  Ao testar um método de busca binária, o testador pode tentar as seguintes situações: 1.  Existe apenas uma entrada na tabela pesquisada 2.  O tamano da tabela é uma potência de dois

(exemplo: 16) 3.  O tamanho da tabela é um abaixo ou um acima

de uma potência de dois (exemplo: 15 ou 17)

ESTRATÉGIA DE TESTE

A Estratégia •  As metodologias de projeto de casos de teste discuFdas podem ser combinadas de forma a construir uma estratégia razoável: 1.  Se a especificação contém combinações das

condições de entrada, comece por grafo de causa-‐efeito

2.  Em qualquer evento, uFlize análise de valor limite 3.  IdenFque as classes de equivalência válidas e

inválidas para a entrada e saída. Complemente os casos de teste idenFficados acima, caso necessário.

4.  Use a técnica baseada em erro para casos de teste adicionais

5.  Examine a lógica do programa considerando o conjunto de casos de teste


Considere-‐se o testador de um sistema de gerenciamento de uma biblioteca. E você deve elaborar casos de teste para o contexto de solicitação de empresFmo. As restrições são as seguintes:

•  O usuário (solicitante) deve estar cadastrado •  O solicitante pode ter até 3 emprésFmos simultâneos •  O solicitante não pode ter multa(s) à pagar •  O solicitante não pode ter quaiquer outra pendência

IdenFfique casos de teste com as técnicas aprendidas.

Projeto de Casos de Teste

por Alcemir Santos

Slides baseados no Capítulo 4 do livro abaixo: Myers, Glenford J.. The Art of So1ware Tes3ng. Editora Wiley. 2004.

2ed.

Perguntas?

Documents

Projetode Casosde Teste’ - homes.dcc.ufba.brhomes.dcc.ufba.br/~esa/disciplinas/pdf/aula12.pdf · • Como soluçãodo dilema, recomendaseo usode ... (outros(casosde( teste(