SLIDES - UNIDADE 02- Fundamentos ao Teste de Software

Prévia do material em texto

1
NÍVEIS DE TESTE DE 
SOFTWARE
Priscila Souza
Os Três Fundamentos
QUANDO 
TESTAR?
COMO
TESTAR?
O QUE
TESTAR?
A atividade de testes é dividida em níveis (fases).
Cada nível aborda diferentes tipos de erros e aspectos do 
software.
Fonte: Shutterstock
Níveis (estágios) de Testes
Testes de 
Unidade
Testes de 
Integração
Testes de 
Sistema
Testes de 
Aceitação
Entrega
QUANDO 
TESTAR?
Fonte: Priscila Souza
Teste de Unidade
Teste de Unidade
 Uma unidade é o menor componente testável de software: 
 função, procedimento, método, classe, objeto.
 O teste de unidade também é conhecido como teste de 
componente, teste de módulo ou teste de programa.
 Objetivo principal do teste de unidade é garantir que cada
unidade funciona de acordo com sua especificação
 Pode incluir testes de funcionalidade e requisitos não 
funcionais.
2
Teste de Unidade
 Normalmente é realizado pelo 
programador
 mas pode ser feito por outro 
programador –
independência.
 Defeitos são corrigidos tão logo 
são encontrados.
 Geralmente é automatizado, 
através de ferramentas como 
Junit, PHPUnit, XXXUnit e outras. 
Fonte: Shutterstock
Tarefas de preparação para testes de unidade
 Planejar a abordagem geral 
dos testes de unidade
 Projetar os casos de testes e 
os procedimentos de teste
 Definir relações entre os 
testes
 Preparar o código auxiliar 
necessário para o teste
Fonte: Shutterstock
Ambiente de Testes de Unidade
 Para ser possível testar a unidade normalmente é necessário 
desenvolver pseudocontroladores e pseudocontrolados:
 Pseudocontrolador (drivers) 
 “Programa principal” que aceita os dados do caso 
de teste e repassa-os à unidade que esta sendo 
testada.
 Pseudocontrolado (stubs)
 Substitui uma unidade subordinada ao 
componente que esta sendo testado.
Ambiente de Testes de Unidade
unidade
stub stub
driver
resultados
casos de teste
Fonte: Professora Maria Augusta
Problemas Tratados por Teste de Unidade
 Erros mais comuns de cálculo:
 precedência aritmética mal entendida ou incorreta;
 iniciação incorreta;
 falta de precisão;
 representação incorreta de expressão simbólica.
 Erros de comparação e fluxo de controle:
 comparação de tipos de dados diferentes;
 operações ou precedência lógica incorretos;
 comparação incorreta de variáveis;
 terminação de ciclo inadequado ou inexistente, etc.
Fonte: Shutterstock
Teste de Integração
3
Teste de Integração
 Objetivo: validar a comunicação entre os componentes e 
sistemas.
 Conduzido pelos desenvolvedores.
 Podem ser feitos antes de o sistema estar concluído, à 
medida em que os componentes vão ficando prontos.
 Geralmente os tipos de falhas encontradas são de 
transmissão de dados.
Teste de Integração
 São automatizados através de 
ferramentas como Junit, 
PHPUnit, XXXUnit e outras. 
 Pode ser conduzido de diversas 
formas:
 Big Bang
 Integração Incremental
 Algo entre os dois extremos Fonte: Shutterstock
Abordagem Big-bang
 Todos os componentes são 
combinados e o programa inteiro 
é testado de uma só vez.
 Menor esforço
 Testa só no final
 O resultado, em geral, é 
desastroso;
 Dificuldade de identificar o 
local de ocorrência do defeito.
Fonte: Shutterstock
Abordagem Incremental
 O programa é integrado e 
testado em pequenos 
incrementos.
 Opções:
 Top-down
 Bottom-up
Fonte: Shutterstock
Integração Top Down
O driver é utilizado como módulo 
de controle principal
stubs são trocados pelos módulos reais, 
um de cada vez, seguindo o critério da 
profundidade ou amplitude
a medida que novos módulos são integrados 
testes de regressão são executados.
A
B
C
D E
F G
Integração Bottom-Up
drivers são removidos uma vez que 
o teste do subsistema é feito 
módulos são integrados usando um driver
A
B
C
D E
F G
subsistema
4
Problemas tratados no teste de integração
 Dados podem ser perdidos através de uma 
interface;
 Um módulo pode ter um efeito imprevisto 
