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

1/1OI-IT-20_缺陷管理规范缺陷管理规范2012年12月27日起发布实施文档修订历史修订版本修订日期作者审核人批准人说明目的本文档用于规范信息系统部缺陷管理的过程以及与缺陷相关的一些属性。

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

定义/专用术语Administrators:系统管理员Developer:开人员Users：

AllMembersBug：

缺陷职责配置组：

定期对Jira系统及数据库进行维护，数据备份。

(建议每天备份时间为24：

00)测试组：

依照需求规格及测试用例进行测试。

提交Bug，IssueType必须选为BUG类型，对Bug进行状态跟踪，对已交付Bug进行验证；项目组定期组织会议跟踪Bug处理进度，定期提交Bug汇总报告。

开发组：

及时接收处理Bug，修复Bug所涉及相关问题，如因其他原因不能及时修复，应及时将原因通知项目经理，由项目组协调决定是否修复，并在Bugcomment中注明缘由。

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

工作程序缺陷理论5.1.1缺陷生命周期从提交到关闭状态，所有bugs都要经历一个特定的生命周期，信息系统部缺陷生命周期是在Jira中定义的，它一共有5个状态，具体如下：

Created-一个新的缺陷被提交后的状态；Open-bug停留未开始修复状态Reopenedbug没修复完全或者再次出现InProgressbug修复中Resolved-当bug被处理完后，DEV就可以选择相应的处理结果（Fixed,WontFix,Incomplete,,Dplicated,CannotReporduce）；Closed-缺陷被验证通过，提交者改成Closed状态；5.1.2缺陷库权限控制缺陷管理按照三个角色来定义权限，它们分别是：

Developers,Users,Administrator。

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

特别注明：

缺陷只能由提交者才能关闭。

5.1.3缺陷属性下面描述了Jira的缺陷相关属性，同时各个项目可以根据自己的不同特点添加相关属性，标准信息如下（红色标记为必填字段）：

IDBug的唯一识别码,系统自动生成State参考Jira缺陷生命周期流程图，此状态由系统自动转换SummaryBug概要描述PriorityBug优先级SeverityBug严重级别Component组件模块名称AffectsVersio/sbug发现版本FixVersion/sBug修复版本AssigneeBug修复人员ReporterBug提交人员Environment测试环境描述DescriptionBug详细信息Blocked是否阻塞测试AttachmentBug附加描述信息5.1.4缺陷级别(Severity)缺陷的严重级别是由提交者根据它的表现情况而决定的，包括但是不限于以下所述问题:重级别状态描述举例Blocks（致命）致命错误：

a、导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等。

b、由于程序引起的非法死机，退出，数据丢失，主要功能完全丧失等错误。

从用户角度：

由于产品功能或者性能造成80%以上用户无法使用的问题：

a)操作某一功能时，导致程序异常退出，或其余功能无法使用，或造成经常性死机和重启b)内存泄漏c)用户数据丢失或破坏d)系统崩溃/死机/冻结e)模块无法启动或异常退出f)严重的数值计算错误g)功能设计与需求严重不符h)导致其它功能无法测试的错误Cirtical（严重）严重错误：

a、较大的功能缺陷如该功能没有实现或实现有错误，b、严重影响系统要求或基本功能的实现，且没有办法更正冲突。

C、主要功能丧失，导致严重的问题，或致命的错误声明。

从用户角度：

用户可以使用，但性能非常不稳定，经常出现服务中断a)实现的功能与相关需求严重不符，b)功能未实现c)功能错误d)系统刷新错误e)轻微的数值计算错误f)系统所提供的功能或服务受到明显的影响Major（一般性错误）普通错误：

次要功能丧失，不太严重，可通过变通手段解决。

从用户角度：

用户可以使用，偶尔出现服务中断（软件功能和需求规格级别基本相符）。

a)边界值的处理无效，重要界面的显示问题，会对用户产生一定影响的文字错误b)操作界面错误（包括数据窗口内列名定义、含义是否一致）c)边界条件显示错误d)提示信息错误（包括未给出信息、信息提示错误等）e)长时间操作无进度提示f)系统未优化（性能问题）g)光标跳转设置不好，鼠标（光标）定位错误a)字符串显示不统一，b)拼写、对齐类的错误、UI图标、文字性错误；c)界面显示不美观但对用户不产生影响的问题；d)不经常出现而且用户可恢复的非严重问题，e)辅助说明描述不清楚f)操作时未给用户提示g)可输入区域和只读区域没有明显的区分标志h)个别不影响产品理解的错别字i)文字排列不整齐等一些小问题Minor（较小错误）较小的功能缺陷：

微小的问题，如果不进行修改，不影响主要功能，产品及属性仍可使用，如有字符大小不统一。

从用户角度：

用户可以使用，但交互性不好，对于用户可能造成难于操作、学习和理解。

Trivial（建议性）建议性意见：

从使用者角度，提出的建议性意见。

从用户角度：

个别功能使用不够方便，但是不影响用户使用的问题a)用户界面不太友好；b)使用不习惯；c)好的操作建议等；5.1.5缺陷优先级(Priority)缺陷的优先级是由测试Teamlead或者PM根据缺陷严重程度以及版本发布策略来定义。

P1立即解决P2高度关注P3正常排队P4低优先级优先级(Priority)应变措施(Resolution)预计完成时间预设值(EstimatedFinishDate)P1-立即解决立即修改完成(Fiximmediately)即日完成P2-高度关注下一个版本结束前必须修改完成(Fixbeforenextstage)三个工作日内P3-正常排队产品推出前必须修改完成(Fixbeforerelease)七个工作内P4-低优先级如果时间允许才进行修改(Fixifavailable)十五个工作天内5.1.6缺陷描述规范这里我们主要关注缺陷报告的如下两个方面。

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

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

可重现按照描述中给出的步骤可以再现缺陷隔离仅描述重现Bug所需的必要步骤，没有冗余步骤简洁简要而清楚地说明问题，只解释事实和描述软件缺陷必需的细节单一每个报告只针对一个缺陷完整信息完整，包含预期结果，实际结果，必要的补充说明（如截屏图）等中立只要求说出事实。

不带倾向性、个人观点和煽动性发现及提交Bug当发现一个Bug时，报告人员应第一时间确定Bug所属产品模块并按缺陷规范要求提交Bug记录到缺陷管理库，系统将自动发送邮件到预先定义产品负责人邮箱。

审核接收外部入口提交Bug到缺陷库后，应先由测试人员进行审核接收，确认是否为真实Bug，并按缺陷管理规范完善所需信息后分配Bug到所属产品模块负责人。

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

如果是自己负责项目Bug，应先更改Bug状态更改为INprogress。

如果不是，需要重新分配Bug给项目经理，由项目经理确定最终