bug管理规范

一、概述

本规范是常规的bug管理流程,适用于项目过程中的bug管理

 二、BUG周期

 三、Bug的分类、状态、级别

 3.1 bug分类

  1. 功能 A.重复的功能;B.多余的功能;C.功能没有达到设计的要求;D.功能实现与设计要求不相符。
  2. 易用性 A.界面不美观,控件排列、格式不统一,焦点控制不合理或不全面;B.缺少帮助信息,或者帮助信息不完全; C.功能操作复杂,提示信息不合理,易产生歧义。
  3. 安全性 A.数据有效性检测不合理;B.重要数据在传输中没有加密;C.缺少身份认证机制或认证不合理;
  4. 可靠性 A.数据存贮的可靠性;B.业务处理的可靠性;
  5. 性能 A.并发量;B.吞吐量;C.响应时间。
  6. 兼容性 不同厂商的浏览器以及浏览器的不同版本,手机 app指不同操作系统

 3.2 bug状态

Bug的状态主要分为新建、已分派、已解决、重新打开、已关闭、挂起。

• 新建状态( NEW ): Bug创建后的初始状态。
• 已分派状态(ASSIGNED):经过确认为有效问题后分配给开发人员的状态。
• 已解决状态(RESOLVED):开发人员对软件问题进行处理或修改后的状态。
• 重新打开状态(REOPENED):对开发人员修改后软件问题,经过验证,如果仍然存在,则 将其状态改为“重新打开”状 态。
• 关闭状态(CLOSED):Bug解决后测试人员验证通过,则将其状态修改为已关闭
• 挂起状态:经过项目经理确认延期修改的bug

 3.3 bug严重等级和优先级定义

bug的严重级别定义:

严重等级
描述
对应的优先级
S 严重影响用户使用,且需要立即修复的线上bug,通常对应A、B级的线上bug P1
A 软件崩溃、严重丢失数据或严重的内存泄露 P1
B 功能没有实现,主流程bug P1
C 一般的错误,普通的 bug P2
D 轻微的错误,不至于影响软件的使用,而且应该很容易解决 P3

BUG优先级定义:

优先级
描述
备注
P1 需要马上修复的bug。  
P2 应该尽快修复的bug,但不是很急  
P3 可以以后修复的bug  

 四bug描述规范

bug描述要简洁明了,方便开发人员重现和后续跟踪。
版本:当前测试的版本号
平台:测试使用的平台说明
摘要:概要描述问题。 
描述:应该描述问题发现的步骤、期望结果和实际结果
描述可分为“步骤”、“结果”(含:期望结果、实际结果)、“补充说明”三部分,各部分之间用空行隔开。“补充说明”部分可根据实际情况选择是否需要描述。具体格式如下:
步骤:

期望结果:
实际结果:

补充说明:

  1. 如果多处出现类似问题,应描述出现该问题的所有模块或界面。
  2. 如果不可重现,应说明
    附件:添加错误附图或错误信息。

猜你喜欢

转载自blog.csdn.net/zhaodj5660/article/details/79975714