Questão de Engenharia de Software — Conceitos e Tipos de Testes de Software — FCC 2025

Diagnóstico e correção de falhas em manutenção de software

Gabarito: letra D. A abordagem correta é, primeiramente, analisar os logs de erro e o consumo de memória, replicar o problema em ambiente de teste com dados reais e usar ferramentas de profiling/depuração para identificar a causa raiz antes de propor qualquer correção — isso segue as boas práticas de diagnóstico de erros e manutenção de software, que exigem entender o problema antes de agir.

O cenário descreve um problema clássico de manutenção corretiva: um sistema que falha de forma intermitente sob condições específicas (alto volume de dados na geração de PDFs). A manutenção corretiva é a atividade de engenharia de software que visa corrigir defeitos identificados após a implantação. O ponto central aqui não é apenas "consertar", mas sim diagnosticar corretamente antes de qualquer intervenção. As boas práticas de diagnóstico seguem uma sequência lógica: (1) coletar evidências (logs, métricas de memória), (2) reproduzir o problema em ambiente controlado, (3) identificar a causa raiz com ferramentas adequadas (profiler, depurador) e só então (4) propor e implementar a correção definitiva. Essa abordagem evita correções superficiais que mascaram o sintoma sem resolver a causa, e também evita introduzir novos defeitos — o que é verificado posteriormente por testes de regressão.

A alternativa D é a única que segue integralmente esse fluxo. Ela combina três elementos essenciais: a análise de logs (evidência do que ocorreu), a replicação em ambiente de teste com dados reais (reprodução controlada do problema) e o uso de profiler/depurador (ferramentas de diagnóstico que identificam gargalos e vazamentos de memória). Esse é exatamente o procedimento recomendado para problemas intermitentes relacionados a consumo de recursos, como o travamento ao gerar relatórios com muitos processos.

As demais alternativas representam anti-padrões de manutenção: soluções paliativas que ignoram o diagnóstico (A), tratamento genérico de exceções que esconde o erro (B), comentar código para "evitar" a falha (C) e abandonar testes automatizados (E). Todas violam o princípio fundamental de que a correção deve ser baseada em evidências e na compreensão da causa raiz.

O que separa a alternativa correta das demais é exatamente o método: diagnóstico baseado em evidências antes da correção. As alternativas incorretas propõem ações imediatas e superficiais, enquanto a correta propõe um processo investigativo completo. Guarde esse critério: em questões de manutenção de software, a resposta certa quase sempre envolve diagnosticar, reproduzir e identificar a causa raiz antes de corrigir.

Alternativa A — ❌ Incorreta

Propõe "evitar o problema" dividindo o relatório em múltiplos arquivos e enviando por e-mail diretamente do backend, "sem necessidade de depuração manual ou logs". O erro está em tratar o sintoma (travamento) com uma solução paliativa que não investiga a causa raiz — que pode ser um vazamento de memória, um algoritmo ineficiente ou um problema de concorrência. Além disso, a alternativa afirma explicitamente que não há necessidade de depuração ou logs, o que contraria frontalmente as boas práticas de diagnóstico. Dividir o relatório pode até reduzir o consumo de memória, mas não corrige o defeito subjacente e pode introduzir novos problemas (como envio de e-mails não solicitados).

Alternativa B — ❌ Incorreta

Sugere um try/catch genérico envolvendo toda a rotina, exibindo mensagem padrão ao usuário e continuando a execução "sem registrar logs detalhados". Isso é um anti-padrão de tratamento de exceções: capturar exceções de forma genérica e continuar a execução sem registrar detalhes esconde o erro e impede o diagnóstico. Além disso, "continuar a execução" após uma falha na geração do relatório pode levar a registros incompletos — exatamente o problema descrito no enunciado. A prática correta é capturar exceções específicas, registrar logs detalhados e, quando necessário, interromper a operação para evitar corrupção de dados.

Alternativa C — ❌ Incorreta

Propõe "comentar o trecho de código em que ocorre a falha" para evitar que a exceção interrompa o sistema, e depois reimplantar em produção. Comentar código é uma prática de depuração temporária, nunca uma correção definitiva. Isso remove a funcionalidade de geração do relatório (ou parte dela), o que certamente não é aceitável, e não resolve a causa do travamento. Reimplantar em produção sem corrigir o defeito e sem testes adequados é extremamente arriscado e viola as boas práticas de manutenção.

Alternativa D — ✅ Correta ⟵ GABARITO

Esta é a abordagem correta e mais adequada. Ela segue o processo de diagnóstico estruturado: (1) analisar logs de erro e consumo de memória — coleta de evidências; (2) replicar o erro em ambiente de teste com dados reais — reprodução controlada; (3) utilizar ferramentas de profiler ou depurador para identificar gargalos e vazamentos — identificação da causa raiz. Só depois disso se propõem correções definitivas. Esse fluxo é o recomendado pelas boas práticas de manutenção de software e é exatamente o que se espera de um profissional ao lidar com falhas intermitentes relacionadas a volume de dados.

Alternativa E — ❌ Incorreta

Afirma que se deve "evitar o uso de testes de integração automatizados" porque o erro só ocorre com alto volume de dados, sendo mais eficiente "aguardar relatos de usuários". Isso é completamente equivocado: testes de integração automatizados são essenciais justamente para detectar problemas que só aparecem quando componentes interagem, e testes de volume/carga são projetados exatamente para simular condições de alto volume. Abandonar testes automatizados e esperar relatos de usuários é reativo e aumenta o custo de correção, além de permitir que o problema afete usuários reais.

Gabarito: letra D