Aula 06 - Testes de Software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
*
*
Unidade 2 – Parte III
Técnicas de 
Teste de Software
Caixa Preta
*
*
*
2.3 Teste de Caixa Preta (ou Comportamental)
 Foco: requisitos funcionais do software
Possibilita a derivação de conjuntos de condições de entrada que exercitem todos os requisitos funcionais para um programa.
O Teste de Caixa Preta desconsidera a estrutura de controle; a atenção é voltada ao domínio da informação.
O Teste de Caixa Preta não é uma alternativa às técnicas Caixa Branca, mas ao contrário, é uma abordagem complementar, que mais provavelmente descobrirá uma classe diferente de erros.
*
*
*
2.3. Teste de Caixa Preta
Abordagem complementar que tem a probabilidade de descobrir uma classe de erros diferente daquela dos métodos de caixa branca, por exemplo: 
Funções incorretas ou ausentes;
Erros de interface;
Erros nas estruturas de dados ou no acesso a bancos de dados;
Erros de desempenho;
Erros de inicialização e término.
*
*
*
2.3 Teste de Caixa Preta
Testes projetados para responder às seguintes perguntas:
	- Como a validade funcional é testada?
	- Quais classes de entrada constituirão bons casos de teste?
	- O sistema é particularmente sensível a certos valores de entrada?
	- Como as fronteiras de uma classe de dados são isoladas?
	- Quais índices de dados e volumes de dados o sistema pode tolerar?
	- Que efeito terão combinações específicas de dados sobre a operação do sistema?
*
*
*
2.3 Teste de Caixa Preta
Aplicando-se técnicas de caixa preta, derivamos um conjunto de casos de teste que satisfaz aos seguintes critérios básicos:
Redução do número de casos de teste adicionais que devem ser projetados para se conseguir testes razoáveis;
Casos de teste que relatam algo sobre a presença ou ausência de classes de erros, em vez de um erro associado a um teste específico.
*
*
*
2.3.1 Particionamento de Equivalência
Método de teste de caixa preta que divide o domínio 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.
*
*
*
2.3.1 Particionamento de Equivalência
O particionamento de equivalência procura definir um caso de teste que descubra classes de erros, reduzindo o número 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 equivalência baseia-se numa avaliação de classes de equivalência (conjunto de estados válidos ou inválidos) para uma condição de entrada (valor numérico, intervalo de valores, conjunto de valores relacionados ou uma condição booleana).
*
*
*
2.3.1 Particionamento de Equivalência
As classes de equivalência podem ser definidas, conforme as seguintes diretrizes:
	1. Se uma condição de entrada especificar um intervalo, uma classe de equivalência válida e duas classes de equivalência inválidas são definidas.
	2. Se uma condição de entrada exigir um valor específico, uma classe de equivalência válida e duas inválidas são definidas.
*
*
*
2.3.1 Particionamento de Equivalência
	3. Se uma condição de entrada especificar um membro de um conjunto, uma classe de equivalência válida e uma inválida são definidas.
	4. Se uma condição de entrada for booleana, uma classe de equivalência válida e uma inválida são definidas.
*
*
*
2.3.1 Particionamento de Equivalência
Exemplo: 
Dados mantidos como parte de uma aplicação bancária automatizada. O usuário pode acessar o banco via Web, fornecer senha de 6 dígitos e seguir uma série de comandos-chave que acionam funções bancárias. O software fornecido à aplicação bancária aceita dados da seguinte forma:
*
*
*
2.3.1 Particionamento de Equivalência
- Código de área: em branco ou número de 3 dígitos;
- Prefixo: número de 3 dígitos (não iniciados por 0 ou 1);
- Sufixo: número de 4 dígitos;
- Senha: alfanumérico de 6 dígitos;
- Comandos: “cheque”, “depósito”, “pagamento’, etc.
*
*
*
2.3.1 Particionamento de Equivalência
Condições de entrada podem ser especificadas como:
	- Código de área: booleana  cód área pode ou não estar presente;
		 	 intervalo  valores definidos entre 200 e 999. 	
	- Prefixo: intervalo  valor especificado > 200;
		 	
	- Sufixo: valor  extensão de 4 dígitos.
	- Senha: booleana  uma senha pode ou não estar presente.
		 valor  string de 6 caracteres.
	- Comando: conjunto  contendo os comandos: “cheque”,
 “depósito”, “pagamento”, transferência, etc
