3.3 单元测试
驱动模块（driver）。相当于被测模块的主程序，它接收测 试数据，把这些数据传给被测模块，最后输出实测结果。 桩模块（stub）。用以代替被测模块调用的子模块，桩模块 可以做少量的数据操作，不需要把子模块所有功能都带进来， 但不允许什么事情也不做。被测模块与被测模块相关的驱动 模块及桩模块共同构成了一个“测试环境”，如下图所示。
3.4 集成测试
1）一次性集成测试 一次性集成测试又称非增量式集成测试，先分别测试 每个模块，再把所有模块按设计要求一次全部组装起来所要 的系统，然后进行整体测试。
3.4 集成测试
在增量式集成测试模式中，程序一段一段地扩展，测试 的范围一步一步地增大，具体做法是把下一个要测试的模块 同已经测好的模块结合起来进行测试，测试完毕，再把下一 个应该测试的模块结合进来继续进行测试。在组装的过程中 边连接边测试，以发现连接过程中产生的错误。如果出现错 误，则错误发生在新加入的模块中。增量式集成测试有3种 方式： ①自顶向下增量测试方式（Top-down Integration） ②自底向上增量测试方式（Bottom-up Integration） ③混合增量测试方式（ModifiedTop-downIntegration）
3.4 集成测试
③混合增量测试方式（ModifiedTop-downIntegration） 与自顶向下增量的方式优缺点正好相反，自底向上集成 方法不用桩模块，测试用例的设计也相对简单，同时由于涉 及复杂算法和真正输入／输出的模块最先得到组装和测试， 可以把最容易出问题的部分在早期解决。此外自底向上增量 的方式可以实施多个模块的并行测试。但缺点是“程序一直 未能作为一个实体存在，直到最后一个模块加上去后才形成 一个实体”。
3.4 集成测试
在集成测试时需要考虑以下问题： 模块集成后，穿越模块接口的数据是否会丢失。 模块集成后，各模块的功能是否会相互抑制。 模块集成后的功能能否达到预期的要求。 各模块的接口是否一致、各模块间的数据流和控制流是否按 照设计实现其功能。 全局及局部数据的作用域是否存在问题,是否会被非法修改。 单个模块的误差通过累积是否会放大到不能接受的程度。 单个模块的错误是否会导致数据库错误。
3.1 软件测试过程
被测模块 单元 测试 设 计 信 息 软 件 需 求 系 统 其 它 元 素 系统 测试 已确认 的软件 基本可 交付的 软件 用 户 预 定 要 求 验收 测试
被测模块
单元 测试 基本可 交付的 软件
集成 测试 已集成 的软件
确认 测试
被测模块
单元 测试
3.2软件测试过程与软件开发的
3.2.3 测试在开发阶段的作用
3、详细设计和概要设计阶段 确保集成测试计划和单元测试计划完成。 测试计划后，会对参考的设计文档进行修改，也可能会修改 前一阶段的文档。 4、编码阶段 开发人员在编写代码的同时，还必须撰写自己负责部分的测 试代码。 在项目较大的情况下，必须由专人负责编写项目组各开发人 员都需要的测试代码。 5、测试阶段(单元测试、集成测试、系统测试) 测试工程师依据测试代码进行测试。 专人主持测试工作，并提交相应的测试状态报告和测试结果 报告。
第3章 软件测试过程与方法
3.1 3.2 3.3 3.4 3.5 3.6 3.7 软件测试过程 软件测试过程与软件开发的关系 单元测试 集成测试 确认测试 系统测试 验收测试

