Teste de Software
Engenharia de Software



Fase de definição ("o que")
Análise do Requisitos
Planejamento de projeto de software
Fase de Desenvolvimento ("como")
Projeto de software
Codificação
Realização de testes
Fase de manutenção ("atualizações e alterações")
Testes para detecção de defeitos
Teste de Defeitos
Testar programas para
demonstrar
a presença de defeitos
#
Teste de Validação
Demonstrar que o sistema
cumpre
as suas especificações
Fases de Teste
Component
testing
Integration
testing
Software developer
Independent testing team
O processo de teste

Teste de Componentes
•
•

Teste de componentes individuais dos programas
Normalmente é de responsabilidade do desenvolvedor do
programa (exceto em alguns sistemas críticos)
Testes de Integração
•
•
•
Teste de um grupo de componentes integrados para a criação
de um sistema ou sub-sistema.
Responsabilidade de uma equipe de testes independente
Testes são baseados na especificação do sistema.
Objetivos da atividade de teste
1- A atividade de teste é o processo de executar um
programa com a finalidade de descobrir um erro.
2- Um bom caso de teste é aquele que tem uma elevada
probabilidade de revelar um erro ainda não descoberto,
forçando o programa a uma ação anormal.
3- Um teste bem sucedido é aquele que revela um erro
ainda não descoberto.
O objetivo é projetar casos de teste que descubra
sistematicamente diferentes classes de erros e façam-no
com um quantidade de tempo e esforço mínimos.
Objetivos da atividade de teste


Se a atividade de teste for conduzida com
sucesso, ela descobrirá erros no software.
A atividade de teste não pode mostrar a
ausência de erros nos programas, mas sim a
presença de erros nos programas. importante !!!
Fluxo de informações de teste
Configuração do SW
Especificação de Requisitos
Especificação de projeto
Código Fonte
Resultados
dos Testes
Avaliação
Erros
Atividades
de teste
Configuração de Teste
Plano e procedimento de teste
Ferramentas de teste
Casos de teste e
resultados esperados
Dados de taxas de erros
Modelo de
Confiabilidade
Depuração
Correções
Confiabilidade Prevista
Fluxo de informações de teste



Se erros graves forem encontrados com regularidade =>
a qualidade e a confiabilidade de software são suspeitas.
Se erros facilmente corrigíveis forem encontrados =>
a qualidade e a confiabilidade do software estão
aceitáveis ou os testes são inadequados para revelar
erros graves.
Se não for encontrado erro => a configuração de teste
não foi suficientemente elaborada e erros podem estar
escondidos no software
Dados de teste e Casos de teste


Dados de teste: são as entradas selecionadas
para testar o sistema.
Casos de Teste: Definição das entradas para
testar o sistema e das saídas esperadas caso o
sistema opere de acordo com o especificado.
Processo de teste
Projetos de casos de teste abordagens

Teste da caixa branca




Baseia-se em um minucioso exame dos detalhes procedimentais.
São testados os caminhos lógicos através do software, fornecendose 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 status esperado ou estabelecido corresponde ao
status real.
Teste da caixa preta



Refere-se aos testes que são realizados nas interfaces do software.
São usados para demonstrar que as funções dos softwares são
operacionais, que a entrada é adequadamente aceita e a saída é
corretamente produzida; que a integridade das informações externas
é mantida.
Examina aspectos de um sistema sem se preocupar muito com a
estrutura lógica interna do software.
Características dos testes

Somente testes exaustivos pode mostrar que o
programa é livre de defeitos. Entretanto, testes
exaustivos são impossíveis.
Teste da Caixa Branca


É um método de projeto de casos de teste que usa uma
estrutura de controle do projeto procedimental para
derivar casos de teste.
Podem ser derivados 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 sua
validade.
Teste da Caixa Branca - teste do caminho
básico


