搜索
单元测试书写规范第一章总则第一条本文档规定了应用软件系统和部分系统平台模块的单元测试方法和步骤、测试用例的设计方法、测试代码的书写规范、流程以及单元测试的产品提交和验收规范，目的在于控制单元测试的质量，加强项目的质量管理，从而提高整个产品的质量。第二条主要是应用软件的单元测试、部分系统平台软件模块测试第三条本文档的预期读者为项目的项目经理、产品经理、系统软件主研人员、应用软件主研人员、高级测试人员等。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个子目录分别对应PCLinux、PXA250评估板、IXP425评估板、PXA255目标板、IXP425目标板的测试目录，用于构建、执行单元测试、管理测试日志和测试报告。第十一条测试代码的书写规范其规范见附录三。第十二条测试单元的文件组成及命名规范每个测试单元由测试代码文件、程序主函数文件和编译运行脚本文件组成，单元测试完成之后还生成一系列测试报告，这些测试报告将与模块单元一起提交。为了便于管理，对组成测试单元的各个文件及测试生成的测试结果和测试报告文件的命名都从被测类/模块派生而来。假定被测类为DemoClass，测试单元包含如下文件及其所处目录位置如下所述：1)测试单元文件TestDemo/DemoClassTest.h：测试类头文件TestDemo/DemoClassTest.cpp：测试类实现文件TestDemo/DemoUnitMain.cpp：测试类主函数TestDemo/$(运行平台)/Makefile：用于特定运行平台的makefile文件TestDemo/$(运行平台)/DemoTestDemo：为特定运行平台生成的可执行程序其中运行平台为：PCLinux、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被测单元的代码性能分析结果文件其中运行平台为：PCLinux、PXA250评估板、PXA255目标板、IXP425评估板、IXP425目标板第十三条单元测试的实施按照单元测试规程进行实施，进行代码审查和动态测试。1)单元测试或集成测试涉及的源程序三种：被测类/被测单元、已通过的类/桩模块、测试单元。只需对被测类进行测试设计、进行代码覆盖率分析和代码性能分析，用多种优化编译选项进行编译和测试；2)不需为已通过的类/桩模块进行测试设计，这些模块单元和测试单元本身都进行代码不需要使用ccmalloc、gcov和gprof等工具要求的编译选项和编译优化选项进行编译，也不需要为其生成.gcov代码覆盖率报告。3)对于各种运行平台下，都需要使用-O0,-O2,-O3三种编译优化选项对测试单元进行编译，并运行一个测试单元中的所有测试用例，生成测试报告第十四条单元模块正确性测试进行单元正确性测试的过程是将被测单元源程序、测试单元源程序和测试主函数程序放到一起编译产生可执行程序，并在目标平台上运行可执行程序，即可获得测试结果报告。对应上述的DemoClass被测类的正确性测试过程的命令序列为：$(CC)$(OPT)-cDemoClass.cpp;编译被测类$(CC)-cDemoClassTest.cpp$(CC)-cDemoUnitMain.cpp$(CC)-oDemoTestDemoDemoClass.oDemoClassTest.oDemoUnitMain.o-lstdc++-lcppunit./DemoTestDemo;运行测试./DemoTestDemoDemoUnit$(OPT).log;生成单元测试结果文件，该文件随模块一起提交其中，变量CC为C/C++编译器，如gcc/g++；$(OPT)为编译优化选项。项目要求每个被测模块在用-O0,-O2和-O3三种编译选项进行编译，并分别进行正确性测试。第十五条单元内存溢出检查项目要求用ccmalloc内存检查工具对被测单元进行内存溢出检查，测试过程与正确性测试相似，只是要求被测单元代码的编译和最后的连接命令前添加ccmalloc命令，如下命令序列所示：ccmalloc$(CC)$(OPT)-cDemoClass.cpp$(CC)-cDemoClassTest.cpp$(CC)-cDemoUnitMain.cppccmalloc$(CC)-oDemoTestDemoDemoClass.oDemoClassTest.oDemoUnitMain.o-lstdc++-lcppunit./DemoTestDemo;运行测试，产生内存检查结果显示于屏幕./DemoTestDemo2DemoUnit.ccmalloc;运行测试，产生内存检查结果文件用于提交第十六条测试代码覆盖率分析项目要求用gcov工具对测试单元的代码覆盖率进行分析，测试单元的代码覆盖率分析的命令序列如下所示：$(CC)$(OPT)-c-g-fprofile-arcs-ftest-coverageDemoClass.cpp-fprofile-arcs;对被测代码使用-g-ftest-coverage等编译选项$(CC)-cDemoClassTest.cpp$(CC)-cDemoUnitMain.cpp$(CC)-oDemoTestDemoDemoClass.oDemoClassTest.oDemoUnitMain.o-lstdc++-lcppunit./DemoTestDemo;运行测试gcovDemoClass.cppDemoClass.gcov.sum;对每个被测源程序生成2个覆盖率结果文件;DemoClasscpp.gcov和DemoClass.gcov.sum;前者包含源代码每条语句的执行计数，;后者包含一个该文件覆盖率统计catDemoClass.gcov.sumDemoClass.cppDemoClass.gcov;合并以上两个代码覆盖率文件，;最后提交合并后的文件第十七条模块单元代码性能分析项目还要求用gcov工具对测试单元的代码性能进行分析，测试单元的代码性能分析的命令序列如下所示：$(CC)$(OPT)-c-g-pgDemoClass.cpp;对被测类使用-g-pg等编译选项$(CC)-cDemoClassTest.cpp$(CC)-cDemoUnitMain.cpp$(CC)-pg-oDemoTestDemoDemoClass.oDemoClassTest.oDemoUnitMain.o-lstdc++-lcppunit./DemoTestDemo;运行测试gprof-pgDemoTestDemoDemoUnit.prof;产生性能分析结果文件第三章测试结果提交和验收第十八条单元测试工作产品提交项目要求随模块提交2.8列出的5种测试单元文件和6种测试结果和测试报告文件，而每增加一种被测类，提交时要求增加相应的测试类文件和代码覆盖率报告文件。1对于每个被测类的测试文档产品测试类头.h文件测试类实现.cpp文件PCLinux平台和2个XScale平台（2个PXA25X平台或2种IXP425平台）下的代码覆盖率.gcov文件2对于每个测试单元的测试文档产品测试类主函数.c