8 模块(单元)测试

自底向上
5.4 执行测试
审核测试用例 当测试用例造成模块输出的实际结果与预期结果不匹配 的情况时，存在两种可能：该模块存在错误，或者测试 用例不正确。因此，执行测试前应审核测试用例集。 使用自动化测试工具可以减少测试过程中的劳动，如流程分 析工具等。 执行测试时，应该查找程序的副作用，即模块是否执行了不 该执行的操作。 程序员不应测试自己编写的模块，最好交换测试；编写调用 模块的程序员是测试被调模块的最佳人选。 模块测试的目的不是证明模块能够正确地运行，而是证明模 块中存在着错误。
非增量测试和增量测试
增量测试
工作量小：使用前面测试过的模块来取 代非增量测试中所需要的驱动模块或桩 模块。 可以较早发现模块中与不匹配接口、不 正确假设等编程错误。 容易进行调试，新出现的错误往往与最 近添加的模块有关 测试可以进行地更彻底，每个模块经受 了更多的检验 在测试上花费的时间多，设计驱动模块 和桩模块所用时间少 并行性差
集成测试往往不作为一个独立的测试步骤，尤其对增量 式模块测试而言，它是其中的隐含部分。 集成测试人员应包括具有两种背景的人员：熟知模块的 内部细节，并能从足够高的层次上观察整个系统
集成测试的内容
单元间的接口测试 全局数据结构测试 边界和人为条件下的性能 软件功能模块的功能测试
自顶向下
必须开发桩模块 桩模块可能要比最初表现的更复杂 缺点 创建测试环境可能很难，甚至无法实现 观测测试输出比较困难 如果主要的缺陷发生在程序的底层将非常有利 提早发现程序当中的主要算法问题 优点 测试环境比较容易建立 观测测试输出比较容易 必须开发驱动模块 缺点 直到最后一个模块添加进去，程序才形成一个整体
5.1 测试用例的设计
需要的信息
模块的规格说明：模块的输入和输出以及模块的功能 模块的源代码
测试用例的设计方法
单元测试总体上是面向白盒测试的（静态、动态）
后续测试针对较大的元素不易进行白盒测试 后续测试着眼于发现其他类型的错误，不一定 与程序逻辑结构有关
使用一种或多种白盒测试方法分析模块的逻辑结构，然后 使用黑盒测试方法对照模块的规格说明补充测试用例
5.2 增量测试
测试单独的模块可能需要一个特殊的驱动 模块和一个或多个桩模块 驱动模块是为测试编写的一个小模块， 用来将测试用例驱动或传输数据到被测 模块。驱动模块还需要向测试人员显示 被测模块的结果。 桩模块充当被测模块调用的模块，模拟 该模块的功能，接受被测模块的调用指 令。 例如测试模块B时需要一个驱动模块， 和一个模拟模块E的桩模块
stubH
I
J
自顶向下的增量测试中的桩模块
A
B
C
D
显示跟踪信息
显示传递信息
返回一个值
根据输入返回 一个值
自底向上的增量测试
第一步是测试E,J,G, K,L 和I中的部分或全部模块， 既可以串行也可以并行进 行；需要设计驱动模块， 有的驱动模块可以供几个 测试模块使用 接着测试的模块序列有多 种可能，如果接下来是测 试较关键的模块F,H，则 用它们代替相应的驱动模 块，并加入它们的驱动模 块，如图
模块（单元）测试
测试单个子程序或过程
单元测试
单元测试（模块测试）的元素
对程序中较小构成元素——（面向过程）单个子程序 或过程进行测试/（面向对象）类或方法（通常为类）
动机
单元测试减轻了调试的难度，因为错误一旦发现，就 知道它在哪个具体的模块中（例如malloc失败） 单元测试提供了同时测试多个模块的可能，将并行工 程引入了软件测试。
5.3 自顶向下测试与自底向上测试
自顶向下测试
从程序的顶部或初始模块开始测试。选择后续模块进行 增量测试的原则是：至少一个调用该模块的模块事先经 过了测试。有多种可能的测试序列时，应该考虑先测试 关键模块和I/O模块 为了测试上层模块，需要设计桩模块，桩模块通常要向 被测模块提供测试数据，如读取外部数据文件
自底向上测试
从不调用其他模块的终端模块开始测试，选择下一个模 块进行增量测试的原则是：该模块调用的所有的模块都 已经事先经过了测试。 为了测试低层模块，需要为它们设计驱动模块：即包含 着有效的测试输入、调用被测模块且显示输出的模块。
例子
A
B
C
D
图中共有12个模块A 到L 模块I包含IO的写操作 模块J包含IO的读操作
Driver
Driver
Driver D
Driver F
Driver H
I
J
K
L
自底向上的增量测试中的驱动模块
A B C D
调用从属模块
调用从属模块， 并传递参数
调用从属模块， 并要求得到参 数
兼有B,C的功 能
自顶向下测试和自底向上测试的比较
如果主要缺陷发生在程序顶层将非常有利 优点 早期程序框架可以进行演示，即提早发现主要的控 制问题
I
E
F
G
H
J
K
L
自顶向下的增量测试
首先测试模块A， 需要设计代表模块 B,C,D的桩模块； 如图 接着用实际模块代 替桩模块，如B， 并添加B的桩模块； 如图 stubE 增量的序列有多种 可能，例如： ABFJDICGEKHL， 加入I后如图
A
B stubB
stubC
D stubD
F stubF
A
B
C
D
E
ห้องสมุดไป่ตู้
F
5.2 增量测试
单元测试除了要考虑如何设计一个有效的测试用例 集之外，还有一个重要问题，就是模块组装方式 两类测试方法
非增量测试：先独立地测试每个模块，然后再将所 有这些模块组装成完整的程序测试，又称为崩溃 （big-bang）测试。 big-bang 增量测试：将被测模块组装到测试完成的模块集合 中，然后再进行测试。 注：在进行增量模块测试时，单元测试和集成是同 步进行的，集成测试就是模块测试的隐含部分，往 往并不作为一个独立的测试步骤。
目的
将模块的功能与定义模块的功能规格说明或接口规格 说明进行比较，揭示出模块与其规格说明之间存在的 矛盾。
单元测试针对的问题
模块接口：检查进出单元的数据流是否正确 局部数据结构：测试内部数据是否完整？例如：不 正确的类型说明，错误的初始化等。 路径测试：发现由于不正确的判定或不正常的控制 流而产生的错误，例如：不正确的逻辑操作或优先 级，不适当地修改循环变量。 边界条件：测试边界处程序是否正确工作？ 出错处理：测试出错处理措施是否有效？例如：提 供的错误信息不足，难以找到错误原因等。
单元测试的通过准则
命名符合规则 控制流程正确； 变量存取无误差； 所有软件单元达到质量度量指标； 功能与设计说明一致； 性能达到软件设计指标； 覆盖测试达到规定的覆盖率； 对发现的问题已进行修改并通过回归测试。
单元测试与集成测试
每个模块完成单元测试后，需要按照结构图把它们 连接起来，进行集成测试。
非增量测试
工作量较大：要设计驱动模块和桩模 块 到了测试过程的最后阶段，模块之间 才能“互相看到” 直到整个程序组装之后，模块之间接 口相关的错误才会浮现，难以定位 使用驱动模块和桩模块而非实际模块， 对被测试模块的测试只影响自身 测试时间少，但设计驱动模块和桩模 块需要大量时间 可以同时并行测试很多模块