Fundamentos de Engenharia de SW

Apresentação em tema: "Fundamentos de Engenharia de SW"— Transcrição da apresentação:

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 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 20 vezes B

11 TOTAL DE CAMINHOS A B ~ 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 Caixa Branca 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 Case If Sequence While Until

17 GRAFO DE FLUXO 1 2 3 6 4 7 8 5 9 10 11

18 GRAFO DE FLUXO 1 1 2,3 2 6 4,5 3 7 8 6 4 9 7 8 5 10 9 10 11 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. Um caminho independente é qualquer caminho através do programa que introduza pelo menos um novo conjunto de instruções de processamento ou uma nova condição.

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 6 4,5 7 8 9 10 11

22 COMPLEXIDADE CICLOMÁTICA
1 2,3 6 4,5 R3 R1 7 8 R2 9 10 R4 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 11

23 Caminhos Independentes
1 2,3 6 4,5 R3 R1 7 8 R2 9 R4 10 11

24 Caminhos Independentes
1 2,3 6 4,5 R3 R1 7 8 R2 1: 1-11 2: 3: 4: 9 R4 10 11

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; END 2 3 1 6 4 5 7 8 9 10 11 12 13

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; END 2 3 1 6 1 4 2 5 3 10 7 4 12 11 8 5 13 9 6 10 7 11 8 12 13 9

29 EXEMPLO Complexidade Ciclomática: 6 = 17 – 13 + 2 = 5 + 1 Caminhos:
6 = 17 – = 5 + 1 2 3 Caminhos: 1: 2: 3: 4: 5: 6: 10 4 12 11 5 13 6 7 8 9

30 EXEMPLO CASOS DE TESTE Caminho Min Max Value Average t.input t.valid
1: 10 50 - 2: -999 3: 12, 30, ... 100 4: 5, -999 1 5: 60, -999 6: 30, -999 30

31 EXEMPLO CASOS DE TESTE Caminho Min Max Value Average t.input t.valid
1: 10 50 - 2: -999 3: 12, 30, ... 100 4: 5, -999 1 5: 60, -999 6: 30, -999 30

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.