Tabela de decisão

A tabela de decisão é uma forma organizada de listar todas as possíveis

combinações de entradas em um sistema e as saídas que esperamos obter para
cada combinação.

Imagine que você tem um sistema que recebe algumas informações como entrada e
precisa dar uma resposta com base nessas informações. A tabela de decisão é uma
maneira de mapear todas as diferentes situações possíveis e o resultado esperado
para cada uma delas.

Por exemplo, se você estivesse testando um aplicativo de entrega de comida, as

condições de entrada poderiam ser coisas como "tipo de comida", "endereço de
entrega" e "horário do pedido". A tabela de decisão ajudaria a listar todas as
combinações possíveis dessas condições e a resposta esperada para cada
combinação, como "entregar pizza no endereço X às 19h".

A tabela de decisão ajuda os testadores a garantir que o sistema esteja funcionando

corretamente, executando as combinações de entrada e comparando as respostas
reais com as respostas esperadas na tabela. Se houver alguma diferença, significa
que algo pode estar errado e precisa ser corrigido.

Basicamente, a tabela de decisão é uma ferramenta útil para mapear todas as

diferentes situações possíveis e suas saídas esperadas, permitindo que os
testadores verifiquem se o sistema está respondendo corretamente em cada
situação.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
técnica pair-wise

A técnica de pair-wise, também conhecida como comparação em pares, envolve

comparar dois itens de cada vez e atribuir uma pontuação ou classificação a cada
par. Essas comparações são feitas usando critérios específicos. Em seguida, as
pontuações são usadas para determinar a classificação geral dos itens. Essa
abordagem é comumente usada em métodos de análise de decisão, como a Análise
Hierárquica (AHP) e a Análise de Valor Relativo (RVA). Em suma, a técnica de
pair-wise é uma maneira de classificar itens ou características ao compará-los de
forma sistemática e relativa.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Teste de caixa branca

● teste de caixa branca é feito nas funções mais utilizadas, críticas e com
mais possibilidades de erros

● TESTE UNITÁRIO
verificação da menor unidade do projeto de software. Realiza o teste de uma
unidade lógica, com uso de dados suficientes para se testar apenas a lógica
da unidade em questão.

análise de cobertura
A análise de cobertura é uma técnica utilizada no teste de caixa branca para medir o
quão bem o conjunto de casos de teste está exercitando o código fonte de um
programa. Ela envolve a avaliação do grau de cobertura dos elementos estruturais
do código, como instruções, ramos condicionais, laços de repetição e caminhos
lógicos.

A análise de cobertura ajuda a identificar áreas do código que não estão sendo
adequadamente testadas e, portanto, podem conter erros não detectados. Quanto
maior a cobertura, maior a probabilidade de descobrir defeitos no código.

Existem diferentes critérios de cobertura utilizados na análise de cobertura, tais

como:

1. Cobertura de instruções (Statement coverage): mede a proporção de instruções

executadas durante a execução dos casos de teste. O objetivo é garantir que todas
as instruções do código tenham sido executadas pelo menos uma vez.

2. Cobertura de decisões (Decision coverage): verifica se todas as decisões lógicas,

como os ramos condicionais "if" e "switch", foram avaliadas em ambos os resultados
possíveis (verdadeiro e falso).

3. Cobertura de caminhos (Path coverage): procura garantir que todos os caminhos

possíveis do código tenham sido percorridos durante a execução dos casos de
teste. Isso inclui a cobertura de todos os caminhos lógicos independentes dentro de
um método ou função.

4. Cobertura de condições (Condition coverage): foca na cobertura de todas as

condições individuais dentro de cada decisão lógica. O objetivo é verificar se todas
as combinações possíveis de valores booleanos foram testadas.

5. Cobertura de laços (Loop coverage): visa garantir que todos os laços de repetição
tenham sido testados pelo menos uma vez e que também foram testados casos em
que o laço não foi executado nenhuma vez.

A escolha do critério de cobertura depende do contexto do projeto e dos requisitos

de teste. Geralmente, é recomendado buscar um equilíbrio entre a cobertura
desejada e o esforço necessário para alcançá-la.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

geração de casos de teste

A geração de casos de teste é uma atividade realizada no contexto do teste de caixa
branca, onde os casos de teste são criados com base na análise da estrutura interna
do código fonte do programa. O objetivo é garantir que todos os caminhos e
condições lógicas do código sejam exercitados durante os testes.

Existem várias técnicas de geração de casos de teste utilizadas no teste de caixa

branca. Algumas delas incluem:

1. Partição de Equivalência: divide o conjunto de dados de entrada em classes de

