自顶向下集成测试是一种从主控模块（顶层模块）开始，逐步向下集成子模块的测试策略。在该方法中，主控模块首先作为驱动模块进行测试，而其下层尚未实现的子模块则用桩模块（Stub）代替。随着集成的推进，按照深度优先或广度优先的方式，逐步用实际模块替换对应的桩模块，并持续进行测试和回归测试，以确保接口正确性和功能稳定性。

• 深度优先集成路径：例如 M₁ → M₂ → M₅ → M₈，先完成一条分支的所有层级集成，再转向其他分支。
• 广度优先集成路径：例如先集成第一层 M₂、M₃、M₄，再集成第二层 M₅、M₆、M₇、M₈ 等。

优点是能较早验证主要控制流程；缺点是底层模块测试较晚，且需要大量桩模块。

自底向上集成测试则从最底层的模块（如工具类、原子操作模块）开始，这些模块通常不依赖其他子模块。将它们组合成功能簇后，通过编写驱动模块来模拟上层调用，进行测试。由于无需桩模块（因为被调用的下层已存在），减少了桩的开发开销。

优点是底层模块得到充分验证，测试环境更接近真实运行状态；缺点是主控逻辑直到最后才集成，高层逻辑错误发现较晚。

两种策略可根据项目特点结合使用，形成“混合集成”策略，兼顾早期验证与底层可靠性。

自顶向下集成测试适用于控制结构复杂、高层模块主导逻辑决策的软件系统架构，例如传统的瀑布模型系统、分层架构或主控型应用（如命令解释器、GUI 主控制器等）。这类系统强调从主模块逐级调用子模块，早期验证主流程有助于尽早发现控制流和接口设计问题。由于使用桩模块替代未实现的下层模块，适合在底层模块尚未完成时就开始测试。

而自底向上集成测试更适合底层功能模块稳定、复用性强、数据处理密集型的系统，如嵌入式系统、编译器、操作系统内核或工具库等。这些系统的底层模块（如文件读写、内存管理、数学计算）通常先于上层开发完成，且被多个上层模块调用。从底层开始集成可以确保基础服务的可靠性，并避免桩模块的开销，但要求上层驱动模块能有效模拟调用环境。

因此，选择策略应基于系统架构的控制流向、模块依赖关系以及开发进度安排：若顶层设计优先且需早期验证控制逻辑，选自顶向下；若底层模块独立性强且已完成，则宜采用自底向上。