ou adverso sobre outro;
 Subfunções podem não produzir o 
resultado esperado pela função principal;
 Imprecisão aceitável individualmente pode 
ser amplificada;
 Estruturas de dados globais podem gerar 
problemas, etc...
Fonte: Shutterstock
Teste de Sistema
Teste de Sistema
 Objetivo:
 garantir que o sistema funciona de 
acordo com seus requisitos 
funcionais e de qualidade 
(confiabilidade, usabilidade, 
desempenho, etc.) 
 São realizados após a codificação do 
sistema estar concluída.
 Relacionado ao comportamento do 
sistema como um todo. Fonte: Shutterstock
Teste de Sistema
Fonte: Google Fonte: Facebook
Teste de Sistema
 Baseados na especificação de requistitos, casos 
de uso, …
 Cenários de testes coerentes com requisiotos
 Seu propósito é encontrar o maior número de 
defeitos
 Conduzido pela equipe de testes
 Deve verificar requisitos funcionais e não 
funcionais
 Demandam ambiente de testes controlado
 Último teste antes da entrega
Fonte: Shutterstock
Teste de Aceitação
5
Teste de Aceitação
 Objetivo: executar o sistema sob 
ponto de vista de seu usuário final
 É realizado após correções dos 
defeitos encontrados internamente 
nos testes de Sistema.
 Objetivo é estabelecer confiança no 
sistema
 Encontrar defeitos não é foco 
principal.
Fonte: Shutterstock
Teste de Aceitação
 Planejados e executados por um grupo restrito 
de usuários finais do sistema, que simulam 
operações de rotina do sistema de modo a verificar 
se seu comportamento está de acordo com o 
solicitado.
 Testes alfa
 Usuários convidados a utilizar o sistema no 
ambiente do desenvolvedor.
 Testes beta
 Usuários utilizam o sistema em condições reais.
Fonte: Shutterstock
Imagens de versões beta
Fonte: Google Play
Estratégias de Teste de Software
Devem acomodar:
 Testes de baixo nível;
 Necessários para verificar se um pequeno trecho de código-fonte foi 
corretamente implementado
 Testes de alto nível;
 Necessários para validar as principais funções do sistema com base nos 
requisitos dos usuários e clientes.
 Diferentes técnicas de testes
 São adequadas em diferentes momentos
 Testes devem ser conduzidos: desenvolvedores e testadores
Técnicas de Teste
Priscila Souza
Na aula anterior, nós respondemos a pergunta 
“Quando testar?” entendendo os níveis de teste 
que precisam ser executados a medida que o 
processo de desenvolvimento avança.
Nessa aula, vamos responder a pergunta “Como 
testar?” descobrindo quais são e como funcionam 
as técnicas de testes.
6
Técnicas de Teste
 O entendimento das técnicas para elaboração de um projeto de 
teste é primordial para a consolidação do planejamento e 
preparação para execução dos testes dentro de um determinado 
projeto. 
 As técnicas de teste são divididas em 2 categorias: 
 Técnicas estáticas: compreendem os testes que não envolvem 
a execução do software.
 Técnicas dinâmicas: são relacionadas a execução do software. 
Técnicas Dinâmicas
 O software é executado com alguns casos de teste e os resultados 
da execução são examinados para verificar se o programa operou 
de acordo com o esperado. 
 O ideal seria testar o programa com todos os elementos do 
domínio de entrada (teste exaustivo).
 Infactível para grandes ou infinitos domínios de entrada.
 Por isso, devemos selecionar subdomínios, mas garantindo a alta 
probabilidade em revelar defeitos no software.
Técnicas Dinâmicas
 Como identificar esses subdomínios?
São definidas “regras”, chamadas de técnicas e seus 
critérios, para identificar quando dados de teste devem estar 
no mesmo subdomínio ou em subdomínios diferentes.
 Nessa aula vamos aprender sobre essas técnicas que são 
classificadas em: 
 Caixa-Branca e Caixa-Preta.
Testes Caixa-Branca
Testes Caixa-branca
 Nesta técnica os casos de 
teste são gerados tendo-se 
conhecimento da estrutura 
interna (lógica) do 
programa. 
 São também denominados 
testes estruturais. 
Dados 
de 
Entrada
Saída
Fonte: Prof. Priscila Souza
Testes Caixa-branca
 Se for realizado por umanalista de testes, este 
