QC管理规范

规范QualityCenter（以下简称QC）平台的缺陷状态及相关字段的流程，统一标准，提高效率。

2.名词解释

产品缺陷是指在产品测试过程中发现的错误、故障及建议的统称（一般也可以称为bug）。

QC平台中缺陷字段列表以及相关描述，如表1：

表1 字段定义及各角色权限对应表

测试 缺陷属性 *缺陷标识(ID) *缺陷状态(Status) *概要(Summary) 测试 负责人 / 有 有 / 研发 人员 / 有 有 / 研发 负责人 / 有 有 / 描 述 人员 缺陷唯一的标识，QC自动生成 详见表2缺陷状态定义 缺陷内容的概要描述 缺陷的详细描述，描述出现该缺陷的步骤，原因/ 有 有 有 *详细描述(Description) 初步分析等等 *缺陷发现者(Detected by) 发现该缺陷的人员 缺陷严重等级是指因缺陷引起的故障对产品的*缺陷严重等级(Severity) 影响程度，详见表3。 缺陷的优先级指缺陷必须被修复的紧急程度，详*缺陷优先级(Priority) 见表4。 *可重现性(Reproducible) 是否可重现此缺陷，详见表8。 *实际修复版本 实际修复缺陷的版本 (Closed in Version) *缺陷发现阶段 *项目(Project) *模块（Subject） 评论(Comments) 缺陷发现时所处的阶段，详见表7 缺陷所在的项目名称和项目编号 缺陷所在的功能模块名称 研发人员、测试人员等相关人员对缺陷进行的评有 有 有 有 有 有 有 有 / 有 有 有 / 有 有 有 有 有 / 有 / / / / 有 / / 有 有 有 / 有 / / / /

论或注释 指派给(Assigned to) 缺陷发现日期 (Detected on Date) 版本 缺陷所在产品的版本信息 (Detected in Version) 预计修复时间 预估修复此缺陷所需要的时间 (Estimated Fix Time) 最近更改时间 (Modified) 缺陷相关信息最后一次被修改的时间（系统自动更新） 计划在此日期前修复缺陷，该字段为非必需字计划修复时间 段，可被定义为开发修复时间，回归测试时间或（Planned Closing Date） Bug关闭时间，必要时可扩展成多个字段 计划修复版本 (Planned Version) 实际修复时间 (Actual Fix Time) 修复日期(Closing Date) 缺陷起源(Source) 缺陷被修复并通过验证的时间。若此项不填，QC则默认为Closing Date - Detected on Date. 缺陷被修复的日期 引起该缺陷的原因，详见表5 在缺陷无法修复的情况下规避此缺陷的方法。该注意事项(Notice) 字段可为空。 质量因素 质量因素，详见表6 New和Open，Open和Fixed状态之间开发和测试过程活动（Action） 交互的活动，详见表9 缺陷引入者（Bug Owner） 导致缺陷产生的人，由PM填写 / / / 有 有 / 有 / / 有 / 有 / / 有 / 有 有 / / 有 / 有 有 / / 有 有 Closing 计划修复缺陷的版本 / / / 有 / / / 有 / / / / / / / 有 修改此缺陷的人，一般由研发负责人指定。 表示该缺陷的发现日期，QC默认为当前的日期，点击可通过日期控件选择不同的日期。 有 有 有 有 / 有 有 有 / 有 有 有 注：标“*”的字段在录入缺陷的时候为必填字段；

表2 状态(Status)定义

缺陷状态 描 述

New Open Rejected Fixed Reopen Closed 新发现并已提交的缺陷 研发负责人确认后的缺陷 研发负责人拒绝的“缺陷” 缺陷已被研发人员修复 缺陷被修复，测试人员确认测试不通过 关闭缺陷 表3 严重等级(Severity)评价

严重程度等级 5-重大 4-主要 3-次要 2-轻微 1-建议 见《产品缺陷等级判定标准》 见《产品缺陷等级判定标准》 见《产品缺陷等级判定标准》 见《产品缺陷等级判定标准》 见《产品缺陷等级判定标准》 描 述 表4 优先级(Priority)对应表

优先级 5-Urgent 4-Very High 描 述 立即进行修改，停止与此密切相关功能的进一步测试。 必须在本版本修改。 必须修改，若需在后续特定版修改，应提出规避措施、明确后续3-High 修改的版本号，且须经过工程应用人员确认。 2-Medium 1-Low 建议修改 允许不修改 注：缺陷处理优先级一般不低于严重等级

