1、编号： OI-IT-20缺陷管理规范页码/页数： 1/10工作文件 版本 A 修订次数 00 修订人 修订日期 2012-12-27第 1 页，总 10 页缺陷管理规范2012 年 12 月 27 日起发布实施编号： OI-IT-20缺陷管理规范页码/页数： 2/10工作文件 版本 A 修订次数 00 修订人 修订日期 2012-12-27第 2 页，总 10 页文档修订历史修订版本修订日期 作者 审核人 批准人 说明编号： OI-IT-20缺陷管理规范页码/页数： 3/10工作文件 版本 A 修订次数 00 修订人 修订日期 2012-12-27第 3 页，总 10 页目的本文档用于规范信息
2、系统部缺陷管理的过程以及与缺陷相关的一些属性。适用范围本文档适用于研发测试过程中所有缺陷的处理。定义 / 专用术语 Administrators:系统管理员 Developer:开人员 Users：All Members Bug：缺陷职责 配置组： 定期对 Jira 系统及数据库进行维护，数据备份。(建议每天备份时间为 24：00)测试组： 依照需求规格及测试用例进行测试。提交 Bug，Issue Type 必须选为 BUG 类型，对 Bug 进行状态跟踪，对已交付 Bug 进行验证；项目组定期组织会议跟踪 Bug处理进度，定期提交 Bug 汇总报告。开发组： 及时接收处理 Bug，修复 Bu
3、g 所涉及相关问题，如因其他原因不能及时修复，应及时将原因通知项目经理，由项目组协调决定是否修复，并在 Bug comment 中注明缘由。项目组应定期组织会议，对未修复 Bug 进行协商，或调整优先级。编号： OI-IT-20缺陷管理规范页码/页数： 4/10工作文件 版本 A 修订次数 00 修订人 修订日期 2012-12-27第 4 页，总 10 页工作程序缺陷理论5.1.1 缺陷生命周期 从提交到关闭状态，所有 bugs 都要经历一个特定的生命周期，信息系统部缺陷生命周期是在 Jira 中定义的，它一共有 5 个状态，具体如下： Created- 一个新的缺陷被提交后的状态； Ope
4、n -bug 停留未开始修复状态 Reopened bug 没修复完全或者再次出现 In Progress bug 修复中 Resolved- 当 bug 被处理完后，DEV 就可以选择相应的处理结果（Fixed,Wont Fix,Incomplete, Dplicated,Cannot Reporduce） ； Closed- 缺陷被验证通过，提交者改成 Closed 状态；编号： OI-IT-20缺陷管理规范页码/页数： 5/10工作文件 版本 A 修订次数 00 修订人 修订日期 2012-12-27第 5 页，总 10 页5.1.2 缺陷库权限控制 缺陷管理按照三个角色来定义权限，它们
5、分别是：Developers,Users,Administrator。 各角色具体最终权限的控制需要根据缺陷管理工具和各项目实际情况而定。特别注明：缺陷只能由提交者才能关闭。5.1.3 缺陷属性 下面描述了 Jira 的缺陷相关属性，同时各个项目可以根据自己的不同特点添加相关属性，标准信息如下（红色标记为必填字段）： ID Bug 的唯一识别码,系统自动生成 State 参考 Jira 缺陷生命周期流程图，此状态由系统自动转换 Summary Bug 概要描述 Priority Bug 优先级编号： OI-IT-20缺陷管理规范页码/页数： 6/10工作文件 版本 A 修订次数 00 修订人
6、修订日期 2012-12-27第 6 页，总 10 页 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) 缺陷的严重级别是由提交者根据它的表现情况而决定的，包括但是不限于以下所述问题:重级别 状态描述 举例Block
7、s（致命）致命错误：a、导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等。b、由于程序引起的非法死机，退出，数据丢失，主要功能完全丧失等错误。从用户角度：由于产品功能或者性能造成 80%以上用户无法使用的问题：a) 操作某一功能时，导致程序异常退出，或其余功能无法使用，或造成经常性死机和重启b) 内存泄漏c) 用户数据丢失或破坏d) 系统崩溃/死机/冻结e) 模块无法启动或异常退出f) 严重的数值计算错误g) 功能设计与需求严重不符h) 导致其它功能无法测试的错误Cirtical（严重）严重错误：a、较大的功能缺陷 如该功能没有实现或实现有错误，b、严重影响系统要求
8、或基本功能的实现，且没有办法更正冲突。C、主要功能丧失，导致严重的问题，或致命的错误声明。a) 实现的功能与相关需求严重不符，b) 功能未实现c) 功能错误d) 系统刷新错误e) 轻微的数值计算错误f) 系统所提供的功能或服务受到明编号： OI-IT-20缺陷管理规范页码/页数： 7/10工作文件 版本 A 修订次数 00 修订人 修订日期 2012-12-27第 7 页，总 10 页从用户角度：用户可以使用，但性能非常不稳定，经常出现服务中断显的影响Major（一般性错误）普通错误：次要功能丧失， 不太严重，可通过变通手段解决。从用户角度：用户可以使用，偶尔出现服务中断（软件功能和需求规格级
9、别基本相符）。a) 边界值的处理无效，重要界面的显示问题，会对用户产生一定影响的文字错误b) 操作界面错误（包括数据窗口内列名定义、含义是否一致）c) 边界条件显示错误d) 提示信息错误（包括未给出信息、信息提示错误等）e) 长时间操作无进度提示f) 系统未优化（性能问题）g) 光标跳转设置不好，鼠标（光标）定位错误Minor（较小错误）较小的功能缺陷：微小的问题， 如果不进行修改，不影响主要功能，产品及属性仍可使用，如有字符大小不统一。从用户角度：用户可以使用，但交互性不好，对于用户可能造成难于操作、学习和理解。a) 字符串显示不统一，b) 拼写、对齐类的错误、UI 图标、文字性错误；c)
10、界面显示不美观但对用户不产生影响的问题；d) 不经常出现而且用户可恢复的非严重问题，e) 辅助说明描述不清楚f) 操作时未给用户提示g) 可输入区域和只读区域没有明显的区分标志h) 个别不影响产品理解的错别字i) 文字排列不整齐等一些小问题Trivial（建议性）建议性意见：从使用者角度，提出的建议性意见。从用户角度：个别功能使用不够方便，但是不影响用户使用的问题a) 用户界面不太友好；b) 使用不习惯；c) 好的操作建议等；编号： OI-IT-20缺陷管理规范页码/页数： 8/10工作文件 版本 A 修订次数 00 修订人 修订日期 2012-12-27第 8 页，总 10 页5.1.5 缺
11、陷优先级(Priority) 缺陷的优先级是由测试 Team lead 或者 PM 根据缺陷严重程度以及版本发布策略来定义。P1 立即解决P2 高度关注P3 正常排队P4 低优先级优先级 (Priority)应变措施 (Resolution) 预计完成时间预设值 (Estimated Finish Date)P1-立即解决立即修改完成 (Fix immediately)即日完成P2-高度关注下一个版本结束前必须修改完成 (Fix before next stage)三个工作日内P3-正常排队产品推出前必须修改完成 (Fix before release)七个工作内P4-低优先级如果时间允许才进
12、行修改 (Fix if available)十五个工作天内5.1.6 缺陷描述规范这里我们主要关注缺陷报告的如下两个方面。 摘要（Summary）努力做到将问题抽象化，争取用最少的语言清晰的描述存在的问题，通过一句话描述清楚该缺陷的主要信息。 描述（Description ）有效的缺陷报告描述一般具备以下特征： 可重现 按照描述中给出的步骤可以再现缺陷 隔离 仅描述重现 Bug 所需的必要步骤，没有冗余步骤编号： OI-IT-20缺陷管理规范页码/页数： 9/10工作文件 版本 A 修订次数 00 修订人 修订日期 2012-12-27第 9 页，总 10 页 简洁 简要而清楚地说明问题，只解
13、释事实和描述软件缺陷必需的细节 单一 每个报告只针对一个缺陷 完整 信息完整，包含预期结果，实际结果，必要的补充说明（如截屏图）等 中立 只要求说出事实。不带倾向性、个人观点和煽动性发现及提交 Bug 当发现一个 Bug 时，报告人员应第一时间确定 Bug 所属产品模块并按缺陷规范要求提交 Bug 记录到缺陷管理库，系统将自动发送邮件到预先定义产品负责人邮箱。审核接收 外部入口提交 Bug 到缺陷库后，应先由测试人员进行审核接收，确认是否为真实Bug，并按缺陷管理规范完善所需信息后分配 Bug 到所属产品模块负责人。分配处理 研发人员收到 Bug 记录邮件通知后，应及时判定 Bug 是否为归属
14、自己。如果是自己负责项目 Bug，应先更改 Bug 状态更改为 IN progress。如果不是，需要重新分配 Bug 给项目经理，由项目经理确定最终负责修复 Bug 人员。验证测试 当一个新版本发布，测试人员检索已经修复 Bug，安排测试计划，经测试人员验证通过后关闭。 如果一个 Bug 在随后版本发现或部分修复，验证人员需要将此 Bug 重新打开，Bug 状态切换到 NEW 状态，系统自动邮件通知研发人员修复 Bug。支持性文件 无编号： OI-IT-20缺陷管理规范页码/页数： 10/10工作文件 版本 A 修订次数 00 修订人 修订日期 2012-12-27第 10 页，总 10 页记录保存 相关记录保存在缺陷库中，期限是三年。流程图 无
