Slides da da palestra sobre Estratégias e Técnicas de Testes, apresentada por mim, na data de 19/11/2013 aos formandos do curso de Análise de Sistemas da instiutição IBES
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
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)
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
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.
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.
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
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.
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
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