Fundamentos de Engenharia de SW
TÉCNICAS DE TESTE DE SOFTWARE
1
TESTE DE SOFTWARE
• GARANTIA DE QUALIDADE
– VERIFICAÇÃO E VALIDAÇÃO
• TESTE (última atividade de V & V do
desenvolvimento)
2
CICLO DE VIDA
Análise
Projeto
Codificação
Teste
Operação
3
Custo do Erro
Custo Relativo da Correção de Erros
10000
1000
100
10
1
Requisitos
Análise e Projeto
Código
Teste
Produção
4
UMA ESTRATÉGIA DE TESTE
•
•
•
•
Teste de unidade
Teste de integração
Teste de validação
Teste de sistema
5
TESTE DE SOFTWARE
• Questões psicológicas
– Definições
• ... demonstrar ausência de erros
• ... mostrar que o programa cumpre suas funções
corretamente.
• ... o programa faz o que ele é suposto fazer
6
TESTE DE SOFTWARE
• Questões psicológicas
– Definições
• ... demonstrar ausência de erros
• ... mostrar que o programa cumpre suas funções
corretamente.
• ... o programa faz o que ele é suposto fazer
• PROCESSO DE EXECUTAR UM PROGRAMA
COM A INTENÇÃO DE ACHAR ERROS
(conotação destrutiva)
7
TESTE DE SOFTWARE
• Questões psicológicas
– Teste bem (e mal) sucedido)
– Impossibilidade (prática) de detetar todos os erros
– Problematização da definição: ... faz o que é suposto
fazer.
8
TESTE DE SOFTWARE
• Questões econômicas
– A impossibilidade de se encontrar todos os erros.
• Nos testes caixa preta
• Nos testes caixa branca
– Dada a impossibilidade, quantos erros se deve
descobrir? Quanto se deve investir no teste?
– Maximizar o número de erros encontrados por um
número “finito” de casos de teste
9
TOTAL DE CAMINHOS
A
20 vezes
B
10
TOTAL DE CAMINHOS
A
B
520 + 519 + ... + 5 ~ 1014
11
TESTE DE SOFTWARE
• Testes de software (Myers):
– processo de executar um programa com o objetivo de encontrar
erros.
– bom caso de teste é aquele que tem uma alta probabilidade de
revelar um erro ainda não descoberto.
– teste bem sucedido é aquele que revela um erro ainda não
descoberto.
• Sucesso na atividade de teste:
– descobrir erros no software
• Teste de software:
– não mostra a ausência de bugs - somente sua presença.
12
TIPOS DE TESTE
• Caixa Preta
– baseado na especificação
– o testador não conhece o módulo “por dentro”, mas apenas sua
interface (o módulo é opaco)
– data driven
• Caixa Branca
– baseado na lógica interna
– o testador conhece o módulo “por dentro” (o módulo é
transparente)
– logic driven
13
TESTE DE CAIXA BRANCA
• Teste do caminho básico.
• Teste dos fluxos de dados.
• Teste dos laços.
14
TESTE DO CAMINHO BÁSICO
• O teste do caminho básico
– deriva uma medida da complexidade lógica do procedimento
– use essa medida para definir um conjunto básico de caminhos de
execução.
• Estes casos de teste
– Garantem a execução de cada instrução do programa (cada aresta
do grafo de fluxo) pelo menos uma vez
• Como obter uma medida da complexidade lógica do procedimento?
– A partir do grafo do fluxo (representação do fluxo de controle).
15
GRAFO DE FLUXO
If
Case
Sequence
While
Until
16
GRAFO DE FLUXO
1
2
3
6
4
7
8
5
9
10
11
17
GRAFO DE FLUXO
1
1
2,
3
2
4,
5
6
3
7
6
8
4
9
7
8
5
1
0
9
10
11
1
1
18
CAMINHO INDEPENDENTE
• Um caminho independente é um caminho no grafo de fluxo que
inclui pelo menos uma aresta nova (que não tenha sido ainda
atravessada)
• Conjunto básico é o conjunto formado pelos caminhos independentes
que cubram todas as arestas do grafo de fluxo
• A complexidade ciclomática é uma métrica de software que
proporciona uma medida da complexidade lógica de um programa.
• O valor da complexidade ciclomática estabelece um limite superior
para o número de caminhos independentes
19
COMPLEXIDADE CICLOMÁTICA
• A complexidade ciclomática
– Baseado na teoria dos grafos
– Dado um grafo G, V(G) =
• número de regiões do grafo de fluxo
• E – N + 2, onde E corresponde ao número de arestas e N o
número de nós do grafo de fluxo.
• P + 1, onde P é o número de nós predicativos (desviantes)
contidos no grafo.
20
COMPLEXIDADE CICLOMÁTICA
1
2,
3
4,
5
6
7
8
9
1
0
1
1
21
COMPLEXIDADE CICLOMÁTICA
1
2,
3
4,
5
6
7
R3
R1
8
R2
9
R4
1
1
1
0
O grafo de fluxo tem 4 regiões.
V(G) = 11 arestas – 9 nós + 2 = 4
V(G) = 3 nós predicativos + 1 = 4
Portanto a complexidade ciclomática é 4
22
Caminhos Independentes
1
2,
3
4,
5
6
7
R3
R1
8
R2
9
R4
1
0
1
1
23
Caminhos Independentes
1
2,
3
4,
5
6
7
R3
R1
8
R2
1: 1-11
9
R4
1
1
1
0
2: 1-2-3-4-5-10-1-11
3: 1-2-3-6-8-9-10-1-11
4: 1-2-3-6-7-9-10-1-11
24
DERIVANDO CASOS DE TESTE
• Usando o projeto ou o código como base, trace um grafo
de fluxo.
• Determine a complexidade ciclomática do grafo de fluxo
resultante.
• Determine um conjunto básico de caminhos independentes
• Prepare os casos de teste que forcem a execução de cada
caminho no conjunto básico.
25
EXEMPLO
• PROCEDURE AVERAGE;
•
•
INTERFACE RETURNS average, total.input, total.valid;
INTERFACE ACCEPTS value, minimum, maximum;
•
•
•
•
TYPE value [1:100] IS SCALAR ARRAY;
TYPE average, total.input, total.valid,
minimum, maximum, soma IS SCALAR;
TYPE i IS INTEGER;
26
EXEMPLO
•
i = 1;
2
•1
total.input = total.valid = 0;
3
6
•
sum = 0;
•
DO WHILE value[i] <> -999 AND total.input <100
• 4 increment total.input by 1;
•
IF value[i] >= minimum AND value[i] <= maximum
• 5
THEN increment total.valid by 1;
•
sum = sum + value[i]
• 7
ELSE skip
•
ENDIF
•8
increment i by 1;
• 9 ENDDO
•
IF total.valid > 0 10
• 11 THEN average = sum / total.valid;
•
ELSE average = -999; 12
• 13 ENDIF
• END
27
EXEMPLO
•
i = 1;
2
•1
total.input = total.valid = 0;
3
6
•
sum = 0;
•
DO WHILE value[i] <> -999 AND total.input <100
• 4 increment total.input by 1;
•
IF value[i] >= minimum AND value[i] <= maximum
• 5
THEN increment total.valid by 1;
1
•
sum = sum + value[i]
0
7
•
ELSE skip
1
1
2
1
•
ENDIF
1
•8
increment i by 1;
3
• 9 ENDDO
•
IF total.valid > 0 10
• 11 THEN average = sum / total.valid;
8
•
ELSE average = -999; 12
• 13 ENDIF
• END
1
2
3
4
5
6
7
9
28
EXEMPLO
1
Complexidade Ciclomática:
2
6 = 17 – 13 + 2 = 5 + 1
3
Caminhos:
4
1: 1-2-10-11-13
5
2: 1-2-10-12-13
6
3: 1-2-3-10-11-13
1
0
1
2
1
1
1
3
7
8
4: 1-2-3-4-5-8-9-2-...
5: 1-2-3-4-5-6-8-9-2-...
9
6: 1-2-3-4-5-6-7-8-9-2-...
29
EXEMPLO
CASOS DE TESTE
Caminho
Min Max Value
Average t.input t.valid
1: 1-2-10-11-13
10
50
-
2: 1-2-10-12-13
10
50
-999
3: 1-2-3-10-11-13
10
50
12, 30, ...
4: 1-2-3-4-5-8-9-2-...
10
50
5, -999
0
1
0
5: 1-2-3-4-5-6-8-9-2-...
10
50
60, -999
0
1
0
6: 1-2-3-4-5-6-7-8-9-2-...
10
50
30, -999
30
1
1
-999
0
0
100
30
EXEMPLO
CASOS DE TESTE
Caminho
Min Max Value
Average t.input t.valid
1: 1-2-10-11-13
10
50
-
2: 1-2-10-12-13
10
50
-999
3: 1-2-3-10-11-13
10
50
12, 30, ...
4: 1-2-3-4-5-8-9-2-...
10
50
5, -999
0
1
0
5: 1-2-3-4-5-6-8-9-2-...
10
50
60, -999
0
1
0
6: 1-2-3-4-5-6-7-8-9-2-...
10
50
30, -999
30
1
1
-999
0
0
100
31
TESTE DO FLUXO DE DADOS
• O método de teste de fluxo de dados
– seleciona caminhos de teste de um programa de acordo com as
localizações das definições e usos de variáveis no programa.
• Def(S) = {X | S contem uma definição de X};
• Use(S) = {X | S contem um uso de X};
• uma definição de X em S está viva em S1 se existe um
caminho de S a S1que não contenha outra definição de X
• Cadeia DU = [X,S,S1] onde X  Def(S) e X  Use(S1) e a
definição de X em S está viva em S1.
• Testar todas DUs.
32
TESTE DOS LAÇOS (LOOPS)
• focaliza a validade das construções de laços.
• Quatro tipos: simples, aninhados, concatenados, nãoestruturados.
• Casos de teste para laços simples (n: maximo de iterações):
– pular o laço
– executar 1 passada
– executar m passadas ( m<n)
– executar n-1, n, n+1 passadas
33
TESTE DE CAIXA PRETA
• Concentra-se nos requisitos funcionais do software.
• Procura descobrir os seguintes tipos de erro:
– Funções incorretas ou ausentes;
– Erros de interface;
– Erros na estrutura de dados ou no acesso a banco de
dados externos;
– Erros de desempenho e
– Erros de inicialização e término.
34
PARTICIONAMENTO POR EQUIVALÊNCIA
• propõe dividir o domínio de entrada em classes (partições) cujos dados
produzam o “mesmo comportamento” na execução do teste, ou seja,
os dados de uma classe ou devem todos não dar erro, ou todos o
mesmo tipo de erro.
• diretrizes para definição de classes. Se a condição de entrada
– especifica um intervalo então uma classe válida e duas inválidas.
– requer um valor então uma classe válida e duas inválidas.
– especifica a pertinência a um conjunto então uma válida e uma
inválida
– é booleana então uma classe válida e uma inválida
35
ANÁLISE DOS VALORES LIMITE
• Um maior número de erros tende a ocorrer nas fronteiras do domínio
de entrada do que no centro.
• Complementa o particionamento por equivalência
• Diretrizes:
– se a condição de entrada especificar um intervalo (a .. b) inclua
casos com valores a e b, e logo acima e logo abaixo de a e b.
– se uma condição de entrada especifica um conjunto de valores,
inclua casos com os valores máximo e mínimo, e também com
valores logo acima e logo abaixo de a e b.
– idem ao caso acima para intervalos de saídas.
– testar valores limites das estruturas de dados.
36
BIBLIOGRAFIA
• Capítulo 14, Pressman, R., Engenharia de Software, 6a
edição, McGraw Hill, 2006.
• Capítulos 1 e 2, Myers, G., The Art os Software Testing,
Wilwy, 1979.
37