Testes baseados na especificação - interface -

1. Testes baseados na especificação - interface - Criado: abril/2001 Últ. atualiz.: jun/2009

2. Tópicos • Introdução • Partição de equivalência • Análise de valores-limite • Grafo causa-efeito • Gramática

3. Testes caixa preta Especificação: Requisitos Projeto Independente de notação Partição de equivalência Valores Limite Grafo causa-efeito Tabela de decisão Dependente de notação Baseada em modelo Baseada em linguagem de especificação

4. Testes caixa preta Especificação: Requisitos Projeto Independente de notação Partição de equivalência Valores Limite Grafo causa-efeito Tabela de decisão ... Testes de interface Dependente de notação Baseada em modelo Baseada em linguagem de especificação

5. Motivação - aplicabilidade • Testes de interface são aplicáveis: • Quando só se tem a descrição da interface do software em teste • Nos testes de robustez • Para criar dados para testes cx branca ou cx preta

6. ?xml version="1.0"?> <definitions name="StockQuote" targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" ... <types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> ... </schema> </types> Como gerar os dados para esse serviço?

7. domínio de entrada entradas válidas entradas inválidas sistema domínio de saída Partições de equivalência: princípio

8. Partições de equivalência • Princípio: • O domínio de entrada (ou saída) do programa/função é dividido em um número finito de partições de equivalência • supõe-se que dados pertencentes a uma partição têm capacidade de revelar as mesmas classes de falhas • uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma dada condição de entrada • Geração de testes: selecionar um ou mais dados de cada partição • Critério de cobertura: cada partição deve ser considerada ao menos 1 vez

9. Partição de equivalência: 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 1 e somente 1 de cada vez

10. Determinação das classes de equivalência

11. Determinação das classes de equivalência

12. Exemplo 1 • Função: Supor uma função que calcula o valor de • Valores válidos para X: • X  -2 • X  1 NSF-SWENET

13. Exemplo 1 • Determinação das classes de equivalência: Condições Classes Válidas Classes Inválidas de entrada X  -2 C1. X  -2 C3. -2 < X < 1 X  1 C2. X  1

14. Exemplo 1 • Casos de teste: • selecionar casos de testes cobrindo as classes válidas das diferentes variáveis C1 C2 C3 variável valor X -5 X  -2  X  1  X 5 -2 < X < 1  X 0

15. Exemplo 2 • Função MDC, que calcula o máximo divisor comum de dois inteiros (ambos não podem ser negativos) • MDC(a,b) = c onde • c é um inteiro positivo • c é divisor comum de a e b (i.e., c divide a e c divide b) • c é maior que todos os divisores comuns de a e b. • Exemplo: • MDC(45, 27) = 9 • MDC (7,13) = 1 • MDC(-12, 15) = 3 • MDC(13, 0) = 13 • MDC(0, 0) indefinido NSF-SWENET

16. Exemplo 2 - Descrição O algoritmo do MDC pode aceitar quaisquer inteiros como entrada. Neste exemplo vamos considerar que 0, inteiros positivos e inteiros negativos são valores especiais, i.e., são tratados diferentemente pelo programa.

17. Exemplo 2 – Classes de Equivalência

18. 1 2 3 4 5 6 1   2   3 4 5 6 7 8 9 Exemplo 2 – Casos de teste Classes de equivalência casos de teste Condições: a<0, b<0 a<0, b=0 a<0, b>0 . . . 1. 2. 3. 4. 5. 6. 7. 8. 9.

19. Análise de valores-limite • Critério de seleção que identifica valores nos limites das classes de equivalência • Exemplos: • valor mínimo (máximo) igual ao mínimo (máximo) válido • uma unidade abaixo do mínimo • uma unidade acima do máximo • arquivo vazio • arquivo maior ou igual à capacidade máxima de armazenamento • cálculo que pode levar a “overflow” (“underflow”) • erro no primeiro (último) registro

20. Exemplo 1 - Análise de valores limites • No exemplo 1, após determinar as classes de equivalência, devemos fazer uma análise de valores-limites para a escolha dos valores de cada classe (ou partição) de equivalência. Assim, considerando que a função roda em um processador de 32 bits, temos: C1. X  -2 -231, -100, -2.1, -2 C2. X  1 1, 1.1,100, 231-1 C3. -2 < X < 1 -1.9, -1, 0, 0.9 NSF-SWENET

