深入理解bug的相关概念

什么是bug？

功能不符合需求， 不正确或缺失的异常处理，不符合用户使用习惯的(要根据实际情况来)， 超出用户期望的需求(画蛇添足，也不一定)

 

一个bug单包含哪些要素

1、所属的系统(产品)

2、发现的版本（轮次）

3、发现bug所属的模块

4、bug提交人

5、bug的错误类型：代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题等（默认）

6、bug的重现概率： 必现 大概率重现 小概率重现 极小概率重现

7、bug的严重级别：致命 严重 一般 提示 （影响范围越大，严重级别越高）

8、bug的优先级：高 中 低

9、bug的标题 言简意赅说明是什么bug， 而不是把测试用例名字复制一遍

10、bug单号 一般系统自动生成

11、bug内容：发现的环境、 预制条件、重现步骤、预期结果、实际结果， 截图证明，bug错误说明，(当开发看到能容能够独立重现这个bug，说明写的还行)

12：附件：测试用的数据或者出错的日志， 如果需要添加上日志

 

 

提交bug的时候尽量把截图附上，并对截图进行标注，如果不好描述的可以录制视频， 如果是偶现bug ，把发生这个错误的错误日志，操作过程说明清楚

毕竟字不如图，描述半天不如一张图， 图不如视频

 

 

发现bug为什么要提单？

1、bug容易漏掉，导致bug遗漏到客户那里

2、把bug录入系统，给开发提供bug解决的依据，哪些bug 要优先改、哪些bug可以先不修改、

3、把bug录入系统，方便开发定位这个bug，因为bug会记录重现步骤

4、把bug录入系统，方便测试知道哪些bug 需要修改但是未修改，哪些bug已经修改可以回归

5、提交bug，测试人员有成就感

6、把bug录入系统，是研发过程改进的大数据库，根据不同维度的统计数据，发现研发过程中存在的问题

 

 

针对第6点举例： 比如问题单过多（可能模块太复杂，分给技能不熟练的人了，可能是这个人就没有认真干活）， 比如问题单回归不通过数量多（修改问题单不认真，导致延长测试周期）， 比如 版本上线后线上问题多 （测试不到位，测试点覆盖不全，测试设计和用例评审不到位，或者执行的时候不认真 该打测试板子），通过这些数据我们可以优化我们的研发过程，提升团队的效率

 

 

 

bug解决者一般填写哪些内容

 

1、bug的解决方案有哪些：

设计如此、 重复bug、外部原因、已解决、无法重现、延期处理、不予解决

2、bug解决版本

3、问题原因

4、解决问题的方案

5、解决方案的影响范围

开发写这5点的目的是方便测试回归，回归时测试更有重点

 

 

bug回归的时候应该怎么处理

前提： 回归之前，如果这个bug涉及到代码修改，那么修改好的代码一定是部署到测试环境了

1、阅读解决方案的内容

2、检查问题单中的场景是否修改

3、检查解决方案影响范围的功能是否正确

阅读1、2、3， 测试2、3涉及到的场景，都通过时， 问题单关闭，否则问题单打回给开发，让重新修改

 

对于不予解决或者设计如此的问题，如果不认可开发的解决方案，有疑问怎么处理？

1、认真阅读不予解决的原因，或者这样设计是否合理

2、如果认可原因，即可把问题单给关闭掉，如果不认可，反馈给测试领导吧

Bug处理流程

流程描述：

1、测试人员发现bug 提交给开发。

2、开发人员判断是否是bug。

3、如果是bug，进行修改，修改完成后更改bug 状态为已解决。

4、如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因，

或者不能重现。

5、开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。

6、验证未通过的bug 重新激活，开发人员继续修改，直至验证通过，关闭bug。

7、测试人员需要对开发人员退回的bug 进行确认。

8、确认不是bug 关闭。

9、如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。

10、项目负责人确认是bug 由开发人员修改，不是bug 由测试人员关闭。

 

 

测试处理bug单经常会遇到哪些问题

1、bug修改不完整 ，bug打回

2、开发说bug不是问题，  和开发沟通，不能达成一致，走给测试负责人处理

3、测试中不停发现BUG，一些比较小的BUG还要提吗？

      当然要提，

4、项目要着急上线， 但是还有一些bug没处理，这个时候应该怎么办？

把这些bug的影响范围汇报上去， 至于要不要上线让领导定夺，咱们负责把bug的风险给汇报上去

 

偶现问题如何处理

1、出现bug后，首先截图，查看日志，把对应日志保留下来

2、尝试重现这个bug ，思考这个bug可能产生的原因， 然后每个原因逐步验证，如果重现不出来，可以找开发帮忙 ， 这个步骤是为了准确找到重现bug 的步骤， 开发修改的时候就容易多了，不然又会和开发来来回回扯皮

3、如果实在重现不出来， 还是要提交bug 的， bug单一定要写清楚bug出现的环境， 版本、步骤， 错误截图， 对应的日志， 尽可能多的提供出现bug时的信息， 方便开发定位

 

 

怎么和开发沟通bug

1.把自己的Bug Report完善；有时候开发看到一些莫名其妙的Bug Report会很生气，这样首先就影响了你在他心目中的印象，要让别人改正，首先要保证自己是正确的、完善的。

2. 对事不对人；找开发的时候应该针对具体的问题，可以用“我们的软件出现了这样的问题”，而不要说“你这里写的不对”。

3. 摆事实；对于具体的bug，可以给开发说明一些事实，例如某个样式问题其实十分影响用户体验。

4. 挖历史；如果以前有类似的问题，可以把那个问题，以及造成的后果给开发阐述一下。

5. 平时跟开发拉好关系。测试立场要坚持， 该提bug还得提

6. 把更高层的人拉进来；很多时候都是公说公有理婆说婆有理，这时候就需要一些第三方的同事来帮忙，这个人通常要是能说事的才行，例如研发总监或者项目经理，但是主要不要让人觉得狐假虎威的感觉，这招不适宜经常用。

 

缺陷的分布特征

  缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。

如果一个模块bug较多，怎么来判断这个模块bug发现干净了？ 那就是连续2轮发现的bug都很少

 

缺陷的抗药性

测试进行得越多，新缺陷就越难被发现

  因为之前一直使用同样的测试思路，同样的一套测试用例，没有新的突破。

   某些缺陷天然地只有在很特殊或者很极端的情况下才会被触发

所以需要进行交叉测试、bug学习（不断在扩展我们的测试思路）、发散测试

 

发布时并非所有的缺陷都要修复

有一些原因，使得有些缺陷我们不修复：

没有足够的时间

不算真正的软件缺陷，可能这个bug是优化

修复的风险太大

不值得修复