Questão de Engenharia de Software — Teste de Software — VUNESP 2026
Engenharia de Software›Teste 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
Averificar a correção dos comentários inseridos no
código fonte do software.
Bavaliar as funcionalidades implementadas pelo
software, sem que se tenha conhecimento do código
fonte interno.
Cexecutar, manualmente, linha a linha o software sob
teste.
Dverificar e avaliar a legibilidade do código fonte do
software sob teste.
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 💪.