单元测试和集成测试
单元测试
检验程序最小单位有无错误,主要关注内部处理逻辑和数据结构
– 模块接口测试
– 独立路径测试
– 局部数据结构测试
– 错误处理测试
– 边界测试
单元测试过程
简单过程
- 实例化被测试对象
- 提供测试数据
- 调用被测试方法
- 验证测试结果
问题:
1)对象创建后未进行必要的初始化。可能内存访问异常,无法调用被测试的方法。
2)构造函数没有返回值,不知道如何验证结果。
优点
1)它是一种确认(Validation)行为
2)它是一种设计(Design)行为:先写单元测试明确接口
3)它是一种编写文档(Documentation)的行为:单元测试告诉我们模块该怎么调用
4)它具有回归性:一次写完后面可以反复执行
局限性
1)只验证单元自身的功能,不能捕获系统范围的错误
2)被测模块现实中可能接收的复杂或少见输入情况难以预料
单元测试工具–JUnit
一个类中可以写上任意多个测试,每个测试都可以单独像main()方法那样运行,还可以灵活组装成测试集批量运行
集成测试
又称组装测试、联合测试、子系统测试或部件测试。
在单元测试的基础上,将所有模块按照设计方案(如结构图)集成为子系统或系统,进行集成测试。
驱动模块与桩模块
模块之间存在调用关系,测试某一模块时,其下级模块和上级模块可能还未实现,需要其它模块来模拟
驱动模块
模拟待测模块的上级模块,将相关的数据传送给被测模块,启动被测模块,并获得相应的结果。
桩模块
模拟待测模块调用的模块,被待测模块调用,一般只进行很少的数据处理,用于检测接口的联通性。
非渐增式测试策略
先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序。
策略:大棒集成法
因为所有模块是一次集成的,所以很难确定出错的真正位置、错误的原因。适合在规模较小的应用系统中使用。
渐增式测试策略
把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试。
优点:相对非渐增式策略,可较早发现模块间的接口错误;发现问题也易于定位。
缺点:测试周期比较长,可以同时投入的人力物力受限。
方式:
- 自顶向下
- 深度或宽度优先
- 优点
- 不需要测试驱动程序
- 程序主体形成较早,较早实现并验证系统的主要功能
- 能在早期发现上层模块的接口错误
- 缺点
- 需要桩模块
- 要使桩模块能够模拟实际子模块的功能可能十分困难
- 复杂、容易出问题的模块一般在底层,到集成后期才遇到这些模块,一旦发现问题将导致过多的回归测试
- 这种方法在早期不能充分展开人力
- 自底向上
- 优点
- 不需要桩模块,建立驱动模块一般比建立桩模块容易
- 可以把最容易出问题的部分在早期解决
- 可以实施多个模块的并行测试,提高测试效率
- 缺点
- 主体较晚才形成,不能较早验证程序主要功能
- 优点
- 混合式集成(三明治集成方法)
- 优点
- 自顶向下+ 自底向上,桩、驱动开发工作量小
- 缺点
- 细致性不如自顶向下和自底向上
- 优点
几种集成方法比较
自底向上 | 自顶向下 | 大棒 | 三明治 | |
---|---|---|---|---|
集成 | 早 | 早 | 晚 | 早 |
基本程序能工作时间 | 晚 | 早 | 晚 | 早 |
需要驱动程序 | 是 | 否 | 是 | 是 |
需要桩程序 | 否 | 是 | 是 | 是 |
工作并行性 | 中 | 低 | 高 | 中 |
特殊路径测试 | 容易 | 难 | 容易 | 中等 |
计划与控制 | 容易 | 难 | r容易 | 难 |
与系统测试的差别
测试类型 | 对象 | 目的 | 测试依据 | 测试方法 | 输入输出边界 |
---|---|---|---|---|---|
单元测试 | 局部模块 | 消除局部模块内的逻辑和功能上的错误和缺陷 | 模块逻辑设计,外部说明 | 白盒为主 | 由程序给入 |
集成测试 | 模块间的集成调用关系 | 找出与设计相关的程序结构、模块调用关系、模块间接口方面的问题 | 结构设计 | 白盒+黑盒 | 由程序+设备给出 |
系统测试 | 整个系统(包括硬件等) | 对整个系统进行一系列的整体、有效性测试 | 系统结构设计、需求规格说明等 | 黑盒为主 | 由设备给入(键盘、鼠标等) |