PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

Transcrição

1 PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

2 CMP1132 Processo e qualidade de software II Prof. Me. Elias Ferreira Sala: 402 E Quarta-Feira: 20:30 as 22:00 Sábado: 10:50 as 12:20

3 Níveis de teste de software

4 Níveis de teste de software Planejamento e projeto dos testes devem ocorrer de cima para baixo, ou seja: 1. Inicialmente é planejado o teste de aceitação a partir do documento de requisitos; 2. Após isso é planejado o teste de sistema a partir do projeto de alto nível do software; 3. Em seguida ocorre o planejamento dos testes de integração a partir do projeto detalhado; 4. E por fim, o planejamento dos testes a partir da codificação. A execução ocorre no sentido inverso

5 Técnicas de teste de software Atualmente existem muitas maneiras de se testar um software. Técnicas muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda têm grande valia para os sistemas orientados a objeto. Apesar de os paradigmas de desenvolvimento serem diferentes, o objetivo é o mesmo: encontrar falhas no software.

6 Técnicas de teste de software As técnicas de teste são classificadas de acordo com a origem das informações utilizadas para estabelecer os requisitos de teste.

7 Técnicas de teste de software Contemplam diferentes perspectivas do software e impõe-se a necessidade de se estabelecer uma estratégia de teste que contemple as vantagens e os aspectos complementares dessas técnicas. As técnicas existentes são: funcional e estrutural.

8 Técnica Estrutural (ou teste caixabranca) Técnica de teste que avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição; teste de fluxo de dados teste de ciclos teste de caminhos lógicos

9 Teste Estrutural Aspectos avaliados dependerão da complexidade e da tecnologia que determinarem a construção do componente de software. Testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes.

10 Teste Estrutural Este tipo de teste é desenvolvido analisandose o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do componente de software. Todas as variações originadas por estruturas de condições são testadas.

11 /* 01 */ { /* 01 */ char achar; /* 01 */ int length, valid_id; /* 01 */ length = 0; /* 01 */ printf ("Digite um possível identificador\n"); /* 01 */ printf ("seguido por <ENTER>: "); /* 01 */ achar = fgetc (stdin); /* 01 */ valid_id = valid_starter (achar); /* 01 */ if (valid_id) /* 02 */ length = 1; /* 03 */ achar = fgetc (stdin); /* 04 */ while (achar!= '\n') /* 05 */ { /* 05 */ if (!(valid_follower (achar))) /* 06 */ valid_id = 0; /* 07 */ length++; /* 07 */ achar = fgetc (stdin); /* 07 */ } /* 08 */ if (valid_id && (length >= 1) && (length < 6) ) /* 09 */ printf ("Valido\n"); /* 10 */ else /* 10 */ printf ("Invalido\n"); /* 11 */ } Teste Estrutural - Exemplo

12 Grafo de Programa

13 Teste Estrutural Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de casos de teste para avaliar classes ou métodos desenvolvidos na linguagem Java.

14 Teste Estrutural A técnica de teste Estrutural é recomendada para os níveis de Teste da Unidade e Teste da Integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que são profissionais que conhecem bem o códigofonte desenvolvido e dessa forma conseguem planejar os casos de teste com maior facilidade.

15 Método dos Caminhos Básicos Método criado pelo matemático norteamericano Thomas McCabe baseado na teoria de grafos. Sua lógica consiste essencialmente em fazer com que os casos de teste sejam gerados de forma a fazer com que o fluxo do programa passe por um número mínimo de caminhos entre a entrada e a saída do programa, sem o risco de ocorrerem redundâncias.

16 Grafo de Controle É um grafo orientado (ou seja, suas arestas possuem setas) que descreve o fluxo de controle do programa. Na realidade, o grafo de controle não passa de um fluxograma com símbolos diferentes, quais sejam:

17 Exemplo Grafo de Controle procedure Teste(A,B,C : integer); begin if A=B then A : = A + 1 else if B = C then B : = B+1 else B : = B -1; end;

