软件测试(4)——单元测试和集成测试

文章目录

  • 单元测试和集成测试
    • 单元测试
      • 单元测试过程
      • 优点
      • 局限性
      • 单元测试工具--JUnit
    • 集成测试
      • 驱动模块与桩模块
      • 非渐增式测试策略
      • 渐增式测试策略
      • 几种集成方法比较
    • 与系统测试的差别

单元测试和集成测试

单元测试

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

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

单元测试过程

简单过程

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

问题:

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

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

优点

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

局限性

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

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

单元测试工具–JUnit

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

集成测试

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

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

驱动模块与桩模块

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

驱动模块

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

桩模块

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

非渐增式测试策略

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

策略:大棒集成法

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

渐增式测试策略

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

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

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

方式:

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

几种集成方法比较

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

与系统测试的差别

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

你可能感兴趣的:(软件测试)