precisa ter conhecimento 
básico de programação.
Estudaremos as técnicas: 
 Cobertura Lógica (Critérios 
Myers) e Método dos 
Caminhos Básicos.
Exemplo de bloco básico de código:
1. READ A
2. READ B
3. C = A + B
4. IF A > B THEN
5. PRINT “RESULTADO INVÁLIDO”
6. ELSE
7. PRINT C
8. END IF
SENTENÇASCONDIÇÕES
DECISÕES
7
Cobertura Lógica (Critérios Myers)
 Este método é constituído de critérios que, quando 
obedecidos, determinam os casos de teste a serem gerados. 
 Os critérios vão se tornando cada vez mais abrangentes e 
rigorosos, partindo-se do mais simples, ineficiente e menos 
rigoroso (Cobertura de Comandos) até o mais complexo, 
eficiente e rigoroso (Cobertura de Múltiplas Condições). 
Cobertura Lógica (Critérios Myers)
A escolha do critério adequado será norteada pelos seguintes 
fatores:
 Complexidade do programa a testar
Programas mais simples podem ser satisfeitos pela 
utilização de critérios menos rigorosos.
 Estrutura do programa a ser testado
Certas estruturas são mais adequadas a determinados 
critérios.
Cobertura Lógica (Critérios Myers)
A escolha do critério adequado será norteada pelos seguintes 
fatores:
 Criticidade do programa a testar
Programas cujo funcionamento não é crítico podem 
exigir testes menos rigorosos.
 Nível de confiança que se deseja atingir
Se o nível de confiança de bom funcionamento é alto, 
critérios mais rigorosos são necessários.
Grafo de programa/Fluxo de controle
 É um grafo orientado que descreve o fluxo de controle do 
programa.
 Auxilia na criação de casos de testes caixa-branca;
 Nodos representam comandos;
 Arestas representam fluxo de controle;
 Regiões do grafo são áreas limitadas pelas arestas e 
nodos (incluindo a área fora do grafo).
Grafo de programa/Fluxo de controle
Sequência
Decisão/condição
verdadeiro falso
Repetição
falso
verdadeiro
Exemplo – Grafo de Programa
1 if A=B then
2 A : = A + 1
else
3 if B = C then
4 B : = B+1
else
5 B : = B -1;
6 end;
R1
R2
R3
a b
c
d
e
fg
V F
V F
R1
1
2 3
4 5
6
R2
R3
8
Exemplo – Grafo de Programa
1 soma_vetor (a, num_elementos, soma)
2 soma = 0
3 i = 1
4 while (i <= num_elementos)
5 if a[i] > 0
6 soma = soma + a[i]
endif
7 i = i + 1
end while
8 end soma_vetor
Caminhos no Grafo de Programa
 Um caminho é uma sequência de nodos: começando do 
nodo de entrada do grafo e chegando ao nodo de saída.
Exemplo:
No grafo anterior um caminho possivel é: 1,2,3,4 e 8.
Responda: a sequência 1,2,3,4,5,6,7,8 é um caminho factível? 
Cobertura de comandos (statements)
 Neste critério os casos de teste devem ser gerados de forma 
que ao serem executados, o fluxo do programa passe por 
todos os COMANDOS existentes no mesmo.
 Em termos do grafo de fluxo de controle consiste em garantir
que todos os nodos serão exercitados pelo menos uma vez
pelo conjunto de testes. 
Cobertura de comandos (statements)
1 if (a == b) 
2 + +i;
3 if (x == y)
4 - -i;
5 return i;
}
2
3
4
5
Verdadeiro
1
falso
Verdadeiro
falso
(4 caminhos possíveis, 
apenas 1 é testado pelo
critério de cobertura de 
comandos)
 Não é capaz de detectar diversos tipos de defeitos;
 Basta executar um comando de repetição uma única vez;
 Condições compostas não são testadas;
 Ifs sem elses são particularmente vulneráveis 
 se houver um defeito na condição e esta for sempre 
verdadeira, como não existe comando a ser testado no else, 
este defeito não é descoberto usando cobertura de 
comandos.
Cobertura de comandos (statements) Cobertura de desvios ou decisões (branches)
 Cada desvio ou decisão consiste em uma condição (simples 
ou composta) que deve ser avaliada pelo menos uma vez
como verdadeira e uma como falsa.
 Em termos do grafo de fluxo de controle consiste em
garantir que todos as arestas serão exercitados pelo menos
uma vez pelo conjunto de casos de teste. 
9
Cobertura de desvios ou decisões (branches)
1 if (a == b) 
2 + +i;
3 if (x == y)
4 - -i;
5 return i;
}
2
3
4
5
Verdadeiro
1
falso
Verdadeiro
falso
(4 caminhos possíveis, 
apenas 2 são testados
pelo critério de cobertura
de desvios)
Cobertura de desvios ou decisões (branches)
 Resolve alguns problemas da cobertura por comandos, 
