Aula 4 - Técnicas de Teste

Técnicas de teste
Revisão
O primeiro incremento é frequentemente chamado de “núcleo

do produto” (PRESSMAN, 2006) e contém a implementação dos
requisitos básicos para que o sistema possa funcionar e atender
minimamente às necessidades do cliente.
Revisão
O desenvolvimento iterativo ocorre quando grupos de

recursos são especificados, projetados, construídos e testados
juntos em uma série de ciclos, geralmente com duração fixa.
Iterações podem envolver mudanças em recursos
desenvolvidos em iterações anteriores, juntamente com
mudanças no escopo do projeto.
Revisão
Revisão
Revisão
Revisão
Atividades e tarefas de teste
● Planejamento do teste;
● Monitoramento e controle do teste;
● Análise do teste;
● Modelagem do teste;
● Implementação do teste;
● Execução do teste;
● Conclusão do teste.
Revisão
Níveis de teste
Os níveis de teste estão relacionados com outras atividades
dentro do ciclo de vida de desenvolvimento de software:
● Teste de componentes;
● Teste de integração;
● Teste do sistema;
● Teste de aceite.
Técnicas de teste
O objetivo principal do processo de teste de software é

detectar a presença de erros no sistema testado. Sendo
assim, o teste bem sucedido é aquele que consegue
determinar situações nas quais o software falhe. Para se
alcançar tal objetivo, diversas são as técnicas que podem
ser empregadas. A seguir são descritas algumas dessas
técnicas.
Técnicas de teste
O objetivo de uma técnica de teste é ajudar a identificar as

condições de teste, os casos de teste e os dados de teste.
Algumas técnicas são mais aplicáveis em determinadas
situações e níveis de teste, outras são aplicáveis em todos os
níveis de teste. Ao criar casos de teste, os testadores
geralmente usam uma combinação de técnicas de teste para
obter os melhores resultados do esforço de teste.
Técnicas de teste
A escolha de quais técnicas de teste usar depende de

vários fatores, incluindo:
● Complexidade do componente ou do sistema;
● Normas regulatórias;
● Requisitos contratuais ou do cliente;
● Níveis e tipos de risco;
● Documentação disponível;
● Conhecimento e habilidades do testador;
Técnicas de teste
A escolha de quais técnicas de teste usar depende de

vários fatores, incluindo:
● Ferramentas disponíveis;
● Tempo e orçamento;
● Modelo de ciclo de vida de desenvolvimento de
software.
● Os tipos de defeitos esperados no componente ou
sistema.
Categorias de técnicas de teste e suas
características
As técnicas de teste são classificadas como caixa-preta,

caixa-branca ou baseada na experiência.
Teste caixa preta, o teste funcional
Essa técnica pode ser adotada quando a equipe de teste

tem acesso a especificação do sistema. Isso porque a
base para definição dos casos de teste é a especificação
do sistema, visto que ao usar essa técnica, o intuito é
testar o sistema do ponto de vista das suas
funcionalidades.
Como o próprio nome indica, essa técnica de teste

considera que o sistema a ser testado é uma caixa preta
– você não sabe o que tem dentro, só sabe o que precisa
colocar dentro da caixa e o que você espera que saia da
caixa.
Em outras palavras, trazendo um pouco mais para a

realidade do teste, você sabe os dados que devem
colocar dentro da caixa, considerando a especificação
das funcionalidades que devem estar implementadas no
software, e você também sabe qual a saída de dados
esperada.
De acordo com Myers (Myers, 2004), na técnica

funcional o objetivo do testador é não se preocupar com
o comportamento interno da estrutura do programa, ao
invés disso, o testador deve se concentrar em encontrar
situações nas quais o sistema não se comporta da forma
como foi especificado.
Para aplicar esse critério de teste, precisamos dividir o

domínio de entrada de dados em classes e partições de
equivalência. Classes são divididas em válidas e inválidas
e dependendo do requisito e dos dados de entrada, as
partições de equivalência são definidas – partições de
equivalência é quando qualquer valor, dentro de um
dado intervalo, tem a mesma importância.
Requisito:
Requisito:
Com base nessa descrição, sabemos que se informar que
um funcionário trabalhou 50h no mês, sabe-se que o
sistema deve informar que esse funcionário fez 25% de
hora extra, visto que 10h é 25% de 40h
Para ajudar o time de teste do ERP (e todos os

testadores do mundo), existe o que chamamos de
critérios de teste.
De acordo com Maldonado e Fabbri (Maldonado &

Fabbri, 2001), os critérios de teste servem para ajudar a
definir, selecionar ou revisar os casos de teste a fim de
aumentar as possibilidades de identificação de defeitos e
estabelecer um nível elevado de confiança dos testes.
Cada critério possui seus requisitos de teste, que ajudam

a gerar os casos de teste de forma a satisfazer o critério
escolhido e também avaliar a qualidade de um conjunto
de teste existente, analisando quais casos de teste
precisam ser acrescentados ao conjunto para que
determinado critério seja atingido.
Critério de teste fictício chamado “Critério dos números

