Bug 提交管理规范
修订历史


1. BUG 管理工具介绍
常用的 BUG 管理工具有 JIRA、BugFree、Bugzilla、Mantis、XPWeb 等。我们公司采用 的是 JIAR，JIRA 是 Atlassian 公司出品的项目与事务跟踪工具， 被广泛应用于缺陷跟踪、 客 户服务、需求采集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
2. BUG 定义
1. BUG 分类
BUG 就是指系统存的各种缺陷，可以从不少角度对BUG 进行分类。
1、从功能方面分，产生 BUG 的原因大体可以归结为以下四种：
A.重复的功能；        B.多余的功能；
C.功能没有达到设计的要求；  D.功能实现与设计要求不相符。
2、从易用性方面分，可以归结为三点：
A.界面不美观，控件罗列、格式不统一，焦点控制不合理或者不全面； B.缺少匡助信息，或者匡助信息不彻底；
xp提交更改C.功能操作复杂，提示信息不合理，易产生歧义。
3、从 安全性方面分， BUG 可以划分为以下几类：
A.数据有效性检测不合理；   B.重要数据在传输中没有加密；
C.缺少身份认证机制或者认证不合理； D.数据产生缺乏随机性；
E．网络安全性：开放端口、服务； F ．系统日志、审计。
4、从 可靠性方面分， BUG 可划分为以下几类：
A.数据存贮的可靠性；  B.业务处理的可靠性；
C．硬件可靠性：如打印机； D.应急处理措施；
E ．数据备份、恢复。
5、从性能方面考虑， BUG 可划分为三种：
A．并发量； B．吞吐量；  C ．响应时间。
6 、从兼容性方面考虑， BUG 有两种：
A．硬件兼容性；  B ．软件兼容性。
7、从可维护性方面考虑，可划分为两种原因：
A．可扩展性；  B ．方便升级。
2. Bug 等级
BUG 等级是根据 BUG 浮现在系统中的严重程度来分的，主要定义如下5 级：
1  级—— 致命： 系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导 致用户利益受到重大损失。该级别需要程序员修改。
2 级—— 严重： 系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益 受到
损失。该级别需要程序员修改。
3  级—— 普通： 系统次要功能无法实现；主要功能部份失效；系统业务受到影响；导 致用户利益受到一定损失。该级别需求程序员修改。

4 级—— 弱小： 系统能够正常使用，但有潜在风险；系统业务受到轻微影响。如提示 信息不完整。该级别需要程序员修改。
5  级—— 改进： 不影响正常使用，对功能几乎没有影响，产品及属性仍可使用，如有 个错别字。修改优先级为低，该级别建议程序员修改。
3. Bug 状态
BUG 状态标记 BUG 当前所处的状态， 是用来处理 BUG 流程的主要参数， JIRA 缺陷管 理平台有以下一些状态：
开始：测试人员新发现的系统 Bug；
进行中：开辟人员正在修改的 BUG；
已解决：开辟人员通知测试人员已修复的BUG；
关闭：测试人员经回归测试后确定已修复的BUG；
重新打开： Bug 未被修复，重新浮现在新的测试版本中；
4. Bug 优先级
➢  危（wei）险 ：要求即将修改，作为修改最高等级；
➢  严重： 要求重点修改，产品发布前必须修复；
➢  重要： 需要尽快进行修改，产品发布前必须修复；
➢  轻微： 如果时间允许应该修改；
➢  弱小： 可能要修复，时间空余情况下进行修改。
3. BUG 的生命周期
1、测试人员在测试中发现 BUG 需要将其添加记录到JIRA 中，然后由相关人员对 BUG 进行分配(普通由项目经理分配)给对应的开辟人员进行处理。
2、开辟人员修改好 BUG 后需要在注释框中填写说明信息，并将BUG 的状态设为“已  解决”状态，同时开辟人员如果认为有的缺陷没有必要修改、无法重现、延期修改等，可将 其设置为对应的“不解决”、 “重复提交”、 “Not a bug”、 “无法再次重现”、 “未完成” 等状态。
3、开辟人员处理完毕BUG 后需要测试人员对 BUG 进行验证，验证通过后就把其状态 设置为“关闭”状态，若验证不通过则把状态设置为“重现开启”状态。
4、对被置为 ‘不解决’状态的 BUG，测试人员与开辟人员商议后允许关闭， 则置为 ‘关 闭’；若测试人员不允许关闭则提交到产品负责人处，由他来决定是否要修改，若要修改， 则把 BUG 状态置为 “重新开启”，然后开辟人员继续修改； 若不用再修改则置为 ‘关闭’； 若延期处理则置为‘未完成’。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。