OI-IT-20 缺陷管理规范.docVIP

缺陷管理规范 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进行协商，或调整优先级。 工作程序 缺陷理论 缺陷生命周期 从提交到关闭状态，所有bugs都要经历一个特定的生命周期，信息系统部缺陷生命周期是在Jira中定义的，它一共有5个状态，具体如下： Created- 一个新的缺陷被提交后的状态； Open -bug停留未开始修复状态 Reopened – bug没修复完全或者再次出现 In Progress –bug修复中 Resolved- 当bug被处理完后，DEV就可以选择相应的处理结果（Fixed,Won’t Fix,Incomplete,, Dplicated,Cannot Reporduce）； Closed- 缺陷被验证通过，提交者改成Closed状态； 缺陷库权限控制 缺陷管理按照三个角色来定义权限，它们分别是：Developers,Users,Administrator。 各角色具体最终权限的控制需要根据缺陷管理工具和各项目实际情况而定。 特别注明：缺陷只能由提交者才能关闭。 缺陷属性 下面描述了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附加描述信息 缺陷级别(Severity) 缺陷的严重级别是由提交者根据它的表现情况而决定的，包括但是不限于以下所述问题: 重级别 状态描述 举例 Blocks（致命） 致命错误：a、导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等。b、由于程序引起的非法死机，退出，数据丢失，主要功能完全丧失等错误。从用户角度：由于产品功能或者性能造成80%以上用户无法使用的问题： 操作某一功能时，导致程序异常退出，或其余功能无法使用，或造成经常性死机和重启 内存泄漏 用户数据丢失或破坏 系统崩溃/死机/冻结 模块无法启动或异常退出 严重的数值计算错误 功能设计与需求严重不符 导致其它功能无法测试的错误 Cirtical（严重） 严重错误：a、较大的功能缺陷 如该功能没有实现或实现有错误，b、严重影响系统要求或基本功能的实现，且没有办法更正冲突。C、主要功能丧失，导致严重的问题，或致命的错误声明。从用户角度：用户可以使用，但性能非常不稳定，经常出现服务中断 实现的功能与相关需求严重不符， 功能未实现 功能错误 系统刷新错误 轻微的数值计算错误 系统所提供的功能或服务受到明显的影响 Major（一般性错误） 普通错误：次要功能丧失， 不太严重，可通过变通手段解决。从用户角度：用户可以使用，偶尔出现服务中断（软件功能和需求规格级别基本相符）。 边界值的处理无效，重要界面的显示问题，会对用户产生一定影响的文字错误 操作界面错误（包括数据窗口内列名定义、含义是否一致） 边界条件显示错误 提示信息错误（包括未给出信息、信息提示错误等） 长时间操作无