Questão de Engenharia de Software — Geral — Quadrix 2025

Classe de equivalência: técnica de caixa preta

Gabarito: CERTO. A classe de equivalência (ou particionamento de equivalência) é, de fato, uma técnica de teste de caixa preta, pois divide o domínio de entrada do programa em classes de dados a partir das quais são criados casos de teste, sem considerar a estrutura interna do código. Essa é uma distinção fundamental entre as técnicas de caixa preta e caixa branca.

Para entender por que a afirmação está correta, é preciso primeiro compreender o que diferencia as duas grandes famílias de técnicas de teste de software. O teste de caixa preta (também chamado de teste funcional) trata o software como uma "caixa fechada": o testador não conhece (ou não se preocupa com) a implementação interna, o código-fonte ou a lógica do programa. O foco está exclusivamente nos requisitos funcionais — ou seja, o que o sistema deve fazer, dado um conjunto de entradas, qual deve ser a saída. Já o teste de caixa branca (ou teste estrutural) exige que o testador conheça a estrutura interna do software, pois o objetivo é exercitar caminhos, condições, decisões e fluxos específicos do código.

A classe de equivalência é uma das técnicas mais clássicas de caixa preta. Seu princípio é simples e poderoso: em vez de testar todas as entradas possíveis (o que seria inviável na prática), o domínio de entrada é particionado em grupos (classes) de dados que, espera-se, sejam tratados de forma semelhante pelo programa. Se um caso de teste de uma classe revela um defeito, é provável que todos os outros valores da mesma classe também o façam; se passa, é provável que todos os demais da classe também passem. Assim, um único caso de teste por classe é suficiente para cobrir um conjunto grande de possibilidades.

Um exemplo concreto: suponha um sistema que aceita idades entre 18 e 65 anos. O domínio de entrada pode ser particionado em três classes de equivalência: (1) idades abaixo de 18 (inválidas), (2) idades entre 18 e 65 (válidas) e (3) idades acima de 65 (inválidas). Em vez de testar dezenas de valores, o testador escolhe um representante de cada classe — por exemplo, 15, 30 e 70 — e verifica se o sistema se comporta conforme o esperado para cada grupo. Essa é a essência da técnica.

É importante não confundir classe de equivalência com outras técnicas de caixa preta, como a análise de valor limite. Enquanto a classe de equivalência foca em particionar o domínio em grupos, a análise de valor limite se concentra nos valores nas fronteiras dessas classes (os limites), pois é onde os defeitos costumam se esconder. No exemplo acima, os valores limite seriam 17, 18, 65 e 66. Ambas são técnicas de caixa preta, mas com abordagens distintas. Outras técnicas de caixa preta incluem a tabela de decisão, a matriz ortogonal e os diagramas de transição de estado.

A pegadinha que a banca explora neste tema é justamente a inversão: apresentar uma técnica de caixa preta como se fosse de caixa branca, ou vice-versa. Questões anteriores da VUNESP, por exemplo, já cobraram exatamente essa distinção, perguntando qual técnica é de caixa preta e qual é de caixa branca. O particionamento de equivalência (sinônimo de classe de equivalência) é sempre classificado como caixa preta, enquanto técnicas como teste de condição, fluxo de dados e teste estrutural pertencem à caixa branca.

Guarde essa fronteira: se a técnica trabalha com o domínio de entrada, requisitos e comportamento externo, é caixa preta; se trabalha com a estrutura interna, caminhos e condições do código, é caixa branca. É exatamente nessa linha divisória que as alternativas se separam.

Item — ✅ CERTO

A afirmação "Classe de equivalência é uma técnica de caixa preta de teste de software" está correta. A classe de equivalência (ou particionamento de equivalência) é uma técnica de teste funcional, ou seja, de caixa preta, pois divide o domínio de entrada do programa em classes de dados a partir das quais são criados casos de teste, sem considerar a estrutura interna do código. O foco está nos requisitos funcionais e no comportamento externo do software, não na sua implementação.

Gabarito: CERTO