You are on page 1of 6

Copyiight Ç Anuié Luis Sena Nascimento Pág.

1

Técnicas de Caixa Preta de Teste de Software

Na maioria de projetos de teste, o tempo para a realização dos mesmos sempre é
curto e os números de testes a serem realizados nas aplicações são inúmeros. Isso sem falar
dos testes “Não-Funcionais”, como por exemplo, os de performance, de usabilidade, de
stress, de escalabilidade, etc. É necessário se ter um planejamento bem elaborado para que
todo o projeto de testes, consiga entregar um produto com no mínimo qualidade esperada
pelo cliente e no prazo que foi acordado.
No intuito de se realizar esse processo com certa eficiência, é necessário utilizar das
técnicas de teste de software que é o tema desse artigo. Para isso, respondemos a pergunta
de como fazer o processo. Entretanto, para responder a pergunta, o que e o que priorizar
primeiro, temos que levar em consideração os riscos associados ao projeto de teste que
devem ser levantados tão logo se inicia o projeto de todo o software. Levantados e
analisados os riscos e, fazendo uso correto das técnicas de teste, é muito provável que todo
o projeto de teste consiga alcançar o mínimo de qualidade esperada.
O nome caixa preta vem do sentido de que nesse tipo de teste, não é
necessário saber a estrutura interna de como o código foi implementado ou a tecnologia que
foi utilizada. Nesse tipo de análise, essas questões são transparentes para os analistas de
teste. É claro que para se ter um projeto de teste bem sucedido, é necessário usar a técnica
de caixa preta e mais a de caixa branca, isto é, analisar, também, a estrutura interna da
aplicação.
Na nomenclatura também se utiliza o termo em inglês “Black Box” ou “Testes
Funcionais”. Aqui, listo as principais técnicas de caixa preta de teste de software, com
exemplos ilustrativos e, ainda, mostra como se medir a porcentagem de cobertura depois
que os testes são executados para cada uma das técnicas.

1) Classe de Equivalência (Equivalent Partioning)

Essa técnica é baseada na premissa que a entrada e saída de um componente podem
ser particionados em classes de equivalência que, de acordo com a especificação do
componente serão tratados similarmente pelo componente. Assim, o resultado de um teste
usando um simples valor dessa classe de equivalência é considerado representativo em
relação a uma classe.
O modelo deve compreender partições de valores de entrada e saída. Cada partição
deve conter um intervalo de valores, escolhidos de tal maneira, que todos os valores nessa
classe têm o mesmo resultado, daí o nome equivalência. Podem ser usados valores válidos e
inválidos para serem candidatos à classe de equivalência. É desejável se ter pelo menos um
caso de teste para exercitar cada uma das classes de equivalência para se ter uma máxima
cobertura da aplicação.
Um exemplo de onde essa técnica pode ser aplicada é a classificação das notas dos
alunos em A, B, C ou D de acordo com a pontuação de cada um. Se, para se conseguir uma
classificação A, o aluno tem que tirar nota entre 90 e 100, B entre 80 e 89, C entre 70 e 79 e
D abaixo de 70, sendo que o sistema só aceita caracteres numéricos.
Graficamente, temos:

Copyiight Ç Anuié Luis Sena Nascimento Pág. 2

Para exercitar todas as classificações das notas que são as classes de equivalência A,
B,C e D é necessário ter como entradas dos casos de teste pelo menos um representante de
cada classe de equivalência, por exemplo, entradas 69 para ter como saída o valor “D”, o
valor 75 exercitar a segunda classe de equivalência e ter a classificação “C”, o valor 84,
para se obter “B” e o valor 93 para se obter “A”. Além desse conjunto de entradas válidas,
as entradas inválidas, também seriam pertinentes para avaliar o sistema, como por exemplo,
caracteres alfas-numéricos e especiais. Esses valores são mostrados na tabela abaixo:

Conjunto de Casos de Teste de Classes de Equivalência
Caso de Teste 1 2 3 4 5 6
Entrada 69 75 84 93 A &
Saída D C B A Erro Erro

Para medir a cobertura dos testes usando essa técnica, usa-se a seguinte fórmula:

Cobertura Classe de Equivalência = Número de Partições Testadas * 100 %
Total de Partições