21. Exemplo 2 - Análise de valores limites • Para a função MDC • Valores limites C1. -231, -1 a = C2. 0, C3. 1, 231-1 C4. -231, -1 b = C5. 0, C6. 1, 231-1

22. MDC – Plano de Testes (2) Ainda falta algum teste? Complete ... NSF-SWENET

23. Alguns valores-limites interessantes Fonte: Projeto Ballista - http://www.ece.cmu.edu/~koopman/ballista/

24. Limitação • Testes baseados em partições de equivalência ou análise de valores-limite: consideram cada valor de entrada isoladamente • e se existirem combinações de valores que constituam situações interessantes a serem testadas?

25. Análise causa - efeito • Necessária quando se deseja testar combinações de entradas • Utiliza tabelas de decisão e árvores de decisão • grafo causa-efeito como modelo auxiliar

26. Definições • Causas: • condições de entrada (valor lógico) • Efeitos: • ações realizadas em resposta às diferentes condições de entrada

27. = 0 b  0 mdc(a, b) Árvore de decisão: exemplo do mdc (a, b) mdc(a,b) = a  0 a exceção = 0 = 0 b  0 mdc(a, b)=b

28. Tabela de decisão c1 ... V ... F Condições de entrada (causas) e1 ... X Ações (efeitos) regra

29. Construção da tabela de decisão a 0 V V F F b 0 V F V F mdc(a, b) = a  mdc(a,b) = b  mdc(a, b)  exceção 

30. Utilidade da tabela de decisão • A tabela de decisão: • Facilita a determinação de quais testes aplicar. • Permite que se analise a especificação para determinar: • Redundâncias: duas regras iguais, i.e, mesmas causas levando aos mesmos efeitos • Contradições: duas regras com as mesmas causas levando a efeitos diferentes • Omissões: não há regras para todas as combinações de causas. • Redundâncias e contradições não são necessariamente erros: podem indicar concorrência. • Omissões podem indicar situações irrelevantes ou até mesmo impossíveis  é preciso fazer uma análise

31. Limitação das tabelas de decisão • Tamanho: • 3 causas  23 combinações (regras) • 5 causas  25 regras • ... • 8 causas  28 regras • ... • Será que vale a pena testar todas as regras?

32. Exemplo Supor um sistema bancário que trate somente duas transações: depósito nº da conta quantia saque nº da conta quantia Requisitos: • se o comando é depósito e o nº da conta é válido então a quantia é depositada • se o comando é saque e o nº da conta é válido e a quantia é válida (0 < quantia  saldo) então a quantia sacada • se o comando ou nº da conta ou a quantia for inválido então exibir mensagem de erro apropriada

33. Causas: c1. Comando é depósito c2. Comando é saque c3. Nº da conta é válido c4. Quantia é válida • Efeitos: e1. Exibir “comando inválido” e2. Exibir “nº da conta inválido” e3. Exibir “quantia inválida” e4. Depositar a quantia e5. Sacar a quantia nº de regras = 2 4 = 16 será que todas interessam ?

34. c1 c1 c2 c1 c2 c1 e1 e1 e1 e1   Grafo causa-efeito: notação básica Identidade Negação Ou E

35. c2 c4 c1 c3 e4 e2 e3 e1 e5 Exemplo: grafo causa-efeito • Causas: c1. Comando é depósito c2. Comando é saque c3. Nº da conta é válido c4. Quantia é válida • Efeitos: e1. Exibir “comando inválido” e2. Exibir “nº da conta inválido” e3. Exibir “quantia inválida” e4. Depositar a quantia e5. Sacar a quantia       

36. Conversão em tabela de decisão • Escolher um efeito como ação a ser executada, ie, marcar um “” na regra correspondente a este efeito. • Rastrear no grafo quais as combinações de causas que levam a esse efeito e marcar um “V” ou “F” na posição correspondente na tabela • Para cada combinação criada, verificar se ocorrem ou não os outros efeitos

