Questão de Engenharia de Software — Teste de Software — FCC 2018
Engenharia de Software›Teste de Software
Código
fc044234
Banca
FCC
Órgão
DPE-AM
Ano
2018
Cargo
Analista em Gestão Especializado de Defensoria - Analista de Sistema
Considere, por hipótese, que na Defensoria esteja sendo desenvolvido um projeto com prazo crítico, sendo necessário que os desenvolvedores avaliem o software frequentemente. A equipe envolvida decidiu utilizar uma abordagem de teste de integração que trabalha da seguinte maneira:I. Componentes necessários para implementar funções do software, como arquivos de dados, bibliotecas, módulos reutilizáveis etc são integrados em uma build (construção).II. Diversos testes são projetados para que erros que possam impedir a build em andamento de desempenhar de forma adequada sua função, com o objetivo de descobrir showstoppers que impliquem em atrasos no cronograma.III. A build é integrada a outras builds e todo o software passa diariamente por este tipo de teste, podendo usar abordagem ascendente ou descendente de integração.O teste de integração descrito é denominado teste
Ade fumaça.
Bde regressão.
Ctop-down.
Dbreadth-first.
Ede caixa cinza (grey box).
Revelar gabarito e comentário▾
GabaritoA — de fumaça.
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 Integração: Smoke Test (Teste de Fumaça)
Gabarito: letra A. O teste descrito é o teste de fumaça (smoke test). Suas características – integração de componentes em uma build, foco em descobrir showstoppers (erros críticos que impedem o funcionamento) e execução diária com possibilidade de abordagens ascendente/descendente – são exatamente o que define esse tipo de teste. O termo vem da expressão "se a fumaça sair, desliga e conserta" (teste de sanidade em hardware).
A banca testa o conhecimento sobre os diferentes tipos de teste de integração. Vamos analisar cada alternativa:
Característica
Teste de Fumaça (Smoke Test)
Teste de Regressão
Integração Top-Down
Integração Breadth-First
Teste de Caixa Cinza
Objetivo principal
Verificar estabilidade da build e encontrar showstoppers
Garantir que mudanças não quebraram funcionalidades existentes
Integrar módulos de alto nível primeiro, usando stubs
Integrar todos os módulos de uma mesma camada antes de avançar
Testar com conhecimento parcial da estrutura interna
Foco em erros críticos (showstoppers)
Sim, prioritário
Não é o foco principal
Não é o foco principal
Não é o foco principal
Não é o foco principal
Frequência de execução
Diária ou frequente (após cada build)
Após alterações significativas
Durante a fase de integração
Durante a fase de integração
Variável, conforme necessidade
Relação com builds diárias
Essencial e descrita no enunciado
Pode ser, mas não é regra
Não é característica definidora
Não é característica definidora
Não é característica definidora
Abordagem ascendente/descendente
Pode usar ambas
Não se aplica
Apenas descendente
Apenas em largura
Não se aplica
Teste de fumaça (smoke): Integração em build (Componentes + dados + bibliotecas); Foco em showstoppers (Erros críticos que impedem funcionamento); Execução frequente (Diária, Ascendente ou descendente)
Alternativa A — ✅ Correta ⟵ GABARITO
O teste de fumaça (ou smoke test) é uma abordagem de teste de integração que verifica rapidamente se a build está estável e se as funcionalidades mais críticas funcionam. É executado frequentemente (diariamente) e prioriza encontrar erros que inviabilizariam a continuidade do desenvolvimento (showstoppers). Os itens I, II e III descrevem exatamente esse processo.
PEGA ESSA DICA!
Lembre-se: teste de fumaça = "build de ontem funciona hoje?" Teste de regressão = "a mudança não quebrou nada que já funcionava?"
Alternativa B — ❌ Incorreta
O teste de regressão tem por objetivo garantir que modificações recentes não introduziram novos defeitos em funcionalidades já testadas. Embora também seja executado após alterações, ele não é focado em showstoppers nem necessariamente integrado a builds diárias; seu escopo é mais amplo (repetir todos os casos de teste relevantes). O enunciado descreve algo mais específico e imediato.
Alternativa C — ❌ Incorreta
Top-down é uma estratégia de integração (ordem em que os módulos são integrados), não um tipo de teste. No top-down, módulos de nível superior são testados primeiro, usando stubs para os inferiores. A descrição do enunciado não fala de ordem, mas de construção de builds e testes diários.
Alternativa D — ❌ Incorreta
Breadth-first (busca em largura) é outra estratégia de integração, onde todos os módulos de uma mesma camada são integrados antes de ir para a próxima. Novamente, não é um tipo de teste, e sim um plano de integração. O enunciado não menciona essa abordagem, apenas cita que o teste de fumaça pode usar abordagens ascendente ou descendente – mas isso não o torna breadth-first.
Alternativa E — ❌ Incorreta
O teste de caixa cinza (grey box) é uma técnica que combina conhecimentos da estrutura interna (caixa-branca) com testes funcionais (caixa-preta). Não está relacionado com o processo de integração diária de builds ou à busca de showstoppers.