Slide 1 - WordPress.com

TESTES DE SOFTWARE – AULA 3
Prof. Me. Ronnison Reges Vidal
Revisão, 2016
TESTE NO PROGRAMA
TESTE CAIXA BRANCA E
TESTE CAIXA PRETA
OBJETIVOS DESTA AULA
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
INTRODUÇÃO

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
PROJETOS DE CASOS TESTE
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
operacional;
Abordagem: Teste de Caixa Preta
7
é
totalmente
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
TESTE CAIXA BRANCA
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
procedimentais.
9
minucioso
exame
dos
detalhes
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
11
sua validade.
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 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.
13
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:
14
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.
15
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
1
3:
then process record;
store in
buffer;
2
increment counter;
4
3
4:
else if record field2 = 0
5:
then reset counter;
6
5
6:
else process record;
store in file;
7
7:
endif
8
endif
8: enddo
9
9: end
16
TESTE DO CAMINHO BÁSICO
Caminho 1: 1-9
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
R3 5
3
R2
7
8
9
17
R4
R1
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.
18
TESTE DE CONDIÇÃO
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 DOMÍNIO
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 CICLO (LAÇOS)
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.
21
21
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.
22
TESTE DE CICLO (LAÇOS)
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.
23
TESTE DE CICLO (LAÇOS)
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.
24
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.
A atenção é voltada ao domínio da informação.
25
TESTE CAIXA PRETA
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.
26
TESTE CAIXA PRETA
Também
chamados
de
testes
funcionais,
pois
a
especificação funcional é usada para derivar os casos de
teste
Especificação
funcional
muitas
vezes
pode
ser
completada ou criada pelo projetista de testes
Efeito colateral benéfico: ajuda a revelar falhas na
especificação
27
TESTE CAIXA PRETA
Projeto de casos de testes pode começar desde cedo
– E continua ao longo do desenvolvimento
– Aplicáveis em todas as fases de testes: unidades →
sistemas
Prescindem do código fonte:
– Úteis quando código fonte não está disponível (ex.:
uso de componentes de terceiros)
– Podem ser usados quando código muito complexo
(ex.: testes de sistemas
28
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 as combinações específicas de dados terão
sobre a operação do sistema?
29
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.
30
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
31
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.
32
TESTE CAIXA PRETA
Particionamento de Equivalência

O Particionamento de Equivalência divide o domínio
de entrada em uma série de diferentes classes (ex:
números positivos, strings sem ’brancos’).

Um caso de teste ideal descobre sozinho uma classe
de erros.
33
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.
34
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.
35
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 (boundary-value
analysis) leva à seleção de casos de teste nas
36
“extremidades”da classe.
TESTE CAIXA PRETA
Análise do Valor Limite
Qualquer número
(neste intervalo)
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.
37
TESTE CAIXA PRETA
Diretrizes para BVA
Se uma condição de entrada especifica um intervalo:
1. Casos de teste com o valores a e b, e imediatamente
acima e abaixo são planejados.
2. Se uma condição de entrada especifica vários
valores:
• Casos de teste devem ser desenvolvidos para
exercitar o mínimo e o máximo.
• Valores imediatamente acima e abaixo também
38
devem ser testados.
TESTE CAIXA PRETA
Diretrizes para BVA
Aplique as diretrizes 1 e 2 às condições de saída.
• Exemplo: a saída de um programa é uma tabela de dados.
Casos de teste devem ser criados para gerar tabelas com o
mínimo e o máximo de linhas e colunas.
4. Se as estruturas de dados internas do programa têm
limites definidos, testes devem ser projetados para exercitar
os limites internos
39
TESTE CAIXA PRETA
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.
40
TESTE CAIXA PRETA
Teste de matriz ortogonal
Se o domínio de entrada é limitado, é possível realizar testes
exaustivos de todos as combinações de valores de entrada.
– Exemplo: três parâmetros que assumem três valores discretos
cada um (3×3×3 = 27 casos de teste).
• Para domínios de entrada muito grandes, uma abordagem
comum é variar um parâmetro de cada vez.
– Não detecta interações entre parâmetros
• O teste de matriz ortogonal é um meio termo, aplicável a
problemas com domínio de entrada relativamente pequeno, mas
grande demais para testes exaustivos.
41
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.
42
TESTE CAIXA PRETA
Matriz ortogonal para a função envie da aplicação de fax:
Parâmetros de Teste
Casos
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
43
TESTE CAIXA PRETA
Matriz Ortogonal
Casos de teste ficam espalhados uniformemente pelo
domínio de teste.
• Detecta e isola todas as falhas de modo singular.
– Pela análise da informação sobre quais testes revelam
erros, pode-se identificar quais valores de parâmetro
causam a falha.
• Detecta todas as falhas de modo duplo.
• Falhas multi-modo podem ou não ser detectadas.
44
TESTE CAIXA PRETA
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.
45
TESTE CAIXA PRETA
Baseado em grafo
O primeiro passo no teste é entender os objetos que estão
modelados no softwaree as relações entre eles.
– Para isso, o engenheiro cria um grafo onde cada nó
representa um objeto e cada aresta representa uma relação
entre os objetos.
• Depois disso, uma série de testes é criada para cobrir o
grafo de modo que cada objeto e cada relação seja
exercitada
46
TESTE CAIXA PRETA
Baseado
em grafo
47
TESTE CAIXA PRETA
Tipos de Modelagem em grafo



Modelagem de fluxo de transação

Nós representam passos em alguma transação.

Arestas representam as conexões lógicas entre os passos.
Modelagem de estado finito

Nós representam diferentes estados do software observáveis pelo usuário.

Arestas representam transições de um estado para outro.
Modelagem de fluxo de dados

Nós representam os objetos de dados.

Arestas representam as transformações que ocorrem para traduzir um objeto em
outro.


Eg: FTW = 0,62 x GW
Modelagem de tempo

Nós representam objetos do programa.

Arestas representam ligações seqüenciais entre esses objetos.

48
Pesos são usados para especificar os tempos de execução.