模块(单元)测试
构建大型程序测试的第一个步骤:模块(单元)测试
桩模块(Stub)是指模拟被测试的模块所调用的模块,而不是软件产品的组成的部分。主模块作为驱动模块,与之直接相连的模块用桩模块代替。在集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块,以代替被测模块的接口,接受或传递被测模块的数据,这些专供测试用的“假”模块称为被测模块的桩模块。
测试用例设计
- 模块的规格说明
- 模块的源代码
使用一种或多种白盒测试方法分析模块的逻辑结构,然后使用黑盒测试方法对照模块的规格说明以补充测试用例。
增量测试
不同于独立地测试每个模块,增量测试首先将下一个要测试的模块组装到前面已经测试过的模块集合中去。
如果使用了增量测试,可以较早地发现模块中与不匹配接口、不正确假设相关的编程错误。如果使用了增量测试,调试会进行得容易一些,因为该错误很可能与最近添加的模块有关。
自顶向下的测试
自顶向下的测试是从程序的顶部或初始模块开始。
原则:
要成为合乎条件的下一个模块,至少一个该模块的从属模块(调用它的模块)事先经过了测试。
优点:
- 如果主要的缺陷发生在程序的顶层将非常有利
- 一且引入I/O功能,提交测试用例会更容易
- 早期的程序框架可以进行演示,并可激发积极性
缺点:
- 必须开发桩模块
- 桩模块要比最初表现的更复杂
- 在引入I/O功能之前,向桩模块中引人测试用例比较困难
- 创建测试环境可能很难,甚至无法实现
- 观察测试输出很困难
- 使人误解设计和测试可以交迭进行
- 会导致特定模块测试的完成延后
自底向上的测试
策略开始于程序中的终端模块(此类模块不再调用其他任何模块)。
原则:
要成为合乎条件的下一个模块,该模块所有的从属模块(它调用的模块)都已经事先经过了测试。
优点:
- 如果主要的缺陷发生在程序的底层将非常有利
- 测试环境比较容易建立
- 观察测试输出比较容易
缺点:
- 必须开发驱动模块
- 知道最后一个模块添加进去,程序才形成一个整体
执行测试
当测试用例造成模块输出的实际结果与预期结果不匹配的情况时,存在两个可能的解释:要么该模块存在错误,要么预期的结果不正确(测试用例不正确)。为了将这种混乱降低到最小程度,应在测试执行之前对测试用例集进行审核或检查(对测试用例进行测试)