mas não todos…
 Condições compostas podem não ser testadas;
 Podem haver caminhos não testados; 
 comandos de repetição só necessitam ser executados
uma vez apesar da condição de repetição ter de ser
testada duas vezes.
Cobertura de condições
 Cada parte de uma condição deve ser testada pelo menos 
uma vez como verdadeira e uma vez como falsa;
 Não requer testar todas as possibilidades;
 Não requer que todos os desvios sejam cobertos;
 O desvio pode ser sempre falso, por exemplo, mas cada 
parte da condição foi testada como V e F.
Cobertura de condições
1 if (idade >= 18) and (Aprovado = ‘OK’) then
2 contrato =‘SIM’;
else
3 contrato =‘NÃO’;
4 end if
2 Casos de testes:
1) Idade = 19, Aprovado = OK 
2) Idade = 18, Aprovado = Não 
Idade >=18 e Idade <18
Aprovado= OK e Aprovado <> OK
Cobertura de condições/decisões
 Uma combinação dos dois últimos critérios
 Cada condição em uma decisão é testada em todas as suas 
saídas possíveis e cada decisão tem sua saída V ou F percorrida 
ao menos uma vez. 
Cobertura de condições/decisões
1 if (idade >= 18) and 1A (Aprovado = ‘OK’) then
2 contrato =‘SIM’;
else
3 contrato =‘NÃO’;
4 end if
3 Casos de testes:
1) Idade = 19, Aprovado = OK 
2) Idade = 18, Aprovado = Não 
3) Idade = 17, Aprovado = X
Idade >=18
Aprovado =OK
Aprovado <>OK
Idade <18
2 3
4
1
1A
10
Cobertura de múltiplas condições
 Todas as combinações de V ou F de cada condição devem
ser testadas
 Este é sem dúvida o critério mais abrangente. 
 Porém, esta abrangência tem um preço: o número de 
casos de teste para satisfazê-lo é maior.
 As falhas deste critério estão relacionadas ao número de 
caminhos percorridos: ele não garante que este número 
seja suficiente para testar com confiança o programa.
Cobertura de múltiplas condições
1 if (idade >= 18) and (Aprovado = ‘OK’) then
2 contrato =‘SIM’;
else
3 contrato =‘NÃO’;
4 end if
4 Casos de testes:
1) Idade = 19, Aprovado = OK 
2) Idade = 18, Aprovado = Não 
3) Idade = 17, Aprovado = OK
4) Idade = 16, Aprovado = Não 
Caminhos independentes
 Método criado pelo matemático norte-americano 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.
Caminhos independentes
 Existem 3 formas de se determinar quantos são os caminhos 
independentes, também denominado complexidade 
ciclomática:
 Contar o Número de Regiões;
 Aplicar a fórmula C = E – N + 2;
 onde C = número de caminhos independentes; E = número 
de arestas; N = número de nós;
 Contar o número de estruturas de decisão no programa e 
somar 1. 
Exercício – Complexidade Ciclomática
R1
R2
R3
a b
c
d
e
fg
V F
V F
Qual é a complexidade 
Ciclomática?
R1
1
2 3
4 5
6
1 if A=B then
2 A : = A + 1
else
3 if B = C then
4 B : = B+1
else
5 B : = B -1;
6 end;
Resposta: 3
R2
R3
Caminhos independentes
 Para identificar os caminhos independentes em um grafo é preciso:
 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 anterior, 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.
11
Caminhos independentes – Casos de testes
 Cada caminho obtido dará origem a um caso de teste. Os 
casos de teste sãogerados de forma que façam com que os 
caminhos aos quais correspondam sejam percorridos. 
No exemplo anterior 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=5.
Caminho bef: Entradas: A=3, B=5, C=6. Saídas: A=3, B=4.
Caminhos independentes – 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 e checar os resultados 
obtidos contra os esperados.
Testes Caixa-Preta
Testes Caixa-preta
 Nesta metodologia os casos de 
teste são gerados sem o 
conhecimento da estrutura 
interna do programa. 
 Apenas o conhecimento das 
