Teste de Software. Técnica de Teste Estrutural. Rosemary Silveira Filgueiras Melo

Transcrição

1 Teste de Software Técnica de Teste Estrutural Rosemary Silveira Filgueiras Melo 1

2 Agenda Casos de Teste e Cenários de Teste Técnicas de Teste Técnica de Teste Estrutural 2

3 Casos de Teste Diante da impossibilidade de se realizar teste exaustivo é necessário realizar casos de teste com critérios de teste específico com o fim de identificar erros. Conceitos de Casos de teste: conjunto de dados de entrada, condições de execução do sistema e resultado desenvolvido/projetado para atingir um objetivo específico (IEEE ). Sequência de passos que devem ser executados no sistema, sendo que os dados de entrada e saída esperada para cada passo são especificados. 3

4 Modelo de Casos de Teste Itens do Caso de teste (conforme norma IEEE ) Identificador do caso de teste Objetivo do caso de teste Entradas Saídas Ambientes necessários ou condições de ambiente Execução do caso de teste Dependência entre outros casos de teste Número de identificação do caso de teste Define o objetivo do caso de teste Entradas que serão consideradas no caso de teste Saídas esperadas de acordo com as entradas indicadas na execução dos testes Ambiente de hardware e software que devem ser montados para o caso de teste em questão Especifica com detalhe o que deve ser testado e a forma de como o teste deve ser executado Casos de teste relacionados 4

5 Exemplo de Casos de teste 1. Identificador do caso de teste 2. Objetivo do caso de teste Caso de teste 1 Testar Login Verificar login inválido 3. Entradas Inserir um inválido 4. Saídas Exbir mensagem Login inválido 5. Ambientes necessários ou condições de ambiente 6. Execução do caso de teste nenhum 1. Selecione ícone do aplicativo 2. Exibir tela de login 3. Insira um inválido 4. Exbir mensagem Login inválido 5. Exibir cursor no campo de login para usuário poder corrigir login 7. Dependência entre outros casos de teste nenhum 5

6 Casos de Teste Critério de teste: Ajuda a definir um conjunto de casos de teste que potencialmente podem identificar erros. Cada critério de teste possui seus requisitos de teste, que ajudam a gerar os casos de teste de forma a satisfazer os critérios escolhido e também avaliar a qualidade do conjunto de teste existente. 6

7 Casos de Teste Exemplo de Critério de teste Crítério dos números primos menores que 20. Significado: Toda funcionalidade que requer as entradas com números inteiros deve ser testada usando todos os números primos menores que 20. Definir Casos de Teste que considerem como entrada os números 2, 3, 5, 11, 13, 17 e 19. Se não tiver casos de teste para esses números, então não se está em conformidade com os requisitos do critério de teste. 7

8 Cenário de teste Conjunto de casos de teste relacionados, ou agrupamento de casos de teste, que comumente testam o mesmo componente ou a mesma funcionalidade do sistema. Bastante utilizados em teste de regressão (teste realizados na fase de manutenção) para garantir que novas funcionalidades não inseriram defeitos nas antigas. Usados para revalidar mudanças nos casos de teste e treinar novos testadores e pessoas que darão suporte ao sistema. 8

9 Técnicas de Teste Não existe um procedimento genérico que possa ser usado para provar a correção de um programa A norma ISSO/IEC/IEEE define três técnicas de teste: Técnica baseada em estrutura também conhecida como técnica de caixa branca ou técnica estrutural Técnica baseada em código Técnica baseada em especificação também conhecida como técnica de caixa preta ou técnica funcional. Técnica baseada em funcionalidade Técnica baseada em experíência ou técnica baseada em erros. não comumente utilizada na indústria 9

10 Técnica Estrutural (Caixa Branca) Estabelece os requisitos de teste com base em uma dada implementação. Objetivo de testar as linhas de código do sistema (implementação) que irão prover as funcionalidades esperadas pelo sistema. Requer a execução de partes do programa. Adotada quando a equipe de teste tem acesso ao código fonte do sistema Essa técnica considera que o sistema a ser testado é uma caixa branca, ou seja, você sabe exatamente o que está dentro da caixa. 10

