软件单元测试工作流程规范V10Word下载.docx
- 文档编号:17528545
- 上传时间:2022-12-07
- 格式:DOCX
- 页数:14
- 大小:24.40KB
软件单元测试工作流程规范V10Word下载.docx
《软件单元测试工作流程规范V10Word下载.docx》由会员分享,可在线阅读,更多相关《软件单元测试工作流程规范V10Word下载.docx(14页珍藏版)》请在冰豆网上搜索。
作者
参与者
起止日期
备注
V1.0
2009-5-11/2009-5-17
1引言
1.1编写目的
本文档规定了应用软件系统和部分系统平台模块的单元测试方法和步骤、测试用例的设计方法、测试代码的书写规范、流程以及单元测试的产品提交和验收规范,目的在于控制单元测试的质量,加强项目的质量管理,从而提高整个产品的质量。
1.2适用范围
此规范适用于应用软件的单元测试、部分系统平台软件模块测试。
1.3参考文件
CppUnitDocumentation
RationalUnifiedProcess
1.4定义与缩写
RUP统一开放过程
被测模块:
需要进行模块级测试的应用软件系统的一个单元或模块,也称被测单元
测试单元:
用于对被测模块进行单元级测试,由源代码、测试脚本和输入数据等构成的程序单元
2单元测试指南
2.1单元的定义
对于结构化的编程语言,程序单元指程序中定义的函数或子程序。
单元测试是指对行数或子程序所进行的测试。
对于面向对象的编程语言,程序单元指特定的一个具体的类或相关的多个类。
单元测试主要是对类方法的测试。
2.2角色工作体系
角色
职责
测试主管
审查单元测试过程,对测试结果进行评估。
根据单元测试发现的缺陷提出变更申请。
测试工程师
对单元代码进行检查,设计单元测试用例,加载运行测试用例,记录和分析测试结果,填写单元测试Bug清单。
开发工程师
设计测试需要的驱动程序和桩模块,以及辅助测试工具的开发。
配置管理员
管理测试需要的资源,包括软硬件环境,版本管理和Bug管理
2.3单元测试规程
包括静态的代码审查和动态测试两个阶段。
代码审查是按照《代码审查单》中的条项对单元模块进行逐项检查,并填写《单元测试Bug清单》。
《代码审查单》的格式见附录一,《单元测试Bug清单》见附录二。
动态测试阶段首先编写驱动模块或桩模块后,在驱动模块和桩模块中设计相应的测试用例,对所有的测试用例进行统一编号,在源代码中进行注释标识。
测试用例应该覆盖单元模块的所有功能项,如果单元模块有性能、余量等其它测试特性要求,则必须设计相应的测试用例测试这些特性,编制完测试用例后,把测试用例提交给配置管理员或测试主管进行审查,审查没有通过则根据审查意见进行修改,知道审查通过后测试人员加载测试用例,编译运行得到测试结果,比对测试结果,如果发现错误或Bug则需要填写《单元测试Bug清单》并提交测试经理和配置管理人员。
在进行功能测试时,可以利用其它测试工具进行内存溢出分析、代码覆盖率分析、代码性能测试等。
2.3.1代码审查
要求:
根据《代码审查表》中的要求,对被测试单元进行逐项检查,检查收在对应的条项后进行标记,发现问题后,填写《代码单元测试Bug清单》并提交。
2.3.2白盒测试
白盒测试进入的前提条件是在测试人员已经对被测试对象有了一定的了解,基本上明确了被测软件的逻辑结构。
过程是通过针对程序逻辑结构设计和加载测试用例,驱动程序执行,检查在不同点程序的状态,以确定实际的状态是否与预期的状态一致。
白盒测试主要是对被测试对象进行如下测试项目:
1)对程序模块的所有独立的执行路径至少覆盖一次;
2)对所有的逻辑判定,真假两种情况都至少覆盖一次;
3)在循环的边界和运行界限内执行循环体;
4)测试内部数据结构的有效性等。
白盒测试达到的目标:
语句覆盖率达到100%,分支覆盖率达到100%,覆盖程序中主要的路径,主要路径是指完成需求和设计功能的代码所在的路径和程序异常处理执行到的路径。
2.4测试单元的文件组成
每个测试单元由测试代码文件、程序主函数文件和编译运行脚本文件组成,单元测试完成后还生成一系列测试报告,这些测试报告将与模块单元一起提交。
2.5单元测试的实施
按照单元测试规程进行实施,进行代码审查和动态测试。
2.5.1单元模块正确性测试
进行单元正确性测试的过程是将被测单元源程序、测试单元源程序和测试主函数程序放到一起编译产生可执行程序,并在目标平台上运行可执行程序,即可获得测试结果报告。
2.5.2单元内存溢出检查
使用内存检查工具对被测单元进行内存溢出检查,测试过程与正确性测试相似。
2.5.3测试代码覆盖率分析
使用gcov工具对测试单元的代码覆盖率进行分析。
2.5.4模块端元代码性能分析
使用gcov工具对测试单元的代码性能进行分析。
2.6单元测试产生的工件清单
1、软件单元测试计划
2、单元测试用例
3、测试过程
4、测试脚本
5、测试日志
6、测试评估摘要
附录一:
代码审查表
检查大项
检查小项
是否
编程风格检查
按照代码编写规范,该缩进的地方是否已正确地缩进?
程序代码布局结构清楚吗?
注释准确并有意义吗?
在每一个模块之前,是否有注释说明,描述该模块的输入/输出、参数、功能处理和其调用的外部模块以及该模块是否有使用限制等?
是否有多余的资源定义和宏定义
头文件是否使用了ifndef/define/endif预处理块
程序结构和模块功能定义清楚吗?
是否遵循该语言的指令编写格式?
注释的行数不少于代码总行数的1/5吗?
注释说明和代码功能一致吗?
错误处理分支信息表达清楚吗?
每一个模块单元的圈复杂度都小于10吗?
模块内做到了高内聚、模块之间达到了低耦合吗?
模块的扇出不超出7-9之间吗?
屏蔽了没有明确含义的输入和按键吗?
常量、变量、类、数据结构等命名有意义吗?
函数接口检查
实参和形参的个数、属性和次序一致吗?
对另一个模块的每一次调用:
全部所需的参数是否已传送给每一个被调用的模块?
被传送的参数值是否正确设置?
函数功能是否齐全?
函数返回值类型正确吗?
Return语句是否返回指向“栈内存”的“指针”或者“引用”?
函数的返回值是否全面反应了各种状态和结果?
程序语言检查
动态链接库和外部设备接口驱动程序使用正确吗?
动态分配的指针是否在不使用之后删除,并释放内存?
调用类成员函数或API函数时,检查了返回值吗?
文件、数据库和注册表等打开后,在对其进行操作之后是否进行了关闭?
对于使用附带例外的函数是否增加了例外处理程序?
如对数据库或文件操作。
变量的数据类型定义是否合理?
程序中是否出现相同的局部变量和全部变量?
数据类型转换使用了正确的转换函数并转换正确吗?
是否使用了只用于调试版本的函数、宏等?
有多个线程的程序中,资源分配是否合理,会不会造成死锁?
在使用GDI对象后是否进行删除?
变量的作用域和生命期是否满足设计的目的?
表达式运算优先级是否正确?
是否忘记写switch的default分支?
使用goto语句时是否留下隐患?
Case语句的结尾是否忘了加break?
如果有运算符重载,则检查运算符重载是否正确?
类检查
类封装是否合理,检查成员函数和成员变量的访问属性是否满足操作要求?
外部可以修改类的行为吗?
内联函数代码足够小吗?
多重继承中,虚拟函数定义明确吗?
继承类和自定义类所封装的函数和过程是否合理?
类的功能是否详细,全面?
是否使用合理的类?
查看该类使用时需要注意的问题。
是否违背编程规范而让C++编译器自动为类产生四个缺省的函数:
(1)缺省的无参数构造函数;
(2)缺省的拷贝构造函数;
(3)缺省的析构函数;
(4)缺省的赋值函数。
构造函数中是否遗漏了某些初始化工作?
是否正确地使用构造函数的初始化表?
析构函数中是否遗漏了某些清除工作?
是否错写、错用了拷贝构造函数和赋值函数?
赋值函数一般分四个步骤:
(1)检查自赋值;
(2)释放原有内存资源;
(3)分配新的内存资源;
并复制内容;
是否违背了继承和组合的规则?
(1)若在逻辑上B是A的“一种”,并且A的所有功能和属性对B而言都有意义,则允许B继承A的功能和属性。
(2)若在逻辑上A是B的一部分,则不允许B从A派生,而是要用A和其它东西组合出B。
内存检查
每一个域在每一次使用前正确地初始化了吗?
是否忘记为数组和动态内存赋初值?
数组或指针的下标是否越界?
动态内存的申请与释放是否配对?
是否有效地处理了”内存耗尽”问题?
是否修改“指向常量的指针”的内容?
每个域是否已由正确的变量类型声明?
存储区重复使用吗?
可能出现冲突吗?
用malloc或new申请内存之后,是否立即检查指针值是否为NULL?
是否出现野指针?
例如
(1)指针变量没有被初始化。
(2)用free或delete释放了内存之后,忘记将指针设置为NULL
测试和转移检查
是否进行了浮点数相等比较?
测试条件逻辑组合正确吗?
逻辑“或”中一个条件满足就执行对其他逻辑表达式有影响吗?
用于测试的是正确的变量吗?
每个转移目标正确并至少执行一次吗?
三种情况(大于0,小于0,等于0)是否已全部测试?
边界值是否进行了测试?
循环语句是否有正常跳出循环的条件吗?
是否会出现死循环?
break和continue语句使用正确吗?
性能检查
逻辑是否被最佳地编码
提供的是一般的错误处理还是异常的例程?
对屏幕输出操作,是否达到了最快的刷新速度?
效率是否为最佳?
需部分刷新区域的地方是否进行了全部刷新?
有无可优化的程序块、函数或子程序等?
算法是否可以优化?
可维护性检查
注释比例达到25%以上吗/
标号和子程序名符合代码的意义吗?
是否使用了GOTO语句?
是否使用了非通用的函数库?
对于非标准的库是否提供了源程序?
对于重复出现的常量是否定义了宏?
对于重复出现并完成同样单一功能的一段代码,是否用函数对其进行了封装?
避免过多的使用技巧性编程,如使用,是否作了详细解释说明?
逻辑检查
代码是否正确地实现了设计功能?
编码是否做了设计所规定以外的内容?
每个循环是否执行正确的次数?
输入参数的所有异常值是否已直接测试?
逻辑判断表达式符合程序设计吗?
软件多余物
有没有不可能执行到的代码?
有没有即使不执行也不影响程序功能的指令?
有没有未引用的变量、标号和常量?
有没有多余的程序单元?
附件二、单元测试Bug清单
单元测试Bug清单
下面由测试人员填写
项目名称
BugID
用例ID
提交时间
提交人
提交给
问题名称
问题描述
项目阶段
□需求分析□详细设计□集成测试□验收测试□结构设计□单元测试
□系统测试□维护
问题类型
□硬件□设计□编码□建议□疑问
问题级别
□重大□高□中□低
可再现否
□是□否□不一定
再现描述
修改建议
下面由Bug管理人员【项目经理】填写
优先级
□立即解决□尽快解决□下一阶段解决□可能的情况解决
意见
对问题解决的以及,建议,修改期限等
是否纳入Bug管理
□是□否
下面由问题解决者【开发负责人员】填写
问题状态
□正在解决□无法再现问题□依照设计
□已经解决□保留□问题被撤回
已解决版本
解决时间
处理说明
下面由测试验证人员填写
验证人
验证版本
验证时间
□已经解决□没有解决□已经解决但引起新的问题
已经解决但引起新的问题BugID
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 单元测试 工作 流程 规范 V10