Questão de Engenharia de Software — Geral — VUNESP 2024
Engenharia de Software›Geral
Código
vu212229
Banca
VUNESP
Órgão
Pref Aparecida (SP)
Ano
2024
Cargo
Ana ( )
Testes de aceitação automatizados de software ajudam a detectar se erros de regressão foram introduzidos após alguma alteração no código-fonte. Esse tipo de erro caracteriza- se
Apor resultados incorretos apresentados por algoritmos de regressão linear, em geral causados por falhas de implementação.
Bpor incompatibilidades na comunicação entre um front-end e um back-end, em geral causadas por alterações na API fornecida pelo back-end.
Cpor alguma funcionalidade que já estava operando corretamente antes das alterações no código-fonte, e que passou a apresentar defeito após essas modificações.
Dpela ocorrência de exclusões indevidas de registros no banco de dados relacional usado pela aplicação.
Epela criação de alguma funcionalidade que não existia antes na aplicação, mas que foi implementada com defeito.
Revelar gabarito e comentário▾
GabaritoC — por alguma funcionalidade que já estava operando corretamente antes das alterações no código-fonte, e que passou a apresentar defeito após essas modificações.
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 Regressão
Gabarito: letra C. O teste de regressão é o tipo de teste que verifica se novas alterações no software não introduziram defeitos em funcionalidades já existentes e previamente testadas. Essa é a definição clássica, presente na literatura de Engenharia de Software (por exemplo, em Sommerville e Pressman), e é exatamente o que a alternativa C descreve: uma funcionalidade que operava corretamente antes das modificações e passou a apresentar defeito após elas.
O teste de regressão é um dos conceitos mais cobrados em provas de Engenharia de Software, e a banca costuma explorar justamente a confusão entre ele e outros tipos de teste. Para entender bem, é preciso separar duas dimensões: os níveis de teste (unitário, integração, sistema, aceitação) e os tipos de teste (funcional, regressão, desempenho, segurança, etc.). O teste de regressão não é um nível, mas um tipo que pode ser aplicado em qualquer nível — ele se preocupa com o efeito colateral de uma mudança: garantir que o que já funcionava continue funcionando.
A lógica por trás é simples: quando um desenvolvedor altera o código para corrigir um bug ou adicionar uma funcionalidade, existe o risco de quebrar algo que já estava funcionando. O teste de regressão reexecuta os testes existentes (ou novos testes específicos) para detectar essas quebras. Ele é essencial em ambientes de integração contínua, onde cada commit pode disparar uma suíte de regressão automaticamente. Por isso, a alternativa C está correta: ela descreve exatamente o cenário que o teste de regressão visa detectar.
A pegadinha da banca está em alternativas que descrevem outros tipos de teste ou problemas específicos, como a alternativa B (que fala de incompatibilidade front-end/back-end, típica de teste de integração) ou a alternativa E (que fala de funcionalidade nova com defeito, que é um bug comum, mas não é regressão). O candidato que não domina a definição precisa acaba marcando uma dessas opções por parecerem plausíveis.
Guarde a fronteira: regressão = quebra do que já funcionava; integração = problemas na comunicação entre módulos; funcionalidade nova com defeito = bug de implementação, não regressão. É nessa fronteira que as alternativas se dividem.
Teste de regressão
1O que é
Funcionalidade que já funcionava
Passa a apresentar defeito após alteração
2Objetivo
Detectar efeito colateral de mudança
Garantir que o que funcionava continue funcionando
3Aplicação
Qualquer nível de teste
Essencial em integração contínua
4Confusões comuns
Integração: comunicação entre módulos
Bug de implementação: funcionalidade nova com defeito
Regressão linear: método estatístico
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Fala de "resultados incorretos apresentados por algoritmos de regressão linear". Isso é uma pegadinha com o termo "regressão", mas em contexto totalmente diferente: regressão linear é um método estatístico, não tem relação com teste de software. O erro é a troca de conceito — o candidato que confunde os dois termos cai nessa alternativa.
Alternativa B — ❌ Incorreta
Descreve incompatibilidade na comunicação entre front-end e back-end, causada por alterações na API. Isso é um problema típico de teste de integração, que verifica se os módulos interagem corretamente. Embora uma alteração na API possa causar regressão, a alternativa foca na comunicação entre componentes, não na quebra de funcionalidade já existente. O erro é a confusão entre teste de regressão e teste de integração.
Alternativa C — ✅ Correta ⟵ GABARITO
Define exatamente o que é regressão: uma funcionalidade que funcionava corretamente antes das alterações e passou a apresentar defeito após elas. É a definição clássica, presente em qualquer livro de Engenharia de Software. O teste de regressão serve justamente para detectar esse tipo de erro.
Alternativa D — ❌ Incorreta
Fala de exclusões indevidas de registros no banco de dados. Isso pode ser um bug de integridade de dados, mas não é uma definição de regressão. A regressão é sobre funcionalidade que quebrou após mudança, não sobre um tipo específico de defeito de banco. O erro é a generalização: exclusão indevida pode ser um sintoma, mas não caracteriza o conceito.
Alternativa E — ❌ Incorreta
Descreve a criação de uma funcionalidade nova que foi implementada com defeito. Isso é um bug de implementação, não uma regressão. A regressão pressupõe que a funcionalidade já existia e funcionava; aqui, a funcionalidade é nova. O erro é a inversão do conceito: regressão é sobre o que já existia, não sobre o que é novo.