O método de caminho básico possibilita que o projetista do caso de
teste derive uma medida de complexidade lógica de um projeto
procedimental e use essa medida como guia para definir um
conjunto básico de caminhos de execução.
Grafo de fluxo: uma notação para representar o fluxo de controle.
Cada construção estruturada tem um símbolo de grafo
correspondente.
SEQUENCE
IF
WHILE
UNTIL
CASE
Teste da caixa branca - caminhos
independentes

Qualquer caminho através do programa que introduza pelo
menos um novo conjunto de instruções de processamento
ou uma nova condição.
Grafo de Fluxo
Conjunto Básico para o grafo de fluxo
1
2,3
6
7
4,5
8
9
10
11
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
Teste da caixa branca - caminhos
independentes



É uma métrica de Software que proporciona uma medida
quantitativa da complexidade lógica de um programa.
Quando usado no contexto do método de teste do caminho básico,
o valor computado da complexidade ciclomática define o número
de caminhos independentes do conjunto básico de um programa
e oferece um limite máximo para o número de testes que deve ser
realizado para garantir que todas as instruções sejam executadas
pelo menos uma vez.
A complexidade ciclomática é computada numa das 3 formas:
1- Número de regiões do grafo de fluxo.
2- V(G) = (Número de Ramos) - (Número de nós) + 2
3- V(G) = (Número de Nós Predicativos) + 1
Teste da caixa branca - caminhos
independentes - Exemplo de complexidade
Ciclomática

Complexidade Ciclomática
Grafo de Fluxo
1
1- O Grafo de fluxo tem 4 regiões.
2,3
2- V(G) = 11ramos - 9 nós + 2 = 4
6
7
4,5
8
3- V(G) = 3 Nós predicativos + 1 = 4
A complexidade do grafo de fluxo é 4.
9
10
11
A complexidade ciclomática indica o
número de casos de teste que devem
ser projetados para garantir a cobertura
de todas as instruções de um programa
Exemplo completo - teste da caixa
Branca
Procedimento Maior (A:vetor; T:inteiro;
var MAX:inteiro);
Variáveis I,M inteiro
Início
1- M
A[ 1];
2- I
2;
3- enquanto I<= T faça
4- se A[I] > M
5então M
A[I];
6I
I + 1;
7senão I
I +1;
8- fim se
9- fim enquanto
10MAX
M;
fim do procedimento;
1- Grafo de fluxo
1,2
3
R1
7
4
R2
8
9
10
R3
5,6
Exemplo completo - teste da caixa
Branca - (cont.)
1,2
2. Determinar a complexidade ciclomática
3
1- Número de regiões no grafo = 3
2- V(G) = 9 ramos - 8 nós + 2 = 3
3- V(G) = 2 nós predicativos +1 = 3
==> A complexidade ciclomática é 3
3. Identificar os caminhos independentes
caminho 1: 1,2,3,10
caminho 2: 1,2,3,4,5,6,8,9,3
caminho 3: 1,2,3,4,7,8,9,3
R1
7
4
R2
8
9
10
R3
5,6
Exemplo completo - teste da caixa
Branca
4. Fazer Casos de Teste para cada caminho encontrado:
Casos de teste
Caminho 1: 1,2,3,10
Caminho 2: 1,2,3,4,5,6,8,9,3
Caminho 3: 1,2,3,4,7,8,9,3
Entrada
A=(1,3)
T =0
Saída Esperada
MAX =1
A = (1,3)
T=2
MAX = 3
A = (3,1)
T=2
MAX = 3
Exemplo 2- teste da caixa Branca
Lógica composta - E
1
1- Grafo de fluxo
2
3
10
12
11
13
4
5
6
8
Procedimento médio;
define variáveis;
1- i= 0; te=0;tv=o;s=0;
2- enquanto valor[i] <> E
3te <0
4- te = te +1
5- Se valor[i] >= min E
6valor[i] <= max
7tv= tv + 1;
8- fim se
9- fim enquanto
10- se tv >0
11- media = s/tv;
12- Senao media = -999;
13- Fim se
fim do procedimento;
9
7
SE a OU b então x senão y
a
b
y
x
x
Lógica composta - OU
Teste da Caixa Branca - exercícios
/* calc.c */
1.
main()
2.
{
3.
float num1, num2;
4.
char op;
5.
while (1) { /* sempre verdadeiro */
6.
printf(“Digite um numero, operador, numero\n”);
7.
scanf(“%f %c %f”, &num1, &op, &num2);
8.
if (op==`+`)
9.
printf(“ = %f,num1 + num2);
10.
Else
11.
If (op==´-´ )
12.
Printf(“ = %f, num1 - num2);
13.
Else
14.
If (op==’*’)
15.
Printf (“ = %f”, num1+ num2);
16.
Else
17.
If(op ==’/’)
18.
Printf(“ = %f”,num1/num2);
19.
Printf(“\n\n”);
20.
}
21.
}
Teste da Caixa Preta
Concentram-se nos requisitos funcionais do software.
O teste da caixa preta procura descobrir erros nas seguintes
categorias:
1- funções incorretas ou ausentes
2- erros de interface
3- erros nas estruturas de código
4- erros de desempenho
5- erros de inicialização ou término
Teste da Caixa Preta (Teste Funcional)
Input test data
I
Inputs causing
anomalous
behaviour
e
System
Output test results
Oe
Outputs which reveal
the presence of
defects
Particionamento de Equivalência




