Pular para o conteúdo principal

Questão de Engenharia de Software — Teste de Software — VUNESP 2026

Engenharia de SoftwareTeste de Software
Código
gp044429
Banca
VUNESP
Órgão
UNESP
Ano
2026
Cargo
V - - Analista de Informática I - Área de Atuação: Desenvolvimento de Sistemas - Edital nº 350
Uma das técnicas de teste de software é constituída pelos denominados testes de caixa preta, que têm como fundamento principal
  1. Averificar a correção dos comentários inseridos no código fonte do software.
  2. Bavaliar as funcionalidades implementadas pelo software, sem que se tenha conhecimento do código fonte interno.
  3. Cexecutar, manualmente, linha a linha o software sob teste.
  4. Dverificar e avaliar a legibilidade do código fonte do software sob teste.
  5. Erealizar testes que façam o software sob teste operar por 24 horas sem interrupção.
Revelar gabarito e comentário

GabaritoB — avaliar as funcionalidades implementadas pelo software, sem que se tenha conhecimento do código fonte interno.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Teste de caixa preta (teste funcional)

Gabarito: letra B. O teste de caixa preta (também chamado de teste funcional ou teste baseado em especificação) tem como fundamento avaliar as funcionalidades do software a partir de suas entradas e saídas, sem considerar o código-fonte interno — exatamente o que afirma a alternativa B. Essa é a definição clássica da técnica, contraposta ao teste de caixa branca, que analisa a estrutura interna do programa.

O teste de caixa preta é uma das duas grandes famílias de técnicas de teste de software, ao lado do teste de caixa branca. Enquanto o teste de caixa branca (também chamado de teste estrutural ou orientado à lógica) examina o comportamento interno do componente — fluxos, condições, caminhos do código —, o teste de caixa preta enxerga o software como uma "caixa fechada": o testador fornece entradas e observa as saídas, sem se preocupar com a implementação. O foco está na funcionalidade e na conformidade com a especificação.

Na prática, o testador de caixa preta projeta casos de teste a partir dos requisitos e da especificação do sistema, utilizando técnicas como particionamento de equivalência, análise de valor limite, tabelas de decisão e testes de transição de estado. Por exemplo, em um sistema que aceita um número inteiro como entrada, o testador não precisa saber como o programa processa esse número internamente; ele apenas verifica se, para entradas válidas e inválidas, as saídas são as esperadas. Essa abordagem é aplicável a todas as fases de teste: integração, sistema e aceitação.

A distinção central que a banca explora é entre caixa preta e caixa branca. A tabela abaixo resume os contrastes:

Critério

Caixa preta

Caixa branca

Foco

Funcionalidades (entradas/saídas)

Estrutura interna (código, fluxos)

Conhecimento do código

Não necessário

Necessário

Base dos casos de teste

Especificação/requisitos

Código-fonte

Também chamado de

Teste funcional

Teste estrutural

A pegadinha desta questão é justamente inverter essa lógica: as alternativas incorretas descrevem atividades que pertencem ao teste de caixa branca (como executar linha a linha o código) ou que não são testes de software (como verificar comentários ou legibilidade do código). O candidato que confunde as duas técnicas cai facilmente na alternativa C, que descreve a execução manual linha a linha — típica do teste de caixa branca.

Guarde a fronteira: caixa preta = funcionalidade, sem código; caixa branca = estrutura, com código. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Verificar a correção dos comentários inseridos no código-fonte não é uma atividade de teste de caixa preta, nem de qualquer técnica de teste de software. Comentários são parte da documentação interna do código e não influenciam o comportamento funcional do sistema. Essa alternativa confunde teste com revisão de código ou análise estática, que não é o foco da caixa preta.

Alternativa B — ✅ Correta ⟵ GABARITO

A alternativa B descreve com precisão o fundamento do teste de caixa preta: avaliar as funcionalidades implementadas pelo software, sem conhecimento do código-fonte interno. O testador trata o software como uma caixa fechada, fornecendo entradas e verificando as saídas, com base na especificação. É a definição clássica da técnica, também chamada de teste funcional.

Alternativa C — ❌ Incorreta

Executar manualmente, linha a linha, o software sob teste é uma descrição do teste de caixa branca (ou teste estrutural), que exige conhecimento do código-fonte e percorre os caminhos internos do programa. A caixa preta não se preocupa com a execução linha a linha; ela observa apenas as entradas e saídas. Essa é a pegadinha clássica da banca: trocar a técnica de caixa preta pela de caixa branca.

Alternativa D — ❌ Incorreta

Verificar e avaliar a legibilidade do código-fonte é uma atividade de revisão de código ou análise estática, não de teste de caixa preta. A caixa preta não analisa o código; ela testa o comportamento externo do software. A legibilidade é uma preocupação de manutenibilidade, não de funcionalidade.

Alternativa E — ❌ Incorreta

Realizar testes que façam o software operar por 24 horas sem interrupção descreve um teste de estabilidade ou resistência (soak test), que é um tipo de teste não funcional, não uma técnica de caixa preta. A caixa preta pode ser usada em testes de estabilidade, mas o fundamento da técnica é avaliar funcionalidades, não a duração da operação.

NÃO CAIA NESSA!

A banca adora inverter as técnicas de teste: a alternativa C descreve o teste de caixa branca (executar linha a linha o código) e a apresenta como se fosse caixa preta. Fique atento: caixa preta = funcionalidade, sem código; caixa branca = estrutura, com código. Com treino, você enxerga essas trocas de longe 💪.

Gabarito: letra B

Link permanente: /questoes/gp044429