Questão de Engenharia de Software — Conceitos e Tipos de Testes de Software — FUNDATEC 2023

Técnicas de Teste de Software: Caixa-Preta e Caixa-Branca

Gabarito: letra A. As técnicas de Tabela de Decisão, Particionamento de Equivalência e Análise do Valor Limite são, de fato, técnicas clássicas de teste funcional (caixa-preta), usadas para criar casos de teste a partir da especificação do software, sem olhar o código interno. As demais alternativas misturam conceitos que não são técnicas de criação de testes, como Caso de Uso (um artefato de modelagem de requisitos), Builder (um padrão de projeto) e a inexistente "Técnica da Melhor Entrada".

As técnicas de teste são procedimentos sistemáticos para derivar casos de teste — ou seja, para escolher quais entradas, condições e resultados esperados serão usados para verificar o software. Elas se dividem em duas grandes famílias: as de caixa-preta (funcionais), que partem da especificação e não enxergam o código, e as de caixa-branca (estruturais), que analisam a lógica interna do programa. A questão cobra exatamente o reconhecimento das técnicas de caixa-preta mais tradicionais.

Particionamento de Equivalência divide o domínio de entrada em classes (partições) de dados que devem ser tratadas de forma equivalente pelo sistema; testar um representante de cada classe é suficiente. Análise do Valor Limite foca nos limites dessas partições, onde os erros são mais frequentes (ex.: se a regra aceita valores de 1 a 100, testar 0, 1, 100 e 101). Tabela de Decisão é uma técnica que mapeia combinações de condições (entradas) e ações (saídas) em uma matriz, garantindo a cobertura de todas as combinações relevantes de regras de negócio. Todas são técnicas de caixa-preta, pois derivam os casos de teste da especificação funcional.

Para fixar, veja a comparação entre as técnicas citadas nas alternativas:

A pegadinha da banca é misturar termos que soam plausíveis no contexto de teste ("melhor entrada", "caso de uso") com técnicas reais, para induzir o candidato a marcar uma alternativa com termos familiares, mas incorretos. O critério decisivo é: a técnica serve para derivar casos de teste a partir da especificação? Se sim, é uma técnica de teste; se é um artefato de modelagem, um padrão de projeto ou um nome inventado, não é.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa reúne exatamente as três técnicas clássicas de teste funcional (caixa-preta): Tabela de Decisão, Particionamento de Equivalência e Análise do Valor Limite. Todas são usadas para criar casos de teste a partir da especificação do software, sem depender do conhecimento do código interno. É a única alternativa em que todos os elementos são, de fato, técnicas de criação de testes.

Alternativa B — ❌ Incorreta

A alternativa contém duas técnicas válidas (Análise do Valor Limite e Caso de Uso), mas Caso de Uso não é uma técnica de teste — é um artefato de modelagem de requisitos da UML, que descreve a interação entre atores e o sistema. Além disso, "Técnica da Melhor Entrada" não existe na literatura de engenharia de software; é um nome inventado para confundir. O erro está em incluir elementos que não são técnicas de criação de testes.

Alternativa C — ❌ Incorreta

A alternativa traz duas técnicas corretas (Particionamento de Equivalência e Análise do Valor Limite), mas Builder é um padrão de projeto (Design Pattern) da família GoF, usado para construir objetos complexos passo a passo — não tem relação com a criação de casos de teste. O erro está em substituir uma técnica de teste por um padrão de projeto.

Alternativa D — ❌ Incorreta

A alternativa é a mais distante da correta: Caso de Uso é um artefato de modelagem de requisitos, Builder é um padrão de projeto, e "Técnica da Melhor Entrada" não existe. Nenhum dos três elementos é uma técnica de criação de testes. A banca montou essa alternativa com termos que parecem plausíveis, mas que pertencem a outras áreas da engenharia de software.

Alternativa E — ❌ Incorreta

A alternativa contém apenas Particionamento de Equivalência como técnica válida. "Técnica da Melhor Entrada" é um nome inventado, e Caso de Uso é um artefato de modelagem de requisitos, não uma técnica de teste. O erro está em incluir dois elementos que não são técnicas de criação de testes, deixando a alternativa incompleta e incorreta.

Gabarito: letra A