entradas e saídas possíveis para 
o programa é necessário. São 
também denominados testes 
funcionais. 
W
Dados 
de 
Entrada
Saída
Fonte: Prof. Priscila Souza
?
Testes Caixa-preta
 Estudaremos os seguintes métodos:
 Partição em Classes de Equivalência
 Análise de Valores de Borda (limite)
 Grafo de Causa-Efeito
 Todos os critérios baseiam-se na especificação do sistema.
Partição em Classes de Equivalência
 Naturalmente, é impossível testar todas as combinações 
possíveis de entradas.
 É preciso achar um subconjunto significativo.
 O método envolve achar partições;
 Para cada tipo de dado.
12
Partição em Classes de Equivalência
Fonte: shutterstock
Partição em Classes de Equivalência
 Definição - Classe de Equivalência
 Uma classe de equivalência nada mais é do que um 
subconjunto das entradas possíveis de um programa, de 
tal forma que um teste efetuado para um valor 
representativo da mesma é equivalente ao teste para 
qualquer outro valor nesta classe.
Partição em Classes de Equivalência
 Particionar o domínio de entrada em classes de 
equivalência
 Resultado: número finito de partições ou classes de 
equivalência.
 Selecionar um dado membro de uma classe de 
equivalência como sendo um representante da classe
 Premissa: assume-se que todos os membros de uma 
classe de equivalência são processados de maneira 
equivalente pelo software.
Como Identificar as Classes? 
 Identificar na especificação de requisitos as condições que 
dividem o domínio de entrada:
 Intervalo de valores: define-se uma classe válida e duas 
inválidas.
 Conjunto de valores: define-se uma classe válida para 
cada conjunto e uma classe inválida para outros valores 
quaisquer.
 Valor ou característica mandatória: define-se uma classe 
válida e uma inválida.
Intervalo de Valores Válidos
 Por exemplo: o comprimento de um objeto de entrada pertence 
ao intervalo de 1 a 499 Milímetros
 Criar uma classe de equivalência:
 para todos os valores dentro do intervalo - Partição Válida
 para todos os valores menores do que 1 - Partição Inválida
 para todos os valores maiores que 499 - Partição Inválida
Conjunto de Valores Válidos
 Por exemplo: se a especificação de um módulo de pintura de objetos 
diz que as cores vermelho, verde e amarelo são permitidas como 
valores de entrada.
 Criar uma classe de equivalência que inclui:
 vermelho, verde e amarelo (CORES - valores válidos) 
 e uma classe que inclui todas as outras entradas (valores inválidos).
13
Valor ou característica mandatória
 Por exemplo: se o primeiro caracter do identificador de um item 
de pedido tiver de ser uma letra
 Criar uma classe de equivalência válida onde os identificadores 
começam com uma letra, e uma classe inválida onde o primeiro 
caracter não é uma letra.
Vantagens das Classes de Equivalência
 Elimina a necessidade de teste exaustivo que não é viável de 
qualquer forma;
 Guia o testador na seleção de um subconjunto de entradas 
para os testes com alta probabilidade de detectar um defeito;
 Permite cobrir um domínio maior de entrada selecionando 
um subconjunto menor de valores dadas as classes de 
equivalência.
Análise dos Valores de Borda
 Muitos defeitos acontecem nas bordas (limites) entre as 
classes de equivalência:
 Exatamente na fronteira
 Logo abaixo da fronteira
 Logo acima da fronteira
Análise dos Valores de Borda
 Casos de testes que consideram estas bordas (limites) em geral 
revelam defeitos.
 Princípio da Timidez:
 "Os 'BUGS' se concentram nos cantos e nas frestas" 
 Este método complementa o Partição em Classes de 
Equivalência (que utiliza valores típicos), testando valores 
focalizados nas fronteiras dos intervalos de validade. 
Análise dos Valores de Borda
 Se a condição de entrada for um Intervalo de valores:
 Criar casos de teste com valores válidos
 nas fronteiras do intervalo.
 Criar casos de teste com valores inválidos
 logo acima e logo abaixo da fronteira do intervalo.
Análise dos Valores de Borda
 Exemplo: 
A entrada é um valor do intervalo de -1.0 a +1.0:
 Casos de teste:
 Entrada: -1.0; Saída: Válido;
 Entrada: +1.0; Saída: Válido; 
 Entrada: +1.1; Saída: Inválido;
 Entrada: -1.1; Saída: Inválido.
14
Análise dos Valores de Borda
 Se a condição de entrada for um Conjunto ordenado 
(listas, tabelas):
 Criar casos de teste focando
 no primeiro elemento do conjunto
 no último elemento do conjunto
 no elemento anterior ao primeiro do conjunto 