11 Técnica Estrutural (Caixa Branca) É preciso saber o que colocar dentro da caixa com base no que tem dentro da caixa (código fonte do sistema) e o que se espera que saia da caixa (saída de dados esperada). O testador deve está preocupado com a lógica que foi implementada o programa. Caminhos lógicos do software são testados fornecendo casos de teste que põem a prova conjunto de condições, laços, definições e uso de variáveis 11

12 Grafo de Fluxo de Controle (GFC) ou Grafo de Programa representação visual do código a ser testado para facilitar a definição dos casos de teste. conjunto de nós conectados por arcos com setas que indicam a direção de execução. Os nós representam um bloco de comando. Bloco de comandos é uma sequência atômica de linhas de código se uma for executada, todas serão. Os arcos indicam a precedência ou a sequência de execução do código e seus desvios. 12

13 Grafo de Fluxo de Controle (GFC) ou Grafo de Programa Um programa P pode ser decomposto em blocos de comandos. A execução do primeiro comando do bloco acarreta a execução dos demais comandos do bloco, na ordem especificada. Todos os comandos do bloco tem um único predecessor e um único sucessor, exceto o último e o primeiro. Não existe desvio de execução para nenhum comando dentro do bloco. 13

14 Grafo de Fluxo de Controle (GFC) ou Grafo de Programa Para um programa P o GFC é dado por (G=(N,E,s)) N representa o conjunto de nós E representa o conjunto de arcos s representa o nó de entrada GFC é um grafo orientado com um único nó de entrada (s que pertence N) e um único nó de saída (o que pertence a N) Faz-se uma correspondência entre vértices (nós) e blocos Cada vértice representa um bloco indivisível de comandos Cada aresta representa um possível desvio de um bloco para outro 14

15 Representação de Estruturas de Programação Representação de Estruturas de programação em grafo de fluxo de controle Adaptado de (Pressman, Engenharia de Software, 2006) 15

16 16

17 Critérios Os critérios do teste estrutural são baseados em: Complexidade Fluxo de controle Teste de Comandos ou Teste todos os nós Teste de Ramos ou todas as tarefas ou todos os arcos Todos Caminhos Fluxo de dados Todos os usos 17

18 Critérios baseados em complexidade Utilizam informações sobre a complexidade do programa para derivar os requisitos de teste Ex. Critério McCabe (teste de caminho básico) Utiliza a complexidade ciclomática para derivar os requisitos Métrica para medida quantitativa da complexidade lógica do programa O valor da complexidade define o número de caminhos que serve de limite para derivar casos de teste que cobrem todas as instruções Cada instrução terá a garantia de ser executada pelo menos uma vez Cada condição terá sido executada com verdadeiro ou falso Ex. de calculo V(G) = E N + 2, tal que E: número de arcos N: número de nós 18

19 Critérios baseados em fluxo de controle Utilizam características de controle da execução do programa Ex.: Comandos, desvios Critério Todos-Nós: exige que a execução do programa passe ao menos uma vez em cada nó do GFC (cada comando seja executado pelo menos uma vez) Critério Todas-Arestas (ou Todos-Arcos): requer que cada arco do grafo (cada desvio de fluxo de controle do programa) seja exercitada pelo menos uma vez. Critério Todos-Caminhos: requer que todos os caminhos possíveis do programa sejam executados Mínimo esperado: Todos-Nós Pode ser um número muito grande de caminhos (até infinito) 19

20 Critérios baseados em fluxo de controle Critério Todos-Nós - Teste de Comandos ou Teste todos os nós Define como requisito de teste que todos os comandos dos programas sejam executados pelo menos uma vez. Deve-se criar casos de teste cujos nós sejam executados pelo menos uma vez. Deve-se criar uma menor quantidade de casos de teste possível, mas que atinja esse critério. O foco deve ser nos comandos que controlam as decisões do sistema visando direcionar os testes para que todos os nós sejam atingidos. 20

21 Critérios baseados em fluxo de controle Critério Todas-Arestas - Teste de Ramos ou todas as arestas ou todos os arcos Define como requisito de teste que todas as condições verdadeiras e falsas do programa sejam executadas. Todos os arcos (também chamados arestas) do fluxo de controle devem ser executados, mesmo que um nó seja executado mais de uma vez. 21

