O particionamento de equivalência divide os dados de entrada em classes dentro das quais o sistema deve se comportar da mesma maneira. Em vez de verificar dezenas de valores semelhantes, QA seleciona um ou dois representantes de cada classe significativa.
A ideia básica
Se o sistema lidar com um intervalo inteiro de forma idêntica, testar cada valor acrescenta pouco. Em vez disso, identifique as classes: formatos válidos, inválidos, vazios, grandes, proibidos e assim por diante.
Um exemplo simples
Suponha que um campo Idade aceite valores de 18 a 60 inclusive. Existem pelo menos três classes: abaixo de 18, 18–60 e acima de 60. Escolha um valor representativo de cada classe em vez de tentar todos os números.
Aplicando na prática
- →Primeiro, entenda as regras de validação e o significado de negócio do campo ou parâmetro.
- →Identifique classes com comportamento esperado diferente.
- →Selecione um valor de cada classe e considere os limites separadamente.
- →Verifique os valores válidos junto com entradas vazias, de tipo errado, proibidas e logicamente conflitantes.
Erros comuns
- →Definir classes mecanicamente sem entender a lógica de negócios.
- →Esquecer que as classes de equivalência não substituem a análise de valores-limite.
- →Assumir que os valores são equivalentes quando o sistema os trata de maneira diferente.
- →Usando apenas classes válidas e ignorando entradas negativas.
O particionamento de equivalência é particularmente útil para formulários, parâmetros API, filtros, intervalos, status e qualquer entrada em que testes exaustivos sejam impraticáveis ou inúteis. Seu ponto forte é reduzir o volume de testes e, ao mesmo tempo, manter a cobertura lógica.
Exemplo resolvido: elegibilidade de idade inteira
Regra de treinamento: um aplicativo aceita uma idade inteira de 18 a 65 inclusive. Trate os valores inteiros abaixo de 18, de 18 a 65 e acima de 65 como três partições disjuntas para esta regra. Escolha um representante de cada um antes de adicionar verificações de limites.
Partição Representante Esperado
Inteiro abaixo de 18 16 Rejeitar: fora da faixa etária elegível
Inteiro de 18 a 65 40 Aceitar
Inteiro acima de 65 70 Rejeitar: fora da faixa etária elegívelO modelo assume que os valores dentro de cada partição são processados de forma semelhante. Essa é uma hipótese de projeto de teste, e não uma prova de que um valor encontra todos os defeitos. Se a regra de negócio introduzir um resultado diferente para as idades 60–65, divida a partição válida adequadamente. Não combine resultados diferentes apenas porque todas as entradas têm o mesmo tipo de dados.
Mantenha os erros de representação separados
Defina também o contrato de transporte. Neste exercício, o campo JSON age deve estar presente e conter um número inteiro; strings, frações e null são inválidos. Os valores a seguir não são representantes adicionais das três partições de inteiros.
Payload Esperado
{} Rejeitar: campo obrigatório ausente
{"age": null} Rejeitar: inteiro obrigatório
{"age": "40"} Rejeitar: inteiro obrigatório
{"age": 40.5} Rejeitar: inteiro obrigatório
{"age": 40} AceitarExercício e resposta
25, 40 e 55 cobririam as três partições inteiras? Não: todos os três estão na partição válida. Um conjunto como 16, 40 e 70 cobre todos os três; em seguida, adicione 17, 18, 19, 64, 65 e 66 para investigar o comportamento específico do limite. Os resultados esperados vêm da regra declarada, enquanto os códigos de status e esquemas de erro HTTP exigem um contrato API separado.