É um método de teste que divide o domínio de entrada de um
programa em classes de dados a partir das quais os casos de teste
podem ser derivados.
O particionamento de equivalencia procura definir um caso de teste
que descubra classes de erros, reduzindo assim o número total de
casos de teste que devem ser desenvolvidos.
O projeto de casos de teste para o particionamento de equivalencia
baseia-se numa avaliação de classes de equivalencia para uma
condição de entrada.
Uma classe de equivalencia representa um conjunto de estados
válidos ou inválidos para condições de entrada. Típicamente pode
ser um valor numérico, um intervalo de valores, um conjunto de
valores relacionados ou uma condição booleana.
Particionamento de Equivalência

As classes de equivalência podem ser definidas de acordo com as
seguintes diretrizes:
1- Se uma condição de entrada especificar um intervalo, uma classe de
equivalência e duas classes 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 classes de equivalência inválidas são
definidas.
3- Se uma condição de entrada especificar um membro de uma conjunto,
uma classe de equivalência válida e uma classe de equivalência
inválida são definidas.
4- Se uma condição de entrada for booleana, uma classe de equivalência
válida e uma classe de equivalência inválida são definidas.
Equivalence partitioning
Invalid inputs
System
Outputs
Valid inputs
Particionamento de Equivalência


As entradas e saídas do sistema são particionadas em "conjuntos
de equivalencia".
EXEMPLO:
•
•

Se a entrada é um inteiro de 5 dígitos entre 10.000 e 99.999,
as classes de equivalencia são:
<10.000, entre 10.000 e 99.999 , > 99.999
Temos 3 conjuntos de equivalência:
Duas classes inválidas: valores < 10.000
valores > 99.999
Uma classe válida: valores >= 10.000 e <= 99.999
Procure fazer casos de teste para cada classe de equivalencia
Particionamento de Equivalencia
3
4
Less than 4
7
11
10
Between 4 and 10
More than 10
Number of input values
9999
10000
Less than 10000
Input values
50000
100000
99999
Between 10000 and 99999
More than 99999
Análise do Valor Limite




A análise do valor limite (BVA - Boundary Values Analysis) é uma
técnica de projetos de casos de teste que complementa o
particionamento de equivalência.
Em vez de selecionar qualquer elemento da classe de
equivalência, a BVA leva a seleção de casos de teste nas
"extremidades" da classe (por razões que não são completamente
claras, um número maior de erros tende a ocorrer nas fronteiras do
domínio de informação)
Em vez de se concentrar somente nas condições de entrada, a
BVA deriva casos de teste também no domínio de saída.
Para o exemplo anterior teríamos casos de teste adicionais com os
valores: 00000, 09999, 10000, 99999, 10001