Teste de Software Aulas 4 e 5

Prévia do material em texto

TESTES DE SOFTWARE – AULAS 4 E 5
TESTE NO PROGRAMA
TESTE CAIXA BRANCA E
TESTE CAIXA PRETA 
1. Compreender os testes de interior do programa;
2. Definir testes para o interior do programa;
3. Implementar testes para o interior do programa;
4. Avaliar testes realizados no interior do programa.
3
OBJETIVOS DESTA AULA
 Uma vez gerado o código-fonte, o software deve ser
testado para descobrir (e corrigir) tantos erros quanto
possível antes de fornecê-lo ao cliente.
 O objetivo do teste é encontrar erros, e um bom teste é
aquele que tem alta probabilidade de encontrar um erro.
 Devem ter uma serie de características que permitam
atingir o objetivo de encontrar o maior número de erros com
o mínimo de esforços.
4
INTRODUÇÃO
 Testes podem ser usados para descobrir a presença de
erros, mas não para mostrar a sua ausência.
 Testes de software é o processo de executar o software
de uma maneira controlada com o objetivo de descobrir
diferenças entre o comportamento previsto e o
comportamento observado.
 Um teste bem-sucedido é aquele que revela um erro
ainda não descoberto.
5
INTRODUÇÃO
 Devemos projetar testes que tenham a mais alta
probabilidade de descobrir a maioria dos erros com uma
quantidade mínima de tempo e esforço;
 Os métodos de projeto de casos de teste oferecem ao
desenvolvedor uma abordagem sistemática ao teste.
 Oferecem ainda um mecanismo que ajuda a garantir a
integridade do teste e proporciona a mais alta probabilidade
de revelar erros no software.
6
INTRODUÇÃO
Qualquer produto trabalhado por engenharia pode ser
testado de duas maneiras:
1 - Conhecendo-se a função específica que um produto
projetado deve executar, testes podem ser realizados
para demonstrar que cada função é totalmente
operacional;
Abordagem: Teste de Caixa Preta
7
PROJETOS DE CASOS TESTE
2 - Conhecendo-se o funcionamento interno de um 
produto, testes podem ser realizados para garantir que 
a operação interna do mesmo tenha desempenho de 
acordo com as especificações e que os componentes 
internos foram postos à prova.
Abordagem: Teste de Caixa Branca
8
PROJETOS DE CASOS TESTE
Teste de caixa branca é uma abordagem de projeto de
casos de teste que usa a estrutura de controle do projeto
procedimental para derivar casos de teste.
Baseia-se num minucioso exame dos detalhes
procedimentais.
9
TESTE CAIXA BRANCA
Os caminhos lógicos através do software são testados,
fornecendo-se casos de teste que põem à prova conjuntos
específicos de condições e/ou laços.
O status do programa pode ser examinado em vários
pontos para determinar se o esperado corresponde ao real.
10
TESTE CAIXA BRANCA
Com este método nós podemos projetar casos de teste que:
Garantam que todos os caminhos independentes dentro de
um módulo tenham sido exercitados pelo menos uma vez;
Exercitem todas as decisões lógicas para valores falsos ou
verdadeiros;
Executem todos os laços em suas fronteiras e dentro de
seus limites operacionais;
Exercitem as estruturas de dados internas para garantir a
sua validade.
11
TESTE CAIXA BRANCA
Tipos de Teste Caixa Branca:
 Teste de Caminho Básico
 Teste de Condição
 Teste de Fluxo de Dados
 Teste de Ciclo
