BUG等级得分.doc

软件质量评估参照标准
深圳市艾派应用系统有限公司
Shenzhen iPi Application System Co.,Ltd.
文档基本信息
文档级别
填写对外绝密,对内公开
文档编号
产品、质量名称(含版本信息)

文档修订历史记录
文档版本
修订日期
修订描述
拟制
修订
审核

2008-04-10
首次发布版本
邱容珍
邱容珍

2009-04-21
修改目的:
;
;
,强化研发不同过程中出现的问题的扣分差距。
修订内容:
修改等级划分
去掉版本提交不成功的扣分;
增加按BUG类型的扣分
修订按BUG等级的扣分细项
修订各评估指标的占分情况
邱容珍

2009-12-16
修改目的:为减少因提交次数多而造成的成本增加,故进行修订。
修订内容:将回归次数修订为提交次数,并适当调整详细得分
邱容珍

2010-02-22
修订提交次数的描述
邱容珍

2011-11-16~30
修改目的:调整一些参数设置及常见的非常规问题说明,以使评估更合理
修改了不同级别的用例个数;
修改了BUG密度的得分差距;
修改了不同级别下的BUG密度评分差异;
修改了返修率在不同级别下的评分差距;
修改了不同等级的送测次数的得分差距;
修改了等级评分、类型的分布降低基准分,以使评分更合理;
对BUG多次返修、历史遗留问题、测试明显漏测特殊事项进行了说明;
邱容珍

2012-03-06
;
(降低高级BUG占式);
;
邱容珍
.
2015-7-1
修改目的:针对版本规模及历史BUG的相关争议进行调整,以使评估更具参照性
重新调整版本规模分级,(300以内按50分级;后续递增);
统一各规模下的BUG返修得分;修改其它4个标准细则全面调整。
修订历史BUG的评分标准;
邱容珍
前言
为了评估研发部的项目版本质量,提供研发过程改进的参考数据及提倡各项目之间的质量横向对比,故制定此《软件质量评估参照标准》,以期更好、更快的提高软件产品质量。
评估对象
正式送测且在测试环境下正常完成测试的版本;
评估方法
根据研发部门现有项目状况,以及度量基准数据来源的准确性及方便程度,现主要采用如下方式:
定义评估参数及每个参数的得分比重;
定义按测试用例数来度量软件规模等级;
定义不同等级下的评估参数取值范围;
根据以上3个基本要求,再拟定算法最终得出该版本的得分。
评估数据来源
评估数据来源主要来自于质量组的测试用例数以及BUG数据,其中需使用的名词解释如下:
测试用例数:指在QC中当前版本执行的用例数(统计来源:DESSTEPS或step表中的数据)。
有效BUG数:指对应版本中正确有效的BUG数,不包括被Rejected及Cancel的BUG数。
评估参数定义
评估参数包括BUG密度、提交次数、返修率、基于等级的BUG得分四项;同时存在如下声明:
版本打回:版本打回指在经过冒烟测试时被测试人员拒绝接收的版本,版本打回计多提交一次;它主要包括3类打回的情况:
版本提交后测试问题过多,每走一个功能点就出现多个问题等,严重影响测试效率;
版本提交后测试过程中因影响测试重新进行了关键性代码提交;
版本提交后无法正常进行测试,排除2小时仍没有解决。
注:对于版本打回失误的情况,项目经理可进行申诉。
历史问题:指当前项目中存在的但非当前版本引入的问题;为了更好的提高最终上线的项目质量,对于历史问题不纳入当前版本的评估中;但因修改此历史问题引发了新的BUG单或修改未
成功时,会将新产生的问题纳入当前版本评估中,同时评估需叠加相应的用例数(功能问题对应1~10个用例;非功能问题对应1~5个用例)。
BUG密度
指基于执行测试用例的BUG密度;。
计算公式:缺陷数/(当前版本执行的用例总数+叠加用例数)
评价目的:BUG的密度控制
所占比重:30分
提交次数
指版本实际的提交次数;当存在非常小的需求的迭代版本提交送测时,仍按常规的提交次数计算(版本打回的重新提交也统计在内);对于多模块的分次送测,以单模块的最大送测次数为计(如DC单独送测4次,desktop单独送测2次;则统计本版本的送测次数为4);对于明确的分阶段迭代提交,则按总提交次数/2+1的方式计算提交数