18 Caminhos independentes Dentre um conjunto de caminhos identificados para um grafo, dizemos que eles são independentes quando nenhum deles é formado da combinação de dois ou mais outros. Para determinarmos os caminhos independentes de um grafo, temos que inicialmente determinar quantos são.

19 Caminhos independentes Um caminho independente é qualquer caminho ao longo do programa que introduz pelo menos um novo conjunto de comandos de processamento ou uma nova condição. Quando enunciado em termos de grafo de fluxo, um caminho independente deve incluir pelo menos uma nova aresta que não tenha sido atravessada antes do caminho ser definido.

20 Caminhos independentes Existem 3 formas de se determinar este número, também denominado complexidade ciclomática: 1. Contar o número de regiões no grafo de controle. No exemplo da figura 3, temos três regiões, R1, R2 e R3: as duas internas(r1 e R2) e a externa (R3). Logo, este grafo tem 3 caminhos independentes.

21 Caminhos independentes 2. Aplicar a fórmula: C = E - N + 2 C = número de caminhos independentes E = número de arestas N = número de nós No exemplo da figura 3 temos: E = 7, N = 6, logo C = = 3

22 Caminhos independentes 3. Método manual: Contar o número de estruturas de decisão no programa e somar 1. No exemplo da figura 3, temos 2 "if". Logo, o número de caminhos independentes é 3.

23 Caminhos independentes Para identificar os caminhos independentes em um grafo fazemos o seguinte: Determinar o número de caminhos independentes conforme visto anteriormente. Tomar o caminho mais a esquerda possível no grafo como primeiro caminho independente. No exemplo, este caminho é o ac. Tomar o próximo caminho à direita, tendo o cuidado de incluir nele pelo menos uma aresta que não tenha sido incluída nos outros caminhos já determinados. No exemplo, caminho bdg. Repetir o passo anterior até que se obtenham todos os caminhos. No exemplo, só nos resta o caminho bef.

24 Geração dos Casos de Teste Cada caminho obtido dará origem a um caso de teste. Os casos de teste são gerados de forma que façam com que os caminhos aos quais correspondam sejam percorridos. No exemplo temos: Caminho ac: Entradas: A=3, B=3, C=3. Saídas: A=4, B=3. Caminho bdg: Entradas: A=3, B=4, C=4. Saídas: A=3, B=4. Caminho bef: Entradas: A=3, B=5, C=6. Saídas: A=3, B=4.

25 Passos do método Passo 1: Desenhar o grafo de controle Passo 2: Determinar o número de caminhos independentes (complexidade ciclomática) Passo 3: Obter os caminhos independentes Passo 4: Para cada caminho, gerar os casos de teste, utilizando a especificação do programa para inferir os resultados esperados. Passo 5: Executar cada caso de teste Checar os resultados obtidos contra os esperados O teste estará completo quando houver confiança absoluta em que todos os casos de teste obtêm resultados satisfatórios.

26 Gráfico de Fluxo: condições complexas

27 Teste Funcional (ou teste caixapreta) Técnica de teste em que o componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo.

28 Teste Funcional Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido.

29 Teste Funcional Haverá sucesso no teste se o resultado obtido for igual ao resultado esperado. O componente de software a ser testado pode ser um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. A técnica de teste funcional é aplicável a todos os níveis de teste.

30 Particionamento em classes de equivalência Esse critério divide o domínio de entrada de um programa em classes de equivalência, a partir das quais os casos de teste são derivados. Ele tem por objetivo minimizar o número de casos de teste, selecionando apenas um caso de teste de cada classe, pois em princípio todos os elementos de uma classe devem se comportar de maneira equivalente.

31 Particionamento em classes de equivalência Uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma condição de entrada. Tipicamente uma condição de entrada pode ser um valor numérico específico, uma faixa de valores, um conjunto de valores relacionados, ou uma condição lógica.

