Questão de Engenharia de Software — Qualidade de Software — FUNDATEC 2025
Engenharia de Software›Qualidade de Software
Código
qg474976
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Nível
Superior
Cargo
Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Um produto de tecnologia com pipeline de CI (Azure DevOps) integra serviços .NET, API REST, fila de mensagens e SPA. O time relata builds lentos, flaky tests e regressões ocasionais no front-end. O pipeline atual executa dotnet test (unit), sobe dependências via Testcontainers para integração e roda E2E com Playwright em ambiente efêmero. Qual estratégia de distribuição e desenho de testes otimiza custo/benefício e confiabilidade, em linha com a pirâmide de testes?
AAmpliar a camada E2E acima da base unitária para cobrir "caminhos felizes" e regressão visual, deixando unitários focados em lógica periférica; a integração torna-se residual.
BEliminar a camada de integração, substituindo-a por unit tests com mocks extensivos e por uma bateria robusta de E2E contra ambiente efêmero para validar contratos "de ponta a ponta".
CPriorizar testes manuais (exploratórios/UAT) em cada pull request, usando automação apenas no merge principal, para não "atrapalhar" o fluxo de desenvolvimento.
DAplicar mocks extensivos nos E2E para isolar flakiness (simulando praticamente todas as dependências internas e externas), mantendo poucos unitários e integração mínima.
EManter base ampla de testes unitários rápidos e determinísticos; ter camada moderada de integração/contratos para verificar pontos de acoplamento; e poucos E2E críticos estáveis e bem instrumentados.
Revelar gabarito e comentário▾
GabaritoE — Manter base ampla de testes unitários rápidos e determinísticos; ter camada moderada de integração/contratos para verificar pontos de acoplamento; e poucos E2E críticos estáveis e bem instrumentados.
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”.
Testes em Pipeline CI/CD e a Pirâmide de Testes
Gabarito: letra E. A estratégia que otimiza custo/benefício e confiabilidade, em linha com a pirâmide de testes, é manter uma base ampla de testes unitários rápidos e determinísticos, uma camada moderada de testes de integração/contrato para verificar pontos de acoplamento, e poucos testes E2E críticos, estáveis e bem instrumentados — exatamente o que a alternativa E propõe.
A pirâmide de testes (Mike Cohn) preconiza que a maioria dos testes deve ser de unidade (rápidos, baratos e determinísticos), uma quantidade moderada de testes de integração (para verificar interfaces) e uma minoria de testes E2E (lentos, frágeis e caros). No contexto descrito (builds lentos, flaky tests, regressões no front-end), a abordagem correta é fortalecer a base unitária e usar integração com parcimônia, mantendo E2E apenas para os caminhos críticos.
Estratégia
Descrição
Alinhamento com a Pirâmide de Testes
Otimização Custo/Benefício e Confiabilidade
A
Ampliar E2E acima da unitária, focando em "caminhos felizes" e regressão visual; integração residual.
❌ Inverte a pirâmide (E2E massivo, unitário reduzido).
❌ Aumenta lentidão e flakiness; não otimiza.
B
Eliminar integração; substituir por unitários com mocks e E2E robustos.
❌ Risco de regressões em interfaces; E2E não cobre todas as combinações.
C
Priorizar testes manuais em cada PR; automação apenas no merge principal.
❌ Viola automação contínua; não segue pirâmide.
❌ Gargalo humano e retrabalho; baixa confiabilidade.
D
Mocks extensivos nos E2E para isolar flakiness; poucos unitários e integração mínima.
❌ Descaracteriza E2E (ambiente artificial); base unitária fraca.
❌ Esconde problemas reais; aumenta complexidade e falsos positivos.
E
Base ampla de unitários rápidos/determinísticos; camada moderada de integração/contratos; poucos E2E críticos estáveis.
✅ Segue a pirâmide (maioria unitários, minoria E2E).
✅ Otimiza custo (rápidos/baratos) e confiabilidade (testes determinísticos e focados).
Pirâmide de testes (Mike Cohn)
1Base ampla
Unitários (rápidos, determinísticos)
2Camada moderada
Integração/contratos (acoplamentos)
3Topo reduzido
E2E críticos (estáveis, instrumentados)
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Ampliar a camada E2E acima da unitária inverte a pirâmide, tornando os testes lentos e frágeis. A regressão visual e "caminhos felizes" devem ser cobertos por uma combinação de testes de integração e E2E bem selecionados, não por uma base E2E massiva. Isso aumentaria o tempo de pipeline e a flakiness.
Alternativa B — ❌ Incorreta
Eliminar a camada de integração deixa de validar contratos entre serviços e componentes reais, aumentando o risco de regressões em interfaces. Substituir integração por mocks extensivos em testes unitários não substitui a verificação de acoplamentos reais, e uma bateria robusta de E2E não cobre todas as combinações de integração de forma confiável.
Alternativa C — ❌ Incorreta
Priorizar testes manuais em cada pull request viola o princípio de automação contínua, introduzindo gargalos humanos e retrabalho. Testes manuais devem ser reservados para validação exploratória em momentos específicos, não como parte do pipeline de CI.
Alternativa D — ❌ Incorreta
Aplicar mocks extensivos nos E2E para isolar flakiness descaracteriza o propósito dos testes E2E, que é validar o sistema como um todo em ambiente real. Mocks em E2E criam um ambiente artificial que pode esconder problemas reais de integração, além de aumentar a complexidade de manutenção.
Alternativa E — ✅ Correta ⟵ GABARITO
Esta alternativa reflete fielmente a pirâmide de testes: base unitária forte (rápida e determinística), camada moderada de integração (focada em contratos e acoplamentos críticos) e poucos E2E estáveis e instrumentados para os cenários de maior risco. Essa distribuição minimiza flaky tests, acelera o pipeline e mantém a confiabilidade com custo controlado.
SE LIGUE NESSA!
A pirâmide de testes é um guia clássico para alocar esforço de automação. Adaptações modernas (como o troféu de testes ou a pirâmide invertida para microsserviços) podem ser úteis em contextos específicos, mas para o cenário descrito a abordagem tradicional continua sendo a mais indicada.