Unidade 2 Parte III

Tcnicas de
Teste de Software

Caixa Preta

1
 2.3 Teste de Caixa Preta (ou
Comportamental)

Foco: requisitos funcionais do software

Possibilita a derivao de conjuntos de condies de entrada
que exercitem todos os requisitos funcionais para um programa.

O Teste de Caixa Preta desconsidera a estrutura de controle; a

ateno voltada ao domnio da informao.

O Teste de Caixa Preta no uma alternativa s tcnicas Caixa

Branca, mas ao contrrio, uma abordagem complementar, que
mais provavelmente descobrir uma classe diferente de erros.

2
 2.3. Teste de Caixa Preta

Abordagem complementar que tem a probabilidade de

descobrir uma classe de erros diferente daquela dos
mtodos de caixa branca, por exemplo:

1.Funes incorretas ou ausentes;

2.Erros de interface;
3.Erros nas estruturas de dados ou no acesso a bancos de dados;
4.Erros de desempenho;
5.Erros de inicializao e trmino.

3
 2.3 Teste de Caixa Preta

Testes projetados para responder s seguintes perguntas:

- Como a validade funcional testada?

- Quais classes de entrada constituiro bons casos de teste?

- O sistema particularmente sensvel a certos valores de entrada?

- Como as fronteiras de uma classe de dados so isoladas?

- Quais ndices de dados e volumes de dados o sistema pode tolerar?

- Que efeito tero combinaes especficas de dados sobre a operao

do sistema?
4
 2.3 Teste de Caixa Preta

Aplicando-se tcnicas de caixa preta, derivamos um

conjunto de casos de teste que satisfaz aos seguintes
critrios bsicos:

Reduo do nmero de casos de teste adicionais que

devem ser projetados para se conseguir testes
razoveis;

Casos de teste que relatam algo sobre a presena ou

ausncia de classes de erros, em vez de um erro
associado a um teste especfico.
5
 2.3.1 Particionamento de
Equivalncia
Mtodo de teste de caixa preta que divide o
domnio de entrada de um programa em classes de
dados a partir das quais os casos de testes podem
ser derivados.

Um caso de teste ideal descobre sozinho uma classe

de erros que, de outro modo, poderia exigir que
muitos casos fossem executados antes que o erro
geral fosse observado.

6
 2.3.1 Particionamento de
Equivalncia
O particionamento de equivalncia procura definir um caso
de teste que descubra classes de erros, reduzindo o nmero
total de casos de teste que devem ser desenvolvidos (ex.
Processamento incorreto de todos os dados do tipo
caracter).

O projeto de casos de teste para o particionamento de

equivalncia baseia-se numa avaliao de classes de
equivalncia (conjunto de estados vlidos ou invlidos) para
uma condio de entrada (valor numrico, intervalo de
valores, conjunto de valores relacionados ou uma condio
booleana).
7
 2.3.1 Particionamento de
Equivalncia
As classes de equivalncia podem ser definidas, conforme as
seguintes diretrizes:

1. Se uma condio de entrada especificar um intervalo,

uma classe de equivalncia vlida e duas classes de
equivalncia invlidas so definidas.

2. Se uma condio de entrada exigir um valor

especfico, uma classe de equivalncia vlida e duas invlidas
so definidas.

8
2.3.1 Particionamento de
Equivalncia
3. Se uma condio de entrada especificar um membro de
um conjunto, uma classe de equivalncia vlida e uma
invlida so definidas.

4. Se uma condio de entrada for booleana, uma classe de

equivalncia vlida e uma invlida so definidas.

9
 2.3.1 Particionamento de
Equivalncia
Exemplo:
Dados mantidos como parte de uma aplicao bancria
automatizada. O usurio pode acessar o banco via Web,
fornecer senha de 6 dgitos e seguir uma srie de comandos-
chave que acionam funes bancrias. O software fornecido
aplicao bancria aceita dados da seguinte forma:

10
 2.3.1 Particionamento de
Equivalncia
- Cdigo de rea: em branco ou nmero de 3 dgitos;
- Prefixo: nmero de 3 dgitos (no iniciados por 0 ou 1);
- Sufixo: nmero de 4 dgitos;
- Senha: alfanumrico de 6 dgitos;
- Comandos: cheque, depsito, pagamento, etc.

11
 2.3.1 Particionamento de
Equivalncia
Condies de entrada podem ser especificadas como:

