自底向上集成测试从最底层的模块开始，将这些底层模块按功能或结构分组为“簇”（如簇 1、簇 2、簇 3）

1. 自底向上集成测试

   • 过程：
     自底向上集成测试从最底层的模块开始，将这些底层模块按功能或结构分组为“簇”（如簇 1、簇 2、簇 3）。每个簇通过一个驱动模块（D₁、D₂、D₃）来模拟上层调用，进行独立测试。当底层簇测试完成后，驱动模块被移除，这些已测试的簇逐步集成到它们的上层模块中（例如簇 1 和簇 2 集成到 Mₐ，簇 3 集成到 Mᵦ），最终所有模块逐层向上合并至顶层模块 Mₑ。
   • 特点：
     • 不需要桩模块（Stub），因为是从底层开始集成；
     • 对驱动模块的需求在初期较高，但随着集成向上推进而逐渐减少；
     • 可与自顶向下集成结合使用，形成混合集成策略，从而兼顾两者的优点，简化整体测试过程。

2. 回归测试

   • 作用：
     在软件集成新模块、修复缺陷或进行代码变更后，重新执行部分或全部已有测试用例，以确保原有功能未被破坏，即“变更不引入新错误”。
   • 执行方式：
     • 手动执行选定的测试用例子集；
     • 使用捕捉 / 回放工具（Capture/Playback Tools）自动记录用户操作并重放，提高效率和一致性，并便于前后结果对比。
   • 测试子集包含的三种典型用例类型（虽未图示，但通常包括）：
     1. 发现过缺陷的用例：历史上曾暴露错误的测试用例，可靠性高，优先回归；
     2. 核心功能用例：覆盖系统关键业务流程的测试用例，确保主路径正常；
     3. 高频使用场景用例：代表用户常用操作路径的测试用例，影响面广，需重点保障。

自顶向下集成测试与自底向上集成测试是两种典型的集成测试策略，它们在测试起点、依赖模块处理方式、所需辅助模块及优缺点方面存在显著区别：

1. 测试起点不同：

   • 自顶向下集成：从顶层主控模块（如主程序或用户界面）开始，逐步向下集成和测试下层被调用模块。
   • 自底向上集成：从最底层的模块（如工具类、基础服务）开始，分组测试后逐层向上集成到高层模块。

2. 使用的辅助模块不同：

   • 自顶向下：需要桩模块（Stub）来模拟尚未集成的下层模块功能，以便上层模块可以被测试。
   • 自底向上：需要驱动模块（Driver）来调用和测试底层模块，因为这些模块本身没有上层调用来触发执行。

3. 对关键功能验证的时机不同：

   • 自顶向下：能更早地验证系统的整体控制流程和主要逻辑路径，有利于尽早发现架构设计问题。
   • 自底向上：先验证底层数据处理和算法正确性，适合底层模块复杂、可靠性要求高的系统。

4. 适用场景差异：

   • 自顶向下：适用于输入处理复杂、控制逻辑集中的系统（如GUI应用），便于早期原型演示。
   • 自底向上：常用于嵌入式系统、编译器、操作系统等底层机制复杂的软件。

5. 集成过程中的驱动/桩需求变化趋势相反：

   • 自顶向下：初期大量使用桩模块，随着下层集成完成，桩逐渐被真实模块替代；
   • 自底向上：初期大量使用驱动模块，随着向上集成推进，驱动逐步被移除。

6. 发现问题的类型侧重不同：

   • 自顶向下更容易发现接口不匹配、控制流错误；
   • 自底向上更容易暴露数据流错误、计算精度等问题。

实际项目中常采用混合集成策略（如三明治集成），结合两者优势，提高测试效率和覆盖率。