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、附加必要的特殊文档和个人建议和注解。
如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误；为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。
7、每条错误报告只包括一个错误。
每条错误报告只包括一个错误，可以使错误修正者迅速定位一个错误，校验者每次只校验一个错误是否已经正确修正。
8、检查拼写和语法错误。
在提交每条缺陷或错误之前，检查拼写和语法，确保容正确，正确的描述错误。
9、版本号：
缺陷的版本号研发团队、实施团队应该保持一致，按照公司的规定：
如MMS-SX-V2.0.0.0（MMS：
系统名称、SX:
地域简称、V2.0.0.0：
回归版本号、V2.0.0外部版本号）
10、尽量使用业界惯用的表达术语和表达方法。
使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
11、尽量使用短语和短句，避免复杂句型句式。
实例：
1、基本信息
2、缺陷步骤描述
3、附件信息
附件信息可根据缺陷需要进行提交。
1.4缺陷数据统计分析
缺陷数据统计分析是缺陷跟踪管理的容之一。
可以通过选择不同的研究对象，如缺陷的状态、严重程度、优先级、提交人、修复责任人、验证人、解决方案和解决时间等建立查询、统计缺陷数据。
项目管理人员应生成缺陷数据统计图表，对统计结果进行分析。
一般可建立的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、打开关闭曲线、关闭周期曲线、严重程度统计分布图、优先级统计分布图、缺陷类型统计分布图、缺陷及时处理情况统计表等。
通过建立缺陷查询、统计图表，可使项目管理层从不同角度了解当前缺陷的解决进度，更加准确地度量项目的开发质量以及整个开发团队，尤其是开发人员和测试人员的工作效率，使项目管理工作变得更加易于管理、富有成效。
升级会员 