- Cdigo de rea: booleana cd rea pode ou no estar presente;

intervalo valores definidos entre 200 e 999.

- Prefixo: intervalo valor especificado > 200;

- Sufixo: valor extenso de 4 dgitos.

- Senha: booleana uma senha pode ou no estar presente.

valor string de 6 caracteres.

- Comando: conjunto contendo os comandos: cheque,

depsito, pagamento, transferncia,
12 etc
 2.3.1 Particionamento de
Equivalncia
Aplicando-se as diretrizes para derivao de classes de
equivalncia, os casos de teste para cada item de dados
do domnio de entrada poderiam ser desenvolvidos e
executados.

13
 2.3.2 Anlise de Valor
Limite
Percebe-se que um nmero maior de erros tende a ocorrer
nas fronteiras do domnio de entrada do que no centro. Por
isso desenvolveu-se a Anlise de valor de limite (Boundary
Value Analysis BVA) como tcnica de teste.

A anlise de valor de limite leva escolha de casos de

teste que pem prova os valores fronteirios.

uma tcnica de projeto de casos de teste que

complementa o particionamento de equivalncia: em vez de
selecionar qualquer elemento de uma classe de equivalncia, a
BVA leva seleo de casos de teste nas extremidadesda
classe.
14
 2.3.2 Anlise de Valor Limite -
Diretrizes
BVA concentra-se nas condies de entrada
e sada para derivar casos de teste.

1. Se uma condio de entrada especificar um intervalo

delimitado por a, b, os casos de teste devem ser projetados com
valores a e b, logo acima e logo abaixo de a e b,
respectivamente.

2. Se uma condio de entrada especificar uma srie de

valores, devem ser desenvolvidos casos de teste que ponham
prova nmeros mximos e mnimos. Alm dos valores logo
acima e abaixo do mximo e mnimo.
15
 2.3.2 Anlise de Valor Limite -
Diretrizes

3. Aplique 1 e 2 s condio de sada. Ex. Exige-se uma tabela

de temperatura X presso como sada de um programa de
engenharia. Os casos de teste devem ser projetados para criar
um relatrio de sada que produza um nmero mximo (e
mnimo) permissvel de entradas na tabela.

4. Se estruturas internas de dados do programa tiverem

prescrito fronteiras (ex. Array com limite definido de 100
entradas), certifique-se de projetar um caso de teste para
exercitar a estrutura de dados em sua fronteira.

16
 2.3.3 Teste de Comparao (back-
to-back)
Em alguma situaes a confiabilidade do software
absolutamente crtica. Em tais aplicaes, muitas vezes so usados
hardware e software redundantes para minimizar a possibilidade
de erros.
Quando um software redundante desenvolvido, equipes
distintas produzem verses independentes de uma mesma
aplicao usando a mesma especificao mesmo quando uma
nica verso for usada no sistema computadorizado entregue.

Em tais situaes, cada verso pode ser testada com a

mesma massa de teste para garantir que todas ofeream sadas
idnticas.

17
 2.3.3 Teste de Comparao (back-
to-back)

Usando a experincia com sistemas redundantes, alguns

pesquisadores tm sugerido que verses independentes de software
sejam desenvolvidas para aplicaes crticas( ex. Controle de
usinas nucleares, controle de trfego areo, etc.), mesmo quando
uma nica verso for usada no sistema computadorizado entregue.

Essas verses independentes formam a base de uma tcnica

de teste de caixa preta: teste de comparao ou teste back-to-back.

18
 2.3.3 Teste de Comparao (back-
to-back)

Quando mltiplas implementaes da mesma especificao

so produzidas, os casos de teste projetados por meio de outras
tcnicas de caixa preta (ex. Particionamento de equivalncia) so
oferecidos como entrada a cada verso do software.

Se a sada de cada verso for a mesma todas as implementaes

corretas.

Se a sada for diferente cada uma das aplicaes investigada para

determinar se um defeito numa das verses ou mais responsvel pela
diferena.

19
 2.3.3 Teste de Comparao (back-
to-back)

Este teste no infalvel. Se a especificao a partir da

qual todas as verses foram desenvolvidas estiver errada,
provavelmente todas as verses refletiro este erro. Outro fator
importante que se cada uma das verses independentes produzir
resultados idnticos, mas incorretos, os testes de condio
deixaro de detectar o erro.

20