12
TESTE CAIXA BRANCA
13
TESTE DO CAMINHO BÁSICO
Técnica de teste de caixa branca inicialmente
proposta por Tom McCabe.
Permite ao projetista do caso de teste derivar uma medida
da complexidade lógica de um projeto procedimental e usá-
la para definir um conjunto básico de caminhos de
execução;
A Complexidade Ciclomática é uma métrica que
proporciona uma medida quantitativa da complexidade
lógica de um programa.
14
TESTE DO CAMINHO BÁSICO
Os casos de teste projetados para exercitarem este conjunto
básico têm garantia de executar cada instrução do programa
pelo menos uma vez durante a atividade de teste.
Os seguintes passos devem ser aplicados:
15
TESTE DO CAMINHO BÁSICO
1. Usando o projeto ou o código como base, desenhar o 
grafo de fluxo correspondente;
2. Determinar a complexidade ciclomática do diagrama de 
fluxo resultante.
3. Determinar um conjunto base de caminhos linearmente 
independentes. 
4. Preparar casos de teste que vão forçar a execução de 
cada caminho do conjunto base.
16
TESTE DO CAMINHO BÁSICO
Exemplo: Segmento de programa fonte e seu correspondente grafo de fluxo.
procedure:sort
1: do while records remain
read record;
2: if record field1 = 0
3: then process record;
store in buffer;
increment counter;
4: else if record field2 = 0
5: then reset counter;
6: else process record;
store in file;
7: endif
endif
8: enddo
9: end
1
2
4
6 5
7
3
8
9
17
TESTE DO CAMINHO BÁSICO
Caminho 1: 1-11
Caminho 2: 1-2-3-8-1 ...
Caminho 3: 1-2-4-5-7-8-1 ...
Caminho 4: 1-2-4-6-7-8-1 ... 
1
2
4
6 5
7
3
8
9
R3
R2
R1
R4
18
TESTE DE CONDIÇÃO
Método de Projeto de casos de teste que põe à prova as
condições lógicas contidas em um módulo de programa.
 Condição Simples: variável booleana ou expressão
relacional, precedida ou não por um operador NOT (‘)
 Condição Composta: duas ou mais condições simples,
operadores booleanos e parênteses.
Tipos de Erros de uma Condição: erro de operador
booleano, erro de variável booleana, erro de parênteses
booleano, erro de operador relacional, erro de expressão
aritmética.
Teste de Ramos: Para uma condição C composta, os
ramos verdadeiro e falso de C e todas as condições simples
em C precisam ser executadas pelo menos uma vez.
Teste de Domínio: requer 3 ou 4 testes sejam derivados
para uma expressão relacional.
19
TESTE DE CONDIÇÃO
Para uma expressão E1 <operador relacional> E2
3 testes são exigidos para tornar o valor de E1 >, = ou <
que o de E2.
Se <operador relacional> estiver incorreto e E1,E2 corretos,
esses 3 testes garantem a detecção de erro de operador
relacional.
Para detectar erros em E1 e E2, basta executar um teste
que faça o valor de E1 > ou < que o de E2, com uma
diferença menor possível.
20
TESTE DE DOMÍNIO
21
TESTE DE CICLO (LAÇOS)
21
Fundamental para a grande maioria de todos os
algoritmos implementados no software. Técnica que
concentra na validade das construções de laços.
Laços Simples: deve ser aplicado o seguinte conjunto de
teste:
• Pule o laço inteiramente;
• Somente uma passagem através do laço;
• Duas passagens através do laço;
• m passagens através do laço, onde m < n;
• n-1, n, n+1 passagens através do laço.
22
TESTE DE CICLO (LAÇOS)
Laços Aninhados:
1. Inicie pelo laço mais interno. Fixe os outros laços para
valores mínimos.
2. Realize testes de laços simples para o laço mais interno.
3. Trabalhe para fora, realizando testes para o laço seguinte,
mas mantendo todos os ciclos externos nos valores mínimos
4. Continue até que todos os laços tenham sido testados.
23
Laços Concatenados:
1. Se laços independentes dos demais:
 usar abordagem de laços simples.
2. Se contador de laços para o laço 1 for usado
como valor inicial para o laço 2:
 usar abordagem de laços aninhados.
TESTE DE CICLO (LAÇOS)
24
Laços não estruturados:
Sempre que possível, esta classe deve ser reprojetada para
refletir o uso das construções de programação estruturada.
TESTE DE CICLO (LAÇOS)
25
TESTE CAIXA PRETA
Foco: requisitos funcionais do software
Possibilita a derivação de conjuntos de condições de
entrada que exercitem todos os requisitos funcionais para
um programa.
O Teste de Caixa Preta desconsidera a estrutura de
controle.
Aatenção é voltada ao domínio da informação.
26
O Teste de Caixa Preta não é uma alternativa às técnicas
Caixa Branca, mas ao contrário, é uma abordagem
complementar, que mais provavelmente descobrirá uma
classe diferente de erros.
TESTE CAIXA PRETA
São realizados para responder as seguintes perguntas:
Como a validade funcional é testada?
Como o comportamento e o desempenho é testado?
Que classes de entrada farão bons casos de teste?
O sistema é particularmente sensível a certos valores?
Como as fronteiras de uma classe de dados é isolada?
Que taxas e volumes de dados o sistema pode tolerar?
Que efeito combinações específicas de dados terão sobre a
operação do sistema?
27
TESTE CAIXA PRETA
Desta forma o teste de caixa preta tenta encontrar erros
nas seguintes categorias:
Funções incorretas ou faltando;
Erros de interface;
Erros em estruturas de dados ou acesso a bases de dados
externas;
Erros de comportamento ou de desempenho;
Erros de inicialização e término.
28
TESTE CAIXA PRETA
Existem diferentes métodos de testes de caixa preta que
podem ser subdivididos em:
 Particionamento em Equivalência
 Análise do Valor Limite
 Teste de Matriz Ortogonal
 Baseado em Grafo
