Questão de Engenharia de Software — Geral — FCC 2026

Teste de Software: níveis, tipos e a abordagem integral

Gabarito: letra E. A alternativa E é a única que atende integralmente ao contexto porque compõe uma matriz de testes que cobre todos os níveis (unitário, integração, sistema e aceitação), a automação e os testes não funcionais (desempenho, carga e segurança) — exatamente o que o enunciado pede ao mencionar "tipos de teste, testes funcionais e não funcionais, automação e testes de desempenho, carga e segurança". As demais alternativas, embora válidas em parte, são parciais e deixam de fora dimensões essenciais do contexto.

O enunciado descreve um sistema que consolida registros de infrações e notifica órgãos externos via APIs e interfaces web, exigindo "conformidade funcional e robustez operacional sob demanda variável". Essa descrição não aponta para um único tipo de teste, mas para uma estratégia abrangente que combine diferentes níveis e tipos. Para entender por que a letra E é a correta, é preciso dominar a distinção entre níveis de teste (unitário, integração, sistema, aceitação) e tipos de teste (funcional, não funcional, estrutural), além do papel da automação.

Os níveis de teste representam o escopo crescente do que se testa: o teste unitário verifica o menor componente isolado (um método, uma classe); o teste de integração verifica a interação entre componentes (como a orquestração entre serviços e conectores); o teste de sistema valida o sistema completo em ambiente próximo ao real; e o teste de aceitação verifica se o sistema atende aos critérios de negócio do cliente. Já os tipos de teste classificam o objetivo do teste: o teste funcional (caixa-preta) verifica se as funções atendem aos requisitos; o teste não funcional avalia atributos como desempenho, carga, segurança e usabilidade; e o teste estrutural (caixa-branca) analisa o código interno.

A automação de testes é o uso de ferramentas e scripts para executar casos de teste de forma automática, aumentando a velocidade e a repetibilidade — essencial para fluxos operacionais críticos como notificações a órgãos externos. No contexto, a automação deve ser aplicada de forma transversal, complementando os testes em todos os níveis.

A pegadinha desta questão está na palavra "integralmente": cada alternativa incorreta apresenta uma abordagem parcialmente correta, mas que negligencia uma ou mais dimensões do contexto. A banca explora a tendência do candidato de escolher a alternativa que parece mais "técnica" ou "específica", sem verificar se ela cobre todos os aspectos mencionados no enunciado. O critério decisivo é: a alternativa deve contemplar simultaneamente os níveis de teste, os tipos funcional e não funcional, e a automação — é exatamente essa combinação que separa a letra E das demais.

Alternativa A — ❌ Incorreta

A alternativa A foca em testes de integração nas interfaces com órgãos externos e em scripts automatizados para fluxos de notificação. Embora a integração e a automação sejam relevantes, a abordagem é incompleta: não menciona testes unitários, de sistema, de aceitação, nem os testes não funcionais (desempenho, carga, segurança) que o enunciado exige explicitamente. A interoperabilidade é importante, mas não é a única preocupação do contexto.

Alternativa B — ❌ Incorreta

A alternativa B concentra esforços em testes unitários para serviços de domínio e modelos de dados, com cenários funcionais básicos. O erro está na parcialidade: testes unitários verificam apenas o comportamento interno de componentes isolados, sem validar a integração entre serviços, o sistema como um todo, os critérios de aceitação regulatória ou os requisitos não funcionais. É uma abordagem de baixo nível que não atende à robustez operacional sob demanda variável.

Alternativa C — ❌ Incorreta

A alternativa C prioriza testes de aceitação end-to-end orientados aos requisitos regulatórios, com execução automatizada em homologação. Embora a aceitação e a automação sejam importantes, a abordagem ignora os níveis mais baixos (unitário e integração) e os testes não funcionais (desempenho, carga, segurança). Testes de aceitação validam o produto final, mas não garantem que os componentes internos funcionem corretamente nem que o sistema suporte picos de demanda.

Alternativa D — ❌ Incorreta

A alternativa D estrutura testes funcionais exclusivamente sobre a camada de API, com validação de contratos e rastreabilidade. O erro é a exclusividade: limitar-se à camada de API deixa de fora os testes unitários, de integração entre serviços internos, de sistema, de aceitação e os não funcionais. A validação de contratos é uma boa prática, mas não substitui a necessidade de testar o sistema como um todo, incluindo desempenho e segurança.

Alternativa E — ✅ Correta ⟵ GABARITO

A alternativa E é a única que compõe uma matriz de testes integral: inclui testes unitários para regras de infrações, integração para orquestração entre serviços e conectores, sistema para validação ponta a ponta em ambiente próximo ao real, aceitação para critérios regulatórios, automação e testes não funcionais de desempenho, carga e segurança. Essa combinação atende a todos os aspectos do enunciado: conformidade funcional (testes funcionais em todos os níveis), robustez operacional sob demanda variável (testes de desempenho e carga) e proteção de dados sensíveis (testes de segurança). É a abordagem mais completa e equilibrada.

A lição que fica: em questões que pedem uma abordagem "integral", desconfie de alternativas que focam em um único nível ou tipo de teste. A resposta correta quase sempre é a que combina diferentes níveis, tipos e automação, formando uma estratégia abrangente.

Gabarito: letra E