O documento apresenta estratégias e técnicas de teste de software, dividindo suas discussões em introdução, execução e métodos de teste. As técnicas incluem testes estruturais, funcionais e não funcionais, com ênfase nas ferramentas e metodologias para garantir a qualidade do software. O material destaca a importância de selecionar técnicas apropriadas e aplicá-las de acordo com as características do sistema e as fases de desenvolvimento.

1. Estratégias e Técnicas de Teste de Software
Lorena Caldas – 19/11/2013

2. Resumo da Apresentação
•Parte 1 – Introdução ao Teste de Software
▫Principais Conceitos
▫Estratégias de Teste
•Parte 2 – Técnicas de Teste de Software
▫Técnicas, Situações e Ferramentas

3. Técnicas, Situações e Ferramentas

4. Execução dos Testes
•A atividade de execução dos testes é realizada após a construção de um produto de trabalho, quando na etapa de Verificação, ou após o desenvolvimento de um escopo do sistema, quando na etapa de Validação.
▫Verificação:
Revisões de requisitos, modelos, gráficos, inspeções na base de dados
▫Validação
Execução do software e sua infraestrutura para analisá-lo sob ponto de vista dos procedimentos usuais

5. Técnicas
•Devem considerar:
▫Estratégia e Método escolhidos
Características do Software
▫Ferramentas disponíveis

6. Estratégias X Técnicas
•As Técnicas de Teste devem ser escolhidas conforme Estratégia definida. Elas podem participar de várias Estratégias ou ser combinadas entre si
•Por Tipo de Sistema
▫Desktop, Web, Mobile e Híbrido
•Por Arquitetura
▫Top-down e Bottom-up
•Por Abrangência
▫Unidade, Integração e Sistema
•Por Fase
▫Confirmação, Aceite e Manutenção

7. Técnicas
•Podem ser:
▫Estruturais (Caixa Branca)
São testados os caminhos lógicos do sistema em suas diversas camadas
▫Funcionais (Caixa Preta)
Considera as entradas e saídas do sistema, de acordo com as especificações de interface
▫Não Funcionais
Observa os aspectos além daqueles funcionais
▫Baseados em Erros
São inseridos defeitos propositais no sistema para que se já existia falhas no software (código legado)

8. Testes Estruturais (Caixa Branca)

9. Testes Estruturais – Caixa Branca
•Observa os procedimentos de construção do software:
▫Análise dos produtos do projeto: modelos, tabelas, gráficos, classes
▫Revisões de código-fonte
▫Estruturas das tabelas e integridade dos dados
▫Forma da comunicação em rede
•Ator: Projetista, programador, analista de sistemas e tester

10. Testes Estruturais – Caixa Branca
•Objetivo:
▫Garantir que todos os caminhos de uma funcionalidade, suas decisões lógicas, laços, fronteiras e estruturas de dados foram exercitados ao menos 1 vez
•Métodos
▫Caminho Básico
▫Caminho Independente
▫Complexidade Ciclomática

11. Testes Estruturais – Caminho Básico
•O ator define um limite aceitável para os caminhos lógicos básicos do sistema sejam identificados (fluxo de controle)
•Condição de Aceite:
▫Quantidade de itens sem ramificação não ultrapassa limite aceitável
•Notação Utilizada:
▫Grafo de fluxo

12. Testes Estruturais – Caminho Independente
•Extensão do Ciclo Básico – São caminhos do sistema que levam a uma novo conjunto de instruções de processamento de uma nova condição
•Condição de Aceite:
▫Fluxos de controle possuem ramificações
•Notação Utilizada:
▫Grafo de fluxo
Caminhos Independentes:
Caminho 1: 1 – 11
Caminho 2: 1 – 2,3 – 4,5 – 10 – 1 – 11
Caminho 3: 1 – 2,3 – 6 – 8 – 9 – 10 – 1 – 11
Caminho 4: 1 – 2,3 – 6 – 7 – 9 – 10 – 1 – 11

13. Testes Estruturais – Complexidade Ciclomática
•Extensão do Ciclo Básico e Independente – Mede a quantidade de caminhos independentes do conjunto de caminhos básicos
•Condição de Aceite:
▫Limite máximo de teste necessários para exercitar todos os caminhos é respeitado
•Formas de Fazer:
▫Número de regiões do grafo de fluxo
▫V(G) = E – N + 2
V (G) = número de teste necessários para cobrir instruções
E = número de ramos do grafo
N = número de nós do grafos do fluxo G
▫V(G) = P + 1
P = conjunto de nós que contém condicionais,
contidos no fluxo G
A Complexidade Ciclomática do grafo de fluxo é 4
O grafo de fluxo contém 4 regiões;
V(G) = 11 ramos - 9 nós + 2 = 4;
V(G) = 3 nós predicativos + 1 = 4.