*
*
*
2.3.1 Particionamento de Equivalência
	Aplicando-se as diretrizes para derivação de classes de equivalência, os casos de teste para cada item de dados do domínio de entrada poderiam ser desenvolvidos e executados.
*
*
*
2.3.2 Análise de Valor Limite
 Percebe-se que um número maior de erros tende a ocorrer nas fronteiras do domínio de entrada do que no “centro”. Por isso desenvolveu-se a Análise de valor de limite (Boundary Value Analysis – BVA) como técnica de teste.
 A análise de valor de limite 	leva à escolha de casos de teste que põem à prova os valores fronteiriços.
 É uma técnica de projeto de casos de teste que complementa o particionamento de equivalência: em vez de selecionar qualquer elemento de uma classe de equivalência, a BVA leva à seleção de casos de teste nas “extremidades”da classe.
*
*
*
2.3.2 Análise de Valor Limite - Diretrizes
	BVA concentra-se nas condições de entrada e saída para derivar casos de teste.
 Se uma condição 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. 
 Se uma condição de entrada especificar uma série de valores, devem ser desenvolvidos casos de teste que ponham à prova números máximos e mínimos. Além dos valores logo acima e abaixo do máximo e mínimo. 
*
*
*
3. Aplique 1 e 2 às condição de saída. Ex. Exige-se uma tabela de temperatura X pressão como saída de um programa de engenharia. Os casos de teste devem ser projetados para criar um relatório de saída que produza um número máximo (e mínimo) permissível 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.
2.3.2 Análise de Valor Limite - Diretrizes
*
*
*
2.3.3 Teste de Comparação (back-to-back)
	Em alguma situações a confiabilidade do software é absolutamente crítica. Em tais aplicações, muitas vezes são usados hardware e software redundantes para minimizar a possibilidade de erros.
	Quando um software redundante é desenvolvido, equipes distintas produzem versões independentes de uma mesma aplicação usando a mesma especificação mesmo quando uma única versão for usada no sistema computadorizado entregue.
	Em tais situações, cada versão pode ser testada com a mesma massa de teste para garantir que todas ofereçam saídas idênticas.
*
*
*
2.3.3 Teste de Comparação (back-to-back)
	Usando a experiência com sistemas redundantes, alguns pesquisadores têm sugerido que versões independentes de software sejam desenvolvidas para aplicações críticas( ex. Controle de usinas nucleares, controle de tráfego aéreo, etc.), mesmo quando uma única versão for usada no sistema computadorizado entregue.
	Essas versões independentes formam a base de uma técnica de teste de caixa preta: teste de comparação ou teste back-to-back.
*
*
*
2.3.3 Teste de Comparação (back-to-back)
	Quando múltiplas implementações da mesma especificação são produzidas, os casos de teste projetados por meio de outras técnicas de caixa preta (ex. Particionamento de equivalência) são oferecidos como entrada a cada versão do software. 
		
Se a saída de cada versão for a mesma  todas as implementações
corretas.
Se a saída for diferente  cada uma das aplicações é investigada para determinar se um defeito numa das versões ou mais é responsável pela diferença.
*
*
*
2.3.3 Teste de Comparação (back-to-back)
	Este teste não é infalível. Se a especificação a partir da qual todas as versões foram desenvolvidas estiver errada, provavelmente todas as versões refletirão este erro. Outro fator importante é que se cada uma das versões independentes produzir resultados idênticos, mas incorretos, os testes de condição deixarão de detectar o erro.