22 Exemplo utilizando os critério Todos-Nós e Todas-Arestas Para o exemplo acima, dois casos de testes são suficientes: um para uma entrada que faça a execução do programa caminhar para o nó 2 (entrar no IF). outro para uma entrada que faça a execução do programa caminhar para o nó 3 (entrar no SENÃO). Os dois casos de teste atendem os critérios de Teste Todos-Nós e Todas-Arestas Observação: raro satisfazer requisitos de dois critérios para o mesmo conjunto de Casos de teste, só em caso de exemplo bem simples como esse. 22

23 Exemplo utilizando Critério de Todas-Arestas Estar em conformidade com os requisitos de um critério de teste não garante que todos os defeitos serão encontrados. Quanto mais exigente o critério, mais sequência serão necessárias para estarem em conformidade com seu requisito e as chances de identificar os defeitos aumentam. A tendência é que um critério de teste complemente o outro e que o número de casos de teste aumente, a fim de executar o maior número de código fonte possível. Exemplo de alguns casos de teste que atendem esse critério: 23

24 Critérios baseados em fluxo de dados Teste baseado em fluxo de dados Utiliza análise de fluxo de dados para derivar os casos de teste Critério baseados na associação entre a definição de variáveis e seus possíveis usos usa o tipo de uso/ocorrência de uma variável para auxiliar na definição de critérios. Existe três tipos de ocorrências de variáveis: DEF indica definição, quando um valor está sendo atribuído a uma variável C-USO - afeta diretamente uma computação (relacionado aos nós) P-USO - afeta diretamente o fluxo de controle do programa (relacionado aos arcos) 24

25 Critérios de Teste Teste baseado em fluxo de dados - Todos os usos Define como requisito de teste que todos os usos das variáveis utilizadas em cada comando sejam executados. Deve-se identificar os usos de todas as variáveis do programa e classificá-las de acordo com def, c-use e p-use. Construir, para cada variável, uma tabela especificando definição e uso (par d-u) para que esses dados sejam usados na elaboração dos casos de teste. 25

26 Exemplo Ex.: Programa identifier Programa para determinar se um identificador é válido ou não Identificador válido deve começar com uma letra e conter apenas letras e dígitos Deve ter no mínimo 1 e no máximo 6 caracteres de comprimento O programa identifier contém um defeito 26

27 Elabore o GFC para a seguinte implementação: Main() Char achar; Int length, valid_id; Length = 0; Valid_id = 1; Printf( Identificador: ); Achar = fgetc(stdin); Valid_id = valid_s(achar); If (valid_id){ } length = 1; Achar = fgetc(stdin); While (achar!= \n ){ if (!(valid_f(achar))){ } valid_id = 0; } length++; achar = fgetc(stdin); } If (valid_id && (length >= 1) && (length<6)) { printf( valido\n ); } else { } printf( invalido\n ); Int valid_s (char ch){ if (((ch>= A ) && (ch <= Z )) ((ch>= a ) && (ch <= z ))) { Else return (1); return (0); } } Int valid_f(char ch) { if (((ch >= A ) && (ch<= Z )) Else } } ((ch >= a ) && (ch <= z )) ((ch >= 0 ) && (ch <= 9 ))){ return (1); return (0); 27

28 Grafo de Fluxo de Controle do programa anterior 1 2 (2,3,4,5,6,7) caminho simples e livre de laços (1,2,3,4,5,7,4,8,9,11) caminho completo (1,3,4,8,9) caminho não executável

29 O Teste estrutural é baseado em conceitos e elementos do programa para determinar os requisitos de teste A estes elementos estão associados os critérios de teste Elemento Exemplo Critério Nó 6 Todos-Nós Arco (5,6) Todas-Arestas Caminho (1,2,3,4,8,9,11) Todos-Caminhos Definição de variáveis length=0 Todas-Defs Uso predicativo de variável Uso computacional de variável Achar!= \n Length++ Todos-p-Usos Todos-c-Usos 29