OI-IT-缺陷管理规范

个人收集整理勿做商业用途

缺陷管理规范2012年12月27日起发布实施

文档修订历史

目的

本文档用于规范信息系统部缺陷管理的过程以及与缺陷相关的一些属性。

适用范围

本文档适用于研发测试过程中所有缺陷的处理。

定义/ 专用术语

⏹Administrators:系统管理员

⏹Developer:开人员

⏹Users：All Members

⏹Bug：缺陷

职责

配置组：

⏹定期对Jira系统及数据库进行维护，数据备份。(建议每天备份时间为24：00)

测试组：

⏹依照需求规格及测试用例进行测试。提交Bug，Issue Type必须选为BUG类型，对

Bug进行状态跟踪，对已交付Bug进行验证；项目组定期组织会议跟踪Bug处理

进度，定期提交Bug汇总报告。

开发组：

⏹及时接收处理Bug，修复Bug所涉及相关问题，如因其他原因不能及时修复，应

及时将原因通知项目经理，由项目组协调决定是否修复，并在Bug comment 中注

明缘由。项目组应定期组织会议，对未修复Bug进行协商，或调整优先级。

工作程序

缺陷理论

5.1.1缺陷生命周期

⏹从提交到关闭状态，所有bugs都要经历一个特定的生命周期，信息系统部缺

陷生命周期是在Jira中定义的，它一共有5个状态，具体如下：

Created- 一个新的缺陷被提交后的状态；

Open -bug停留未开始修复状态

Reopened – bug没修复完全或者再次出现

In Progress –bug修复中

Resolved- 当bug被处理完后，DEV就可以选择相应的处理结果

（Fixed,Won’t Fix,Incomplete,, Dplicated,Cannot Reporduce）；

Closed- 缺陷被验证通过，提交者改成Closed状态；

5.1.2缺陷库权限控制

⏹缺陷管理按照三个角色来定义权限，它们分别是：

Developers,Users,Administrator。

⏹各角色具体最终权限的控制需要根据缺陷管理工具和各项目实际情况而定。

特别注明：缺陷只能由提交者才能关闭。

5.1.3缺陷属性

⏹下面描述了Jira的缺陷相关属性，同时各个项目可以根据自己的不同特点添加

相关属性，标准信息如下（红色标记为必填字段）：

ID – Bug的唯一识别码,系统自动生成

State –参考Jira缺陷生命周期流程图，此状态由系统自动转换

Summary – Bug概要描述

Priority – Bug优先级

Severity – Bug 严重级别

Component –组件模块名称

Affects Versio/s–bug发现版本

Fix Version/s – Bug修复版本

Assignee – Bug修复人员

Reporter – Bug提交人员

Environment –测试环境描述

Description – Bug详细信息

Blocked –是否阻塞测试

Attachment – Bug附加描述信息

5.1.4缺陷级别(Severity)

⏹缺陷的严重级别是由提交者根据它的表现情况而决定的，包括但是不限于以下

所述问题:

5.1.5

缺陷优先级(Priority)

缺陷的优先级是由测试Team lead 或者PM 根据缺陷严重程度以及版本发布策

略来定义。 P1 – 立即解决 P2 – 高度关注 P3 – 正常排队 P4 – 低优先级

5.1.6缺陷描述规范

这里我们主要关注缺陷报告的如下两个方面。

⏹摘要（Summary）

努力做到将问题抽象化，争取用最少的语言清晰的描述存在的问题，通过一句话描述清楚该缺陷的主要信息。

⏹描述（Description）

有效的缺陷报告描述一般具备以下特征：

●可重现——按照描述中给出的步骤可以再现缺陷

●隔离——仅描述重现Bug所需的必要步骤，没有冗余步骤

●简洁——简要而清楚地说明问题，只解释事实和描述软件缺陷必需

的细节

●单一——每个报告只针对一个缺陷

●完整——信息完整，包含预期结果，实际结果，必要的补充说明（如

截屏图）等

●中立——只要求说出事实。不带倾向性、个人观点和煽动性

发现及提交Bug

⏹当发现一个Bug时，报告人员应第一时间确定Bug所属产品模块并按缺陷规范要

求提交Bug记录到缺陷管理库，系统将自动发送邮件到预先定义产品负责人邮箱。审核接收

⏹外部入口提交Bug到缺陷库后，应先由测试人员进行审核接收，确认是否为真实

Bug，并按缺陷管理规范完善所需信息后分配Bug到所属产品模块负责人。

分配处理

⏹研发人员收到Bug记录邮件通知后，应及时判定Bug是否为归属自己。如果是自

己负责项目Bug，应先更改Bug 状态更改为IN progress。如果不是，需要重新分配Bug给项目经理，由项目经理确定最终负责修复Bug人员。

验证测试

⏹当一个新版本发布，测试人员检索已经修复Bug，安排测试计划，经测试人员验证

通过后关闭。

⏹如果一个Bug在随后版本发现或部分修复，验证人员需要将此Bug重新打开，Bug

状态切换到NEW状态，系统自动邮件通知研发人员修复Bug。

支持性文件

⏹无

记录保存

⏹相关记录保存在缺陷库中，期限是三年。

流程图

⏹无