primos menores que 20”
Sendo assim, o requisito desse critério é: temos que
definir casos de teste que considerem como entrada os
números 2, 3, 5, 7, 11, 13, 17 e 19
Os principais critérios de teste caixa preta são:

● Particionamento de Equivalência
● Análise do Valor limite.
● Teste de tabela de decisão
● Teste de transição de estado

Particionamento de Equivalência
Para aplicar esse critério de teste, precisamos dividir o
domínio de entrada de dados em classes e partições de
equivalência. Classes são divididas em válidas e inválidas
e dependendo do requisito e dos dados de entrada, as
partições de equivalência são definidas – partições de
equivalência é quando qualquer valor, dentro de um
dado intervalo, tem a mesma importância.
Se a condição de entrada mencionada no requisito especifica um
intervalo (por exemplo, entre 0 e 100) ou um valor específico
(número real), devemos definir uma classe válida e duas inválidas;
se a condição de entrada mencionada no requisito específica um
membro de um conjunto (por exemplo, um valor a ser selecionado
a partir de uma lista, valor maior que 40) ou uma condição
booleana (sim/não, verdadeiro/ falso etc.) devemos definir uma
classe válida e uma inválida (Fabbri, 2009).
No exemplo do requisito de horas extras apresentado acima,
temos apenas um valor de entrada, que é o valor para horas
trabalhadas. Qualquer valor informado para horas
trabalhadas deveria se comportar da mesma maneira. No
entanto, sabemos que o número esperado de horas
trabalhadas é 40 – o que nos faz entender que a entrada deve
ser de um conjunto de valores – valores maiores que 40
No exemplo do requisito de horas extras apresentado acima,
temos apenas um valor de entrada, que é o valor para horas
trabalhadas. Qualquer valor informado para horas
trabalhadas deveria se comportar da mesma maneira. No
entanto, sabemos que o número esperado de horas
trabalhadas é 40 – o que nos faz entender que a entrada deve
ser de um conjunto de valores – valores maiores que 40
Sendo assim, se o valor de horas trabalhadas for até 40
horas, o programa se comporta de uma maneira (no caso,
não calculando porcentagem de horas extras).
Qualquer valor maior que 40 horas, o programa deve se
comportar de outra maneira. Resumindo: não devemos
esperar que o valor 35 seja interpretado da mesma
maneira que 45, mas 35 deve ser interpretado como
qualquer valor até 40 e, consequentemente, 45 deve ser
interpretado como qualquer valor maior que 40.
Para esse contexto, temos uma classe válida e uma
inválida: classe válida: valor maior que 40; classe
inválida; valor menor que 40. Dessa forma, devemos
definir dois casos de teste - um no qual o valor de
entrada seja maior que 40; um no qual o valor de entrada
seja menor que 40.
Provavelmente você está se perguntando: “Professor, o valor
40 entra em qual particionamento?”.
Se uma revisão formal tivesse sido aplicada no documento de
requisitos, provavelmente a ambiguidade que enfrentamos
agora teria sido eliminada. Como não há detalhes suficientes
na especificação, devemos questionar o responsável pelo
artefato a fim de definir o caso de teste adequadamente.
Nesse caso, vamos assumir que 40 não deve ser
calculado hora extra e sendo assim, o valor 40 faz parte
da classe inválida.

Análise do valor limite:

O critério de análise do valor limite é complementar ao
Particionamento de Equivalência. O foco desse critério é
identificar fontes favoráveis a terem defeitos e criar
casos de teste para exercitar esses dados (Fabbri, 2009).

Casos de teste bem elaborados são feitos para
identificar defeitos e, se nesse cenário o testador usar o
critério de análise do valor limite, possivelmente o
defeito sobre a interpretação do valor 40 seria
identificado (se houvesse algum).

O requisito do critério análise do valor imite é definir
casos de teste para valores de entrada que estão no
limite das classes de equivalência. Algo importante de se
verificar é que o tipo de dados deve ser observado com
atenção.

Sendo assim, considerando o exemplo anterior, nós
devemos pensar em limites e dados propícios a darem
problema (ou seja, não estão sendo considerados da
forma correta na implementação) – esses serão os
valores de entrada para os casos de teste.


● O valor 40 – que está entre as classes de equivalência;
● Os valores 0 e -1 – que, apesar de não estar especificado, entendemos que 0
e valores negativos podem não se comportar como qualquer valor 0 ← 40 e
por isso, valores negativos e 0 sempre são usados como limites quando não
há especificação clara sobre eles;
● O valor 744 – que é 31 x 24, ou seja, nenhum funcionário conseguiria
trabalhar mais que 24 horas por dia nos 31 dias do mês. Como não há uma
limitação dos requisitos em relação às entradas, um bom testador deve
considerar o domínio da aplicação, o requisito em si e pensar em valores
que podem resultar em problema

● O valor 40 – que está entre as classes de equivalência;
● Os valores 0 e -1 – que, apesar de não estar especificado, entendemos que 0
e valores negativos podem não se comportar como qualquer valor 0 ← 40 e
por isso, valores negativos e 0 sempre são usados como limites quando não
há especificação clara sobre eles;
● O valor 744 – que é 31 x 24, ou seja, nenhum funcionário conseguiria
trabalhar mais que 24 horas por dia nos 31 dias do mês. Como não há uma
limitação dos requisitos em relação às entradas, um bom testador deve
considerar o domínio da aplicação, o requisito em si e pensar em valores
que podem resultar em problema