3.1 软件测试过程
软件测试从测试计划编写到测试实施，需要经过一 系列的过程。这些测试按软件从编写到交付的各个阶 段的先后顺序可分为：单元测试、集成测试、确认 （有效性）测试、系统测试和验收（用户）测试5个阶 段，如下图所示
3.3 单元测试
程序员编写代码时，一定会反复调试保证其能够 编译通过。如果是编译没有通过的代码，没有任何 人会愿意交付给自己的老板。但代码通过编译，只 是说明了它的语法正确，程序员却无法保证它的语 义也一定正确。没有任何人可以轻易承诺这段代码 的行为一定是正确的，单元测试这时会为此做出保 证。编写单元测试就是用来验证这段代码的行为是 否与软件开发人员期望的一致。
3.4 集成测试
有鉴于此，通常是把以上两种方式结合起来进行组装和测试： 改进的自顶向下增量测试：基本思想是强化对输入／输出模 块和引入新算法模块的测试，并自底向上组装成为功能相当 完整且相对独立的子系统，然后由主模块开始自顶向下进行 增量测试。 自底向上－自顶向下的增量测试（混和法）：首先对含读操 作的子系统自底向上直至根结点模块进行组装和测试，然后 对含写操作的子系统做自顶向下的组装与测试。 回归测试：这种方式采取自顶向下的方式测试被修改的模块 及其子模块，然后将这一部分视为子系统，再自底向上测试， 以检查该子系统与其上级模块的接口是否适配。
3.4 集成测试
4、集成测试的组织和实施 集成测试要完成程序的组装及测试，还要进行组装成的 功能模块的测试，因此必须精心计划，并与单元测试的完成 时间协调起来。在制订测试计划时，应考虑如下因素： 采用何种系统组装方法来进行组装测试。 组装测试过程中连接各个模块的顺序。 模块代码编制和测试进度是否与组装测试的顺序一致。 测试过程中是否需要专门的硬件设备。
3.4 集成测试
在实际测试中，应根据软件的特点和工程的进度，选用适当 的测试策略，混和使用两种策略，上层模块用自顶向下的方 法，下层模块用自底向上的方法从而形成改进的三明治方法。 而更重要的是采取持续集成的策略，软件开发中各个模块不 是同时完成，根据进度将完成的模块尽可能早地进行集成， 有助于尽早发现缺陷，避免集成阶段大量缺陷涌现。同时自 底向上集成时，先期完成的模块将是后期模块的桩程序，而 自顶向下集成时，先期完成的模块将是后期模块的驱动程序， 从而使后期模块的单元测试和集成测试出现了部分的交叉， 不仅节省了测试代码的编写，也有利于提高工作效率。
3.3 单元测试
2、单元测试的目标 单元测试的主要目标是确保各单元模块被正确的 编码。单元测试除了保证测试代码的功能性，还需 要保证代码在结构上具有可靠性和健全性，并且能 够在所有的条件下做出正确的响应。进行全面的单 元测试，可以减少应用级别所需的工作量，并且彻 底减少系统产生错误的可能性。
3.3 单元测试
单元测试的主要内容有：模块接口测试；局部数据结构测试； 独立路径测试；出错处理测试；边界条件测试。如下图所示， 这些测试都作用于模块，共同完成单元测试任务。
模块接口 出错处理
模块
独立路径 边界条件
3.3 单元测试
3、单元测试的步骤 通常单元测试在编码阶段进行。当源程序代码编制完成， 经过评审和验证，确认没有语法错误之后，就开始进行单元 测试的测试用例设计。利用设计文档，设计可以验证程序功 能、找出程序错误的多个测试用例。对于每一组输入，应有 预期的正确结果。 由于模块接口测试中的被测模块并不是一个独立的程序， 在考虑测试模块时，同时要考虑它和外界的联系，用一些辅 助模块去模拟与被测模块相关联的其他模块。这些辅助模块 可分为两种：
3.4 集成测试
3）一次性集成测试方式与增量式集成测试方式的比较 增量式集成方式需要编写的软件较多，工作量较大，花费的 时间较多，一次性集成方式的工作量较小。 增量式集成方式发现问题的时间比一次性集成方式早。 增量式集成方式比一次性集成方式更容易判断出问题的所在， 因为出现的问题往往和最后加进来的模块有关。 增量式集成方式测试得更为彻底。 使用一次性集成方式可以多个模块并行测试。
测试用例 驱动模块 测试结果
被测模块
桩模块
桩模块
桩模块
3.4 集成测试
1、集成测试的定义 集成测试（Integration Testing）是单元测试的扩展和 延伸，是为了测试程序模块之间接口的规范性、一致性等， 在测试时根据实际情况对程序模块采用适当的策略组装起来， 对系统的接口及集成后的功能进行正确校验。 通常经过单元测试后的模块能够单独工作，能够达到设 计要求，但在把模块集成后并不能保证各模块能够正常地协 同工作。程序在某些局部反映不出来的问题，在全局上很有 可能暴露出来，从而影响到软件功能的实现。因此，在各模 块完成单元测试的基础上，还应将模块按设计要求组装成起 来，针对程序整体结构进行集成测试。
3.4 集成测试
3、集成测试的模式 选择用何种方式把模块组装起来形成一个可运行的系统 是软件集成测试中的策略体现，其重要性是明显的，集成的 方式直接关系到模块测试用例的形式、所用测试工具的类型、 模块编号的次序和测试的次序、生成测试用例的费用和调试 的费用等，一般是根据软件的具体情况来决定采用哪种模式。 通常，把模块组装成为系统的测试方式有两种： 一次性集成测试 增量式集成测试方式
项目规划 产品发布
项目需求分析
测试需求分析 系统测试 系统测试计划
项目概要分析 集成测试计划 项目详细分析 单元测试计划 代码编号 测试代码编号
集成测试
单元测试
3.2.3 测试在开发阶段的作用
1、项目规划阶段 由专人负责从中单元测试到系统测试的整个测试阶段的监控。 2、需求分析阶段 确保测试需求分析、系统测试计划的制订，并经评审后成为 配置管理项。 测试需求分析对产品生命周期中测试所需要的资源、配置、 每阶段评判通过标志进行规约。 系统测试计划是依据软件的需求规格说明书，制订测试计划 和设计相应的测试用 例。 系统测试计划最大的好处是能够更进一步明确需求。 最大的困难是如何设计测试用例才能验证需求，测试用例的 预测结果是什么。
3.4 集成测试
①自顶向下增量测试方式（Top-down Integration） 自顶向下增量测试方式从主控模块开始，按照软件的控 制层次结构，以深度优先或广度优先的策略，逐步把各个模 块集成在一起。
3.4 集成测试
②自底向上增量测试方式（Bottom-up Integration） 自底向上增量测试是从软件结构最低层的模块开始向上 一层层地组装测试。