Técnica de Teste Estrutural - Teste de Software

Prévia do material em texto

Teste de Software
Rosemary Silveira Filgueiras Melo
rosesfmelo@hotmail.com
1
Técnica de Teste Estrutural
Agenda
 Casos de Teste e Cenários de Teste
 Técnicas de Teste
 Técnica de Teste Estrutural
2
Casos de Teste 
3
• 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 829-2008).
• 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.
Modelo de Casos de Teste 
4
Itens do Caso de teste (conforme norma IEEE 829-2008)
Identificador do caso de 
teste
Número de identificação do caso de teste
Objetivo do caso de teste Define o objetivo do caso de teste
Entradas Entradas que serão consideradas no caso de teste
Saídas Saídas esperadas de acordo com as entradas indicadas na 
execução dos testes
Ambientes necessários 
ou condições de 
ambiente
Ambiente de hardware e software que devem ser montados 
para o caso de teste em questão
Execução do caso de 
teste
Especifica com detalhe o que deve ser testado e a forma de 
como o teste deve ser executado
Dependência entre 
outros casos de teste
Casos de teste relacionados
5
Exemplo de Casos de teste 
1. Identificador do caso 
de teste
Caso de teste 1 – Testar Login
2. Objetivo do caso de 
teste
Verificar login inválido
3. Entradas Inserir um email inválido
4. Saídas Exbir mensagem “Login inválido”
5. Ambientes necessários 
ou condições de 
ambiente
nenhum
6. Execução do caso de 
teste
1. Selecione ícone do aplicativo
2. Exibir tela de login
3. Insira um email 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
Casos de Teste 
6
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.
Casos de Teste 
7
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.
Cenário de teste
8
• 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.
Técnicas de Teste
9
• Não existe um procedimento genérico que possa ser usado para provar a 
correção de um programa
A norma ISSO/IEC/IEEE 29119-4 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
Técnica Estrutural (Caixa Branca)
10
 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.
Técnica Estrutural (Caixa Branca)
11
 É 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
Teste Estrutural (caixa branca) 
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.
Teste Estrutural (caixa branca) 
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.
Teste Estrutural (caixa branca) 
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
Teste Estrutural (caixa branca) 
Representação de Estruturas de Programação
15
Representação de Estruturas de programação em grafo de fluxo de 
controle – Adaptado de (Pressman, Engenharia de Software, 2006)
Teste Estrutural (caixa branca) 
16
Teste Estrutural (caixa branca) 
Critérios
17
 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
Teste Estrutural (caixa branca) 
Critérios baseados em complexidade
18
 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
Teste Estrutural (caixa branca) 
Critérios baseados em fluxo de controle
19
 Utilizam características de controle da execução do programa
 Comandos, desvios
 Ex.:
 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érioTodos-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)
Teste Estrutural (caixa branca) 
Critérios baseados em fluxo de controle
20
 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.
Teste Estrutural (caixa branca) 
Critérios baseados em fluxo de controle
21
 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.
Teste Estrutural (caixa branca) 
Exemplo utilizando os critério Todos-Nós e Todas-Arestas
22
 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.
Teste Estrutural (caixa branca)
Exemplo utilizando Critério de Todas-Arestas
23
 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:
Teste Estrutural (caixa branca) 
Critérios baseados em fluxo de dados
24
 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)
Teste Estrutural (caixa branca) 
Critérios de Teste
25
 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.
Teste Estrutural (caixa branca) 
Exemplo
26
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
Teste Estrutural (caixa branca) 
27
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’))) {
return (1);
Else
return (0);
}
}
Int valid_f(char ch) {
if (((ch >= ‘A’) && (ch<=‘Z’)) ||
((ch >= ‘a’) && (ch <= ‘z’)) ||
((ch >= ‘0’) && (ch <=‘9’))){
return (1);
Else
return (0);
}
}
Elabore o GFC para a seguinte implementação:
Teste Estrutural (caixa branca) 
Grafo de Fluxo de Controle do programa anterior 
28
1
2
3
4
5
6
7
8
9 10
11
(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
Teste Estrutural (caixa branca) 
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
Achar != ‘\n’ Todos-p-Usos
Uso computacional de 
variável
Length++ Todos-c-Usos