软件测试之BUG的生命周期

大家好，又见面了，我是你们的朋友全栈君。

       作为一名测试人员，重要的工作内容之一，就是找BUG，提交BUG，验证BUG，推进BUG的解决，直至软件达到发布的标准，提高软件的质量，及研发的工作效率和质量。

       要找BUG，那么，就要先了解一下BUG的定义是什么？

BUG的定义：

       软件的BUG,狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。

       我们的职责就是，发现这些BUG，并提交给开发，让开发去修改。

BUG的由来

1、缺乏有效沟通

2、软件的复杂度

3、编程错误

4、不断变更的需求

5、时间的压力

      了解了BUG的定义以及由来后，那就要去了解BUG的类型，只有了解了BUG的类型，才能有的放矢，才能有目的，有范围的去寻找BUG，避免盲目寻找BUG，浪费宝贵的测试时间。 

BUG的类型

       要确定一个BUG的类型，需要对项目（或产品）有比较深的理解。这个划分对于问题类型的统计就比较重要了。

       划分方式一：

       功能问题、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、文档错误、兼容问题、用户体验、其它。

       划分方式二：

      功能类、性能类、界面类、易用性类、兼容性类、其它。

       找到BUG后，那么，就要对BUG区分等级，以便开发人员，根据BUG的优先级来处理BUG，优先解决紧急的，致命的BUG，次要解决严重的BUG，接着解决一般的BUG，再接着解决轻微的BUG，最后，解决界面上的细小问题，这样，能提高软件研发的进度，提高软件的质量。

BUG的等级

       Bug等级，这个划分有分三级或四级，也有分五级的。如果是等级越高，那么可能被修复的等级会高一些，有些公司还会根据你提的BUG数量和BUG等级来考察你的绩效。很多情况下，我们提交BUG大致的等级差不多即可，没有严格区分。

如何判断BUG的等级（严重程度1、2、3、4），一般可以参照下面的判断条件

    1、致命错误（1级提BUG需慎重）

（1）常规操作引起的系统崩溃，死机，死循环

（2）造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露

（3）涉及金钱

（4）用户数据受到破坏，或者危及人身安全

     2、严重错误

 （1）重要功能不能实现；

 （2）错误的涉及面广，影响到其他重要功能的正常实现；

  （3）严重操作导致的程序崩溃、死机、死循环；

  （4）外观难以接受的缺陷；

  （5）密码明文显示；

  （6）数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响

    3、一般错误

不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷

  （1）次要功能不能正常实现；

  （2）操作界面错误（包括数据窗口内列名定义、含义不一致）；

  （3）查询错误，数据错误显示；

  （4）简单的输入限制未放在前端进行控制；

  （5）删除操作未给出提示；

     4、细微错误

程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

   （1）界面不规范；

   （2）辅助说明描述不清楚；

   （3）提示窗口文字未采用行业术语；

   （4）界面存在文字错误；

三级BUG_未修改成功，又重新打开等级上升一次_二级BUG_二级还是没解决_直接一级BUG

改进建议：可以提高产品质量的建议，包括新需求和对需求的改进。

       找到BUG，提交BUG后，那么，就要进入BUG的生命周期了。

bug的生命周期

BUG的生命周期，就是一个BUG被发现到这个BUG被关闭的过程。

生命周期中缺陷状态：新建–>指派–>已解决–>待验–>关闭

发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG

如果待验的BUG在验证时没有解决好，我们需要重新打开–指派—已解决—待验，循环这个过程。

中间其他状态：拒绝、延期等

BUG的处理流程图（生命周期图）

设计如此（不是缺陷）：1、核对需求规格说明书  2、找业务或者产品进行确认  3、确认是设计如此（不是缺陷），则直接关闭BUG。4、确认设计不是如此，跟开发沟通，重新激活指派BUG

重复BUG： 测试人员找到对应重复BUG的ID。如果确认是重复BUG，直接关闭（通常是关闭，后面提交的那个重复的BUG）

无法重现：1、确认开发的环境，跟操作步骤是否跟测试人员一致；2、在与提交BUG相同的环境下，重复验证一定的次数，比如，15-20次等，再未重现BUG，将状态该为无法重现

注意事项：

开发人员应在BUG系统中，备注好以下信息：

已修改BUG应在该BUG的注释处，备注修改方案及信息，以备以后出现类似的问题时，可以快速的找到原因

设计如此（不是缺陷）、不予解决、延期解决的BUG、无法重现的BUG，应备注处理的原因，节省沟通的时间，以及，如果后续有相同问题时，可以快速查找到原因

重复BUG注明重复BUGID

状态处理

1.已经指派的BUG—已经指派给开发的，应随时关注并进行跟踪自己所提BUG的状态变化！如果一直未修复，提醒开发人员修改；如果已经修复等待测试环境更新后进行验证

2.已解决的BUG—-等待测试环境更新后进行验证，验证通过则关闭；验证不通过则重新指派给开发

3.重复BUG—-先去查看下是否跟开发指定的BUG或者，自己在BUG系统内看到的BUG重复？如果确定重复则关闭；如果不重复，说明原因，重新打开指派给开发。

4.不是缺陷—-确认开发环境是否和测试环境一致，如果如开发所说不是缺陷则进行关闭；如果确认是缺陷跟开发沟通，沟通未达一致找产品/反馈老大确认，确认是BUG注明情况并再次指派给开发。

5.无法重现—-确认开发环境是否跟测试环境一致？包括操作步骤，浏览器、环境、特定账号等，如果多个版本验证之后，如开发所说重现不了，依据BUG的严重程度跟产品，开发一起确认关闭；如果找到重现原因，注明清楚并再次指派给开发。

6.不予解决—找产品经理进行确认。确认不予解决进行关闭；确认需要解决请备注原因并打开指派给开发

7.设计如此—找产品经理进行确认。确认设计如此进行关闭；确认是问题，备注原因重现指派给开发。

8.延期修改—请看下BUG严重程度，是否影响当前版本发布？与产品经理进行确认。不予延期请根据情况重新打开并将情况进行备注说明；确定延期则做好记录，后续版本进行关注。