14. Testes Estruturais – Como Fazer
• Passo 1: Traçar o gráfico de fluxo para o trecho
este trecho de código
procedimento MAIOR(A:VETOR;
T:inteiro; var MAX:inteiro);
variaveis I,M:inteiro
Inicio
M A[1];
I 2;
enquanto I T faça
se A[I] > M
então M A[I]
I I+1
senão I I+1
fim se
fim enquanto
MAX M;
fim do procedimento
1 -
2 -
3 -
4 -
5 -
6 -
7 -
8 -
9 -
10 -
Resposta

15. Testes Estruturais – Como Fazer
• Passo 2: Definir conjunto de Caminhos Básicos
procedimento MAIOR(A:VETOR;
T:inteiro; var MAX:inteiro);
variaveis I,M:inteiro
Inicio
M A[1];
I 2;
enquanto I T faça
se A[I] > M
então M A[I]
I I+1
senão I I+1
fim se
fim enquanto
MAX M;
fim do procedimento
1 -
2 -
3 -
4 -
5 -
6 -
7 -
8 -
9 -
10 -
Resposta
Nós sem
ramificações: 1, 2,
3, 8, 9 e 10.

16. Testes Estruturais – Como Fazer
• Passo 3: Definir Caminhos Independentes
procedimento MAIOR(A:VETOR;
T:inteiro; var MAX:inteiro);
variaveis I,M:inteiro
Inicio
M A[1];
I 2;
enquanto I T faça
se A[I] > M
então M A[I]
I I+1
senão I I+1
fim se
fim enquanto
MAX M;
fim do procedimento
1 -
2 -
3 -
4 -
5 -
6 -
7 -
8 -
9 -
10 -
Resposta
Caminho 1: 1, 2, 3, 9,
10;
Caminho 2: 1, 2, 3, 4,
5, 6, 8, 3, 9, 10;
Caminho 3: 1, 2, 3, 4,
7, 8, 3, 9, 10.

17. Testes Estruturais – Como Fazer
• Passo 4: Encontrar Complexidade Ciclomática
procedimento MAIOR(A:VETOR;
T:inteiro; var MAX:inteiro);
variaveis I,M:inteiro
Inicio
M A[1];
I 2;
enquanto I T faça
se A[I] > M
então M A[I]
I I+1
senão I I+1
fim se
fim enquanto
MAX M;
fim do procedimento
1 -
2 -
3 -
4 -
5 -
6 -
7 -
8 -
9 -
10 -
Resposta
N. Regiões: 3;
V(G) = 9 ramos - 8 nós
+ 2 = 3;
V(G) = 2 nós
predicativos + 1 = 3.

18. Testes Estruturais – Como Fazer
• Passo 5: Preparar casos de teste que exercitem
todos os caminhos do conjunto básico
procedimento MAIOR(A:VETOR;
T:inteiro; var MAX:inteiro);
variaveis I,M:inteiro
Inicio
M A[1];
I 2;
enquanto I T faça
se A[I] > M
então M A[I]
I I+1
senão I I+1
fim se
fim enquanto
MAX M;
fim do procedimento
1 -
2 -
3 -
4 -
5 -
6 -
7 -
8 -
9 -
10 -
Resposta
Caminho 1: 1, 2, 3, 9,
10
A=(1,3) T = 0
Resultado Esperado –
Max = 1;
Caminho 2: 1, 2, 3, 4,
5, 6, 8, 3, 9, 10
A=(1,3) T = 2
Resultado Esperado –
Max = 3;
Caminho 3: 1, 2, 3, 4,
7, 8, 3, 9, 10
A=(3,1) T = 2
Resultado Esperado –
Max = 3.

19. Ferramentas
•Análise Estática
▫Não precisa executar o código-fonte
•Análise Dinâmica
▫Precisa executar o código-fonte

20. Ferramentas de Análise Estática
•IDEs
▫Eclipse, NetBeans, DevC++, VisualStudio, etc.
•Plugins ou ferramentas integradas às IDEs
▫Code Explorer, Dodgy Code, FXCop, etc.
•Browsers e plugins
▫Firebug, etc.
•Outras ferramentas de visualização de software
▫Code Analisys, CodeScan, etc.

21. Ferramentas de Análise Dinâmica
•Compiladores:
▫Prompt - Windows, Console – Linux
•IDEs
•Outras ferramentas de visualização de software

22. CodeExplorer

23. Quintics

24. FXCop