● Teste de caso de uso
Teste de transição de estado :

Componentes ou sistemas podem responder de maneira
diferente a um evento, dependendo das condições atuais
ou do histórico anterior (p. ex., os eventos que
ocorreram desde que o sistema foi inicializado).

O histórico anterior pode ser resumido usando o
conceito de estados. Um diagrama de transição de
estado mostra os possíveis estados do software, bem
como a forma como o software entra, sai e transita entre
os estados.
Uma transição é iniciada por um evento (p. ex., entrada do usuário de um

valor em um campo). O evento resulta em uma transição. Se o mesmo
evento pode resultar em duas ou mais transições diferentes do mesmo
estado, esse evento pode ser qualificado por uma condição de proteção.
A mudança de estado pode fazer com que o software execute uma ação
(p. ex., gerar uma mensagem de cálculo ou de erro)

https://www.youtube.com/watch?v=ifqQoCVJh5M&ab_
channel=MauroHenriqueLimadeBoni

● Teste de caso de uso
Teste de caso de uso:

Os testes podem ser derivados de casos de uso, que são
uma maneira específica de projetar interações com itens
de software, incorporando requisitos para as funções de
software representadas pelos casos de uso.

Os casos de uso estão associados a atores (usuários
humanos, hardware externo ou outros componentes ou
sistemas) e assuntos (o componente ou sistema ao qual o
caso de uso é aplicado).

Os casos de uso estão associados a atores (usuários
humanos, hardware externo ou outros componentes ou
sistemas) e assuntos (o componente ou sistema ao qual o
caso de uso é aplicado).
Cada caso de uso especifica algum comportamento que um assunto pode

realizar em colaboração com um ou mais atores (UML 2.5.1 2017). Um
caso de uso pode ser descrito por interações e atividades, bem como
condições prévias, pós-condições e linguagem natural, quando
apropriado. Interações entre os atores e o sujeito podem resultar em
mudanças no estado do sujeito.

https://www.youtube.com/watch?v=CoPibmtR68I&ab_
channel=MauroHenriqueLimadeBoni
Sendo assim, com mais quatro casos de teste nós

conseguimos a conformidade com os requisitos de outro
critério de teste funcional. Esses dois critérios são
extremamente úteis e devem fazer parte da mentalidade
de qualquer testador e qualquer desenvolvedor, pois faz
com que todos os artefatos, do requisito até o código
fonte, sejam desenvolvidos de forma a evitar que
enganos sejam cometidos no tratamento desses limites.
Teste caixa branca, o teste estrutural
Essa técnica pode ser adotada quando a equipe de teste

tem acesso ao código fonte do sistema. Obviamente que
ter acesso à especificação do sistema também é
desejável, mas é obrigatório o acesso ao código fonte.
Essa exigência é devido ao fato que a base para definição

dos casos de teste é o código fonte, visto que ao usar
essa técnica, o intuito é testar o sistema do ponto de
vista da implementação, ou seja, das linhas de código que
foram produzidas com o intuito de prover as
funcionalidades esperadas do sistema.
Como o próprio nome indica, essa técnica de teste

considera que o sistema a ser testado é uma caixa branca
– você sabe exatamente o que tem dentro da caixa.
Você continua tendo que saber o que precisa colocar

dentro da caixa e o que você espera que saia da caixa,
como fazemos no teste caixa preta, mas a grande
diferença aqui é que você define “o que colocar dentro
da caixa” com base no que tem dentro da caixa.
Em outras palavras, trazendo um pouco mais para a

realidade do teste, você sabe os dados que deve colocar
dentro da caixa e sabe qual a saída de dados esperada,
mas nessa técnica, você decide os dados a serem
inseridos na caixa com base no código fonte do sistema.
De acordo com Myers (Myers, 2004), na técnica

estrutural o objetivo do testador é se preocupar com o
comportamento de cada uma das estruturas internas do
programa. Em outras palavras, a preocupação é com a
lógica que foi implementada. Quando não há
especificação do sistema, essa pode ser uma das formas
possíveis de testar o que foi implementado.
Voltando no mesmo exemplo que usamos na seção

anterior, podemos considerar que o código-fonte (aqui
apresentado em pseudocódigo) para implementar o
método das horas extras.
Voltando no mesmo exemplo que usamos na seção

anterior, podemos considerar que o código-fonte (aqui
apresentado em pseudocódigo) para implementar o
método das horas extras.
Para facilitar a definição dos casos de teste da técnica

caixa branca (estrutural), a maioria dos critérios dessa
técnica é uma representação visual do código a ser
testado, chamado de Grafo de Fluxo de Controle ou
apenas Grafo do Programa.
O Grafo de Fluxo de Controle nada mais é que um