32 Particionamento em classes de equivalência As seguintes diretrizes podem ser aplicadas: Se uma condição de entrada especifica uma faixa de valores ou requer um valor específico, uma classe de equivalência válida (dentro do limite) e duas inválidas (acima e abaixo dos limites) são definidas. Se uma condição de entrada especifica um membro de um conjunto ou é lógica, uma classe de equivalência válida e uma inválida são definidas.

33 Particionamento em classes de equivalência Devemos seguir tais passos para geração dos testes usando este critério: 1. Identificar classes de equivalência (é um processo heurístico): Condição de entrada válidas e inválidas 2. Definir os casos de teste enumeram-se as classes de equivalência casos de teste para as classes válidas casos de teste para as classes inválidas

34 Exemplo: programa identifier.c

35 Exemplo Programa identifier.c. Deve determinar se um identificador é válido ou não. O primeiro passo é a identificação das classes de equivalência.

36 Exemplo A partir disso, conseguimos especificar quais serão os casos de teste necessários. Para ser válido, um identificador deve atender às condições (1), (3) e (5), logo é necessário um caso de teste válido que cubra todas essas condições. Além disso, será necessário um caso de teste para cada classe inválida: (2), (4) e (6). Assim, o conjunto mínimo é composto por quatro casos de teste, sendo uma das opções: T0 = {(a1,válido), (2B3, Inválido), (Z-12, Inválido), (A1b2C3d, Inválido)}.

37

38 Análise do valor limite Por razões não completamente identificadas, um grande número de erros tende a ocorrer nos limites do domínio de entrada invés de no centro. Esse critério de teste explora os limites dos valores de cada classe de equivalência para preparar os casos de teste.

39 Análise do valor limite Se uma condição de entrada especifica uma faixa de valores limitada em a e b, casos de teste devem ser projetados com valores a e b e imediatamente acima e abaixo de a e b. Exemplo: Intervalo = {1..10}; Casos de Teste à {1, 10, 0,11}.

40 Análise do valor limite Exemplo: "... o cálculo do desconto por dependente é feito da seguinte forma: a entrada é a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes até 12 anos (inclusive) o desconto é de 15%. Entre 13 e 18 (inclusive) o desconto é de 12%. Dos 19 aos 21 (inclusive) o desconto é de 5% e dos 22 aos 24 de 3%... Casos de teste : {-1,0,12,13,18,19,21,22,24,25}

41 Grafo de causa-efeito Esse critério de teste verifica o efeito combinado de dados de entrada. As causas (condições de entrada) e os efeitos (ações) são identificados e combinados em um grafo a partir do qual é montada uma tabela de decisão, e a partir desta, são derivados os casos de teste e as saídas.

42 Grafo de causa-efeito Exemplo: Em um programa de compras pela Internet, a cobrança ou não do frete é definida seguindo tal regra: Se o valor da compra for maior que R$ 80,00 e foram comprados menos que 3 produtos, o frete é gratuito. Caso contrário, o frete deverá ser cobrado.

43 Grafo de causa-efeito 1. Para cada módulo, Causas (condições de entrada) e efeitos (ações realizadas às diferentes condições de entrada) são relacionados, atribuindo-se um identificador para cada um. Causa: valor da compra > 60 e #produtos < 3 Efeito: frete grátis

44 Grafo de causa-efeito 2. Gerar grafo de causa-efeito:

45 Grafo de causa-efeito 3. Transformar o grafo em uma tabela de decisão:

46 Grafo de causa-efeito 4. As regras da tabela de decisão são, então, convertidas em casos de teste: Devemos seguir todas as regras extraídas da tabela. Esse critério deve ser combinado com os dois outros já apresentados para a criação de casos de teste válidos (extraídos das regras) e inválidos (valores foras da faixa definida). Casos de Teste (valor, qtd produtos, resultado esperado) = {(61,2, frete grátis ); (61,3, cobrar frete ); (60, qualquer quantidade, cobrar frete )}