25. Code Analysis

26. Integradas às IDES ou browsers
•Dodgy Code, JFokus, Firebug

27. Outras ferramentas de visualização de software
•Universal Code Lines Counter
•Thinking Craftsman’s Tool Kit

28. Testes Caixa Branca - Unitários
•Criação de pequenos métodos de teste para cada função da classe
•Ferramentas
▫JUnit
▫NUnit
▫Cucumber

29. JUnit

30. NUnit

31. Cucumber
•Linguagem Gherkin

32. Testes Funcionais (Caixa Preta)

33. Testes Funcionais – Caixa Preta
•Analisa a interface e suporte funcional do software:
▫Forma de apresentação do software: tela, terminal, componentes COTs, e-mail, etc.
▫Forma de armazenamento dos dados: base de dados, planilhas, arquivos, etc.
▫Operação sobre ambiente do cliente;
▫Interface de comunicação com outros sistemas ou módulos híbridos.
•Ator: Tester

34. Testes Funcionais – Caixa Preta
•Objetivo:
▫Exercitar todos os requisitos funcionais do sistema
•Métodos
▫Partições de Equivalência
▫Análise do Valor Limite
▫Tabela de Decisão
▫Transição de Estados
▫Teste de Caso de Uso

35. Testes Funcionais – Caixa Preta
•Testes Baseados em Especificações
▫Teste de Roteiro
Quando existe um script pré-definido a ser seguido (caso de teste)
•Testes Baseados na Experiência
▫Teste Exploratório
Quando não existe documentação a ser seguida. Depende do conhecimento técnico do ator

36. Testes Funcionais – Partições de Equivalência
•Os casos de teste são preparados conforme classificação dos dados de entrada

37. Testes Funcionais – Partições de Equivalência
•Um bolo possui 6 camadas e 1 sabor por camada: limão, baunilha, maracujá, morango, nozes e chocolates. Quantas classes podem ser extraídas?
▫6 classes, 1 por sabor
•Sabendo que cada camada possui 20 cm de altura, quais valores válidos e inválidos são necessários para testar todas as condições de teste do bolo?
▫Limão: 0 a 20 cm
▫Baunilha: 20 a 40 cm
▫Maracujá: 40 a 60 cm
▫Morango: 60 a 80 cm
▫Nozes: 80 a 100 cm
▫Chocolate: 100 a 120 cm
Válidos
Inválidos
10
-10, 30
30
15, 50
50
35, 70
70
50, 90
90
70, 110
110
90, 130

38. Testes Funcionais – Análise do Valor Limite
•Os casos de teste são preparados conforme fronteiras das classes de equivalência, para os dados de entrada e saída do sistema
▫Classe Válida
Extremidades mínima e máxima de um intervalo
▫Classe Inválida
Valores fora do intervalo

39. Testes Funcionais – Análise do Valor Limite
•Sabendo que cada camada possui 20 cm de altura, quais valores medem os limites das classes?
▫Limão: 0 a 20 cm
▫Baunilha: 20 a 40 cm
▫Maracujá: 40 a 60 cm
▫Morango: 60 a 80 cm
▫Nozes: 80 a 100 cm
▫Chocolate: 100 a 120 cm
Válidos
Inválidos
0, 20
-1, 21
20, 40
19, 41
40, 60
39, 61
60, 80
59, 81
80, 100
79, 101
100, 120
99, 119

40. Testes Funcionais – Tabela de Decisão
•Avalia causa e efeito. As condições são consideradas falsa e verdadeira
•Traça as combinações entre as regras de negócio do sistema e suas possibilidades de operação

41. Testes Funcionais – Transição de Estado
•Avalia a situação do sistema após a troca de estado de uma variável do sistema.
•Traça a combinação entre as regras de negócio do sistema e suas possibilidades de estado

42. Testes Funcionais – Teste de Caso de uso
•A preparação dos casos de teste é baseada nas regras de negócio do sistema.
•São criados casos positivos e negativos para cobrir cada situação prevista.

43. Ferramentas – Caixa Preta
•Gerência de teste
▫TestLink, HP Quality, etc.
•Cadastro de ocorrências
▫RedMine, Mantis, Bugzilla, etc.
•Geração de Evidências
▫Texto, Imagem e Vídeo.
•Testes Automatizados
▫Selenium IDE, Selenium WebDriver, TestComplete, etc.

44. Ferramentas – Gerência de Teste
•TestLink

45. Ferramentas – Gerência de Teste
•HP Quality Center

46. Ferramentas – Cadastro de Ocorrências
•RedMine

47. Ferramentas – Cadastro de Ocorrências
•Mantis