conjunto de nós conectados por arcos com setas que
mostram sua direção – os nós representam um bloco de
comando (isso é, uma sequência atômica de linhas de
código – se uma for executada, todas as outras serão) e
os arcos indicam a precedência ou a transferência de
controle (a sequência de execução do código fonte e
seus desvios)
Sabendo como representar um programa que será

testado por meio da técnica caixa branca, estamos
prontos para aprender os critérios de teste dessa
técnica.
Os critérios de teste da técnica caixa branca são

divididos em :
● Teste Baseado em Fluxo de Controle
● Teste Baseado em Fluxo de Dados
Os critérios de teste da técnica caixa branca são

divididos em :
● Teste Baseado em Fluxo de Controle
● Teste Baseado em Fluxo de Dados
Os principais critérios de teste caixa branca Baseado em

Fluxo de Controle são:
● Teste de Comandos
● Teste de Ramos.

● Teste de Ramos.
Teste de Comandos ou Teste Todos os nós:

Esse critério de teste define como requisito de teste que
todos os comandos dos programas sejam executados ao
menos uma vez. Ou seja, se olharmos para o grafo de
fluxo e controle de um programa, temos que criar casos
de teste de forma que todos os nós sejam exercitados ao
menos uma vez.
Teste de Comandos ou Teste Todos os nós:

Outro ponto importante para esse critério é que ao
definir os casos de teste o foco deve ser nos comandos
que controlam as decisões do sistema, a fim de
direcionar os testes para que todos os nós sejam
atingidos (Maldonado & Fabbri, 2001).

● Teste de Ramos.
Teste de Ramos ou Todas as Arestas ou Todos os Arcos:

todas as condições verdadeiras e falsas do programa
sejam executadas. Em outras palavras, todos os arcos
(também chamados de arestas) do grafo de fluxo de
controle devem ser exercitados, mesmo que para isso, o
mesmo nó seja executado mais de uma vez (Maldonado
& Fabbri, 2001).

● Teste de Ramos.
Todos os usos:
todos os usos das variáveis utilizadas em cada comando
sejam executados.
Todos os usos:
Para isso, devemos identificar os usos de todas as variáveis
do programa (método, algoritmo), classificar o uso dessas
ocorrências de acordo com def, c-use e p-use e então 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 .
Todos os usos:
Para isso, devemos identificar os usos de todas as variáveis
do programa (método, algoritmo), classificar o uso dessas
ocorrências de acordo com def, c-use e p-use e então 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 estático
A análise estática de softwares, também conhecida como

whitebox, trabalha diretamente com o código de uma
ferramenta. Nesse caso, os componentes de uma ferramenta
são verificados sem que o produto seja executado. Seja por
meio de uma ferramenta automatizada ou dos testes manuais,
o principal objetivo dessa técnica é identificar erros de
programação.
Teste estático
Em contraste com o teste dinâmico, que requer a execução do

software a ser testado, o teste estático depende do exame
manual dos produtos de trabalho (isto é, revisões) ou da
avaliação orientada por ferramentas do código ou outros
produtos de trabalho (isto é, análise estática).
Teste estático
Os dois tipos de testes estáticos avaliam o código ou outro

produto de trabalho que está sendo testado sem realmente
executar o código ou o produto de trabalho que está sendo
testado.
Teste estático
Teste estático
“O teste estático é executado no estágio inicial de

desenvolvimento para evitar erros, pois é mais fácil encontrar
fontes de falhas e pode ser corrigido facilmente. Os erros que
não podem ser encontrados usando o Teste Dinâmico, podem
ser facilmente encontrados pelo Teste Estático.”
Produtos de trabalho que podem ser
examinados por testes estáticos
Quase qualquer produto de trabalho pode ser examinado

usando testes estáticos (revisões ou análise estática), por
exemplo:
● Especificações, incluindo requisitos de negócios,
requisitos funcionais e requisitos de segurança;
● Épicos, histórias de usuários e critérios de aceite;
● Especificações de arquitetura e design;
● Código;
Quase qualquer produto de trabalho pode ser examinado usando

testes estáticos (revisões ou análise estática), por exemplo:
● Testware, incluindo planos de teste, casos de teste,

procedimentos de teste e scripts de teste automatizados;
● Guias de usuários;
● Páginas web;
● Contratos, planos de projeto, cronogramas e orçamentos;
● Modelos, como os diagramas de atividades.
As avaliações podem ser aplicadas a qualquer produto de

trabalho que os participantes saibam ler e entender. A análise
estática pode até ser aplicada com ferramentas que avaliam
produtos de trabalho escritos em linguagem natural, como
requisitos (p. ex., verificação de ortografia, gramática e
legibilidade)
Benefícios do teste estático
As técnicas de testes estáticos fornecem uma variedade de

benefícios. Quando aplicado 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 (p. ex.,
em revisões de requisitos ou especificações de projeto,
refinamento de backlog de produtos etc.)
Os defeitos detectados precocemente costumam ser muito

mais baratos de serem removidos do que os defeitos
encontrados posteriormente no ciclo de vida, especialmente
em comparação aos defeitos encontrados após o software ser
implantado e em uso ativo.
Usar técnicas de testes estáticos para localizar e corrigir os