2) Valores de Borda (Boundary Value Analysis)

Essa técnica usa um modelo de componente que particiona as entradas e saídas dos
valores de um componente em conjuntos de classificações, cujos valores de borda são
exercitados. Esses conjuntos de classificações são obtidos através de especificações do
comportamento do componente.
Primeiramente, é necessário ter em mente quais os conjuntos de classificações
compreendidas pelo sistema e, depois, levantar os valores de borda de cada um desses
conjuntos. O objetivo aqui é produzir casos de teste com entradas usando os valores de
borda de cada um desses conjuntos.
Essa técnica é uma das mais úteis, tanto para testadores quanto para
desenvolvedores, pois através dela é que são identificados muitos problemas de aceitação
de valores de entradas em um sistema, principalmente, quando se usa o valor nulo ou o
valor zero. Muitos desenvolvedores se valem dela para fazer testes unitários, pois eles
precisam analisar se o tratamento dado por eles no código está prevendo essas condições.
Como exemplo prático pode citar o exemplo anterior ou, também, para testes de
datas de um sistema. No caso do exemplo anterior, alguns valores válidos e inválidos para
se testar os valores de borda das classes de equivalências são mostrados na tabela abaixo:

Conjunto de Casos de Teste de Valores de Borda
Classe de Equivalência Entradas Saída
D 69, 68,11,1,0 D
C 70, 78, 79 C
B 80, 88, 89 B
A 90, 98, 99, 100 A
Inválida A, Y, *, ^, %, # Erro

Para se testar datas válidas de um sistema, a técnica de valores de borda pode ser
aplicada, pois sabe que os meses com trinta dias são: Abril, Junho, Setembro e Novembro,
com trinta e um dias são: Janeiro, Março, Maio, Julho, Agosto, Outubro e Dezembro e
Copyiight Ç Anuié Luis Sena Nascimento Pág. S

Fevereiro com vinte e oito ou vinte e nove dias dependendo se é um ano bissexto ou não.
Então podemos levantar os valores de borda para testar se um sistema está validando ou
não, as entradas de data que deve ter o formato: DD/MM/AAAA. Esses valores são
mostrados abaixo:

Conjunto de Casos de Teste de Valores de Borda
Classe de
Equivalência
Entradas Válidas Entradas Inválidas
Janeiro 01/01/2000, 30/01/2000, 31/01/2000 32/01/2000, 31/1/2000, 31/01/00
Fevereiro 01/02/2000, 28/02/2000, 29/02/2000 29/02/2001, 30/02/2000,
31/02/2000
Março 01/01/2000, 30/01/2000, 31/01/2000 32/03/2000, 31/3/2000, 31/03/00
Abril 01/04/2000, 29/04/2000, 30/04/2000 31/04/2000, 30/4/2000, 30/04/00
Maio 01/05/2000, 30/05/2000, 31/05/2000 32/05/2000, 31/5/2000, 31/05/00
Junho 01/06/2000, 29/06/2000, 30/06/2000 31/06/2000, 30/6/2000, 30/06/00
Julho 01/07/2000, 30/07/2000, 31/07/2000 32/07/2000, 31/7/2000, 31/07/00
Agosto 01/08/2000, 30/08/2000, 31/08/2000 32/08/2000, 31/8/2000, 31/08/00
Setembro 01/09/2000, 29/09/2000, 30/09/2000 31/09/2000, 30/9/2000, 30/09/00
Outubro 01/10/2000, 30/10/2000, 31/10/2000 32/10/2000, 31/0/2000, 31/10/00
Novembro 01/11/2000, 29/11/2000, 30/11/2000 31/11/2000, 30/1/2000, 30/11/00
Dezembro 01/12/2000, 30/12/2000, 31/12/2000 32/12/2000, 31/2/2000, 31/12/00

Para medir a cobertura de cobertura usando essa técnica, usa-se a seguinte fórmula:

Cobertura Valor de Borda = Número de Valores de Borda Executados * 100 %
Total de Valores de Borda

3) Transição de Estados (State Transition)

