6.1 集成测试概述
·集成测试也称作 组装测试 和 联合测试 ，是 单元测试 的逻辑扩展；
·定义：根据实际情况将程序模块采用适当的集成测试策略组装起来，对模块之间的接口以及集成后的功能等进行正确性检测的测试工作；
·其实就是经过单元测试后的模块合起来在进行测试。
·注意事项：模块必须先经过单元测试；
·实际操作中，单元测试会和集成测试并行工作。
6.1.1 集成测试过程
·完整的集成测试过程一般包括：计划、设计、开发、运行、分析、评估；
·计划：根据概要设计文档、软件项目计划时间表、需求规格说明书等制定集成测试计划；
·设计：概要设计是集成测试的主要依据；
·开发：
·运行：测试者运行测试用例和被测软件进行集成测试，须记录软件的运行时状态和运行结果，生成集成测试日志；
·分析和评估：测试者根据测试日志对测试结果进行分析和评估，用于检测软件中存在的问题。
6.1.2 集成测试缺陷类型
·程序模块虽可通过单元测试以验证独立工作的正确性，但并不能保证与其他模块连接后也能正常工作；
·接口缺陷：
·单元测试关注模块内部具体实现，往往会忽略模块间接口调用相关缺陷；
·例：软件包含程序模块A和B，其中A包含三个参数str1、str2、str3，功能是将str1中所包含的str2去除后保存到str3中。B在调用A时误将str1和str2的位置写反，导致处理结果不正确；
·数据丢失：
·各个模块需要协同操作，应按照一致的节奏发送、接受、处理数据，否则会导致数据阻塞、丢失；
·例：软件包含程序模块A和B，A负责发送数据，B负责接受、处理数据。当A发送数据速度远高于B处理数据的速度，可能会造成数据阻塞或丢失；
·误差放大：
·单个模块内可接受的误差在模块组装后被严重放大，超过系统可接受范围；
·例：软件包含程序模块A和B，A中包含的变量v的预期值x与实际值存在正误差Δx，B对v进行n次方运算；
·规格问题：
·不同程序模块可能采用了不一致的数据类型、数据单位等环境参数，在模块协同工作时可能存在规格问题；
·例：之前的成绩管理系统中，为了方便输入会用字符型，但是运算时需要的是数值型；
·并发问题：
·对于并发程序，各个模块的处理次序存在不确定性。集成测试时要求每个模块同时运行，若他们的运行次序考虑步骤，则容易出现同步错误、死锁等并发问题；
·例：学过的同步锁之类的问题。
6.2 集成测试分析
·进行集成测试的各个模块或组件应存在 相依性；
·相依性：模块与模块之间存在某种形式的联系或依赖；
·根据模块相依性是否显式可见，分为 显式相依性 和 隐式相依性：
·显式相依性：直接可见，如信息发送模块和信息接收模块；
·隐式相依性：不直接可见，如模块间的操作权限约束；
·根据模块相依性是否依赖模块内部的实现机制，分为 内在相依性 和 外在相依性：
·内在相依性：依赖于模块的实现机制，如继承关系；
·外在相依性：通过外部事物产生关联，如几个模块共用一个数据；
·常见的相依性：关联、聚集、消息、调用、全局变量、公共数据；
·要获取模块间的相依性：
①结构分析：明确系统的单元结构图 ---> 对系统各个组件、模块间的依赖关系进行分析 ---> 据此确定集成测试的粒度，即集成模块的大小；
②接口分析：
·确定系统、子系统的边界以及模块的边界；
·确定模块内部的接口；
·确定子系统内模块间接口；
·确定子系统间接口；
·确定系统与操作系统的接口；
·确定系统与硬件的接口；
·确定系统与第三方软件的接口；
③模块分析：
·确定本次需要集成的模块；
·确定这些模块间的关联；
·分析这些模块所需要的 驱动模块 和 测试桩模块 。
6.3 集成测试策略
6.3.1 一次性集成与增量式集成
·一次性集成：
·定义：软件中所有程序模块完成单元测试后，直接按照程序结构图组装起来，作为一个整体进行测试的过程；
·优点：
·集成次数少、测试工作量小；
·包含了软件的所有组件和功能，不再需要驱动模块和测试桩模块；
·缺点：
·延长了测试开始时间和错误发现时间，因为要等待所有程序模块完成单元测试；
·当测试检测到错误，难以定位缺陷位置；
·适用于：
·软件规模小且结构良好的软件系统；
·只做了少量修改的软件新版本；
·通过复用可信赖的构建构造的软件系统；
·增量式集成：
·定义：按照某种关系，先将一部分程序模块组装起来进行测试，然后逐步扩大集成的范围，直到最后所有程序模块组装起来进行测试的过程；
·优点：
·更早更充分地开展测试和发现错误；
·更容易定位缺陷位置；
·缺点：
·所需的时间和工作量大；
·需要编写驱动模块和测试桩模块；
·适用于：
·大规模、复杂地并发软件系统；
·增量式开发和框架式开发地软件系统。
6.3.2 自顶向下与自底向上集成
·这是两种典型地增量式集成方法；
·自顶向下集成：
·定义：依据程序结构图，从顶层开始由上到下逐步增加集成模块到集成测试地过程；
·步骤：
①以软件结构图的根节点作为起始结点，并根据软件的主控模块构建测试驱动模块；
②根据集成路径，选择添加一个或多个通过单元测试的同级或下级程序模块作为测试对象，并针对相关模块构建测试桩模块；
③针对测试对象开展测试，验证测试对象是否存在缺陷；
④重复②~③直至测试对象包含软件中的所有程序模块；
·优点：
·减轻了驱动模块开发的工作量；
·测试者可尽早了解系统的框架；
·可以自然做到逐步求精；
·若底层接口未定义或可能修改，则可以避免提交不稳定的接口；
·缺点：
·测试桩模块的开发代价较大；
·底层模块无法预料的条件要求会迫使上层模块的修改；
·底层模块的调用和测试不够充分；
·在输入/输出模块接入系统之前，生成测试数据有一定困难；
·测试桩模块不能自动生成数据，若模块间的数据流不能构成有向的非环状图，一些模块的测试数据难于生成；
·观察和解释测试输出比较困难；
·例：如下图，阴影为每一轮的集成结果
·自底向上集成:
·定义：依据程序结构图，从最底层开始由下到上逐步增加程序模块到集成测试的过程；
·步骤：
①以软件结构图的叶子节点作为起始结点，并针对起始结点构建驱动模块；
②根据集成路径，选择添加一个或多个通关单元测试的同级或上级程序模块作为测试对象，并针对对象构建驱动模块；
③针对测试对象开展测试，验证测试对象是否存在缺陷；
④重复②~③知道测试对象包含软件中所有程序模块；
·优点：
·底层叶节点的测试和集成可并行开展；
·底层模块的调用和测试较为充分；
·减轻了测试桩模块开发的工作量；
·测试者可以较好地锁定缺陷位置；
·由于驱动模块模拟了所有地调用参数，即使数据流并未构成有向的非环状图，生成测试数据也没有困难；
·适合于关键模块在结构图底部的情况；
·缺点：
·需要驱动模块；
·高层模块的可操纵性和互操作性测试不够充分；
·在某种开发模式（如XP开发模式）上并不适用；
·测试者不能尽早了解系统的框架；
·时序、资源竞争等问题只有到测试后期才能被发现；
·例：如下图，阴影为每一轮的集成结果
·为了避免自顶向下和自底向上集成测试各自的不足，并结合两者的优势，还可以针对软件系统同时开展自顶向下、自底向上集成测试工作，这种方式称为三明治集成。
6.3.3 基于调用图的集成
·定义：一种用于减少驱动模块和测试桩模块的集成策略；
·步骤：先构建程序调用图，识别各个模块间的程序调用关系；
·适用于：
·需要尽快验证一个可运行的调用或协作关系；
·被测系统已清楚定义了构件的调用和协作关系；
·主要包括 成对集成 和 相邻集成：
·成对集成：把程序调用图的结点对放在一起进行测试，也可理解为以程序调用图中的边为单位进行测试；
·相邻集成：以程序调用图的某个节点为中心，将所有调用该节点的上层节点和所有被该节点调用的下层节点放在一起进行测试。
6.3.4 其他集成测试策略
·核心系统先行集成；
·客户/服务器集成；
·持续集成；
·分层集成；
·基于功能的集成；
·基于进度的集成。