在模块中应对每一条独立执行路径进行测试,单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括:
误解或用错了算符优先级;
混合类型运算;
变数初值错;
精度不够;
表达式符号错。
比较判断与控制流常常紧密相关,测试用例还应致力于发现下列错误:
不同数据类型的对象之间进行比较;
错误地使用逻辑运算符或优先级;
因计算机表示的局限性,期望理论上相等而实际上不相等的两个量相等;
比较运算或变量出错;
循环终止条件或不可能出现;
迭代发散时不能退出;
错误地修改了循环变量。
一个好的设计应能预见各种出错条件,并预设各种出错处理通路,出错处理通路同样需要认真测试,测试应着重检查下列问题:
输出的出错信息难以理解;
记录的错误与实际遇到的错误不相符;
在程序自定义的出错处理段运行之前,系统已介入;
异常处理不当;
错误陈述中未能提供足够的定位出错信息。
边界条件测试是单元测试中最后,也是最重要的一项任务。众的周知,软件经常在边界上失效,采用边界值分析技术,针对边界值及其左、右设计测试用例,很有可能发现新的错误。
单元测试过程
一般认为单元测试应紧接在编码之后,当源程序编制完成并通过复审和编译检查,便可开始单元测试。测试用例的设计应与复审工作相结合,根据设计信息选取测试数据,将增大发现上述各类错误的可能性。在确定测试用例的同时,应给出期望结果。
应为测试模块开发一个驱动模块(driver)和(或)若干个桩模块(stub),下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”,它接收测试数据并将这些数据传递到被测试模块,被测试模块被调用后,“主程序”打印“进入-退出”消息。
驱动模块和桩模块是测试使用的软件,而不是软件产品的组成部分,但它需要一定的开发费用。若驱动和桩模块比较简单,实际开销相对低些。遗憾的是,仅用简单的驱动模块和桩模块不能完成某些模块的测试任务,这些模块的单元测试只能采用下面讨论的综合测试方法。
提高模块的内聚度可简化单元测试,如果每个模块只能完成一个,所需测试用例数目将显著减少,模块中的错误也更容易发现。
3.2 集成测试
在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。这时需要考虑:
在把各个模块连接起来的时侯,穿越模块接口的数据是否会丢失;
一个模块的功能是否会对另一个模块的功能产生不利的影响;
各个子功能组合起来,能否达到预期要求的父功能;
全局数据结构是否有问题;
单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。
单个模块的错误是否会导致数据库错误。
选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序、以及生成测试用例的费用和调试的费用。通常,把模块组装成为系统的方式有两种方式:
① 一次性集成方式
它是一种非增殖式集成方式。也叫做整体拼装。使用这种方式,首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。
由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题,所以一次试运行成功的可能性并不很大。
② 增殖式集成方式
又称渐增式集成方式。首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统,在组装的过程中边连接边测试,以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
自顶向下的增殖方式:将模块按系统程序结构,沿控制层次自顶向下进行集成。由于这种增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序结构中,判断常出现在较高的层次,较早就能遇到。如果主要控制有问题,尽早发现它能够减少以后的返工。
原文转自:http://www.uml.org.cn/Test/201511262.asp