Essa técnica de caixa preta é baseada sobre a análise da especificação de um
componente para modelar o comportamento dele em transições de estados. Ela usa um
modelo de estados que o componente deve ocupar, as transições entre esses estados, os
eventos que causam essas transições e as ações que resultam dessas transições.
O modelo é tipicamente representado por estados, transições de estados, eventos,
entradas e saídas de um componente e todos eles serem identificáveis. Os eventos causam
transições entre estados e transições podem retornar para o estado original onde eles
começaram. Eles são causados pelas ações que causam saídas nos mesmos.
Os casos de teste devem ser elaborados para exercitar todas as transições de estados
do componente. Nele deve ser especificado, o primeiro estado do componente, a entrada, as
saídas esperadas, o evento que causa a transição para o próximo estado, a ação esperada
causada pela transição e o próximo estado esperado. Graficamente, podemos ilustrar essa
técnica da seguinte maneira:
Copyiight Ç Anuié Luis Sena Nascimento Pág. 4



Como exemplo de uso dessa técnica pode citar o sistema de uma companhia aérea
que mostra todos os lugares de um vôo. Os lugares podem estar ocupados, reservados ou
disponíveis. São estados que esse componente pode assumir. A entrada é a escolha de uma
poltrona por um cliente ou uma reserva. Logo após isso, o sistema dispara um evento para
atualizar aquele assento que estava disponível para ocupado ou reservado. O sistema pode
fazer mais algumas validações (eventos) do tipo, se um assento ficar por mais de um tempo
reservado, volta para disponível ou, ainda, se a pessoa ocupar a poltrona e não confirmar a
sua escolha volta de reservado para disponível.
Elaborar casos de teste para esse sistema não é uma tarefa muito fácil para os
analistas, pois eles devem cobrir todos os estados que a poltrona pode assumir e as todas as
condições em que elas ocorrem.
Para medir a cobertura de cobertura usando essa técnica, usa-se o percentual de
todos os valores válidos que foram exercitados durante o teste.

4) Gráfico de Causa e Efeito (Cause & Effect Graphing)

Gráfico de causa e efeito usa um modelo de relações lógicas entre causas e efeitos
para um componente. Cada causa é expressa como uma condição, que pode ser verdadeira
ou falsa (condição Booleana) de entrada ou uma combinação de entradas para o
componente. Cada efeito é expresso como sendo uma expressão Booleana representando
uma saída, ou uma combinação de saídas para o componente ocorrido.
O modelo é tipicamente representado como gráfico Booleano relacionando as
entradas e saídas Booleanas, usando os operadores Booleanos: AND, OR, NAND, NOR e
NOT. Desse gráfico, é produzida uma tabela de decisão representando as relações lógicas
entre causas e efeitos.
Os casos de teste devem ser projetados para exercitar as regras, que definem a
relação entre as entradas e saídas dos componentes, onde cada regra corresponde a uma
possibilidade única de entrada para o componente que tem sido expresso como booleano. O
caso de teste deve identificar o estado booleano de cada causa e o estado para cada efeito.
Copyiight Ç Anuié Luis Sena Nascimento Pág. S

Como exemplo dessa técnica pode citar os casos de teste para validar as operações
bancárias feitas por um correntista. As entradas (causas) para esse projeto de teste seria o
tipo de conta, limite máximo, saldo atual e montante de débito. Os efeitos são flag para
saber se a operação foi realizada ou não e o saldo atual da correntista. Os casos de teste que
podem ser levantados para validar essa aplicação são inúmeros e, o resultado deles,
depende das operações booleanas para saber se será possível ou não realizar a transação.

Para medir a cobertura de cobertura usando essa técnica, usa-se a seguinte fórmula:

Cobertura Causa-Efeito = Número de Regras Exercitadas * 100 %
Total de Regras

5) Técnica de Sintaxe (Syntax Testing)