defeitos rapidamente é quase sempre muito mais barato para
a organização do que usar testes dinâmicos para encontrar
defeitos no objeto de teste e corrigi-los, especialmente
considerando os custos adicionais associados à atualização de
outros produtos de trabalho e à realização de testes de
confirmação e regressão.
Benefícios adicionais do teste estático podem incluir:

● Detectar e corrigir defeitos com mais eficiência e antes da
execução dinâmica dos testes;
● Identificar os defeitos que não são facilmente
encontrados por testes dinâmicos;
● Prevenir defeitos no desenho ou na codificação, revelando
inconsistências, ambiguidades, contradições, omissões,
imprecisões e redundâncias nos requisitos;

● Aumentar a produtividade no desenvolvimento (p. ex.,
devido ao desenho aprimorado, código mais sustentável);
● Reduzir o custo e o tempo de desenvolvimento;
● Reduzir o custo e o tempo de teste;

● Reduzir o custo total de qualidade durante a vida útil do
software, devido a menos falhas nas etapas finais do ciclo
de vida ou após a entrega em operação;
● Melhorar a comunicação entre os membros da equipe
durante a participação nas revisões.
Diferenças entre teste estático e dinâmico
Uma das principais distinções é que o teste estático encontra

os defeitos diretamente em produtos de trabalho, em vez de
identificar as falhas causadas por defeitos quando o software
é executado
Um defeito pode residir em um produto de trabalho por muito

tempo sem causar uma falha. Se caminho onde o defeito está é
difícil de alcançar ou de ser testado, então não será fácil
construir e executar um teste dinâmico que o encontre
Outra distinção é que o teste estático pode ser usado para

melhorar a consistência e a qualidade interna dos produtos de
trabalho, enquanto o teste dinâmico geralmente se concentra
em comportamentos externamente visíveis.
Em comparação com o teste dinâmico, os defeitos mais comuns que são

mais fáceis e baratos de encontrar e corrigir por meio de teste estático
inclui:
● Defeitos em requisitos (p. ex., inconsistências, ambiguidades,
contradições, omissões, imprecisões e redundâncias);
● Defeitos de desenho (p. ex., algoritmos ineficientes ou estruturas de
banco de dados, alto acoplamento, baixa coesão);
● Defeitos de codificação (p. ex., variáveis com valores indefinidos,
variáveis declaradas e nunca utilizadas, código inacessível, código
duplicado)
● Desvios dos padrões (p. ex., falta de aderência aos padrões de

codificação);
● Especificações incorretas de interface (p. ex., unidades de
medida diferentes usadas pelo sistema de chamada do que
pelo sistema chamado);
● Vulnerabilidades de segurança (p. ex., suscetibilidade a estouro
de buffer);
● Lacunas ou imprecisões na rastreabilidade ou cobertura da
base de teste (p. ex., falta de testes para um critério de aceite).
Processo de revisão
As revisões variam de informal para formal. As revisões

informais caracterizam-se por não seguir um processo
definido e não ter um resultado formal documentado.
Revisões formais são caracterizadas pela participação da
equipe, com resultados documentados e procedimentos
documentados para conduzir a revisão.
Processo de revisão
A formalidade de um processo de revisão está relacionada a

fatores como o modelo de ciclo de vida de desenvolvimento de
software, a maturidade do processo de desenvolvimento, a
complexidade do produto a ser revisado, e quaisquer
requisitos legais ou regulatórios ou a necessidade de uma
trilha de auditoria
Processo de revisão do produto de trabalho
O processo de revisão compreende as seguintes atividades

principais:
● Planejar;
● Iniciar revisão;
● Revisão individual (ou seja, preparação individual);
● Analisar e comunicar;
● Corrigir e reportar.

principais:
● Planejar;
Planejar:
● Definir o escopo, que inclui o propósito da revisão, quais
documentos ou partes de documentos devem ser
revisados e as características de qualidade a serem
avaliadas;
● Estimar o esforço e o prazo;
● Identificar as características de revisão, como o tipo de
revisão, as atividades e checklists;
Planejar:
● Selecionar as pessoas para participar da revisão e alocar
funções;
● Definir os critérios de entrada e saída para os tipos de
revisão mais formais (p. ex., inspeções);
● Verificar se os critérios de entrada foram atendidos (para
tipos de revisão mais formais).

principais:
● Planejar;
Iniciar revisão:
● Distribuir o produto de trabalho (fisicamente ou por meios
eletrônicos) e outros materiais, como formulários de registro
de problemas, listas de verificação e produtos de trabalho
relacionados;
● Explicar o escopo, os objetivos, o processo, as funções e os
produtos de trabalho aos participantes;
● Responder a quaisquer perguntas que os participantes possam
ter sobre a revisão.

principais:
● Planejar;
Revisão individual (ou seja, preparação individual)

● Rever todo ou parte do produto de trabalho;
● Observar possíveis defeitos, recomendações e questões.

principais:
● Planejar;
Analisar e comunicar:
● Comunicar possíveis defeitos identificados (p. ex., em uma reunião
de revisão);
● Analisar possíveis defeitos, atribuindo responsável e status a eles;
● Avaliar e documentar características de qualidade;
● Avaliar as conclusões da revisão em relação aos critérios de saída
para tomar uma decisão de revisão (“rejeitar” mudanças importantes
necessárias, “aceitar” possivelmente com pequenas alterações).

