estratégias e técnicas de testes - parte 2

Estratégias e Técnicas de Teste

de Software Lorena Caldas – 19/11/2013

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

Técnicas, Situações e Ferramentas

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

Técnicas

• Devem considerar:

▫ Estratégia e Método escolhidos

Características do Software

▫ Ferramentas disponíveis

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

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)

Testes Estruturais

(Caixa Branca)

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

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

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

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

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.

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


• Passo 2: Definir conjunto de Caminhos Básicos


M A[1];

I 2;


então M A[I]

I I+1



1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 -

Resposta

Nós sem ramificações: 1, 2, 3, 8, 9 e 10.


• Passo 3: Definir Caminhos Independentes


M A[1];

I 2;


então M A[I]

I I+1



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.


• Passo 4: Encontrar Complexidade Ciclomática


M A[1];

I 2;


então M A[I]

I I+1



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.


• Passo 5: Preparar casos de teste que exercitem todos os caminhos do conjunto básico


M A[1];

I 2;


então M A[I]

I I+1



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.

Ferramentas

• Análise Estática

▫ Não precisa executar o código-fonte

• Análise Dinâmica

▫ Precisa executar o código-fonte

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.

Ferramentas de Análise Dinâmica

• Compiladores:

▫ Prompt - Windows, Console – Linux

• IDEs

• Outras ferramentas de visualização de software

CodeExplorer

Quintics

Code Analysis

Integradas às IDES ou browsers

• Dodgy Code, JFokus, Firebug

Outras ferramentas de visualização de

software • Universal Code Lines Counter

• Thinking Craftsman’s Tool Kit

Testes Caixa Branca - Unitários

• Criação de pequenos métodos de teste para cada função da classe

• Ferramentas

▫ JUnit

▫ NUnit

▫ Cucumber

Cucumber

• Linguagem Gherkin

Testes Funcionais

(Caixa Preta)

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


• 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


• 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

Testes Funcionais – Partições de

Equivalência • Os casos de teste são preparados conforme

classificação dos dados de entrada

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

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

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

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

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

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.

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.

Ferramentas – Gerência de Teste • TestLink

Ferramentas – Gerência de Teste • HP Quality Center

Ferramentas – Cadastro de Ocorrências

• RedMine

Ferramentas – Cadastro de Ocorrências • Mantis

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.

• Vídeo

• Plugins dos browsers

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

Ferramentas - Testes Automatizados • Selenium IDE

Selenium WebDriver

TestComplete

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


• 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

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.

Ferramentas – Consumo de recursos

• QuickPerformance

Ferramentas - Performance • JMeter

Ferramentas - Performance • HP Load Runner

Ferramentas - Usabilidade

• Ethnio Status

Ferramentas - Usabilidade

• UseMonitor

Ferramentas - Acessibilidade • ASES

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


• 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

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.

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

Testes Baseados em Erros – SQL

Injection

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

Dúvidas???

Obrigada!