文档介绍：单元测试规范
应用软件单元测试规范
目录
1 引言
编写目的
背景
定义
参考文档
2 单元测试
单元的定义
角色工作体系
单元测试规程
单元测试工具
测试的目录结构
测试代码的书写规范
测试单元的文件组成及命名规范
单元测试的实施
3 测试结果提交和验收
单元测试工作产品提交
单元测试工作产品验收规范
附录一:代码审查单
附录二:单元测试Bug 清单
附录三:驱动模块(类)模板
附录四:单元测试实例介绍
单元测试规范
编写目的
编写目的
本文档规定了应用软件系统和部分系统平台模块的单元测试方法和步骤、测试用例的设计方法、测试代码的书写规范、流程以及单元测试的产品提交和验收规范,目的在于控制单元测试的质量,加强项目的质量管理,从而提高整个产品的质量。
适用范围
主要是应用软件的单元测试、部分系统平台软件模块测试。
背景
XXXXXX 系统软件平台是项目的重要组成部分,主要是依托GUI 子系统、分析子系统和数据采集子系统的硬件环境,共同为高层的应用软件提供必要的软、硬件功能支持,并为应用软件开发人员提供必要的开发环境和测试环境。本规范的提出和制订旨在为本项目开发小组软件单元测试提供依据和支持。
定义
被测模块:需要进行模块级测试的应用软件系统的一个单元或模块,也称被测单元。
测试单元:用于对被测模块进行单元级测试,由源代码、测试脚本和输入数据等构成的程序单元。
参考文档
[1] CppUnit Documentation
[2] gprof homepage
[3] gcov homepage
[4] 应用软件编写规范
[5] DemoUnit 测试单元
[6] 单元测试培训材料
[7] 单元测试总结报告
2 单元测试
单元的定义
对于面向对象的编程语言,程序单元指特定的一个具体的类或相关的多个类。单元测试主要是指对类方法的测试。
单元测试规范
角色
职责
测试主管
审查单元测试过程,评估测试结果。根据测试发现的缺陷提出变更申请。
测试人员
检查单元代码,设计单元测试用例,加载运行测试用例,记录和分析测试结果,填写单元测试Bug 清单。
开发人员
设计测试需要的驱动程序和桩模块,以及辅助测试工具的开发。
配置管理员
管理测试需要的资源,包括软硬件环境,版本管理和Bug 管理。
单元测试规程
包括静态的代码审查和动态测试两个阶段。
代码审查是按照《代码审查单》中的条项对单元模块进行逐项检查,并填写《单元测试Bug 清单》。《代码审查单》的格式见附录一,《单元测试Bug 清单》见附录二。
动态测试阶段首先编写驱动模块(或主类)和桩模块后,在驱动模块和桩模块中设计相应的测试用例,对所有的测试用例进行统一编号,在源代码中进行注释标识。测试用例应该覆盖单元模块的所有功能项,如果单元模块有性能、余量等其它测试特性要求,则必须设计相应的测试用例测试这些特性,编制完测试用例后,把测试用例提交给配置管理员或测试主管进行审查,审查没有通过则根据审查意见进行修改,直到审查通过后测试人员加载测试用例,编译运行得到测试结果,比对测试结果,如果发现错误或Bug 则需要填写《单元测试Bug 清单》并提交给测试主管和配置管理人员。
在进行功能测试时,可以利用其它测试工具进行内存溢出分析、代码覆盖率分析、代码性能测试等。
代码审查
要求:根据《代码审查单》中的要求,对被测试单元进行逐项检查,检查后在对应的条项后进行标记,发现问题后,填写《代码单元测试Bug 清单》并提交。
测试用例
测试用例是测试数据以及与之相关的测试规程的一个特定的集合,它是为验证被测试程序(为测试路径或验证是否符合特定需求)而产生的。
测试用例设计用于白盒测试和黑盒测试。
白盒测试进入的前提条件是在测试人员已经对被测试对象有了一定的了解,基本上明确了被测试软件的逻辑结构。过程是通过针对程序逻辑结构设计和加载测试用例,驱动程序执行,
检查在不同点程序的状态,以确定实际的状态是否与预期的状态一致。
单元测试规范
白盒测试主要是对被测试对象进行如下测试项目:
1、对程序模块的所有独立的执行路径至少覆盖一次;
2、对所有的逻辑判定,真假两种情况都至少覆盖一次;
3、在循环