软件测试（4）——单元测试和集成测试

单元测试和集成测试

单元测试

检验程序最小单位有无错误，主要关注内部处理逻辑和数据结构

– 模块接口测试
– 独立路径测试
– 局部数据结构测试
– 错误处理测试
– 边界测试

单元测试过程

简单过程

1. 实例化被测试对象
2. 提供测试数据
3. 调用被测试方法
4. 验证测试结果

问题：

1）对象创建后未进行必要的初始化。可能内存访问异常，无法调用被测试的方法。

2）构造函数没有返回值，不知道如何验证结果。

优点

1）它是一种确认(Validation)行为
2）它是一种设计(Design)行为：先写单元测试明确接口
3）它是一种编写文档(Documentation)的行为：单元测试告诉我们模块该怎么调用
4）它具有回归性：一次写完后面可以反复执行

局限性

1）只验证单元自身的功能，不能捕获系统范围的错误

2）被测模块现实中可能接收的复杂或少见输入情况难以预料

单元测试工具–JUnit

一个类中可以写上任意多个测试，每个测试都可以单独像main()方法那样运行，还可以灵活组装成测试集批量运行

集成测试

又称组装测试、联合测试、子系统测试或部件测试。

在单元测试的基础上，将所有模块按照设计方案（如结构图）集成为子系统或系统，进行集成测试。

驱动模块与桩模块

模块之间存在调用关系，测试某一模块时，其下级模块和上级模块可能还未实现，需要其它模块来模拟

驱动模块

模拟待测模块的上级模块，将相关的数据传送给被测模块，启动被测模块，并获得相应的结果。

桩模块

模拟待测模块调用的模块，被待测模块调用，一般只进行很少的数据处理，用于检测接口的联通性。

非渐增式测试策略

先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。

策略：大棒集成法

因为所有模块是一次集成的，所以很难确定出错的真正位置、错误的原因。适合在规模较小的应用系统中使用。

渐增式测试策略

把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

优点：相对非渐增式策略，可较早发现模块间的接口错误；发现问题也易于定位。

缺点：测试周期比较长，可以同时投入的人力物力受限。

方式：

• 自顶向下
  • 深度或宽度优先
  • 优点
    • 不需要测试驱动程序
    • 程序主体形成较早，较早实现并验证系统的主要功能
    • 能在早期发现上层模块的接口错误
  • 缺点
    • 需要桩模块
    • 要使桩模块能够模拟实际子模块的功能可能十分困难
    • 复杂、容易出问题的模块一般在底层，到集成后期才遇到这些模块，一旦发现问题将导致过多的回归测试
    • 这种方法在早期不能充分展开人力
• 自底向上
  • 优点
    • 不需要桩模块，建立驱动模块一般比建立桩模块容易
    • 可以把最容易出问题的部分在早期解决
    • 可以实施多个模块的并行测试，提高测试效率
  • 缺点
    • 主体较晚才形成，不能较早验证程序主要功能
• 混合式集成（三明治集成方法）
  • 优点
    • 自顶向下+ 自底向上，桩、驱动开发工作量小
  • 缺点
    • 细致性不如自顶向下和自底向上

几种集成方法比较

	自底向上	自顶向下	大棒	三明治
集成	早	早	晚	早
基本程序能工作时间	晚	早	晚	早
需要驱动程序	是	否	是	是
需要桩程序	否	是	是	是
工作并行性	中	低	高	中
特殊路径测试	容易	难	容易	中等
计划与控制	容易	难	r容易	难

与系统测试的差别

测试类型	对象	目的	测试依据	测试方法	输入输出边界
单元测试	局部模块	消除局部模块内的逻辑和功能上的错误和缺陷	模块逻辑设计，外部说明	白盒为主	由程序给入
集成测试	模块间的集成调用关系	找出与设计相关的程序结构、模块调用关系、模块间接口方面的问题	结构设计	白盒+黑盒	由程序+设备给出
系统测试	整个系统（包括硬件等）	对整个系统进行一系列的整体、有效性测试	系统结构设计、需求规格说明等	黑盒为主	由设备给入（键盘、鼠标等）