(inválido)
 no elemento posterior ao último do conjunto (inválido)
Análise dos Valores de Borda
 Exemplo: A entrada é um elemento da lista ordenada: 
{B, K, M, R, T}
 Casos de teste:
 B, T (válidos) 
 A, U (inválidos)
Grafo de Causa e Efeito
 Método baseado em especificações de ENTRADAS (causas) e 
SAÍDAS (efeitos). 
 Representa a combinação de entradas em saídas de forma 
bastante representativa, não redundante e, muitas vezes, de 
tamanho minimizado. 
 Além disso possui uma vantagem extra, pois aponta 
ambiguidades e incompletezas na especificação.
 Porém, quando o grafo de causa-efeito torna-se muito complexo, fica 
bastante difícil a geração da tabela de decisão. Nesta situação, a 
utilização deste método só é viável com o auxílio do computador.
Grafo de Causa e Efeito – Passos do Método
1 - Desenhar o grafo:
 Identificar as causas: as causas são as entradas do programa. Colocá-
las à esquerda no diagrama.
 Identificar os efeitos: os efeitos são as saídas do programa. Colocá-los 
à direita no diagrama.
2 - Transformar o grafo em tabela de decisão. 
 Como? Para cada um dos efeitos, gerar combinações entre causas que 
façam com que sejam ativados. 
3 - Gerar os casos de teste
Grafo de Causa e Efeito - Notação
 Cada nó do grafo pode assumir valores: 
0 (ausência) ou 1 (presença) do estado.
 A notação do grafo contém os seguintes operadores:
Grafo de Causa e Efeito - Exemplo
Seja a seguinte especificação para um compilador de 
um comando bem simples: 
 O caractere na coluna 1 deve ser "A" ou "B". 
 O caractere na coluna 2 deve ser um número. 
 Se isto ocorrer, o arquivo deve ser atualizado.
 Se o primeiro caractere estiver incorreto, emitir 
mensagem M1. 
 Se o segundo caractere não for um dígito, 
emitir mensagem M2. 
15
Grafo de Causa e Efeito - Exemplo
 CAUSAS:
1 - Caractere na primeira coluna é "A“; 
2 - Caractere na primeira coluna é "B" ;
3 - Caractere na segunda coluna é um número.
 EFEITOS:
70 - Atualiza o arquivo;
71 - Emite mensagem M1;
72 - Emite mensagem M2.
Grafo de Causa e Efeito - Exemplo
 Grafo:
Grafo de Causa e Efeito - Exemplo
 Tabela de decisão:
Outras abordagens para testes Caixa-preta
 Diagrama de transição de teste
 baseado em máquinas de estados finitos
 Adivinhação ou suposição/palpite de erros
 baseado em experiências anteriores; uso de intuição para 
adivinhar onde os erros podem ocorrer.
 Teste exploratório
Quais técnicas devo escolher?
 Para escolher as técnicas corretas deve-se considerar:
 Tipo do sistema
 Nível de risco
 Objetivos do teste
 Documentação disponível
Tempo e orçamento
 Etc.
Técnicas x Níveis de Testes
 Testes caixa-preta são apropriados em todos os níveis mas 
sua utilização é maior nos níveis mais altos: Sistema e 
Aceitação.
 Testes caixa-branca são utilizados predominantemente nos 
níveis mais baixos: Unidade e Integração.
 É durante o planejamento dos testes que devem ser definidas 
quais técnicas utilizar e em quais níveis. 
16
Testes Estáticos 
Priscila Souza
As técnicas de testes de software são divididas em 2 
categorias: técnicas dinâmicas relacionadas a 
execução do software e técnicas estáticas que 
compreendem os testes que não envolvem a 
execução do software.
Nessa aula, vamos continuar respondendo a 
pergunta “Como testar?” descobrindo quais são e 
como funcionam as técnicas de testes estáticas.
Testes Estáticos
 As técnicas de testes estáticas 
são aquelas que não dependem 
de um artefato executável para 
serem realizadas. 
 Artefatos são examinados 
manualmente (inspeção visual).
Fonte: Shutterstock
Testes Estáticos
 Exemplos de artefatos que podem ser 
Examinados por meio de testes estáticos: 
 Especificações de requisitos
 Estórias de usuários
 Código-fonte
 Manual de usuário
 Plano de projeto
 Especificações de arquitetura, etc...
Fonte: Shutterstock
Testes Estáticos
 Podem ser usados em todos os níveis de 
testes.
 Não substituem os testes dinâmicos
 se complementam, encontrando 