48. Ferramentas – Geração de Evidência
•Texto
▫Notepad, Gedit, Ferramentas COTS: Pacotes Office ou BrOffice
•Imagem
▫PrintScreen, Captura automática, Ferramentas de edição de imagem: Paint, Gimp, Plugins dos browsers, etc.
•Vídeo
▫Captura automática do Windows, Plugins dos browsers e outras ferramentas de captura.

49. •Vídeo
•Plugins dos browsers

50. Ferramentas - Testes Automatizados
•Os testes manuais devem ser automatizados quando for executado diversas vezes em diferentes versões do software
•Os principais casos de teste a ser automatizados são aqueles que passam por regressão

51. Ferramentas - Testes Automatizados
•Selenium IDE

52. Selenium WebDriver

53. TestComplete

54. Testes Não Funcionais

55. Testes Não Funcionais
•Analisa os aspectos que não estão diretamente baseados nas regras de negócio do software (funcionalidades);
•Avalia as medidas quantitativas do software:
▫Verifica:
Operacionalidade do sistema (consumo recursos do computador, cliente, servidor, serviço embarcado, etc.)
Acessibilidade
Performance
Usabilidade
Confiabilidade, Recuperação, Portabilidade, etc.
•Ator: Tester e técnico em infraestrutura

56. Testes Não Funcionais
•Objetivo:
▫Garantir operação do sistema sob condições não ligadas às funcionalidades da aplicação
•Métodos
▫Baseado no tipo do teste a ser realizado.
▫Teste de Carga
Conforme base de dados
▫Teste de Stress
Conforme arquitetura e tipo do sistema: desktop, etc.
▫Teste de Acessibilidade
Conforme interface do sistema

57. Ferramentas – Testes não Funcionais
•Consumo dos recursos
▫Gerenciador de tarefas do Windows e do Linux, QuickPerformance, etc.
•Performance, Stress e Carga
▫Jmeter, HP Load Runner, etc.
•Usabilidade
▫Ethnio Status, UseMonitor, etc.
•Acessibilidade
▫ASES, etc.

58. Ferramentas – Consumo de recursos
•QuickPerformance

59. Ferramentas - Performance
•JMeter

60. Ferramentas - Performance
•HP Load Runner

61. Ferramentas - Usabilidade
•Ethnio Status

62. Ferramentas - Usabilidade
•UseMonitor

63. Ferramentas - Acessibilidade
•ASES

64. Testes Baseados em Erros

65. Testes Baseados em Erros
•Inclui defeitos propositalmente no software para testar seu comportamento;
•Necessita das versões: Original (sem defeitos) e Alterada (com defeitos)
• Ator: Tester e analista de sistemas

66. Testes Baseados em Erros
•Objetivo:
▫Fornecem indicadores para gerenciar o processo de teste (porcentagem de erros remanescentes, qualidade dos casos de testes)
•Métodos
▫Semeadura de Erros
▫Análise de Mutantes

67. Semeadura de Erros – Como Fazer
•Passo 1:
▫Erros artificiais são introduzidos no programa;
•Passo 2:
▫Cria-se um caso de uso para identificar falhas naturais e artificiais
•Passo 3:
▫Baseados na proporção erros naturais/artificiais pode-se estimar a quantidade de erros remanescentes para o conjunto de casos de teste definidos para o programa.
Desta forma pode-se comparar a estimativa de erros remanescentes com a confiabilidade esperada (especificada) para o software.

68. Semeadura de Erros – Análise de Mutantes
•Visa avaliar quão adequado um conjunto de testes é para testar uma funcionalidade.
•Passos
▫1 - Gera-se casos de teste (T) para um programa (P);
▫2 - Verifica-se se ele funciona corretamente;
▫3 - Verifica-se o funcionamento do mutante (M) para os casos de teste (T):
Caso a verificação de M apresentar resultados diferentes da verificação de P o mutante é “morto”
Caso contrário, M continua “vivo” e deve ser analisado;
▫4 - Análise dos mutantes vivos:
O mutante M é equivalente ao programa original P
O caso de teste é insuficiente para diferenciar M de P e novos casos de teste devem ser definidos

69. Testes Baseados em Erros – SQL Injection

70. Referências
•Livro - Engenharia de Software, Roger Pressman
•Livro – Base de Conhecimento em Teste de Software - Certificação CBTS / ALATS – Anderson Bastos, Emerson Rios, et. al.
•Artigos – Rex Black
•Syllabus – CTFL / ISTQB
•Comunidade de Testes – Site Elias Nogueira
•Slides da Qualidade BR – Fabrício de Campos

71. Dúvidas???

72. Obrigada!