软件测试(第1章).ppt

检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误： 不合适或不相容的类型说明； 变量无初值； 变量初始化或缺省值有错； 不正确的变量名（拼错或不正确地截断）； 出现上溢、下溢或地址异常。 除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。 在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术，计算中常见的错误包括： 误解或用错了算符优先级； 混合类型运算； 变量初值错误； 精度不够； 表达式符号错误。 比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误： 不同数据类型的对象之间进行比较； 错误地使用逻辑运算符或其优先级； 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等的情况； 比较运算或变量出错； 循环终止条件有错或不可能出现； 迭代发散时不能退出； 错误地修改了循环变量。 一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试时应着重检查下列问题： 输出的出错信息难以理解； 记录的错误与实际遇到的错误不相符； 在程序自定义的出错处理段运行之前，系统已介入； 异常处理不当； 错误陈述中未能提供足够的出错定位信息。 边界条件测试是单元测试中最后，也是最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右来设计测试用例，很有可能发现新的错误。 单元测试的设计原则 测试设计遵循与软件设计相同的工程原则。好的软件设计包含几个对测试设计进行精心描述的阶段。这些阶段是： 测试策略 测试计划 测试描述 测试过程 上述四个测试设计阶段适用于从单元测试到系统测试各个层面的测试。 一个完整的单元测试说明应该包含正面的测试（Positive Testing）；负面的测试（Negative Testing）；正面测试验证程序应该执行的工作；以及负面测试验证程序不应该执行的工作。 单元测试的设计 一旦模块单元设计完毕，下一个开发阶段就是设计单元测试。值得注意的是，如果在书写代码之前设计测试，测试设计就会显得更加灵活。一旦代码完成，对软件的测试可能会倾向于测试该段代码在做什么（这根本不是真正的测试），而不是测试其应该做什么。 单元测试说明实际上由一系列单元测试用例组成，每个测试用例应该包含4个关键元素： 被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用间状态的情况）； 被测单元的输入，包含由被测单元读入的任何外部数据值； 该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如：单元中哪一个决策条件被测试； 测试用例的期望输出结果，测试用例的期望输出结果总是应该在测试进行之前在测试说明中定义。 测试用例设计步骤 测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。设计富有创造性的测试用例是测试设计的关键，其具体步骤可以概述为以下几个方面： 步骤1：首先使被测单元运行起来 步骤2：正面测试(Positive Testing) 步骤3：负面测试(Negative Testing) 步骤4：设计需求中其它测试特性用例设计 步骤5：覆盖率测试用例设计 步骤6：测试执行 步骤7：完善代码覆盖 面向对象的单元测试 面向对象测试的特点 对某软件的类测试相当于传统软件的单元测试。和传统软件的单元测试不同，他往往关注模块的算法细节和模块接口间流动的数据，类测试是由封装在类中的操作和类的状态行为所驱动的。因为属性和操作是被封装的，对类之外操作的测试通常是徒劳的。 封装使对对象的状态快照难于获得，继承也给测试带来了难度，即使是彻底复用的，对每个新的使用语境也需要重新测试。多重继承更增加了需要测试的语境的数量，使测试进一步复杂化。如果从超类导出的测试用例被用于相同的问题域，有可能对超类导出的测试用例集可以用于子类的测试，然而，如果子类被用于完全不同的语境，则超类的测试用例集将没有多大用途，必须设计新的测试用例集。 类的功能性测试 在类的生命周期中，类测试只是一个初始的测试阶段。类作为独立的成分可以多次在不同的应用系统中重复使用，这些成分的用户要求每个类是可靠的，并无需了解其实现细节，这样的类要尽可能