37. Conversão: OU • Se e1 = x1 x2: • não escolha x1 = x2 =V • Se e1 =  (x1 x2): • considere todas as combinações que façam com que x1  x2 = F x1 e x2 podem ser causas ou nós intermediários

38.  c1 c2 e1 Exemplo: tabela de decisão Id. 1 2 3 4 5 c1 F c2 F c3 × c4 × e1  e2 e3 e4 e5

39. Conversão: E • Se e1 = x1 x2: • considere todas as combinações que façam com que x1 = x2 = V • Se e1 =  (x1  x2): • considere somente uma combinação que faça com que x1  x2 = F • para a combinação escolhida inclua uma e somente uma combinação que leve ao resultado desejado x1 e x2 podem ser causas ou nós intermediários

40.  c1 c2 c3 e2  Exemplo: tabela de decisão Id. 1 2 3 4 5 6 7 c1 F V F c2 F F V c3 × F F c4 × × × e1  e2   e3 e4 e5

41. Exemplo: tabela de decisão Id. 1 2 3 4 5 6 7 c1 F V F V F V F c2 F F V F V F V c3 × F F V V V V c4 × × × F F V V e1  e2   e3  e4  e5 

42. Geração de testes • Tabela de decisão critério: exercitar cada regra pelo menos 1 vez • Árvore de decisão critério: exercitar cada caminho da raiz até a folha pelo menos 1 vez • Eliminar os casos de teste que não fazem sentido ou que são redundantes.

43. Exemplo: casos de teste • Regra 1: comando  {depósito, saque},  nº conta,  quantia • Regra 2: comando = depósito, nº de conta inválido,  quantia • Regra 3: comando = saque, nº de conta inválido,  quantia ...

44. E I O e2 e1 e1 c2 c1 c2 c1 e2 c2 c1 M R Restrições Exclusivo no máximo 1 (0+) Inclusivo no mínimo 1 (1+) Somente um 1 e somente 1 (1) Exige e1  e2 Mascara e1  e2

45. c1 c2 c3 c4 e1 e2 e5 e3 e4 Exemplo: uso de restrição  E      M  

46. Outras formas de gerar dados de teste • Além das técnicas vistas, outras podem ser usadas para a geração de dados de teste: • Testes aleatórios • Uso de heurísticas • Algoritmos de otimização • Recozimento simulado (simulated annealing), colônia de formigas, hill climbing, ... • Algoritmos evolutivos: algoritmos genéticos, otimização extrema, ...

47. Testes aleatórios • Testes gerados aleatoriamente • Independem do tipo de dado: inteiros, reais, cadeias de caracteres, ... • Todos tratados como cadeias de bits que são alteradas aleatoriamente • Não é a melhor forma, em geral, de se conseguir uma boa cobertura de algum critério, mas é fácil de implementar • Existem diversas ferramentas: • Fuzz, Ridle • Úteis em testes de robustez

48. Uso de gramáticas • Gramáticas são adequadas para representar: • Entradas de tamanho variável e não limitado • Estruturas recursivas • Condições-limite • Exemplos: • Entradas textuais complexas • Árvores • ex.: documentos XML e HTML são árvores descritas textualmente • Estrutura de programas • Também podem ser consideradas como árvores descritas textualmente

49. Exemplo de gramática Símbolo não terminal Símbolo inicial Cadeias válidas stream ::= action* action ::= actG | actB actG ::= “G” s n actB ::= “B” t n s ::= digit1-3 t ::= digit1-3 n ::= digit2 ”.” digit2 digit ::= “0” | “1” | “2” | “3” | “4” | “5” produção ou regra G 17 03.01 B 13 15.20 G 1 04.23 B 123 45.34 Símbolo terminal • : zero ou mais repetições • m-n: no mínimo m e no máximo n repetições • n: exatamente n repetições

50. Testes baseados em gramáticas • Casos de teste = cadeias geradas a partir da gramática • Alguns critérios: • Cobertura de produções: um caso de teste deve exercitar pelo menos uma produção • Cobertura de terminais: um caso de teste deve conter pelo menos um terminal • Condições-limite: casos de teste devem exercitar cada produção recursiva: • Número mínimo de vezes • Número mínimo + 1 • Número máximo - 1 • Número máximo de vezes