Essa técnica de caixa preta é baseada sobre a análise da especificação de requisitos.
Nesse documento são especificados os valores possíveis que uma entrada do sistema pode
receber. No entanto, nesse documento, as entradas inesperadas, na maioria das vezes, não
são tratadas. É nesse contexto que se insere a técnica de “Técnica de Sintaxe”. Ela consiste
em ter como entradas esperadas e as não esperadas para validar a especificação de
requisitos e avaliar o comportamento de um sistema quando esses valores não especificados
são usados.
Ë nessa técnica onde são encontrados os principais problemas de tratamentos de
exceções, já que ela se divide em “Sintaxe Válida” e “Sintaxe Inválida”. Na primeira,
somente os valores esperados são utilizados, como por exemplo, valores numéricos em
campos que remetem a uma quantidade de dias de férias que um funcionário tem a receber,
saldo de uma conta, livros em um andar de uma biblioteca, valores alfa em campos de
nomes, sobrenomes, endereço, etc. Já na segunda técnica, a Sintaxe Inválida, o objetivo é
exercitar as entradas inválidas, como inserção de valores alfa em campos numéricos,
inserção de valores numéricos em campos de valores alfa, inserção de caracteres especiais,
inserção de valores float em campos numéricos e inteiros, inserção de valores negativos em
campos de valores numéricos e inteiros, inserção de vírgulas e pontos em campos de
valores numéricos. Todas essas entradas visam validar qual será o tratamento dado pela
aplicação quando esses valores forem usados. Ë desejável que mensagens de erro e de ajuda
sejam colocadas na tela no sentido de guiar o usuário a usar os valores corretos.
Outro aspecto que vale mencionar é que na maioria das especificações de requisitos,
nem os valores aceitáveis são especificados. Nesse caso, seria interessante descobrir quais
os tipos de valores que os campos podem receber dando uma olhada no banco de dados
dessa aplicação. O arquiteto de teste aliado a um desenvolvedor que tenha mais
proximidade consegue levantar essa informação. Nesse caso, o levantamento dessas
informações é essencial para a aplicação dessa técnica.

Para medir a cobertura de cobertura usando essa técnica, usa-se a seguinte fórmula:

Cobertura Teste Sintaxe = Número de Testes Sintaxe Exec * 100 %
Total de Casos de Teste



Copyiight Ç Anuié Luis Sena Nascimento Pág. 6

6) Teste Randômico (Random Testing)

Essa técnica consiste em utilizar um algoritmo pseudo-randômico para se escolher
quais os casos de testes serão usados para validar uma funcionalidade de uma determinada
aplicação dentro um conjunto definido de valores. O objetivo aqui não é fazer testes Ad-
Hoc (testes sem resultados previamente esperados e sem um propósito) e, sim,
simplesmente, em uma escolha dos casos de teste que foram previamente elaborados.
Normalmente, se aplica essa técnica quando o tempo de teste foi reduzido em virtude de
eventualidades que aconteceram no projeto.
Um dos exemplos clássicos para exemplificar essa técnica é o “Diagrama de
Pareto”. O princípio se baseia em uma análise quantitativa, ou seja, 80% de todos os
problemas são oriundos de 20% das causas potenciais. No contexto de teste de software, se
baseia em escolher 20% de todos os casos de testes criados, cobrindo 80% das
funcionalidades de todo o projeto. Para ter esse conjunto de casos de teste, é necessário ter
uma relação de requisitos do sistema x testes criados. Depois de feita essa relação, escolher
os casos de testes que mais aparecem nessa relação.
Um exemplo que ilustra essa técnica é mostrado abaixo. Segundo a tabela abaixo,
temos um total de 30 casos de testes criados hipoteticamente ligados aos requisitos básicos
de um sistema de uma biblioteca. Seguindo o principio de Pareto, se testarmos, os casos de
teste, 2,3,7,18,22 e 25 que são os 20% principais e que mais cobrem funcionalidades,
estaremos cobrindo 80% das funcionalidades totais da aplicação.

Sistema de uma Biblioteca
Funcionalidades Básicas Casos de Testes criados
Inclusão de Dados de Usuário 1,2,3,4,5,14
Edição de Dados de Usuário 2,5,6,7,8,9,13
Deleção de Dados de Usuário 2,3,7,10,11,12
Reserva de Livros 15,16,17,18,19,20,21,22
Adição de Livros 18,22,23,24,25,26
Remoção de Livros 25, 27,28,29,30

Para medir a cobertura de cobertura usando essa técnica, usa-se a seguinte fórmula:

Cobertura Teste Randômico = Número de Testes Exec Randomic * 100 %
Total de Casos de Teste







