Um campo de idade que aceita de 18 a 60 anos possui um número enorme de entradas possíveis, uma vez que você conta negativos, números enormes, texto e espaços em branco. Ninguém pode experimentar todos eles. O particionamento de equivalência resolve isso agrupando entradas que o software deve tratar da mesma maneira e testando um valor de cada grupo.

É uma das primeiras técnicas de design de teste que todo testador deve aprender. Neste guia, trabalhamos passo a passo e testamos um exemplo em Python. Executamos esse código no Python 3.13 e sua saída está incluída. As regras de senha e cupom abaixo são exemplos ilustrativos, não retirados de um sistema real.

O que é particionamento de equivalência?

O particionamento de equivalência, também chamado de particionamento de classe de equivalência (ECP), é uma técnica de design de teste de caixa preta. Ele divide as entradas possíveis de um recurso em partições, ou classes. Espera-se que cada valor dentro de uma partição produza o mesmo tipo de comportamento.

Como não é necessário ver o código, você pode aplicá-lo diretamente de um requisito. Para saber mais sobre esse estilo de teste, leia teste de caixa preta versus caixa branca.

Por que funciona

A técnica baseia-se em uma suposição: se um valor em uma partição encontrar um bug, os outros naquela partição provavelmente também o encontrarão. E se um valor for aprovado, os outros provavelmente também serão aprovados. Testar 25, 26 e 27 em um campo de idade adulta provavelmente não dirá nada que o teste 25 sozinho não diga.

É uma suposição, porém, e não uma garantia. O software pode ter casos especiais ocultos dentro de uma partição, uma limitação à qual voltaremos mais tarde.

Como fazer isso em cinco etapas

1. Leia o requisito e identifique a entrada e suas regras.
2. Encontre as partições válidas, que são os grupos de valores que devem ser aceitos e observe se intervalos diferentes se comportam de maneira diferente.
3. Encontre as partições inválidas, incluindo valores muito baixos, muito altos, do tipo errado e em branco.
4. Escolha um valor representativo de cada partição, geralmente em algum lugar no meio.
5. Anote o resultado esperado para cada um, como em qualquer bom caso de teste.

Exemplo resolvido: um campo de idade

Requisito: Podem se cadastrar usuários de 18 a 60 anos.

Cinco testes fornecem cobertura de todos os comportamentos do requisito. Muitos tutoriais param nas três primeiras linhas, mas as duas últimas são aquelas que usuários reais acionam por acidente. Você também pode adicionar linhas para números negativos ou decimais, se eles puderem ser tratados de maneira diferente.

Testando em código

Aqui está essa regra como uma função, com um teste de unidade por partição, usando o recurso interno do Python unittest:

import unittest

def can_register(age):
    if not isinstance(age, int) or isinstance(age, bool):
        raise TypeError("age must be a whole number")
    return 18 <= age <= 60

class EquivalenceTests(unittest.TestCase):
    def test_valid_partition(self):
        self.assertTrue(can_register(35))

    def test_too_young_partition(self):
        self.assertFalse(can_register(10))

    def test_too_old_partition(self):
        self.assertFalse(can_register(75))

    def test_wrong_type_partition(self):
        with self.assertRaises(TypeError):
            can_register("abc")

Nossa corrida passou:

test_too_old_partition ... ok
test_too_young_partition ... ok
test_valid_partition ... ok
test_wrong_type_partition ... ok

Em um projeto real, o recurso de parametrização do pytest é uma maneira interessante de executar uma tabela de valores de partição por meio de um único teste.

Exemplo resolvido: uma senha

Requisito: Uma senha deve ter de 8 a 20 caracteres e conter pelo menos um dígito.

Este tem duas regras, comprimento e conteúdo, por isso consideramos partições para ambos:

Observe que cada teste inválido quebra apenas uma regra. Se um valor fosse muito curto e faltasse um dígito, um teste aprovado não poderia dizer qual verificação funcionou. Uma verificação pode ser quebrada, enquanto a outra esconde o fato.

Exemplo resolvido: entradas não numéricas

A técnica não se limita a intervalos numéricos. Opções, categorias e estados discretos também formam partições. Suponha que uma loja tenha esta regra:

Requisito: A entrega é gratuita para membros Gold, 50 para Silver e 100 para todos os demais. Valores de camada desconhecidos são erros.

Aqui, cada opção é sua própria partição, pois cada uma deve se comportar de maneira diferente. Outras partições comuns incluem tipos de arquivos, como uploads válidos e inválidos, e grupos baseados em resultados, como um empréstimo sendo aprovado ou recusado.

Várias entradas ao mesmo tempo

Com vários campos, o número de combinações cresce rapidamente. Três campos com quatro partições cada fornecem 64 combinações. Duas estratégias ajudam:

• Cobertura fraca: certifique-se de que cada partição apareça em pelo menos um teste, combinando vários valores válidos por teste. Para valores inválidos, teste um de cada vez para que os erros não se mascarem.
• Cobertura baseada em regras: quando as combinações realmente alteram o resultado, como o status do membro com o valor do pedido, use o teste da tabela de decisão para listá-las corretamente.

Emparelhamento com análise de valor limite

O particionamento informa quais grupos testar. Diz pouco sobre onde em um grupo os bugs gostam de se esconder, e muitos se escondem bem nas bordas. Para mostrar isso, escrevemos uma versão com bugs com o clássico erro off-by-one:

def buggy(age):
    return 18 < age <= 60     # should be 18 <= age

[buggy(a) for a in (35, 10, 75)]   # [True, False, False]
buggy(18)                          # False

Nossos valores de partição, 35, 10 e 75, deram as respostas corretas, então esses testes seriam aprovados. No entanto, um jovem de 18 anos é rejeitado injustamente. É por isso que as duas técnicas estão juntas:

Use o particionamento para encontrar os grupos e, em seguida, os limites para testar onde os grupos se encontram. Em nosso código, um teste separado para 17, 18, 60 e 61 passou na função correta e detectaria esse bug. Nosso guia de análise de valor limite cobre isso na íntegra.

Vantagens e limitações

O maior risco é uma suposição incorreta. Se o código tiver uma regra oculta para um valor específico, o teste escolhido pode simplesmente não alcançá-la. Testes exploratórios e cobertura de código ajudam você a encontrar o que as partições perderam.

Erros comuns

• Esquecimento de partições inválidas. Testar apenas caminhos felizes deixa o tratamento de erros desmarcado.
• Testando vários valores de uma partição. Isso adiciona custos sem novas informações.
• Combinar vários valores inválidos em um teste. Um erro pode ocultar outro.
• Ignorando limites. Os testes de partição por si só muitas vezes deixam passar bugs isolados.
• Adivinhar as regras. Se um requisito não estiver claro, pergunte. 60 deveriam incluir pessoas com 60 anos e meio?

Considerações finais

O particionamento de equivalência substitui “quantos testes devo escrever?” com uma pergunta muito melhor: “quais comportamentos existem e eu abordei cada um deles?” Para experimentar, pegue o formulário que você está testando hoje e liste suas partições no papel, inclusive as inválidas. Adicione limites a seguir. Freqüentemente, você acabará com menos testes que encontrarão mais bugs.

Perguntas frequentes

Continue aprendendo