1

Fundamentos de Engenharia de SW

TÉCNICAS DE TESTE DE SOFTWARE

2

TESTE DE SOFTWARE

• GARANTIA DE QUALIDADE

– VERIFICAÇÃO E VALIDAÇÃO

• TESTE (última atividade de V & V do desenvolvimento)

3

CICLO DE VIDA

Análise

Projeto

Codificação

Teste

Operação

4

1

10

100

1000

10000

Requisitos Análise e Projeto Código Teste Produção

Cu

sto

Re

lati

vo d

a C

orr

eç

ão

de

Err

os

Custo do Erro

5

UMA ESTRATÉGIA DE TESTE

• Teste de unidade

• Teste de integração

• Teste de validação

• Teste de sistema

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

7

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)

8

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.

9

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

10

TOTAL DE CAMINHOS

A

B

20 vezes

11

TOTAL DE CAMINHOS

A

B

520 + 519 + ... + 5 ~ 1014

12

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.

13

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

14

TESTE DE CAIXA BRANCA

• Teste do caminho básico.

• Teste dos fluxos de dados.

• Teste dos laços.

15

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).

16

GRAFO DE FLUXO

Sequence

If Case

WhileUntil

17

GRAFO DE FLUXO

1

3

6

2

5

4

8 7

10

9

11

18

GRAFO DE FLUXO

1

3

6

2

5

4

8 7

10

9

11

1

2,3

4,5

6

7 8

9

10

11

19

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

• Diferentes conjuntos de caminhos básicos podem ser derivados para um dado procedimento.

20

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.

21

COMPLEXIDADE CICLOMÁTICA

1

2,3

4,5

6

7 8

9

10

11

22

COMPLEXIDADE CICLOMÁTICA

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

1

2,3

4,5

6

7 8

9

10

11

R1

R4

R3

R2

23

Caminhos Independentes

1

2,3

4,5

6

7 8

9

10

11

R1

R4

R3

R2

24

Caminhos Independentes

1: 1-11

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

1

2,3

4,5

6

7 8

9

10

11

R1

R4

R3

R2

25

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.

26

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;

27

EXEMPLO

• i = 1;• total.input = total.valid = 0;• sum = 0;• DO WHILE value[i] <> -999 AND total.input <100• increment total.input by 1;• IF value[i] >= minimum AND value[i] <= maximum • THEN increment total.valid by 1;• sum = sum + value[i]• ELSE skip • ENDIF• increment i by 1;• ENDDO• IF total.valid > 0• THEN average = sum / total.valid;• ELSE average = -999;• ENDIF• END

1

13 1211

109

7

5

6

8

3

4

2

28

EXEMPLO

• i = 1;• total.input = total.valid = 0;• sum = 0;• DO WHILE value[i] <> -999 AND total.input <100• increment total.input by 1;• IF value[i] >= minimum AND value[i] <= maximum • THEN increment total.valid by 1;• sum = sum + value[i]• ELSE skip • ENDIF• increment i by 1;• ENDDO• IF total.valid > 0• THEN average = sum / total.valid;• ELSE average = -999;• ENDIF• END

1

13 1211

109

7

5

6

8

3

4

2

1

11

13

12

9

8

7

6

5

4

3

2

10

29

EXEMPLO

1

11

13

12

9

8

7

6

5

4

3

2

10

Complexidade Ciclomática:

6 = 17 – 13 + 2 = 5 + 1

Caminhos:

1: 1-2-10-11-13

2: 1-2-10-12-13

3: 1-2-3-10-11-13

4: 1-2-3-4-5-8-9-2-...

5: 1-2-3-4-5-6-8-9-2-...

6: 1-2-3-4-5-6-7-8-9-2-...

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 -999 0 0

3: 1-2-3-10-11-13 10 50 12, 30, ... 100

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

31

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 -999 0 0

3: 1-2-3-10-11-13 10 50 12, 30, ... 100

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

32

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.

33

TESTE DOS LAÇOS (LOOPS)

• focaliza a validade das construções de laços.

• Quatro tipos: simples, aninhados, concatenados, não-estruturados.

• 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

34

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.

35

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

36

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.

37

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.