Agosto. usa-se a seguinte fórmula: Cobertura Classe de Equivalência = Número de Partições Testadas * 100 % Total de Partições 2) Valores de Borda (Boundary Value Analysis) Essa técnica usa um modelo de componente que particiona as entradas e saídas dos valores de um componente em conjuntos de classificações. levantar os valores de borda de cada um desses conjuntos. O objetivo aqui é produzir casos de teste com entradas usando os valores de borda de cada um desses conjuntos. quando se usa o valor nulo ou o valor zero. principalmente. Esses conjuntos de classificações são obtidos através de especificações do comportamento do componente. com trinta e um dias são: Janeiro.C e D é necessário ter como entradas dos casos de teste pelo menos um representante de cada classe de equivalência. pois através dela é que são identificados muitos problemas de aceitação de valores de entradas em um sistema. Esses valores são mostrados na tabela abaixo: Caso de Teste Entrada Saída Conjunto de Casos de Teste de Classes de Equivalência 1 2 3 4 5 69 75 84 93 A D C B A Erro 6 & Erro Para medir a cobertura dos testes usando essa técnica. 99. caracteres alfas-numéricos e especiais. como por exemplo. No caso do exemplo anterior. Muitos desenvolvedores se valem dela para fazer testes unitários. cujos valores de borda são exercitados. pois sabe que os meses com trinta dias são: Abril.0 C 70. B. Como exemplo prático pode citar o exemplo anterior ou.11. para se obter “B” e o valor 93 para se obter “A”. Y. %. entradas 69 para ter como saída o valor “D”. ^. 78. 100 Inválida A. pois eles precisam analisar se o tratamento dado por eles no código está prevendo essas condições. Setembro e Novembro. as entradas inválidas. por exemplo. 68. Julho. a técnica de valores de borda pode ser aplicada. o valor 84. # Saída D C B A Erro Para se testar datas válidas de um sistema. Outubro e Dezembro e . o valor 75 exercitar a segunda classe de equivalência e ter a classificação “C”. 88. alguns valores válidos e inválidos para se testar os valores de borda das classes de equivalências são mostrados na tabela abaixo: Conjunto de Casos de Teste de Valores de Borda Classe de Equivalência Entradas D 69. 98. Junho. Primeiramente. é necessário ter em mente quais os conjuntos de classificações compreendidas pelo sistema e. Março. Essa técnica é uma das mais úteis. também seriam pertinentes para avaliar o sistema.Para exercitar todas as classificações das notas que são as classes de equivalência A. 79 B 80. para testes de datas de um sistema. 89 A 90.1. depois. *. Além desse conjunto de entradas válidas. tanto para testadores quanto para desenvolvedores. Maio. também.

os eventos que causam essas transições e as ações que resultam dessas transições. 30/9/2000. podemos ilustrar essa técnica da seguinte maneira: . 29/02/2000 01/01/2000. 30/01/2000. 31/12/00 Para medir a cobertura de cobertura usando essa técnica. a entrada. 31/3/2000. 31/08/2000 01/09/2000. 30/04/00 32/05/2000. 30/02/2000. 30/04/2000 01/05/2000. 30/06/00 32/07/2000. o primeiro estado do componente. Esses valores são mostrados abaixo: Classe de Equivalência Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro Conjunto de Casos de Teste de Valores de Borda Entradas Válidas Entradas Inválidas 01/01/2000. 31/5/2000. a ação esperada causada pela transição e o próximo estado esperado. usa-se a seguinte fórmula: Cobertura Valor de Borda = Número de Valores de Borda Executados * 100 % Total de Valores de Borda 3) Transição de Estados (State Transition) Essa técnica de caixa preta é baseada sobre a análise da especificação de um componente para modelar o comportamento dele em transições de estados. 30/06/2000 01/07/2000. 30/01/2000. 31/10/2000 01/11/2000. 31/10/00 31/11/2000. Os casos de teste devem ser elaborados para exercitar todas as transições de estados do componente. as entradas de data que deve ter o formato: DD/MM/AAAA.Fevereiro com vinte e oito ou vinte e nove dias dependendo se é um ano bissexto ou não. 31/8/2000. 31/01/00 29/02/2001. 29/11/2000. 31/01/2000 01/04/2000. 28/02/2000. 31/03/00 31/04/2000. 30/11/00 32/12/2000. 30/6/2000. 31/1/2000. o evento que causa a transição para o próximo estado. as saídas esperadas. 30/4/2000. 30/12/2000. 30/09/00 32/10/2000. 30/1/2000. 31/05/00 31/06/2000. eventos. 31/2/2000. as transições entre esses estados. Eles são causados pelas ações que causam saídas nos mesmos. 30/10/2000. 31/02/2000 32/03/2000. 31/0/2000. 29/06/2000. 31/12/2000 32/01/2000. Nele deve ser especificado. Os eventos causam transições entre estados e transições podem retornar para o estado original onde eles começaram. 31/7/2000. 31/05/2000 01/06/2000. Ela usa um modelo de estados que o componente deve ocupar. entradas e saídas de um componente e todos eles serem identificáveis. 31/01/2000 01/02/2000. transições de estados. Então podemos levantar os valores de borda para testar se um sistema está validando ou não. 30/05/2000. 31/07/2000 01/08/2000. 30/09/2000 01/10/2000. 30/07/2000. O modelo é tipicamente representado por estados. 29/04/2000. Graficamente. 31/07/00 32/08/2000. 31/08/00 31/09/2000. 30/11/2000 01/12/2000. 30/08/2000. 29/09/2000.