diferentes tipos de defeitos.
 Normalmente estão associados aos 
marcos do projeto.
 Principais atividades: revisões e 
inspeções e suas variações.
Fonte: Shutterstock
Revisões e Inspeções
Importância das revisões e inspeções:
 Quando aplicadas no início do ciclo de vida de desenvolvimento 
de software, permite a detecção antecipada dos defeitos antes 
da realização dos testes dinâmicos; 
 Reduzem cerca de 60% a 90 % dos defeitos; 
 Reduzem o retrabalho em cerca de 40% a 50%; 
 Reduzem o custo do projeto;
17
Revisões e Inspeções
 Previnem defeitos revelando inconsistências, ambiguidades, 
contradições, omissões, imprecisões e redundâncias nos 
requisitos; 
 Aumentam a produtividade no desenvolvimento (p.e., devido 
ao desenho aprimorado, código mais sustentável); 
 Melhoram a comunicação entre os membros da equipe durante 
a participação nas revisões.
 Equipe possui maior consciência de problemas de qualidade.
Papéis de uma Revisão Formal
 Autor: cria o produto e corrige os defeitos encontrados.
 Facilitador: garante a execução eficaz, media se necessário 
entre os pontos de vista.
 Líder de revisão: decide quem será envolvido e organiza 
quando e onde acontecerá a revisão.
 Revisor: identifica possíveis problemas, pode representar 
diferentes perspectivas.
 Redator: coleta os defeitos encontrados, registra os pontos em 
aberto e decisões da reunião de revisão...
Revisão Informal
 Verificação de parceiros, 
pareamento, revisão de pares;
 O objetivo principal é detectar 
defeitos potenciais;
 Não é baseado em um processo 
formal; 
 O uso de checklists é opcional;
 Muito comumente usado no 
desenvolvimento Ágil.
Fonte: Shutterstock
Revisão Técnica (Technical Review)
 Objetivos: Avaliar um produto de software por equipe qualificada 
para determinar a adequação e seu uso e identificar discrepâncias 
de padrões e especificações; verificar se a qualidade do produto é 
a esperada;
 Os revisores devem ser especialistas técnicos;
 O redator é obrigatório e preferencialmente que não seja o autor;
 O uso de checklists é opcional;
 São produzidos registros de defeitos potenciais e o relatório de 
revisão.
Revisão de Apresentação (Walkthroughs)
 Objetivos: permitir troca de conhecimentos; coletar ideias de 
outros membros do time que levam a uma melhoria geral do 
produto; encontrar anomalias; considerar implementações 
alternativas;
 O autor do material apresenta-o em ordem lógica;
 Pode ser realizado em todos os momentos do desenvolvimento;
 Papeis podem ser compartilhados: Líder, relator, autor;
 Deve ser planejado: participantes definidos, encontro agendado;
 Resultados devem ser registrados.
Inspeção (Inspection)
 Objetivos: detectar defeitos potenciais; avaliar a qualidade; criar 
confiança no produto de trabalho; identificar desvios em relação aos 
requisitos e padrões; coletar dados de métricas;
 Processo definido: regras (exe.: duração 2h) e checklists;
 Utiliza as funções de Autor, Líder, Revisor, Redator e Leitor;
 São produzidos registros de defeitos potenciais e o relatório de 
revisão;
 Métricas são coletadas e usadas para melhorar o processo de 
desenvolvimento de software, incluindo o processo de inspeção.
18
Inspeção de Código
 Um dos tipos de inspeção mais comuns
 Primeira ação é adotar um padrão 
de codificação
 Padrões de codificação
 Recomendado adotar padrões existentes.
 Economiza trabalho
 Pode haver ferramentas automatizadas Fonte: Shutterstock
Dicas para realização de revisões
 Planejar e acompanhar
 Treinar os participantes
 Gerenciar problemas pessoais
 Mantenha a simplicidade
 Melhorar processo e ferramentas
 Reportar resultados
 Ter o apoio da gerência
Fonte: Shutterstock
TIPOS DE TESTE
Priscila Souza
Na aula anterior, nós respondemos a pergunta 
“Como testar?” aprendemos quais são e como 
funcionam as técnicas de testes de software.
Nessa aula, vamos responder a pergunta “O que 
testar?” descobrindo quais são os tipos de testes.
Tipos de Teste de Software
 Um tipo de teste é um grupo de atividades que visa testar 
