CQ缺陷管理规范.docx
- 文档编号:341141
- 上传时间:2022-10-09
- 格式:DOCX
- 页数:15
- 大小:88.12KB
CQ缺陷管理规范.docx
《CQ缺陷管理规范.docx》由会员分享,可在线阅读,更多相关《CQ缺陷管理规范.docx(15页珍藏版)》请在冰豆网上搜索。
CQ缺陷管理规范
1
1.1缺陷记录信息
对缺陷的描述包含以下的内容:
可追踪信息
缺陷ID
唯一的缺陷ID,可以根据该ID追踪缺陷
缺陷基本信息
缺陷状态
缺陷的状态,分为11种(见3.2.8节)
标题
对缺陷简单描述
缺陷类型
缺陷所属类型(见3.2.1节)
严重程度
缺陷的严重程度,一般分为“致命”、“严重”、“一般”、“轻微”和“其它”五种(见3.2.2节)
缺陷来源
引入缺陷的开发阶段(见3.2.3节)
发现阶段
发现缺陷时所属的阶段(见3.2.4节)
重现步骤
重现缺陷的步骤
现象描述
对缺陷的详细描述;因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改,描述应该尽可能详细
内部版本号
发现缺陷时产品的内部版本号
外部(正式)版本号
发布给客户使用的版本号。
修复责任人
在缺陷提交后,由项目经理/开发经理指定修复缺陷的责任人
修复期限
项目经理/开发经理指定修复缺陷的截止日期
优先级
缺陷的紧急程度,修复的优先级,从1-3,1是优先级最高的等级,3是优先级最低的等级(见3.2.6节)
修复描述
对修复内容(将什么改成什么)的描述,如果对代码进行了修改,要求在此处体现出修改
解决方案
排除缺陷的解决方案类型(见3.2.7节)
排除阶段
修复缺陷时所属的阶段(见3.2.5节)
估计工时
估计修复该缺陷所需的工时
实际工时
修复该缺陷实际使用的工时
工作分数
缺陷关闭后,项目经理/开发经理评估修复缺陷所花的工作量和修复缺陷的工作质量
工作量系数
工作质量系数
工作分数评估描述
项目经理/开发经理对缺陷修复工作量和工作质量的评估给予必要的解释说明
1.1.1缺陷类型
#
缺陷类型
详细类型
1
功能性
●展现层错误、未实现、未容错
●控制层错误、未实现、未容错
●业务层错误、未实现、未容错
●数据层错误、未实现、未容错
●功能实现不完整
●功能实现错误
2
数据类
●数据不一致
●数据不完整
●数据重复
●信息填充错误
3
易用性
●业务流程操作繁琐
●界面布局不合理
●操作不习惯
●tab键顺序不合理
●尽量保证一屏能显示,横向滚动条尽量避免,违反此规范的缺陷
●提示信息不充分,或者不友好,甚至错误提示
●按钮摆放位置不符合正常习惯
●设计图标,展示不符合常规,给人误解
●布局设计不合理(静态页面显示)
●风格不统一
●图片、色调不符合业务系统要求
4
可维护性
●系统的故障恢复困难
●系统的升级操作困难
5
其他(性能、可靠性、可扩展性等)
●系统的响应时间差
●并发处理性能差
●过负荷处理处理机制差
1.1.2严重程度
#
严重程度
描述
1
致命
致命是指系统任何一个主要功能完全丧失,或用户数据受到破坏,造成系统崩溃、悬挂、死机或者危机人身安全。
●由于程序所引起的死机,非法退出
●死循环
●导致数据库发生死锁
●数据通讯错误
●数据流环节上严重的数值计算错误
●产品设计存在严重的安全问题,漏洞被利用后可能导致系统瘫痪、数据丢失或隐私泄露等问题
●存在严重的性能问题,导致数据库或者应用服务器压力过大,导致生产不能正常进行
2
严重
主要功能未实现或与产品需求规格书不符:
●功能不符
●数据流错误,如不能保存数据
●程序接口错误
●数据流环节上轻微的数值计算错误
●性能如内存溢出、响应时间超长
●程序正常输入报错无结果或coredump
3
一般
次要功能未实现或与产品需求规格书不符:
●界面错误(详细文档)
●打印内容、格式错误
●简单的输入限制未放在前台进行控制
●删除操作未给出提示、功能按钮不允许使用时没有置灰或给出提示信息
●JavaScript错误
●页面跳转错误
●非数据流环节上的数值计算错误
●非数据流功能提交失败
●长时间操作未给用户进度提示(超过10秒)
●界面操作之后,没有刷新功能
●前后台不能联调(如前台插入数据不能满足后台程序需求)
●界面没有提供不影响生产的功能(如排序、分页、小计、总计等)
●存在必填项冗余字段或内容
4
轻微
装饰性问题:
主要是界面方面问题,如错别字,提示信息不准确:
●辅助说明描述不清楚、提示信息不正确
●显示格式不规范
●长时间操作未给用户进度提示(少于10秒)
●提示窗口文字未采用行业术语
●可输入区域和只读区域没有明显的区分标志
●系统处理未优化
●脚本或说明文档未提供或提供错误
●界面美观性问题
●明显及常用的操作方便或习惯性问题
5
其他
测试建议
1.1.3缺陷来源
#
缺陷来源
详细来源
1
需求
●业务/用户需求描述错误
●业务/用户需求描述不清楚
●业务/用户需求遗漏
●需求规格描述错误
●需求规格描述不清楚
●需求规格需求遗漏
●需求规格与业务/用户需求不符
2
设计
●系统框架存在缺陷
●系统采用的组件存在缺陷
●模块间存在高耦合性(划分不清楚)
●接口设计错误
●接口设计描述不清楚
●数据库设计不合理
●设计与SRS不一致
3
编码
●编码和设计不一致
●变量赋值类错误
●比较表达式错误
●变量溢出
●循环条件错误
●日志格式或内容不符合要求
●SQL语句错误
●SQL语句不可用(存在性能问题等)
●界面展现错误,如:
拼写、标点符号、打字
●脚本不全,配置错误,提供给测试部作系统测试的文档不全
4
测试
●测试用例跟SRS不一致
●修改回归缺陷引起
●测试环境原因(测试环境搭建错误)
1.1.4发现阶段
#
发现阶段
描述
1
需求阶段
在需求阶段发现的缺陷
2
设计阶段
在设计阶段发现的缺陷
3
编码阶段
在编码阶段发现的缺陷
4
集成测试阶段
在集成测试阶段发现的缺陷
5
系统测试阶段
在系统测试阶段发现的缺陷
6
确认测试阶段
在确认测试阶段发现的缺陷
7
运行维护阶段
在运行维护阶段发现的缺陷
1.1.5排除阶段
#
排除阶段
描述
1
需求阶段
在需求阶段排除的缺陷
2
设计阶段
在设计阶段排除的缺陷
3
编码阶段
在编码阶段排除的缺陷
4
集成测试阶段
在集成测试阶段排除的缺陷
5
系统测试阶段
在系统测试阶段排除的缺陷
6
确认测试阶段
在确认测试阶段排除的缺陷
7
运行维护阶段
在运行维护阶段排除的缺陷
1.1.6优先级
#
优先级
描述
1
1-立即解决
缺陷必须被立即解决。
2
2-正常
缺陷需要正常排队等待解决或列入软件发布清单。
3
3-不紧急
缺陷可以在方便时解决
1.1.7解决方案
#
解决方案
描述
1
Duplicate
提交的缺陷和以前的某个缺陷属于同一个缺陷,解决方案直接复制
2
EnhancementRequest
提交的缺陷属于需求功能增强
3
Fixed
修正BUG(直接修复)
4
FixedIndirectly
提交的缺陷是由其它缺陷引起的(间接修复)
1.1.8缺陷状态
#
缺陷状态
描述
1
Submitted
已提交的缺陷
2
Ready
已指派修复责任人的缺陷
3
Canceled
已取消的缺陷(提交后经评审不需要修复或不是缺陷)
4
Postponed
已推迟的缺陷,暂不修复
5
Active
已打开的缺陷,正在解决中
6
Resolved
已解决的缺陷
7
Rejected
已拒收的缺陷(已解决的缺陷经验证不通过)
8
Validated
已验证通过的缺陷
9
Closed
已关闭的缺陷
10
Subrejected
已拒绝测试组提交的缺陷(项目接口人经审核后,发现提交的缺陷单有问题,需要测试组修改.
11
Unactived
开发人员拒绝项目接口人分配的缺陷。
1.2缺陷管理流程
RationalClearQuest使用一条条的记录来跟踪缺陷,每一条缺陷记录都会经历不同的状态,例如已经指派状态、已经解决状态、关闭状态等。
记录通过不同的动作在各个状态间转换,如下图:
●测试人员不能处理的Subrejected状态的缺陷需要由产品经理得出处理方案。
●有效缺陷:
除cancelled状态以外的缺陷。
无效缺陷:
cancelled状态的缺陷。
遗留缺陷:
除closed、cancelled状态以外的缺陷。
●测试人员包括以下人员
◆进行单元测试、代码走读的和集成测试的开发人员
◆进行系统测试的测试人员
◆进行确认测试的实施人员
◆对上线后系统进行维护的维护人员
1.2.1提交(Submit)
一个缺陷,必须经过提交(Submit),才可以成为ClearQuest数据库中的一条记录,从而才可以对其进行跟踪管理。
1.2.2拒绝提交的缺陷(Subreject)
提交的缺陷由项目接口人审核,发现测试人员提交的缺陷单描述不清楚或者不正确,需要打回给测试人员进行修改。
1.2.3重新提交(Resubmit)
对于被项目接口人打回的缺陷,测试人员修改完缺陷单后,重新提交给项目接口人。
1.2.4指派(Assign)
由项目接口人指派(Assign)修复责任人,并明确修复期限。
1.2.5打开(Open)&缺陷排除(Resolve)
修复责任人打开(Open)缺陷记录开始修复工作,在缺陷排除(Resolve)后,填写解决方案、修复描述等信息将缺陷提交验证人,等待验证。
1.2.6验证(Validate)
已修复的缺陷,经测试人员验证(Validate)通过;如验证不通过(缺陷未消除),验证人将此缺陷记录退回(Reject)给修复责任人。
1.2.7再次打开(Re_Open)
已修复的缺陷可以被修复责任人在缺陷被验证之前再次打开(Re_Open)。
1.2.8评估(Audit)
最后,测试人员对已验证通过的缺陷进行工作量和工作质量的评估(Audit),评估完毕,缺陷自动关闭。
1.2.9推迟(Postpone)
项目接口人审核发现该缺陷需要暂停修复,并明确修复期限。
1.2.10取消(Cancel)
Subrejected状态的缺陷,测试人员确认不是缺陷,则可以执行取消操作。
Subrejected状态的缺陷,测试人员不能确认是否缺陷,由产品经理确认不是缺陷的,也可以执行取消操作。
1.3缺陷提交规范
1、标题(headline):
简洁、准确,完整,揭示错误实质,记录缺陷或错误出现的位置。
描述要准确反映错误的本质内容,简短明了。
2、明确指明错误表现类型:
功能、界面、性能、其它。
3、每一个步骤尽量只记录一个操作,保证简洁、条理井然,容易重复操作步骤。
4、确认步骤完整,准确,简短,保证快速准确的重复错误,“完整”即没有缺漏,“准确”即步骤正确,“简短”即没有多余的步骤。
5、根据缺陷或错误类型,选择图象捕捉的方式。
为了直观的观察缺陷或错误现象,通常需要附加缺陷或错误出现的界面,以位图的形式作为附件附着在记录的“附件”部分。
为了节省空间,又能真实反映缺陷或错误本质,可以捕捉缺陷或错误产生时的全屏幕,活动窗口和局部区域。
6、附加必要的特殊文档和个人建议和注解。
如果打开某个特殊的文档而产生
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CQ 缺陷 管理 规范
![提示](https://static.bdocx.com/images/bang_tan.gif)