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

Teste de Integração: Estratégias Top-Down e Bottom-Up

Gabarito: letra D. A integração descendente (top-down) pode ser executada em duas modalidades: primeiro em largura (breadth-first) ou primeiro em profundidade (depth-first), conforme a ordem em que os módulos são integrados a partir do módulo de controle principal. As demais alternativas erram ao restringir indevidamente a aplicação dessas estratégias a tipos específicos de software ou modalidades.

O teste de integração é a fase em que módulos já testados individualmente (teste de unidade) são combinados para verificar se as interfaces entre eles funcionam corretamente. É uma técnica sistemática para construir a arquitetura do software enquanto se descobrem erros associados às interfaces. As duas grandes estratégias são a integração descendente (top-down) e a ascendente (bottom-up), cada uma com suas características, vantagens e desvantagens.

Na integração descendente, parte-se do módulo de controle principal (o "topo" da arquitetura) e os módulos subordinados são integrados incrementalmente. Como os módulos de nível inferior ainda não foram desenvolvidos ou integrados, é necessário criar stubs — versões simplificadas que simulam o comportamento dos módulos ausentes. A ordem de integração dos módulos subordinados pode seguir duas estratégias: primeiro em largura (breadth-first), integrando todos os módulos de um mesmo nível antes de descer ao próximo nível, ou primeiro em profundidade (depth-first), integrando todos os módulos ao longo de um caminho específico da árvore de chamadas antes de passar para o próximo caminho. Essa flexibilidade é exatamente o que a alternativa D afirma.

Na integração ascendente, o processo é inverso: parte-se dos módulos de nível mais baixo (as "folhas" da arquitetura) e vai-se subindo até o módulo de controle principal. Como os módulos de nível superior ainda não estão prontos, utilizam-se drivers — programas que simulam a chamada aos módulos de nível inferior. A integração ascendente não tem a mesma distinção entre "largura" e "profundidade" que a descendente, pois a integração é feita por níveis hierárquicos, de baixo para cima.

A escolha entre as estratégias depende de fatores como a criticidade dos módulos, a complexidade da arquitetura e a necessidade de detectar erros cedo. A integração descendente permite testar a lógica de controle principal mais cedo, mas exige a criação de stubs; a ascendente permite testar módulos de baixo nível mais cedo, mas exige drivers. Ambas são aplicáveis a qualquer tipo de software, independentemente do domínio (folha de pagamento, automação de processos, etc.).

A pegadinha desta questão está em associar as estratégias de integração a domínios específicos de software (folha de pagamento, automação de processos) ou a uma única modalidade de execução. A banca tenta fazer o candidato acreditar que a integração descendente só se aplica a certos tipos de software ou que só pode ser feita de uma forma, quando na verdade a escolha da estratégia é uma decisão de engenharia de software, independente do domínio da aplicação.

Guarde a distinção fundamental: descendente (top-down) usa stubs e pode ser em largura ou profundidade; ascendente (bottom-up) usa drivers e integra por níveis. É exatamente essa distinção que separa as alternativas corretas das incorretas.

Alternativa A — ❌ Incorreta

Afirma que a integração descendente se aplica exclusivamente a software voltado a folhas de pagamento. Isso é um absurdo: a estratégia top-down é uma técnica genérica de teste de integração, aplicável a qualquer tipo de software, independentemente do domínio. A palavra "exclusivamente" já denuncia o erro — não há qualquer restrição desse tipo na engenharia de software.

Alternativa B — ❌ Incorreta

Afirma que a integração descendente só é possível na modalidade primeiro em largura. Isso é falso: a integração descendente pode ser feita tanto primeiro em largura (breadth-first) quanto primeiro em profundidade (depth-first). A alternativa erra ao restringir a estratégia a uma única modalidade, quando na verdade ambas são possíveis e a escolha depende da arquitetura e dos objetivos do teste.

Alternativa C — ❌ Incorreta

Afirma que a integração ascendente não se aplica a software voltado à automação de processos. Assim como a alternativa A, essa é uma restrição artificial e sem fundamento. A integração bottom-up é uma técnica genérica, aplicável a qualquer tipo de software, incluindo automação de processos. Não há qualquer limitação de domínio para o uso dessa estratégia.

Alternativa D — ✅ Correta ⟵ GABARITO

Afirma corretamente que a integração descendente pode ser feita primeiro em largura ou primeiro em profundidade. Essa é a definição clássica das duas modalidades da estratégia top-down: na primeira, integram-se todos os módulos de um nível antes de descer ao próximo; na segunda, segue-se um caminho completo da árvore de chamadas antes de iniciar outro. A alternativa espelha exatamente essa flexibilidade da abordagem descendente.

Alternativa E — ❌ Incorreta

A alternativa está incompleta — termina em "deve ser feita" sem completar a frase. Mesmo que a intenção fosse afirmar algo sobre a integração ascendente, a alternativa não apresenta uma afirmação completa e, portanto, não pode ser considerada correta. Além disso, a integração ascendente não "deve" ser feita de uma única forma específica; ela é uma estratégia com suas próprias características, mas a alternativa não chega a afirmar nada de concreto.

Gabarito: letra D — a integração descendente (top-down) pode ser executada primeiro em largura ou primeiro em profundidade, conforme a ordem de integração dos módulos subordinados.