onde cada regra corresponde a uma possibilidade única de entrada para o componente que tem sido expresso como booleano. reservados ou disponíveis. . Cada causa é expressa como uma condição. Elaborar casos de teste para esse sistema não é uma tarefa muito fácil para os analistas. que pode ser verdadeira ou falsa (condição Booleana) de entrada ou uma combinação de entradas para o componente. Cada efeito é expresso como sendo uma expressão Booleana representando uma saída. se a pessoa ocupar a poltrona e não confirmar a sua escolha volta de reservado para disponível. usa-se o percentual de todos os valores válidos que foram exercitados durante o teste. pois eles devem cobrir todos os estados que a poltrona pode assumir e as todas as condições em que elas ocorrem. NOR e NOT. ou uma combinação de saídas para o componente ocorrido. NAND. Os lugares podem estar ocupados.Como exemplo de uso dessa técnica pode citar o sistema de uma companhia aérea que mostra todos os lugares de um vôo. volta para disponível ou. o sistema dispara um evento para atualizar aquele assento que estava disponível para ocupado ou reservado. ainda. Para medir a cobertura de cobertura usando essa técnica. Logo após isso. Os casos de teste devem ser projetados para exercitar as regras. que definem a relação entre as entradas e saídas dos componentes. 4) Gráfico de Causa e Efeito (Cause & Effect Graphing) Gráfico de causa e efeito usa um modelo de relações lógicas entre causas e efeitos para um componente. é produzida uma tabela de decisão representando as relações lógicas entre causas e efeitos. O modelo é tipicamente representado como gráfico Booleano relacionando as entradas e saídas Booleanas. São estados que esse componente pode assumir. Desse gráfico. usando os operadores Booleanos: AND. O caso de teste deve identificar o estado booleano de cada causa e o estado para cada efeito. A entrada é a escolha de uma poltrona por um cliente ou uma reserva. O sistema pode fazer mais algumas validações (eventos) do tipo. se um assento ficar por mais de um tempo reservado. OR.

