一、单元测试
桩模块
测试要求
在对软件单元进行动态测试之前,应对软件单元的源代码进行静态测试;
应建立测试软件单元的环境,如桩模块和驱动模块,其测试环境应通过评审;
对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试。
每个软件特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖
测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值;
语句覆盖率要达到100%;
分支覆盖率要达到100%;
对输出数据及其格式进行测试。
单元测试任务:
模块接口测试;
模块局部数据结构测试;
模块边界条件测试;
模块中所有独立执行路径测试;
模块的所有错误处理路径测试。
白盒测试用例设计:
逻辑覆盖法
基本路径法
黑盒测试:
测试目标与程序内部处理机制完全无关,而是重点集中于发现程序运行于其期望的输出结果不一致的情况。
静态测试与动态测试
静态分析:
**控制流分析:**是使用控制流程图系统地检查被测程序的控制结构的工作。控制流按照结构化程序规则和程序结构的基本要求进行程序结构检查。
**数据流分析:**是用控制流程图来分析数据发生的异常情况,这些异常包括被初始化、被赋值或被引用过程中行为序列的异常。数据流分析也作为数据流测试的预处理过程
编码规则分析
某些错误的出现与程序中表达式的计算相关。如果对表达式进行分析,就可以避免这些错误。
表达式中的错误常常由于不正确的使用括号造成。如果程序设计标准要求必须用括号括起来,则很多这样的错误就可以避免。
另一类错误出现在数组引用时,它包括数据下标越界。
对含有除式的代数式,必须检查其除数是否为零。
接口分析
程序的接口分析涉及子程序以及函数之间的接口一致性,包括检查形参与实参的类型、数量、维数、顺序以及使用的一致性。当子程序之间的数据或控制使用公共变量或全局变量时,也应检查它们的一致性。
扇入/扇出分析
扇出与程序的宽度有关,扇出过大增加过程或函数复杂性,扇出数最好控制在34,最高不要超过67。
扇入越大表明模块通用性好,但程序聚合性差。
底层过程或函数扇出尽量小,扇入尽量大。
上层过程或函数扇出尽量大,扇入尽量小。
动态测试
-
动态测试—功能测试
功能测试是对软件设计中的软件单元逐项进行的测试,以验证其功能是否满足要求。
功能测试一般需进行:
用正常值的等价类输入数据值测试;
用非正常值的等价类输入数据值测试;
进行每个功能的合法边界值和非法边界值输入的测试;
用一系列真实的数据类型和数据值运行,测试超负荷、饱和及其他“最坏情况”的结果。
- 动态测试—接口测试
接口测试是对软件设计文档中的外部/内部接口逐项进行的测试。接口测试一般需进行:
测试所有外部/内部接口,检查接口信息的格式和内容;
对每一个外部/内部输入/输出接口必须进行正常和异常情况的测试;
测试硬件提供的接口是否便于使用;
测试系统特性(如数据特性、错误特性、速度特性)对软件功能、性能特性的影响。
- 动态测试——边界测试
边界测试是对软件处在边界或端点情况下运行状态的测试。边界测试一般需进行:
软件的输入域或输出域的边界或端点的测试;
状态转换的边界或端点的测试;
功能界限的边界或端点的测试;
性能界限的边界或端点的测试;
容量界限的边界或端点的测试。
- 动态测试——逻辑测试
逻辑测试是测试程序逻辑结构的合理性、实现的正确性。逻辑测试应由测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
逻辑测试应满