29
TESTE CAIXA PRETA
30
TESTE CAIXA PRETA
Particionamento de Equivalência
 Método de teste de caixa preta que divide o domínio
de entrada de um programa em classes de dados a
partir das quais os casos de testes podem ser
derivados.
 Um caso de teste ideal descobre sozinho uma classe
de erros que, de outro modo, poderia exigir que
muitos casos fossem executados antes que o erro
geral fosse observado.
31
TESTE CAIXA PRETA
Particionamento de Equivalência
As classes de equivalência podem ser definidas,
conforme as seguintes diretrizes:
1. Se uma condição de entrada especificar um
intervalo, uma classe de equivalência válida e duas
classes de equivalência inválidas são definidas.
2. Se uma condição de entrada exigir um valor
específico, uma classe de equivalência válida e duas
inválidas são definidas.
32
TESTE CAIXA PRETA
Particionamento de Equivalência
As classes de equivalência podem ser definidas,
conforme as seguintes diretrizes:
3. Se uma condição de entrada especificar um
membro de um conjunto, uma classe de equivalência
válida e uma inválida são definidas.
4. Se uma condição de entrada for booleana, uma
classe de equivalência válida e uma inválida são
definidas.
33
TESTE CAIXA PRETA
Análise do Valor Limite
Percebe-se que um número maior de erros tende a
ocorrer mais nas fronteiras do domínio de entrada do que
no “centro”. A análise de valor de limite leva à escolha de
casos de teste que põem à prova os valores fronteiriços.
É uma técnica que complementa o particionamento de
equivalência: em vez de selecionar qualquer elemento de
uma classe de equivalência, a BVA leva à seleção de
casos de teste nas “extremidades”da classe.
34
A análise do valor limite leva a novos casos de teste
referentes a valores adjacentes aos limites. A seleção de
tais casos adicionais, aumentam a probabilidade de se
detectar uma falha.
Qualquer número
(neste intervalo)
TESTE CAIXA PRETA
Análise do Valor Limite
Teste de matriz ortogonal
O teste de matriz ortogonal pode ser aplicado a problemas
nos quais o domínio de entrada é relativamente pequeno,
mas muito grande para acomodar um teste exaustivo.
O objetivo do teste é a construção de caso de teste com
uma visualização geométrica associada aos valores de
entrada de uma aplicação.
35
TESTE CAIXA PRETA
Para ilustrar, vamos considerar a função envie para uma
aplicação de fax. Neste exemplo, são passados quatro
parâmetros: P1, P2, P3 e P4. Cada parâmetro assume três
valores discretos. P1 assume, por exemplo, os valores:
P1=1, enviar agora;
P1=2, enviar após 1 hora;
P1=3, enviar depois da meia-noite;
P2, P3 e P4 também assumiriam valores, 1, 2 e 3,
significando outras funções de envio.
36
TESTE CAIXA PRETA
Matriz ortogonal para a função envie da aplicação de fax:
37
TESTE CAIXA PRETA
Casos 
de Teste
Parâmetros de Teste
P1 P2 P3 P4
1 1 1 1 1
2 1 2 2 2
3 1 3 3 3
4 2 1 2 3
5 2 2 3 1
6 2 3 1 2
7 3 1 3 2
8 3 2 1 3
9 3 3 2 1
Baseado em grafo
O teste baseado em grafos leva em consideração os objetos
modelados no software e as relações que os unem.
A ideia é definir uma série de testes que verificam se os
objetos têm a relação esperada uns com outros.
Um grafo é uma coleção de nós que representam objetos,
ligações que representam as relações entre objetos, peso
de nó que descreve as propriedades de um nó e pesos de
ligação que descrevem uma característica de uma ligação.
38
TESTE CAIXA PRETA
39
TESTE CAIXA PRETA
Baseado
em grafo