软件测试规范(5)

　　在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：

　　误解或用错了算符优先级;

　　混合类型运算;

　　变数初值错;

　　精度不够;

　　表达式符号错。

　　比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：

　　不同数据类型的对象之间进行比较;

　　错误地使用逻辑运算符或优先级;

　　因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等;

　　比较运算或变量出错;

　　循环终止条件或不可能出现;

　　迭代发散时不能退出;

　　错误地修改了循环变量。

　　一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：

　　输出的出错信息难以理解;

　　记录的错误与实际遇到的错误不相符;

　　在程序自定义的出错处理段运行之前，系统已介入;

　　异常处理不当;

　　错误陈述中未能提供足够的定位出错信息。

　　边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。

　　单元测试过程

　　一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。

　　应为测试模块开发一个驱动模块(driver)和(或)若干个桩模块(stub),下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。

　　驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。

　　提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。

　　3.2 集成测试

　　在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑：

　　在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失;

　　一个模块的功能是否会对另一个模块的功能产生不利的影响;

　　各个子功能组合起来，能否达到预期要求的父功能;

　　全局数据结构是否有问题;

　　单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

　　单个模块的错误是否会导致数据库错误。

　　选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序、以及生成测试用例的费用和调试的费用。通常，把模块组装成为系统的方式有两种方式：

　　① 一次性集成方式

　　它是一种非增殖式集成方式。也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。

　　由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。

　　② 增殖式集成方式

　　又称渐增式集成方式。首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。

　　自顶向下的增殖方式：将模块按系统程序结构，沿控制层次自顶向下进行集成。由于这种增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序结构中，判断常出现在较高的层次，较早就能遇到。如果主要控制有问题，尽早发现它能够减少以后的返工。

原文转自：http://www.uml.org.cn/Test/201511262.asp