Introdução

Exceto para os aplicativos de software mais comuns, geralmente considera-se impossível testar todas as combinações de entrada logicamente praticáveis para um sistema de software. Portanto, a seleção de um bom subconjunto que tenha a maior probabilidade de localizar o maior número de erros é uma tarefa importante e à qual vale a pena os testadores se dedicarem.

O teste com base na análise de classe de equivalência (sinônimos: particionamento de equivalência, análise de domínio) é uma forma de análise de teste de caixa preta que tenta reduzir o número total de testes possíveis para um conjunto mínimo de testes que revelarão o número máximo de erros possível [MYE79]. Isso consiste em um método que particiona o conjunto de entradas e saídas em um número finito de classes de equivalência que permitem a seleção de um valor de teste representativo para cada classe. O teste que resulta do valor representativo para uma classe é chamado de "equivalente" aos outros valores na mesma classe. Se nenhum erro foi localizado no teste do valor representativo, conclui-se que todos os outros valores "equivalentes" também não identificariam quaisquer erros.

O poder das Classes de Equivalência está em sua capacidade de orientar o testador utilizando uma estratégia de amostragem para reduzir a explosão combinatória de testes possivelmente necessários. A técnica fornece uma base lógica por meio da qual pode-se selecionar um subconjunto do número total concebível de testes. Aqui estão algumas categorias de áreas de problemas para um grande número de testes que podem beneficiar-se da consideração de classes de equivalência:

1. Combinações de variáveis independentes
2. Variáveis dependentes baseadas no relacionamento hierárquico
3. Variáveis dependentes baseadas no relacionamento temporal
4. Relacionamentos em cluster com base em exemplos de mercado
5. Relacionamentos complexos que podem ser modelados

Estratégias

Há diferentes estratégias e técnicas que podem ser utilizadas no teste de partição de equivalência. A seguir são apresentados alguns exemplos:

Partição de Classe de Equivalência

Teoria de partição de equivalência proposta por Glenford Myers [MYE79]. Tenta reduzir o número total de casos de teste necessários, particionando as condições de entrada em um número finito de classes de equivalência. As classes de equivalência são classificadas em dois tipos: o conjunto de entradas válidas para o programa é considerado como a classe de equivalência válida e todas as outras entradas são incluídas na classe de equivalência inválida.

Aqui está um conjunto de diretrizes para identificar as classes de equivalência:

1. Se uma condição de entrada especificar um intervalo de valores (por exemplo, o programa "aceita valores de 10 a 100"), uma classe de equivalência válida (de 10 a 100) e duas classes de equivalência inválidas serão identificadas (menor que 10 e maior que 100).
2. Se uma condição de entrada especificar um conjunto de valores (por exemplo, "o tecido pode ter várias cores: VERMELHO, BRANCO, PRETO, VERDE, MARROM"), uma classe de equivalência válida (os valores válidos) e uma classe de equivalência inválida (todos os outros valores inválidos) serão identificadas. Cada valor da classe de equivalência válida deverá ser manipulado distintamente.
3. Se a condição de entrada for especificada como uma situação "deve ser" (por exemplo, "a cadeia de entrada deve ser em letras maiúsculas"), uma classe de equivalência válida (caracteres maiúsculos) e uma classe de equivalência inválida (todas as outras entradas, exceto caracteres maiúsculos) serão identificadas.
4. Tudo concluído "por longo tempo" antes da tarefa estar pronta é uma classe de equivalência. Tudo pronto dentro de um intervalo curto de tempo antes do programa ser concluído é uma outra classe. Tudo pronto exatamente antes do programa iniciar uma outra operação é uma outra classe.
5. Se um programa for especificado para trabalhar com tamanho de memória de 64 M a 256 M. Então este tamanho é uma classe de equivalência. Qualquer outro tamanho de memória, que seja maior que 256 M ou menor que 64 M, pode ser aceito.
6. A partição do evento de saída fica nas entradas do programa. Mesmo que classes diferentes de equivalência de entrada pudessem ter o mesmo tipo de evento de saída, ainda assim você trataria as classes de entrada distintamente.

Análise de Valor de Limite

Em cada classe de equivalência, as condições de limite são consideradas como tendo uma taxa maior de sucesso ao identificar defeitos resultantes do que as condições sem limite. As condições de limite são os valores de acordo com, imediatamente acima de ou abaixo de, o limite ou "bordas" de cada classe de equivalência.

Os testes que resultam das condições de limite utilizam valores no mínimo (mín), logo acima do mínimo (mín+), logo abaixo do máximo (máx-) e no máximo (máx) do intervalo precisa ser testado. Ao testarem valores de limite, os testadores escolhem alguns casos de teste para cada classe de equivalência. Para a amostra relativamente pequena de testes, a probabilidade de descoberta de defeito é alta. Isso livra o Testador da sobrecarga de testar um grande número de casos em uma classe equivalente de valores que são improváveis de produzir grandes diferenças nos resultados do teste.

Algumas recomendações ao escolher os valores de limite:

1. Para uma variável flutuante, se a condição válida for de -1.0 a 1.0, teste -1.0, 1.0, -1.001 e 1.001.
2. Para um inteiro, se o intervalo válido de entrada for de 10 a 100, teste 9, 10, 100, 101.
3. Se um programa esperar uma letra maiúscula, teste o limite A e Z. Teste também @ e [, porque no código ASCII, @ está apenas abaixo de A e [ está apenas acima de Z.
4. Se a entrada ou saída de um programa for um conjunto ordenado, preste atenção ao primeiro e ao último elemento do conjunto.
5. Se a soma das entradas precisar ser um número específico (n), teste o programa em que a soma seja n-1, n ou n+1.
6. Se o programa aceitar uma lista, teste os valores na lista. Todos os outros valores são inválidos.
7. Ao ler ou gravar em um arquivo, verifique o primeiro e último caracteres no arquivo.
8. A menor denominação de valor monetário é um centavo ou equivalente. Se o programa aceitar um intervalo específico, de a até b, teste um -0,01 e b +0,01.
9. Para uma variável com vários intervalos, cada intervalo é uma classe de equivalência. Se os subintervalos não estiverem sobrepostos, teste os valores nos limites, acima do limite superior e abaixo do limite inferior.

Valores Especiais

Depois de tentar as duas estratégias de análise de limite anteriores, um testador experiente observará as entradas do programa para descobrir quaisquer casos de "valores especiais", que, mais uma vez, são origens muito valiosas para revelar defeitos de software. A seguir são apresentados alguns exemplos:

1. Para um tipo inteiro, zero sempre deverá ser testado se estiver na classe de equivalência válida.
2. Ao testar a hora (hora, minuto e segundo), 59 e 0 sempre deverão ser testados como os limites superior e inferior de cada campo, não importa a restrição da variável de entrada. Portanto, exceto os valores de limite da entrada, -1, 0, 59 e 60 sempre deverão ser casos de teste.
3. Ao testar a data (ano, mês e dia), vários casos de teste deverão estar envolvidos, como o número de dias em um mês específico, o número de dias em fevereiro no ano bissexto, o número de dias no ano não-bissexto.

Método de "Partição por Categoria"

Ostrand e Balcer [16] desenvolveram um método de partição que ajuda os testadores a analisar a especificação do sistema, gravar scripts de teste e gerenciá-los. Diferente das estratégias comuns que geralmente têm como foco o código, seu método também baseia-se na especificação e nas informações de design.

A principal vantagem desse método é sua capacidade de expor os erros antes do código ter sido gravado porque a origem de entrada é a especificação e os testes resultam da análise dessa especificação. As falhas nas especificações serão descobertas antecipadamente, geralmente bem antes de serem implementadas no código.

A estratégia para o método de "partição por categoria" é a seguinte:

1. Analise a especificação: decomponha a funcionalidade do sistema em unidades funcionais, que podem ser testadas independentemente por especificação e implementação.
   A partir desse ponto:
   
   
   1. Identifique os parâmetros e as condições do ambiente que influenciarão a execução da função. Os parâmetros são as entradas da unidade funcional. As condições do ambiente são os estados do sistema, que afetarão a execução da unidade funcional.
   2. Identifique as características dos parâmetros e as condições do ambiente.
   3. Classifique as características em categorias, que afetam o comportamento do sistema.
      
      
   Descrições ambíguas, contraditórias e ausentes do comportamento serão descobertas neste estágio.
   
   
2. Particione as categorias em opções: as opções são as diferentes situações possíveis que podem ocorrer e não são esperadas. Elas representam o mesmo tipo de informação em uma categoria.
   
   
3. Determine as relações e as restrições entre as opções. As opções em diferentes categorias influenciam umas às outras, que também influenciam a construção do conjunto de testes. As restrições são incluídas para eliminar a contradição entre as opções de diferentes parâmetros e ambientes.
   
   
4. Projete os casos de teste de acordo com as categorias, opções e informações de restrição. Se uma opção causar um erro, não combine-a com outras opções para criar o caso de teste. Se uma opção puder ser testada "adequadamente" em um único teste, ela será representante da opção ou um valor especial.

Leitura e Referências Adicionais

1. Glenford J. Myers, The Art of Software Testing, John Wiley & Sons, Inc., New York, 1979.
2. White L. J. e Cohen E. I., A domain strategy for computer program testing, IEEE Transaction on Software Engineering, Vol. SE-6, No. 3, 1980.
3. Lori A. Clarke, Johnhette Hassell e Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on Software Engineering, 8-4, 1992.
4. Steven J. Zeil, Faten H. Afifi e Lee J. White, Detection of Linear Detection via Domain Testing, ACM Transaction on Software Engineering and Methodology, 1-4, 1992.
5. BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering and Methodology, 3-3, 1994.
6. Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
7. Martin R. Woodward e Zuhoor A. Al-khanjari, Testability, fault, and the domain-to-range ratio: An eternal triangle, ACM Press New York, NY, 2000.
8. Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software Engineering, 71-16, 2000.
9. Cem Kaner, James Bach e Bret Pettichord, Lessons learned in Software Testing, John Wiley & Sons, Inc., New York, 2002.
10. Andy Podgurski e Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special Interest Group on Software Engineering, 18-5, 1993.
11. Debra J. Richardson e Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM Special Interest Group on Software Engineering, 1981.
12. Lori A. Clarke, Johnette Hassell e Debra J Richardson, A system to generate test data and symbolically execute programs, IEEE Transaction on Software Engineering, SE-2, 1976.
13. Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley & Sons, Inc., 1995.
14. Steven J. Zeil, Faten H. Afifi e Lee J. White, Testing for Liner Errors in Nonlinear computer programs, ACM Transaction on Software Engineering and Methodology, 1-4, 1992.
15. William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
16. Thomas J. Ostrand and Marc J. Balcer, The Category-Partition method for specifying and generating functional tests, Communications of ACM 31, 1988.
17. Cem Kaner, Jack Falk e Hung Quoc Nguyen, Testing Computer Software, John Wiley & Sons, Inc., 1999.