单元测试书写规范
第一章 总则
第一条 本文档规定了应用软件系统和部分系统平台模块的单元测试方法和步骤、测试用例的设计方法、
测 试代码的书写规范、流程以及单元测试的产品提交和验收规范，目的在于控制单元测试的质量，加强项 目的质量管理，从而提高整个产品的质量。
第二条 主要是应用软件的单元测试、部分系统平台软件模块测试
第三条 本文档的预期读者为项目的项目经理、产品经理、系统软件主研人员、应用软件主研人员、高级
测 试人员等。
1. XXXXXX 系统软件平台是项目的重要组成部分，主要是依托 GUI 子系统、分析子系统和数据采集子
系统的硬件环境，共同为高层的应用软件提供必要的软、硬件功能支持，并为应用软件开发人员提供必 要的开发环境和测试环境。本规范的提出和制订旨在为软件单元测试提供依据和支持。
2. 被测模块：需要进行模块级测试的应用软件系统的一个单元或模块，也称被测单元 测试单元：用
于对被测模块进行单元级测试，由源代码、测试脚本和输入数据等构成的程序单元
第二章 单元测试
第四条 对于结构化的编程语言，程序单元指程序中定义的函数或子程序。单元测试是指对函数或子程序所 进
行的测试。对于面向对象的编程语言，程序单元指特定的一个具体的类或相关的多个类。单元测试主要是指对 类方法的测试。
第五条 角色工作体系
角色 测试主管 测试工程师 开发工程师 配置管理员 职责 审查单元测试过程，对测试结果进行评估。根据单元测试发现的缺陷提出变更申请。 对单元代码进行检查，设计单元测试用例，加载运行测试用例，记录和分析测试结果， 填写单元测试 Bug 清单。 设计测试需要的驱动程序和桩模块，以及辅助测试工具的开发。 管理测试需要的资源，包括软硬件环境，版本管理和 Bug 管理。
第六条 单元测试规程
包括静态的代码审查和动态测试两个阶段。 代码审查是按照《代码审查单》中的条项对单元模块进行逐项检查，并填写《单元测试 Bug 清单》。
《代码审查单》的格式见附录一，《单元测试 Bug 清单》见附录二。 动态测试阶段首先编写驱动模块（或主类）和桩模块后，在驱动模块和桩模块中设计相应的测试用
例，对所有的测试用例进行统一编号，在源代码中进行注释标识。测试用例应该覆盖单元模块的所有功 能项，如果单元模块有性能、余量等其它测试特性要求，则必须设计相应的测试用例测试这些特性，编 制完测试用例后，把测试用例提交给配置管理员或测试主管进行审查，审查没有通过则根据审查意见进 行修改，直到审查通过后测试人员加载测试用例，编译运行得到测试结果，比对测试结果，如果发现错 误或 Bug 则需要填写《单元测试 Bug 清单》并提交给测试经理和配置管理人员。在进行功能测试时，可以利用其它测试工具进行内存溢出分析、代码覆盖率分析、代码性能测试等.
第七条 代码审查
要求：根据《代码审查单》中的要求，对被测试单元进行逐项检查，检查后在对应的条项后进行 标记，发现问题后，填写《代码单元测试 Bug 清单》并提交。 第八条 测试用例
测试用例是测试数据及与之相关的测试规程的一个特定的集合，它是为验证被测试程序（为测试路 径或
验证是否符合特定需求）而产生的。 测试用例设计用于白盒测试和黑盒测试。
白盒测试进入的前提条件是在测试人员已经对被测试对象有了一定的了解，基本上明确了被测试软 件的逻辑结构。过程是通过针对程序逻辑结构设计和加载测试用例，驱动程序执行，检查在不同点程序 的状态，以确定实际的状态是否与预期的状态一致。
白盒测试主要是对被测试对象进行如下测试项目： 1、 对程序模块的所有独立的执行路径至少覆盖一次; 2、 对所有的逻辑判定，真假两种情况都至少覆盖一次; 3、 在循环的边界和运行界限内执行循环体; 4、 测试内部数据结构的有效性等。
白盒测试达到的目标：语句覆盖率达到 100%，分支覆盖率达到 100%，覆盖程序中主要的路径，主 要路径是指完成需求和设计功能的代码所在的路径和程序异常处理执行到的路径。
黑盒测试是要首先了解软件产品具备的功能和性能等需求，再根据需求设计一批测试用例以验证程 序内部活动是否符合设计要求的活动。
黑盒测试主要是对被测试对象进行如下测试项目： 1、 测试程序单元的功能是否实现；
2、 测试程序单元性能是否满足要求（可选）；
3、 可选的其它测试特性，如边界、余量、安全性、可靠性、强度测试、人机交互界面测试等。 黑盒测
试达到的目标：程序单元正确地实现了需求和设计上要求的功能，满足性能要求，同时程序 单元要有可靠性和安全性。 第九条 单元测试工具
项目规定使用以下测试工具实现应用软件系统单元测试和子系统集成测试，以及部分系统平台软件 模块的相关测试。
?CppUnit：正确性测试和功能测试 ?ccmalloc：动态内存访问检查 ?gcov：代码覆盖率分析 ?gprof：代码性能分析 第十条 测试的目录结构
建议将模块单元的测试代码组织在一个单独的目录中，作为模块单元源代码目录的一个子目录，取 名为 TestDemo。在测试代码目录下分布创建 5 个子目录分别对应 PC Linux、PXA250 评估板、IXP425 评估板、PXA255 目标板、IXP425 目标板的测试目录，用于构建、执行单元测试、管理测试日志和测试 报告。 第十一条 测试代码的书写规范
其规范见附录三。
第十二条 测试单元的文件组成及命名规范
每个测试单元由测试代码文件、程序主函数文件和编译运行脚本文件组成，单元测试完成之后还生 成一系列测试报告，这些测试报告将与模块单元一起提交。
为了便于管理，对组成测试单元的各个文件及测试生成的测试结果和测试报告文件的命名都从被测 类/模块派生而来。假定被测类为 DemoClass，测试单元包含如下文件及其所处目录位置如下所述： 1) 测试单元文件 TestDemo/DemoClassTest.h：测试类头文件 TestDemo/DemoClassTest.cpp：测试类实现文件 TestDemo/DemoUnitMain.cpp：测试类主函数
TestDemo/$(运行平台)/Makefile：用于特定运行平台的 makefile 文件 TestDemo/$(运行平台)/DemoTestDemo：为特定运行平台生成的可执行程序
其中运行平台为：PC Linux、PXA250 评估板、PXA255 目标板、IXP425 评估板、IXP425 目标板 5 种。 2) 测试结果文件
TestDemo/$(运行平台)/DemoUnit-O0.log：采用-O0 编译的正确性测试结果文件 TestDemo/$(运行平台)/DemoUnit-O2.log：采用-O2 编译的正确性测试结果文件 TestDemo/$(运行平台)/DemoUnit-O3.log：采用-O3 编译的正确性测试结果文件 TestDemo/$(运行平台)/DemoUnit.ccmalloc：内存检查结果文件 TestDemo/$(运行平台)/DemoClass.gcov：DemoClass.cpp 的代码覆盖率结果文件 TestDemo/$(运行平台)/DemoUnit.gprof：DemoUnit 被测单元的代码性能分析结果文件
其中运行平台为：PC Linux、PXA250 评估板、PXA255 目标板、IXP425 评估板、IXP425 目标板 第十三条 单元测试的实施
按照单元测试规程进行实施，进行代码审查和动态测试。
1) 单元测试或集成测试涉及的源程序三种：被测类/被测单元、已通过的类/桩模块、测试单元。 只需对被测类进行测试设计、进行代码覆盖率分析和代码性能分析，用多种优化编译选项进行 编译和测试； 2) 不需为已通过的类/桩模块进行测试设计，这些模块单元和测试单元本身都进行代码不需要使用 ccmalloc、gcov 和 gprof 等工具要求的编译选项和编译优化选项进行编译，也不需要为其生 成.gcov 代码覆盖率报告。
3) 对于各种运行平台下，都需要使用-O0, -O2, -O3 三种编译优化选项对测试单元进行编译，并 运行一个测试单元中的所有测试用例，生成测试报告 第十四条 单元模块正确性测试
进行单元正确性测试的过程是将被测单元源程序、测试单元源程序和测试主函数程序放到一起编译 产生可执行程序，并在目标平台上运行可执行程序，即可获得测试结果报告。对应上述的 DemoClass 被测类的正确性测试过程的命令序列为：
$(CC) $(OPT) -c DemoClass.cpp $(CC) -c DemoClassTest.cpp $(CC) -c DemoUnitMain.cpp
$(CC) -o DemoTestDemo DemoClass.o DemoClassTest.o DemoUnitMain.o -lstdc++ -lcppunit ./DemoTestDemo
;运行测试
;编译被测类
./DemoTestDemo DemoUnit$(OPT).log ;生成单元测试结果文件，该文件随模块一起提交 其中，变量 CC 为 C/C++编译器，如 gcc/g++；$(OPT)为编译优化选项。
项目要求每个被测模块在用-O0, -O2 和-O3 三种编译选项进行编译，并分别进行正确性测试。 第十五条 单元内存溢出检查
项目要求用 ccmalloc 内存检查工具对被测单元进行内存溢出检查，测试过程与正确性测试相似， 只是要求被
测单元代码的编译和最后的连接命令前添加 ccmalloc 命令，如下命令序列所示： ccmalloc $(CC) $(OPT) -c DemoClass.cpp $(CC) -c DemoClassTest.cpp $(CC) -c DemoUnitMain.cpp
ccmalloc $(CC) -o DemoTestDemo DemoClass.o DemoClassTest.o DemoUnitMain.o -lstdc++ -lcppunit
./DemoTestDemo
;运行测试，产生内存检查结果显示于屏幕
./DemoTestDemo 2> DemoUnit.ccmalloc ; 运行测试，产生内存检查结果文件用于提交 第十六条 测试代码覆盖率分析
项目要求用 gcov 工具对测试单元的代码覆盖率进行分析，测试单元的代码覆盖率分析的命令序列 如下所示： $(CC) $(OPT) -c -g -fprofile-arcs -ftest-coverage DemoClass.cpp -fprofile-arcs
;对被测代码使用-g -ftest-coverage 等编译选项
$(CC) -c DemoClassTest.cpp $(CC) -c DemoUnitMain.cpp
$(CC) -o DemoTestDemo DemoClass.o DemoClassTest.o DemoUnitMain.o -lstdc++ -lcppunit ./DemoTestDemo
;运行测试
gcov DemoClass.cpp > DemoClass.gcov.sum ;对每个被测源程序生成 2 个覆盖率结果文件 ; DemoClasscpp.gcov 和 DemoClass.gcov.sum
;前者包含源代码每条语句的执行计数， ;后者包含一个该文件覆盖率统计
cat DemoClass.gcov.sum DemoClass.cpp > DemoClass.gcov ;合并以上两个代码覆盖率文件， ;最后提交合并后的文件 第十七条 模块单元代码性能分析
项目还要求用 gcov 工具对测试单元的代码性能进行分析，测试单元的代码性能分析的命令序列如 下所示：
$(CC) $(OPT) -c -g -pg DemoClass.cpp ;对被测类使用-g -pg 等编译选项 $(CC) -c DemoClassTest.cpp $(CC) -c DemoUnitMain.cpp
$(CC) -pg -o DemoTestDemo DemoClass.o DemoClassTest.o DemoUnitMain.o -lstdc++ -lcppunit ./DemoTestDemo
;运行测试
;产生性能分析结果文件
gprof -pg DemoTestDemo >DemoUnit.prof
第三章 测试结果提交和验收
第十八条 单元测试工作产品提交
项目要求随模块提交 2.8 列出的 5 种测试单元文件和 6 种测试结果和测试报告文件，而每增加一种 被测类，提交时要求增加相应的测试类文件和代码覆盖率报告文件。
1 对于每个被测类的测试文档产品 测试类头.h 文件 测试类实现.cpp 文件
PC Linux 平台和 2 个 XScale 平台（2 个 PXA25X 平台或 2 种 IXP425 平台）下的代码覆盖率.gcov 文件
2 对于每个测试单元的测试文档产品 测试类主函数.cpp 文件
3 对于每种运行平台的测试文档产品
对于每个测试单元需要提在 PC Linux 平台和 2 个 XScale 平台（2 个 PXA25X 平台或 2
单元测试规范文档