características específicas de um software, ou parte de um software, 
com base em objetivos de teste específicos. 
 Tais como: 
 Avaliar funcionalidades
 Medir confiabilidade
 Avaliar a usabilidade
 Avaliar a estrutura do sistema
 Confirmar mudanças no software
Tipos de Teste de Software
Classificação dos testes em função do objetivo do teste:
 Teste Funcional (caixa-preta)
 Teste Estrutural (caixa-branca)
 Teste Não-funcional
 Teste relacionado a mudanças:
 Teste de Confirmação (Reteste)
 Teste de Regressão
19
Teste Funcional (Caixa-preta)
 Funcionalidade normalmente descrita em algum documento de 
requisitos.
 Considera o comportamento especificado.
 Avalia as funções do software (“o que o sistema faz”)
 Observa apenas QUAL foi o resultado do teste e não COMO o 
mesmo foi obtido
 Condições e casos de testes são derivados da funcionalidade 
especificada.
 Executa as funções usando dados válidos e inválidos
Teste Funcional (Caixa-preta)
 Objetivo: garantir que todos os requisitos ou comportamentos 
da aplicação ou componente estão corretos.
 Erros que podem ser descobertos:
 Funções incorretas ou ausentes; 
 Interfaces;
 Estruturas de dados ou acesso a dados; 
 Desempenho; 
 Estratégias:
 Partição de equivalência, Análise de valores limite; etc.
Teste Não-funcional
 Relacionado a requisitos não-funcionais.
 O teste é excutado para medir as caracteristicas que podem 
ser quantificadas em uma escala variável (ex: o tempo de 
resposta em um teste de performance).
 O teste não funcional é o teste de "quão bem" o sistema se 
comporta.
 Uso da ISO/IEC 9126 como base.
Teste Não-funcional
 Inclui, mas não se limitam a:
 teste de performance; 
 teste de carga; 
 teste de estresse; 
 teste de estabilidade.
 teste de usabilidade; 
 teste de interoperabilidade; 
 teste de manutenibilidade; 
 teste de confiabilidade; 
 teste de segurança;
 teste de portabilidade;
 Etc...
Teste Estrutural (Caixa-branca)
 Avalia a estrutura e o comportamento interno do componente 
de software.
 O teste é realizado diretamente sobre o código-fonte dos 
componentes. 
 Interessado na cobertura dos testes pela análise de elementos 
estruturais.
 Mais aplicado aos níveis de unidade e integração.
Teste Estrutural (Caixa-branca)
 Objetivo: garantir que todas as linhas de código e condições 
foram executadas pelo menos uma vez e estão corretas.
 Estratégias:
 Cobertura de comandos; 
 Cobertura de desvios;
 Cobertura de condições;
 Coberturade múltiplas condições.
20
Teste relacionado a mudanças
 Teste de Confirmação (Reteste):
 Executa casos de teste reprovados durante a última 
execução para confirmar se os defeitos foram corrigidos.
 Novos defeitos podem ter sido inseridos.
 As etapas para reproduzir as falhas causadas pelo defeito 
devem ser executadas novamente na nova versão do 
software. 
Teste relacionado a mudanças
 Teste de Regressão:
 Objetivo: procurar alterações não intencionais no 
comportamento como resultado de alterações no 
software ou no ambiente.
 Candidatos a serem automatizados.
 Executados sempre que há mudanças.
 Esforço de manutenção considerável.
Teste relacionado a mudanças
 Teste de Regressão:
 Especialmente em modelos de desenvolvimento ágil, os 
testes de regressão desempenham um papel fundamental 
na criação da confiança de que as alterações não 
impactaram os componentes existentes.
Teste relacionado a mudanças
 Testes de Confirmação e Regressão:
 São realizados em todos os níveis de teste;
 Extremamente importantes devido à natureza evolutiva 
dos softwares;
 Particularmente relevante para os sistemas da Internet 
das Coisas (IoT).
Quando utilizar cada uma das abordagens?
De acordo com cada situação. Por exemplo:
 Para testar a conformidade de um algoritmo de busca por 
exemplo, um teste estrutural é mais adequado;
 Para testar uma operação de inserção de um elemento em 
uma estrutura de dados, um teste funcional é suficiente.
Estratégia para teste de Software
 Uma estratégia de testes de software descreve a abordagem 
geral e os objetivos das atividades de teste.
 E, descreve com clareza os critérios para a conclusão dos 
testes e os critérios de sucesso a serem usados.
 Ela deve contemplar todos os níveis de teste, os tipos de 
testes a serem realizados e as técnicas para sua execução.