principais:
● Planejar;
Corrigir e reportar
● Criar relatórios de defeitos para as descobertas que exigem
mudanças;
● Corrigir os defeitos encontrados (normalmente feitos pelo autor) no
produto de trabalho revisado;
● Comunicar os defeitos à pessoa ou equipe apropriada (quando
encontrado em um produto de trabalho relacionado ao produto de
trabalho revisado);
● Registrar o status atualizado dos defeitos (em revisões formais),
principalmente incluindo o “de acordo” do autor do comentário;
Corrigir e reportar
● Métricas de coleta (para tipos de revisão mais formais);
● Verificar se os critérios de saída foram atendidos (para
tipos de revisão mais formais);
● Aceitar o produto de trabalho quando os critérios de saída
são atingidos.
Os resultados de uma revisão de produto de trabalho

variam, dependendo do tipo de revisão e da formalidade.
Funções e responsabilidades em uma revisão
formal
Uma revisão formal típica incluirá as funções a seguir:

Autor
● Criar o produto de trabalho sob revisão;
● Corrigir os defeitos no produto de trabalho sob
revisão (se necessário)
formal

Gestor
● Responsável pelo planejamento da revisão;
● Decidir sobre a execução das revisões;
● Atribuir pessoal, orçamento e tempo;
● Monitorar a rentabilidade contínua.
formal

Facilitador (geralmente chamado de moderador)
● Garantir a execução eficaz das reuniões de revisão
(quando realizada);
● Mediar, se necessário, entre os vários pontos de vista;
● É frequentemente a pessoa sobre quem o sucesso da
revisão depende.
formal

Líder de revisão
● Assumir a responsabilidade geral pela revisão;
● Decidir quem será envolvido e organizar quando e
onde acontecerá a revisão.
formal

Revisor
● Podem ser especialistas no tema, pessoas trabalhando no projeto,
stakeholders do produto de trabalho ou indivíduos com formação
técnica ou profissional específica;
● Identificar possíveis defeitos no produto de trabalho sob revisão;
● Pode representar diferentes perspectivas (p. ex., testador,
programador, usuário, operador, analista de negócios, especialista
em usabilidade etc.).
formal

Redator (ou registrador)
● Coletar possíveis defeitos encontrados durante a
atividade de revisão individual;
● Registrar novos defeitos em potencial, pontos em
aberto e decisões da reunião de revisão (quando
realizada).
formal
Em alguns tipos de revisão, uma pessoa pode

desempenhar mais de uma função e as ações associadas
a cada função também podem variar com base no tipo de
revisão. Além disso, com o advento de ferramentas para
apoiar o processo de revisão, especialmente o registro
de defeitos, os pontos em aberto e decisões, muitas
vezes não há necessidade de um redator.
Tipos de revisão
Todos os tipos de revisão podem auxiliar na detecção de

defeitos, e o tipo de revisão selecionado deve ser
baseado nas necessidades do projeto, recursos
disponíveis, tipo de produto e riscos, domínio do negócio
e cultura da empresa, entre outros critérios de seleção.
Tipos de revisão
Um único produto de trabalho pode ser objeto de mais

de um tipo de revisão. Se mais de um tipo de revisão for
usado, o pedido pode variar. Por exemplo, uma revisão
informal pode ser realizada antes de uma revisão
técnica, para garantir que o produto de trabalho esteja
pronto para uma revisão técnica.
Tipos de revisão
Os tipos de revisão descritos acima podem ser feitos

como revisões por pares, ou seja, feitas por colegas em
um nível organizacional aproximado semelhante.
Revisão informal (p. ex., verificação de parceiros,
pareamento, revisão de pares)
● O objetivo principal é detectar defeitos potenciais;

● Outros objetivos seriam gerar novas ideias ou soluções,
resolvendo rapidamente pequenos problemas;
● Não baseado em um processo formal (documentado);
● Não pode envolver uma reunião de revisão;
● Pode ser realizado por um colega do autor (verificação de
parceiro) ou por mais pessoas
Revisão informal (p. ex., verificação de parceiros,
pareamento, revisão de pares)
● Os resultados podem ser documentados;

● Varia em utilidade dependendo dos revisores;
● O uso de checklists é opcional;
● Muito comumente usados no desenvolvimento ágil.
Acompanhamento (walkthrough)
● Os principais objetivos são encontrar defeitos, melhorar o

produto de software, considerar implementações alternativas,
avaliar a conformidade com padrões e especificações;
● Objetivos adicionais seriam a troca de ideias sobre técnicas ou
variações de estilo, treinamento de participantes, obtenção de
consenso;
● A preparação individual antes da reunião de revisão é opcional;
● A reunião de revisão é normalmente liderada pelo autor do
produto de trabalho;
Acompanhamento (walkthrough)
● O redator é obrigatório;
● O uso de checklists é opcional;
● Pode assumir a forma de cenários, teste prático (dry run)
ou simulações;
● Possíveis logs de defeitos e relatórios de revisão podem
ser produzidos;
● Pode variar na prática de bastante informal para muito
formal.
Revisão técnica
● Os principais objetivos são a obtenção de consenso e a

