集成测试是软件测试生命周期中位于单元测试和系统测试之间的一个关键阶段。根据IEEE标准定义，集成测试是一种系统化的测试活动，其目标是将已经通过单元测试的独立软件模块按照设计要求逐步组装在一起，验证模块之间的接口、通信和数据交互是否符合设计规范，并发现与模块间交互相关的缺陷。与单元测试关注单个模块内部逻辑的正确性不同，集成测试的核心关注点是模块与模块之间的协作行为——每个模块在独立测试中都表现完美，组合在一起后仍可能出现接口不匹配、数据传递错误、时序不同步和资源竞争等诸多在单元测试层面无法暴露的问题。
集成测试的必要性源于软件系统的结构复杂性。现代软件系统通常由数十甚至数百个模块组成，模块之间存在调用关系、数据传递关系、同步关系和资源共享关系等多维度的交互。单元测试可以验证每个模块"独自做对事"，但无法验证多个模块"一起做对事"。集成测试正是填补这一验证空白的质量保障手段。在软考软件评测师和软件设计师科目中，集成测试策略的选择依据、不同策略的优缺点对比以及策略与项目特征的匹配关系，都是高频命题方向。
从测试的四个标准层次来看，单元测试处于最底层，验证单个函数或类的独立正确性；集成测试位于第二层，验证模块间接口和交互的正确性；系统测试处于第三层，验证整个系统是否满足规格说明书中定义的功能和非功能需求；验收测试处于最高层，验证系统是否满足用户的业务需求和期望。集成测试夹在单元测试和系统测试之间，承担着承上启下的桥梁作用——如果在集成测试阶段遗漏了接口缺陷，这些缺陷将在系统测试阶段以更隐蔽、更难定位的方式暴露出来，修复成本可能比在集成测试阶段发现高出数倍。这也是软件工程中"缺陷越早发现、修复成本越低"这一基本原则在测试策略设计中的具体体现。
集成测试策略根据模块组装的时序和范围可以划分为两大类：非增量式集成（即一次性集成）和增量式集成（包括自顶向下、自底向上和三明治集成等变体）。这两大类策略在缺陷定位效率、测试并行度和对驱动模块与桩模块的依赖程度上存在根本性的差异。
一次性集成策略，也称为大爆炸集成，其基本思路是：首先对系统中的每一个模块独立完成单元测试，然后将所有模块一次性组装在一起，对整个系统执行集成测试。这种策略表面上看似乎最高效——不需要编写额外的驱动模块和桩模块，也不需要分多轮迭代进行测试——但实际的工程风险很高。当一次性集成后发现测试失败时，缺陷的定位变得极其困难，因为任何两个模块之间的交互都可能是问题来源，调试人员在面对一个由全部模块组成的系统中排查缺陷就如同大海捞针。
一次性集成策略在软件工程历史上曾经是默认做法，但随着软件系统规模的增大和模块数量的增加，其缺陷定位效率低的短板越来越突出。当系统模块数量超过十个时，一次性集成后发生的任何一个测试失败都可能涉及数百种潜在的模块交互组合，调试成本将呈指数级上升。当前工业界仅在模块数量极少（最多不超过五个）、模块间耦合关系简单且开发团队对每个模块的内部实现都有充分把握的小型项目或原型验证场景中才会考虑一次性集成策略。软考命题在涉及集成策略选择时，通常会将一次性集成作为"非最佳实践"的干扰项出现。
自顶向下集成策略按照软件系统的层次结构，从最顶层的控制模块开始，沿着控制层次逐步向下集成。每一轮集成中，测试团队选择一个或多个下层模块，用实际开发完成的模块替换之前测试中使用的桩模块，然后执行集成测试验证新增的实际模块与已集成模块之间的交互是否正确。桩模块是在自顶向下集成中用来模拟尚未集成的下层模块行为的临时替代程序——它接收上层模块的调用请求，返回预定义的模拟数据，但不执行真实的业务逻辑。
自顶向下策略的核心优势在于早期验证系统的主控制流程和整体架构的合理性。因为顶层模块通常是系统的调度中心，最早被集成和测试，这意味着系统的核心控制逻辑可以在项目早期得到验证，降低后期架构重构的风险。但这种策略也存在一个显著劣势：底层模块直到测试后期才被集成，而底层模块往往承担着复杂的计算逻辑和高风险的算法实现，将高风险模块的集成推迟到后期可能导致项目后期才发现严重缺陷，修复成本高昂。
自底向上集成策略从层次结构的最底层模块开始，沿着调用关系自下而上逐步集成。每一轮测试中需要编写驱动模块来模拟上层模块对已集成下层模块的调用。驱动模块的作用是主动调用被测试的下层模块，传递测试输入参数，并接收返回结果进行验证，与桩模块的被动角色形成对称关系。
自底向上策略的核心优势在于关键算法和复杂业务逻辑可以在项目早期得到充分验证——因为这些通常位于系统的底层模块中。底层模块先集成、先测试、先稳定，上层模块的集成可以在一个已经稳定的底层基础之上进行，缺陷的逐层传播效应更可控。但自底向上策略也存在一个不可忽视的制约：系统的整体控制流程和用户可感知的功能要到项目后期才逐步呈现，管理层和用户在整个项目周期的大部分时间里都看不到一个可运行的软件雏形，这可能导致来自项目干系人的进度焦虑和信任压力。
三明治集成策略，也称为混合集成策略，是将自顶向下和自底向上两种策略的优点结合起来的一种折中方案。其基本思路是：将系统划分为三层——上层（用户界面和控制逻辑层）、中间层（业务逻辑和数据处理层）和底层（基础服务和数据访问层）。对上层模块采用自顶向下策略进行集成，对底层模块采用自底向上策略进行集成，两个方向同时推进，最终在中间层汇合。
三明治策略在实际工程中的最大优势在于并行度——上层团队和底层团队可以同时进行集成测试，大幅缩短整体集成周期。但这种策略对测试团队的组织协调能力要求较高：两个方向的集成进度需要保持大致同步，如果一端进度严重滞后，汇合点的测试就无法开展。此外，三明治策略要求中间层模块具有良好的内聚性和清晰的接口契约，否则上下两个方向集成到中间层时容易暴露出此前未被测试覆盖的接口不一致问题。
在实际软件工程项目中，集成策略的选择不是教条式地套用一种策略，而是需要根据项目的技术架构特征、团队组织结构、进度约束和风险偏好等因素综合决策。
系统的层次结构清晰度是首要考量因素。采用分层架构风格的系统天然适合增量式集成策略，因为模块之间的调用关系沿着严格的层次方向展开，自顶向下或自底向上都有明确的路径可循。而采用微内核架构或事件驱动架构的系统，模块之间是扁平化的对等通信关系而非层次调用关系，增量式集成的路径规划较为困难，可能更适合采用基于功能主题的渐进式集成——每次集成围绕一个完整的业务功能线，将与该功能相关的所有模块一次性组装。
项目的风险分布也影响集成策略的选择。如果系统的主要技术风险集中在上层的业务规则和用户交互逻辑，自顶向下策略可以在早期暴露这些高风险模块的问题。如果系统的主要技术风险集中在底层的算法精度和数据处理性能，自底向上策略更为合适。如果系统的风险在上下层均匀分布且工期紧张，三明治策略的并行优势将得到充分发挥。