表5 缺陷起源

缺陷起源 需求 设计 实现 测试 其他 需求原因引起的缺陷 设计原因引起的缺陷 实现原因引起的缺陷 测试原因引起的缺陷 其他原因或暂时无法确定缺陷原因 描 述

表6 质量因素

质量因素 描 述 指产品发生故障时的容错处理和恢复能力。 可靠性 局部失效不应引起系统级失效。局部失效不应对系统输出带来扰动。 指产品的易理解性、易操作性。 易用性 系统中的提示信息应容易理解，不应出现歧义和误导。 正确性 在指定条件下使用时，产品满足明确和隐含要求的能力。 在约定的条件下运行时的时间特性、资源占用特性。包括响应性能与效率 时间、内存和CPU占用等。 其他 可维护性、可移植性、可测性。 表7 缺陷发现阶段

缺陷发现阶段 需求设计 实现过程 单元测试 集成测试 系统测试 输出测试 验收测试 产品应用 需求设计阶段 编码实现阶段 单元测试阶段 集成测试阶段 系统测试阶段 输出测试阶段 验收测试阶段 产品应用阶段 描 述 表8 缺陷可重现性( Reproducible)定义

可重现性 Y 能够重现的问题 无法重现的问题 N 或者只是偶尔出现的问题，测试人员若无法重现则须描述出现该问题的概率或者次数。 描 述 表9 过程活动（Action）定义

过程活动 描 述

NeedMoreInfo 测试人员描述不详细或者描述不清楚 Can't Reproducible 无法重现 Not Bug Duplicate SpecModify Other Team 不是缺陷 已存在相同缺陷 架构缺陷，无法修改 非本项目BUG 3.缺陷处理流程

3.1.缺陷状态流程示意图

研发人员修改BugReopen未通过修改完成研发人员修改Bug测试人员回归测试Open是Bugfixed测试人员测试New研发负责人判断Bug存在Action字段定义的问题通过Bug存在Action字段定义的问题Rejected测试人员判断Bug存在Action字段定义的除NeedMoreInfo外的问题Closed补充Bug描述后或研发判断不正确

3.2.缺陷处理流程说明

3.2.1 测试人员

 Status：New：新建缺陷或者建议；

 Fixed→Closed：对状态为fixed的缺陷进行回归测试，回归测试通过；

 Rejected→Closed：对状态为Rejected的缺陷确认无法重现、不是缺陷、已存在相同

缺陷或架构缺陷，无法修改后；

 Rejected→New：对状态为Rejected的缺陷补充更多信息后；

 Fixed→Reopen：回归测试未通过。

3.2.2 测试负责人

 *Any→Closed：在和相关人员讨论之后最终决定需关闭缺陷时；

 *Any→Open：缺陷不在本版本中修改时，同时研发负责人在Planned Closing Version

中选定后续修改的版本。  更改Severity属性。

3.2.3 研发人员

 Open(Reopen)→Fixed：缺陷已修复；

 Open→Rejected：测试人员提交的缺陷需要更多信息、无法重现、不是缺陷、已存在相

同缺陷或架构缺陷，无法修改时。研发人员拒绝缺陷时须在Action里注明拒绝的原因。

3.2.4 研发负责人

 New→Rejected：测试人员提交的缺陷需要更多信息、无法重现、不是缺陷、已存在相

同缺陷或架构缺陷，无法修改时。研发负责人拒绝缺陷时须在Action里注明拒绝的原因；

 Open→Rejected：测试人员提交的缺陷需要更多信息、无法重现、不是缺陷、已存在相

同缺陷或架构缺陷，无法修改时。研发负责人拒绝缺陷时须在Action里注明拒绝的原因；

 New→Open：测试人员提交的缺陷的确是问题，并更改Assigned to属性将此bug指派

给某个具体的研发人员修改；

 本版本不修改的bug，已明确在后续某个版本修改的，在Planned Closing Version字

段候选项中添加该版本后选择，对于暂无法明确修改版本的，Planned Closing Version字段设置为Later Version；  更改Priority属性。

3.3.其它

 在项目后续测试过程中若发现已经Closed的缺陷出现，则重新录入新的缺陷。  严重等级4级或以上的bug以及Reopen的bug，研发人员必须填写3W( What is the

problem, What is the root cause, What is the solution )，测试人员回归测试时

确认，如未填写3W，直接Reopen。

 缺陷状态为Closed或者状态为Open且Planned Closing Version非空时为最终状态，

其余均为中间状态。