equivalência, onde cada classe representa um conjunto de entradas que devem ser
tratadas de maneira semelhante pelo programa. Em seguida, são selecionados
casos de teste que cobrem cada classe de equivalência pelo menos uma vez.

2. Análise de Valor Limite: concentra-se nos limites dos intervalos de valores válidos
para os dados de entrada. Os casos de teste são projetados para testar os limites
inferiores e superiores, bem como os valores adjacentes aos limites.

3. Tabela de Decisão: é uma técnica utilizada quando o comportamento do

programa depende de várias condições combinadas. A tabela de decisão lista todas
as combinações possíveis de valores das condições e especifica o resultado
esperado para cada combinação. Os casos de teste são então derivados para cobrir
todas as combinações na tabela.

4. Cobre-e-Verifica: nessa abordagem, o testador identifica as estruturas de controle

de fluxo no código, como loops e condicionais, e cria casos de teste que percorrem
essas estruturas de forma completa e efetiva. O testador cobre o código com os
casos de teste criados e verifica se o comportamento observado corresponde ao
esperado.

5. Teste de Caminho Básico: utiliza a representação gráfica do fluxo de controle do

programa, como um grafo de fluxo, para identificar todos os caminhos
independentes no código. Os casos de teste são projetados para percorrer cada
caminho pelo menos uma vez.

Essas são apenas algumas das técnicas comuns utilizadas para a geração de casos
de teste no teste de caixa branca. A escolha da técnica ou combinação de técnicas
depende do contexto do projeto, da complexidade do código e dos objetivos de teste
estabelecidos.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Teste estrutural
■ Ponto de entrada é o código fonte.
■ Mais propenso à automação.
■ Procura exercitar o maior número possível de possibilidades de execução do
programa, de acordo com algum critério pré-definido.
■ Especificação funcional é usada apenas como oráculo.

O teste estrutural é uma forma de testar um programa de computador olhando para

o seu código interno. É como abrir a "caixa branca" do programa e examinar como
ele funciona por dentro. O objetivo é garantir que todas as partes do código sejam
testadas corretamente e que todas as instruções funcionem como deveriam. Para
fazer isso, criamos casos de teste que verificam diferentes partes do código, como
as condições e os loops. Dessa forma, podemos ter certeza de que o programa
funciona corretamente e atende às especificações. É uma forma de garantir a
qualidade do software olhando diretamente para o seu "cérebro" interno.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Teste funcional

■ Usa como entrada a especificação funcional .

■ Procura verificar se todas as funcionalidades previstas foram feitas e se
respondem como esperado.
■ Incapaz de verificar funcionalidades ou comportamentos extras não
especificados.

O teste funcional é uma técnica de teste que verifica se um software está

funcionando corretamente de acordo com o que foi planejado. Ele se concentra em
testar as funções ou recursos do software, como botões, formulários, links e outros
elementos que os usuários interagem. O objetivo é garantir que o software esteja
cumprindo suas tarefas corretamente, sem se preocupar com o código interno do
programa. Em suma, o teste funcional verifica se o software está fazendo o que
deveria fazer.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Grafos
● Análise dinâmica.
○ Execução monitorada do programa.
○ Pode exigir instrumentação de código.
○ Abordagens.
■ Análise de cobertura.
■ Geração de casos de teste.
■ Grafo de programa.

● Análise de cobertura: dado um conjunto de execuções do programa, quanto do

código fonte foi exercitado (coberto)?

● Geração de casos de teste: criam-se casos de teste com o objetivo de atingir um

determinado valor de cobertura. As métricas são ○ Fluxo de controle (Grafo de Fluxo
de Controle – GFC) ○ Fluxo de dados.

● Grafo de programa: define uma relação entre o caso de teste e a parte do

programa exercitada por ele. Um caso de teste corresponde a ○ um caminho no
grafo ○ uma execução completa, do nodo inicial até o nodo final.

Grafo de Fluxo de Controle

● Representação abstrata de um programa, de uma função ou de um método
● Consiste de dois componentes:
○ Nodo: representa um ou mais comandos;
○ Aresta ou arco direcionado: representa um caminho alternativo na execução.
● Caminho é uma coleção de nodos ligados com arcos direcionados
Fluxo de controle
● Cada caso de teste corresponde a um caminho no grafo de fluxo de controle (GFC)
● Etapas
○ Construir o GFC do programa
○ Determinar os caminhos factíveis
○ Selecionar um conjunto de caminhos factíveis para teste
○ Gerar as entradas e os resultados esperados para os casos de teste
correspondentes
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Complexidade ciclomática

Região:
Predicado
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Caminhos possíveis
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Teste Unitário