CQ缺陷管理规范标准.docx

1、CQ缺陷管理规范标准1 1.1 缺陷记录信息对缺陷的描述包含以下的容：可追踪信息缺陷ID唯一的缺陷ID，可以根据该ID追踪缺陷缺陷基本信息缺陷状态缺陷的状态，分为11种（见3.2.8节）标 题对缺陷简单描述缺陷类型缺陷所属类型（见3.2.1节）严重程度缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“轻微”和“其它”五种(见3.2.2节)缺陷来源引入缺陷的开发阶段（见3.2.3节）发现阶段发现缺陷时所属的阶段（见3.2.4节）重现步骤重现缺陷的步骤现象描述对缺陷的详细描述；因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细部版本号发现缺陷时产品的部版本号外部（正式）

2、版本号发布给客户使用的版本号。修复责任人在缺陷提交后，由项目经理/开发经理指定修复缺陷的责任人修复期限项目经理/开发经理指定修复缺陷的截止日期优先级缺陷的紧急程度，修复的优先级，从13，1是优先级最高的等级，3是优先级最低的等级(见3.2.6节)修复描述对修复容(将什么改成什么)的描述，如果对代码进行了修改，要求在此处体现出修改解决方案 排除缺陷的解决方案类型（见3.2.7节）排除阶段修复缺陷时所属的阶段(见3.2.5节)估计工时估计修复该缺陷所需的工时实际工时修复该缺陷实际使用的工时工作分数缺陷关闭后，项目经理/开发经理评估修复缺陷所花的工作量和修复缺陷的工作质量工作量系数工作质量系数工作分

3、数评估描述项目经理/开发经理对缺陷修复工作量和工作质量的评估给予必要的解释说明1.1.1 缺陷类型#缺陷类型详细类型1功能性 展现层错误、未实现、未容错 控制层错误、未实现、未容错 业务层错误、未实现、未容错 数据层错误、未实现、未容错 功能实现不完整 功能实现错误2数据类 数据不一致 数据不完整 数据重复 信息填充错误3易用性 业务流程操作繁琐 界面布局不合理 操作不习惯 tab键顺序不合理 尽量保证一屏能显示，横向滚动条尽量避免，违反此规的缺陷 提示信息不充分，或者不友好，甚至错误提示 按钮摆放位置不符合正常习惯 设计图标，展示不符合常规，给人误解 布局设计不合理（静态页面显示） 风格不统

4、一 图片、色调不符合业务系统要求4可维护性 系统的故障恢复困难 系统的升级操作困难5其他（性能、可靠性、可扩展性等） 系统的响应时间差 并发处理性能差 过负荷处理处理机制差1.1.2 严重程度#严重程度描述1致命致命是指系统任何一个主要功能完全丧失，或用户数据受到破坏，造成系统崩溃、悬挂、死机或者危机人身安全。 由于程序所引起的死机,非法退出 死循环 导致数据库发生死锁 数据通讯错误 数据流环节上严重的数值计算错误 产品设计存在严重的安全问题，漏洞被利用后可能导致系统瘫痪、数据丢失或隐私泄露等问题 存在严重的性能问题，导致数据库或者应用服务器压力过大，导致生产不能正常进行2严重主要功能未实现或

5、与产品需求规格书不符： 功能不符 数据流错误，如不能保存数据 程序接口错误 数据流环节上轻微的数值计算错误 性能如存溢出、响应时间超长 程序正常输入报错无结果或coredump3一般次要功能未实现或与产品需求规格书不符： 界面错误(详细文档) 打印容、格式错误 简单的输入限制未放在前台进行控制 删除操作未给出提示、功能按钮不允许使用时没有置灰或给出提示信息 JavaScript错误 页面跳转错误 非数据流环节上的数值计算错误 非数据流功能提交失败 长时间操作未给用户进度提示（超过10秒） 界面操作之后，没有刷新功能 前后台不能联调（如前台插入数据不能满足后台程序需求） 界面没有提供不影响生产的

6、功能（如排序、分页、小计、总计等） 存在必填项冗余字段或容4轻微装饰性问题：主要是界面方面问题，如错别字，提示信息不准确： 辅助说明描述不清楚、提示信息不正确 显示格式不规 长时间操作未给用户进度提示（少于10秒） 提示窗口文字未采用行业术语 可输入区域和只读区域没有明显的区分标志 系统处理未优化 脚本或说明文档未提供或提供错误 界面美观性问题 明显及常用的操作方便或习惯性问题5其他测试建议1.1.3 缺陷来源#缺陷来源详细来源1需求 业务/用户需求描述错误 业务/用户需求描述不清楚 业务/用户需求遗漏 需求规格描述错误 需求规格描述不清楚 需求规格需求遗漏 需求规格与业务/用户需求不符2设计

7、 系统框架存在缺陷 系统采用的组件存在缺陷 模块间存在高耦合性（划分不清楚） 接口设计错误 接口设计描述不清楚 数据库设计不合理 设计与SRS不一致3编码 编码和设计不一致 变量赋值类错误 比较表达式错误 变量溢出 循环条件错误 日志格式或容不符合要求 SQL语句错误 SQL语句不可用（存在性能问题等） 界面展现错误，如：拼写、标点符号、打字 脚本不全，配置错误，提供给测试部作系统测试的文档不全4测试 测试用例跟SRS不一致 修改回归缺陷引起 测试环境原因（测试环境搭建错误）1.1.4 发现阶段#发现阶段描述1需求阶段在需求阶段发现的缺陷2设计阶段在设计阶段发现的缺陷3编码阶段在编码阶段发现的