inserção de caracteres especiais. Outro aspecto que vale mencionar é que na maioria das especificações de requisitos. saldo atual e montante de débito. inserção de valores negativos em campos de valores numéricos e inteiros. usa-se a seguinte fórmula: Cobertura Causa-Efeito = Número de Regras Exercitadas * 100 % Total de Regras 5) Técnica de Sintaxe (Syntax Testing) Essa técnica de caixa preta é baseada sobre a análise da especificação de requisitos. valores numéricos em campos que remetem a uma quantidade de dias de férias que um funcionário tem a receber. a Sintaxe Inválida.Como exemplo dessa técnica pode citar os casos de teste para validar as operações bancárias feitas por um correntista. Ë nessa técnica onde são encontrados os principais problemas de tratamentos de exceções. nesse documento. limite máximo. livros em um andar de uma biblioteca. as entradas inesperadas. como inserção de valores alfa em campos numéricos. Na primeira. Os casos de teste que podem ser levantados para validar essa aplicação são inúmeros e. saldo de uma conta. No entanto. As entradas (causas) para esse projeto de teste seria o tipo de conta. inserção de valores float em campos numéricos e inteiros. Todas essas entradas visam validar qual será o tratamento dado pela aplicação quando esses valores forem usados. Para medir a cobertura de cobertura usando essa técnica. somente os valores esperados são utilizados. etc. usa-se a seguinte fórmula: Cobertura Teste Sintaxe = Número de Testes Sintaxe Exec * 100 % Total de Casos de Teste ! . já que ela se divide em “Sintaxe Válida” e “Sintaxe Inválida”. O arquiteto de teste aliado a um desenvolvedor que tenha mais proximidade consegue levantar essa informação. na maioria das vezes. Nesse documento são especificados os valores possíveis que uma entrada do sistema pode receber. o objetivo é exercitar as entradas inválidas. valores alfa em campos de nomes. Nesse caso. seria interessante descobrir quais os tipos de valores que os campos podem receber dando uma olhada no banco de dados dessa aplicação. Já na segunda técnica. depende das operações booleanas para saber se será possível ou não realizar a transação. É nesse contexto que se insere a técnica de “Técnica de Sintaxe”. inserção de valores numéricos em campos de valores alfa. Para medir a cobertura de cobertura usando essa técnica. não são tratadas. o resultado deles. nem os valores aceitáveis são especificados. como por exemplo. o levantamento dessas informações é essencial para a aplicação dessa técnica. Os efeitos são flag para saber se a operação foi realizada ou não e o saldo atual da correntista. Ë desejável que mensagens de erro e de ajuda sejam colocadas na tela no sentido de guiar o usuário a usar os valores corretos. inserção de vírgulas e pontos em campos de valores numéricos. endereço. Ela consiste em ter como entradas esperadas e as não esperadas para validar a especificação de requisitos e avaliar o comportamento de um sistema quando esses valores não especificados são usados. Nesse caso. sobrenomes.

22 e 25 que são os 20% principais e que mais cobrem funcionalidades. Um dos exemplos clássicos para exemplificar essa técnica é o “Diagrama de Pareto”.2. No contexto de teste de software.22.24.17. simplesmente.18. Seguindo o principio de Pareto.13 2. em uma escolha dos casos de teste que foram previamente elaborados.23. O princípio se baseia em uma análise quantitativa. se testarmos.7.9. usa-se a seguinte fórmula: Cobertura Teste Randômico = Número de Testes Exec Randomic * 100 % Total de Casos de Teste " . Depois de feita essa relação. 27. sim.29.6) Teste Randômico (Random Testing) Essa técnica consiste em utilizar um algoritmo pseudo-randômico para se escolher quais os casos de testes serão usados para validar uma funcionalidade de uma determinada aplicação dentro um conjunto definido de valores.20.30 Para medir a cobertura de cobertura usando essa técnica. Um exemplo que ilustra essa técnica é mostrado abaixo. é necessário ter uma relação de requisitos do sistema x testes criados.19.5.6.7. Normalmente. Sistema de uma Biblioteca Funcionalidades Básicas Inclusão de Dados de Usuário Edição de Dados de Usuário Deleção de Dados de Usuário Reserva de Livros Adição de Livros Remoção de Livros Casos de Testes criados 1.8.12 15.26 25.28. se aplica essa técnica quando o tempo de teste foi reduzido em virtude de eventualidades que aconteceram no projeto.10.25.21. ou seja.3.22 18. O objetivo aqui não é fazer testes AdHoc (testes sem resultados previamente esperados e sem um propósito) e. 2.16.14 2. os casos de teste. se baseia em escolher 20% de todos os casos de testes criados. escolher os casos de testes que mais aparecem nessa relação. 80% de todos os problemas são oriundos de 20% das causas potenciais. Para ter esse conjunto de casos de teste.5. temos um total de 30 casos de testes criados hipoteticamente ligados aos requisitos básicos de um sistema de uma biblioteca.3. cobrindo 80% das funcionalidades de todo o projeto.7. Segundo a tabela abaixo.11. estaremos cobrindo 80% das funcionalidades totais da aplicação.3.4.18.