Engenharia de Software · VUNESP · 2025 | Questão sqc-vu222985

Teste de Software: características de bons testes

Gabarito: letra D. Um bom teste de software deve ter alta probabilidade de encontrar ou detectar erros — essa é uma das características clássicas de qualidade de testes, conforme a literatura de Engenharia de Software (Pressman, Sommerville). As demais alternativas distorcem o propósito do teste, seja limitando sua capacidade, ignorando especificações ou confundindo-o com atividades de compilação.

O teste de software é uma atividade de verificação e validação que visa revelar defeitos no software antes de sua entrega. A boa prática de teste não busca provar que o software está correto, mas sim encontrar erros — e, para isso, um bom caso de teste é aquele que tem alta probabilidade de revelar um defeito ainda não descoberto. Essa é uma das características fundamentais elencadas por autores como Roger Pressman, que define boas características de testes: alta probabilidade de encontrar erros, não redundância, ser da mesma espécie (similaridade) e ter a complexidade adequada (nem simples demais, nem complexa demais).

A lógica por trás disso é simples: se um teste raramente falha ou nunca encontra problemas, ele não está exercitando o software de forma eficaz. Um bom teste é "agressivo" no sentido de tentar quebrar o sistema, explorando entradas inválidas, condições de contorno e caminhos pouco usuais. Por outro lado, testes que apenas repetem o fluxo feliz (happy path) tendem a passar sempre e não agregam valor real à qualidade do produto.

Na prática, imagine um sistema de login. Um teste que apenas digita usuário e senha corretos e verifica se o acesso é permitido é um teste fraco — ele quase nunca falha. Já um bom teste tenta senhas vazias, usuários inexistentes, caracteres especiais, injeção de SQL, tentativas repetidas etc. — ou seja, tem alta probabilidade de encontrar erros de validação e segurança. É exatamente essa a característica que a alternativa D descreve.

A pegadinha da banca aqui é apresentar alternativas que confundem o teste com outras atividades do desenvolvimento: a alternativa A limita artificialmente a capacidade do teste, a B ignora as especificações (que são a base do teste funcional), a C atribui ao teste a função de localizar erros de comentários (que não é um defeito funcional), e a E confunde teste com compilação. A fronteira que separa a correta das demais é o propósito do teste: revelar defeitos de forma eficaz, com alta probabilidade de detecção.

Características de bons testes: Alta probabilidade de encontrar erros; Não redundância; Similaridade (mesma espécie); Complexidade adequada; Baseados nas especificações

Alternativa A — ❌ Incorreta

Afirma que bons testes devem "necessariamente" detectar, no máximo, um erro a cada nova execução. Isso é um absurdo técnico: um bom teste pode (e deve) revelar múltiplos erros em uma única execução, e não há qualquer limitação dessa natureza na teoria de testes. A característica correta é justamente o oposto — maximizar a detecção de defeitos. A palavra "necessariamente" e o limite "no máximo um erro" tornam a afirmação falsa.

Alternativa B — ❌ Incorreta

Diz que bons testes "não levam em conta as especificações determinadas para o software". Isso contraria frontalmente o teste funcional (caixa preta), que deriva casos de teste exatamente a partir das especificações. As especificações são a base para saber o que o software deveria fazer e, portanto, para verificar se ele faz. Ignorá-las tornaria o teste aleatório e sem critério de oráculo.

Alternativa C — ❌ Incorreta

Afirma que bons testes conseguem "localizar erros decorrentes da falta de comentários no código fonte". Falta de comentários é um problema de legibilidade/manutenibilidade do código, não um defeito funcional que o teste de software tenha por objetivo localizar. O teste busca erros de lógica, integração, requisitos etc. — não a ausência de comentários. A alternativa confunde qualidade de código com teste de software.

Alternativa D — ✅ Correta ⟵ GABARITO

Esta é a característica clássica de um bom teste: ter alta probabilidade de encontrar ou detectar erros. É exatamente o que a literatura de Engenharia de Software (Pressman, por exemplo) define como uma das características de um bom caso de teste. Um teste que raramente falha ou nunca encontra defeitos não está exercitando o software de forma eficaz. A alternativa espelha com precisão o conceito.

Alternativa E — ❌ Incorreta

Afirma que bons testes "sempre apresentam erros de compilação a cada teste planejado e implementado". Erros de compilação são problemas do código-fonte, não do teste em si. Um teste bem planejado e implementado deve compilar corretamente para poder executar e verificar o comportamento do software. A alternativa confunde a atividade de teste com a atividade de compilação, que são etapas distintas do desenvolvimento.

NÃO CAIA NESSA!

A banca explora a confusão entre o propósito do teste e outras atividades do desenvolvimento. As alternativas A, C e E misturam teste com limitação artificial, qualidade de código e compilação, respectivamente. A B inverte a base do teste funcional (especificações). O candidato que não domina o conceito de "alta probabilidade de detecção" tende a cair em alguma dessas armadilhas. Com treino, você enxerga essas trocas de longe 💪

PEGA ESSA DICA!

Para questões sobre características de bons testes, lembre-se do tripé: alta probabilidade de encontrar erros, não redundância (cada teste tem propósito único) e similaridade/adequação (testes da mesma espécie). Se a alternativa trouxer "sempre", "nunca", "necessariamente" ou "no máximo", desconfie — a regra geral comporta exceções e a banca adora esses termos absolutos.

Gabarito: letra D