8、缺陷4集成测试阶段在集成测试阶段发现的缺陷5系统测试阶段在系统测试阶段发现的缺陷6确认测试阶段在确认测试阶段发现的缺陷7运行维护阶段在运行维护阶段发现的缺陷1.1.5 排除阶段#排除阶段描述1需求阶段在需求阶段排除的缺陷2设计阶段在设计阶段排除的缺陷3编码阶段在编码阶段排除的缺陷4集成测试阶段在集成测试阶段排除的缺陷5系统测试阶段在系统测试阶段排除的缺陷6确认测试阶段在确认测试阶段排除的缺陷7运行维护阶段在运行维护阶段排除的缺陷1.1.6 优先级#优先级描述11-立即解决缺陷必须被立即解决。22-正常缺陷需要正常排队等待解决或列入软件发布清单。33-不紧急缺陷可以在方便时解决1.1.7 解决方

9、案#解决方案描述1Duplicate提交的缺陷和以前的某个缺陷属于同一个缺陷，解决方案直接复制2Enhancement Request提交的缺陷属于需求功能增强3Fixed修正BUG（直接修复）4Fixed Indirectly提交的缺陷是由其它缺陷引起的（间接修复）1.1.8 缺陷状态#缺陷状态描述1Submitted已提交的缺陷2Ready已指派修复责任人的缺陷3Canceled已取消的缺陷(提交后经评审不需要修复或不是缺陷)4Postponed已推迟的缺陷，暂不修复5Active已打开的缺陷，正在解决中6Resolved已解决的缺陷7Rejected已拒收的缺陷（已解决的缺陷经验证不通过

10、）8Validated已验证通过的缺陷9Closed已关闭的缺陷10Subrejected已拒绝测试组提交的缺陷（项目接口人经审核后，发现提交的缺陷单有问题，需要测试组修改.11Unactived开发人员拒绝项目接口人分配的缺陷。1.2 缺陷管理流程Rational ClearQuest使用一条条的记录来跟踪缺陷，每一条缺陷记录都会经历不同的状态，例如已经指派状态、已经解决状态、关闭状态等。记录通过不同的动作在各个状态间转换，如下图： 测试人员不能处理的Subrejected状态的缺陷需要由产品经理得出处理方案。 有效缺陷：除cancelled状态以外的缺陷。 无效缺陷：cancelled状态

11、的缺陷。遗留缺陷：除closed、cancelled状态以外的缺陷。 测试人员包括以下人员 进行单元测试、代码走读的和集成测试的开发人员 进行系统测试的测试人员 进行确认测试的实施人员 对上线后系统进行维护的维护人员1.2.1 提交(Submit)一个缺陷，必须经过提交（Submit），才可以成为ClearQuest数据库中的一条记录，从而才可以对其进行跟踪管理。1.2.2 拒绝提交的缺陷（Subreject） 提交的缺陷由项目接口人审核，发现测试人员提交的缺陷单描述不清楚或者不正确，需要打回给测试人员进行修改。1.2.3 重新提交（Resubmit） 对于被项目接口人打回的缺陷，测试人员修改

12、完缺陷单后，重新提交给项目接口人。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

13、.2.8 评估(Audit)最后，测试人员对已验证通过的缺陷进行工作量和工作质量的评估（Audit），评估完毕，缺陷自动关闭。1.2.9 推迟（Postpone）项目接口人审核发现该缺陷需要暂停修复，并明确修复期限。1.2.10 取消（Cancel）Subrejected状态的缺陷，测试人员确认不是缺陷，则可以执行取消操作。Subrejected状态的缺陷，测试人员不能确认是否缺陷，由产品经理确认不是缺陷的，也可以执行取消操作。1.3 缺陷提交规1、标题 (headline)：简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置。描述要准确反映错误的本质容，简短明了。2、明确指明错误表现类

14、型：功能、界面、性能、其它。3、每一个步骤尽量只记录一个操作，保证简洁、条理井然，容易重复操作步骤。4、确认步骤完整，准确，简短，保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。5、根据缺陷或错误类型，选择图象捕捉的方式。为了直观的观察缺陷或错误现象，通常需要附加缺陷或错误出现的界面，以位图的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。6、附加必要的特殊文档和个人建议和注解。如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误；为

15、了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。7、每条错误报告只包括一个错误。每条错误报告只包括一个错误，可以使错误修正者迅速定位一个错误，校验者每次只校验一个错误是否已经正确修正。8、检查拼写和语法错误。在提交每条缺陷或错误之前，检查拼写和语法，确保容正确，正确的描述错误。9、版本号：缺陷的版本号研发团队、实施团队应该保持一致，按照公司的规定：如MMS-SX-V2.0.0.0 (MMS：系统名称、SX:地域简称、V2.0.0.0：回归版本号、V2.0.0外部版本号)10、尽量使用业界惯用的表达术语和表达方法。使用业界惯用的表达术语和表达方法，保证表达准确，体现

16、专业化。11、尽量使用短语和短句，避免复杂句型句式。实例：1、 基本信息2、 缺陷步骤描述3、 附件信息附件信息可根据缺陷需要进行提交。1.4 缺陷数据统计分析缺陷数据统计分析是缺陷跟踪管理的容之一。可以通过选择不同的研究对象，如缺陷的状态、严重程度、优先级、提交人、修复责任人、验证人、解决方案和解决时间等建立查询、统计缺陷数据。项目管理人员应生成缺陷数据统计图表，对统计结果进行分析。一般可建立的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、打开关闭曲线、关闭周期曲线、严重程度统计分布图、优先级统计分布图、缺陷类型统计分布图、缺陷及时处理情况统计表等。通过建立缺陷查询、统计图表，可使项目管理层从不同角度了解当前缺陷的解决进度，更加准确地度量项目的开发质量以及整个开发团队，尤其是开发人员和测试人员的工作效率，使项目管理工作变得更加易于管理、富有成效。