detecção de defeitos potenciais.
● Outros objetivos possíveis são: avaliar a qualidade e criar
confiança no produto de trabalho, gerando novas ideias,
motivando e capacitando os autores a melhorar os produtos de
trabalho futuros, considerando implementações alternativas.
● Os revisores devem ser pares técnicos do autor e especialistas
técnicos nas mesmas disciplinas ou em outras disciplinas
Revisão técnica
● É necessária a preparação individual antes da reunião.

● A reunião de revisão é opcional, preferencialmente
conduzida por um facilitador treinado (normalmente que
não seja o autor).
● 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
Inspeção
● Os principais objetivos são detectar os defeitos potenciais e

avaliar a qualidade e criar confiança no produto de trabalho,
evitando futuros defeitos semelhantes por meio do
aprendizado do autor e da análise da causa-raiz.
● Outros possíveis objetivos são: motivar e capacitar os autores
a melhorar os futuros produtos de trabalho e o processo de
desenvolvimento de software, alcançando consenso.
● Segue um processo definido com saídas documentadas
formais, com base em regras e checklists.
Inspeção
● É necessária a preparação individual antes da reunião.

● Os revisores são pares do autor ou especialistas em outras
disciplinas relevantes para o produto de trabalho.
● São usados critérios de entrada e saída especificados.
● O redator é obrigatório.
● A reunião de revisão é liderada por um facilitador treinado
(não pelo autor).
Inspeção
● O autor não pode atuar como líder de revisão, leitor ou

redator.
● São produzidos registros de defeitos potenciais e o
relatório de revisão.
● As métricas são coletadas e usadas para melhorar todo o
processo de desenvolvimento de software, incluindo o
processo de inspeção.
Aplicando técnicas de revisão
Há uma série de técnicas de revisão que podem ser aplicadas

durante a atividade de revisão individual (ou seja, preparação
individual) para descobrir defeitos. Essas técnicas podem ser
usadas nos tipos de revisão descritos anteriormente.
Exemplos de diferentes técnicas de revisão individuais:

● Revisão ad hoc
● Revisão baseada em checklist
● Revisão baseada em cenários
● Revisão baseada na perspectiva
● Revisão baseada em papéis

● Revisão ad hoc
Revisão ad hoc:
Em uma revisão ad hoc, os revisores recebem pouca ou
nenhuma orientação sobre como essa tarefa deve ser
executada. Os revisores geralmente leem o produto de
trabalho sequencialmente, identificando e documentando os
problemas à medida que os encontram.

● Revisão ad hoc
Revisão baseada em checklist:

Uma revisão baseada em checklist é uma técnica sistemática,
na qual os revisores detectam os problemas com base em
checklists que são distribuídos no início da revisão (p. ex., pelo
facilitador)
Um checklist de revisão consiste em um conjunto de perguntas baseadas em possíveis

defeitos, que podem ser derivados da experiência

● Revisão ad hoc
Revisão baseada em cenários:

Em uma revisão baseada em cenário, os revisores recebem
orientações estruturadas sobre como ler o produto de
trabalho. Uma abordagem baseada no cenário dá suporte aos
revisores na execução de "sequências" no produto de trabalho
com base no uso esperado do produto de trabalho (se o
produto de trabalho for documentado em um formato
adequado, como casos de uso).

● Revisão ad hoc
Revisão baseada na perspectiva:

Na revisão baseada na perspectiva, semelhante a uma revisão baseada
em papéis, os revisores assumem os pontos de vista de diferentes
stakeholders na revisão individual. Os pontos de vista comuns dos
stakeholders incluem o usuário final, marketing, designer, testador ou
operador.
Além disso, esse modelo também exige que os revisores tentem usar o
produto de trabalho sob revisão para gerar o produto que eles obteriam

● Revisão ad hoc
Revisão baseada em papéis:

Uma revisão baseada em papéis é uma técnica na qual os
revisores avaliam o produto de trabalho na perspectiva dos
papéis individuais dos stakeholders. Os papéis típicos incluem
tipos específicos de usuário final (experiente, inexperiente,
sênior, jovem etc.) e papéis específicos na organização
(administrador do usuário, administrador do sistema, testador
de performance etc.).
Fatores de sucesso para revisões
Fatores organizacionais de sucesso para revisões incluem:

● Cada revisão tem objetivos claros, definidos durante o seu
planejamento e usados como critérios mensuráveis de saída;
● São aplicados tipos de revisão que são adequados para alcançar os
objetivos e são apropriados ao tipo e nível de produtos de trabalho
de software e participantes;
● Quaisquer técnicas usadas de revisão, como baseada em checklist
ou baseada em papéis, são adequadas para a identificação efetiva de
defeitos no produto de trabalho a ser revisado
Fatores organizacionais de sucesso para revisões incluem:

● Todos os checklists utilizados abordam os principais riscos e
deverão estar atualizados.
● Documentos grandes são escritos e revisados em pequenos
pedaços, para que o controle de qualidade seja exercido
através do fornecimento de feedback antecipado e frequente
aos autores sobre os defeitos.
● Os participantes devem ter tempo suficiente para se preparar.
Fatores organizacionais de sucesso para revisões

incluem:
● As revisões são agendadas com aviso adequado.
● A gerência apóia o processo de revisão (p. ex.,
incorporando tempo adequado para atividades de
revisão nos cronogramas do projeto).
Os fatores de sucesso relacionados às pessoas para revisões incluem:

● As pessoas certas estão envolvidas para atender aos objetivos de
revisão, por exemplo, pessoas com diferentes conjuntos de
habilidades ou perspectivas, que podem usar o documento como
uma entrada de trabalho.
● Os testadores são vistos como revisores valiosos que contribuem
para a revisão e aprendem sobre o produto de trabalho, o que
permite que eles preparem testes mais eficazes e preparem esses
testes antes.
● Os participantes dedicam tempo e atenção adequados aos detalhes.
Os fatores de sucesso relacionados às pessoas para revisões incluem:

● As revisões são realizadas em pequenos trechos, para que os
revisores não percam a concentração durante a revisão individual ou
na reunião de revisão (quando realizada).
● Os defeitos encontrados são reconhecidos, apreciados e
manipulados objetivamente.
● A reunião é bem administrada, para que os participantes considerem
um uso valioso do seu tempo.
● A revisão é conduzida em uma atmosfera de confiança; o resultado
não será usado para a avaliação dos participantes
Os fatores de sucesso relacionados às pessoas para revisões

incluem:
● Os participantes evitam linguagem corporal e
comportamentos que possam indicar tédio, exasperação ou
hostilidade a outros participantes.
● O treinamento adequado é fornecido, especialmente para os
tipos de revisão mais formais, como as inspeções.
● Uma cultura de aprendizado e melhoria de processos é
promovida
Atividades
Realizar os casos de teste e registros de defeitos de

acordo com o documento de exemplo encontrado na
pasta Aula 4 - Técnicas de teste.

Aula 4 - Técnicas de Teste

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula 4 - Técnicas de Teste

Enviado por

Direitos autorais:

Formatos disponíveis

Técnicas de teste

O primeiro incremento é frequentemente chamado de “núcleo

O desenvolvimento iterativo ocorre quando grupos de

Atividades e tarefas de teste

O objetivo principal do processo de teste de software é

O objetivo de uma técnica de teste é ajudar a identiﬁcar as

A escolha de quais técnicas de teste usar depende de

A escolha de quais técnicas de teste usar depende de

As técnicas de teste são classiﬁcadas como caixa-preta,

Essa técnica pode ser adotada quando a equipe de teste

Como o próprio nome indica, essa técnica de teste

Em outras palavras, trazendo um pouco mais para a

De acordo com Myers (Myers, 2004), na técnica

Para aplicar esse critério de teste, precisamos dividir o

Para ajudar o time de teste do ERP (e todos os

De acordo com Maldonado e Fabbri (Maldonado &

Cada critério possui seus requisitos de teste, que ajudam

Critério de teste ﬁctício chamado “Critério dos números

Os principais critérios de teste caixa preta são:

Os principais critérios de teste caixa preta são:

Os principais critérios de teste caixa preta são:

Análise do valor limite:

Análise do valor limite:

Análise do valor limite:

Análise do valor limite:

Análise do valor limite:

Análise do valor limite:

Análise do valor limite:

Os principais critérios de teste caixa preta são:

Teste de transição de estado :

Teste de transição de estado :

Teste de transição de estado :

Uma transição é iniciada por um evento (p. ex., entrada do usuário de um

Teste de transição de estado :

Os principais critérios de teste caixa preta são:

Teste de caso de uso:

Teste de caso de uso:

Teste de caso de uso:

Teste de caso de uso:

Cada caso de uso especiﬁca algum comportamento que um assunto pode

Teste de caso de uso:

Sendo assim, com mais quatro casos de teste nós

Essa técnica pode ser adotada quando a equipe de teste

Essa exigência é devido ao fato que a base para deﬁnição

Como o próprio nome indica, essa técnica de teste

Você continua tendo que saber o que precisa colocar

Em outras palavras, trazendo um pouco mais para a

De acordo com Myers (Myers, 2004), na técnica

Voltando no mesmo exemplo que usamos na seção

Voltando no mesmo exemplo que usamos na seção

Para facilitar a deﬁnição dos casos de teste da técnica

O Grafo de Fluxo de Controle nada mais é que um

Sabendo como representar um programa que será

Os critérios de teste da técnica caixa branca são

Os critérios de teste da técnica caixa branca são

Os principais critérios de teste caixa branca Baseado em

Os principais critérios de teste caixa branca Baseado em

Teste de Comandos ou Teste Todos os nós:

Teste de Comandos ou Teste Todos os nós:

Os principais critérios de teste caixa branca Baseado em

Teste de Ramos ou Todas as Arestas ou Todos os Arcos:

Os principais critérios de teste caixa branca Baseado em

A análise estática de softwares, também conhecida como