bug ？测开必懂必会系列

💕 如何描述一个bug ?
💕 如何定义bug的级别 ?
💕 bug的生命周期 ?
💕 如何开始第一次测试 ?
💕 测试的执行和bug管理 ?
💕 产生争执怎么办 ?
💕 测试开发人员必懂必会系列

如何描述bug?

作为一名测试人员，提bug是最基础的工作，那我们如何才能把bug提的清晰易懂呢?

1. 发现问题的版本 开发人员获取对应版本的代码来重现故障，比如fat/uat/pre

2. 问题出现的环境 环境分为硬件环境和软件环境web (浏览器) 、app (ios/安卓，系统级别)

3. 错误重现的步骤 描述问题重现的最短步骤

4. 预期结果 以用户的角度来描述程序正确预期。依据需求提出的故障，最好写出需求的来源

5. 错误结果 描述错误的现象。crash等可以上传log，UI问题可以有截图

6. 是否重现 能否每次都触发异常，还是偶尔情况

7. 链路/抓包 如果有链路或者能抓到包，可以给开发，让其更好的发现错误代码位置

• 其他 某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等

• 不要把多个bug放到一起 在无法确认是同一段代码造成的故障时，不要将bug放在一起提交

bug的等级

不同公司的bug等级定义可能不一样，但基本都是下面四类

1. Blocker（崩溃）

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2. Critical （严重）

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3. Major （一般）

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(实际测试中存在最多）

4. Minor （次要）

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

bug的生命周期

• New :测试创建一个bug。

• Open ：开发确认是不是bug，是的话就状态改为open。

• Fixed :开发进行修改后修改状态为Fixed，有待测试人员的回归测试验证。

• Rejected ：如果认为不是Bug，则拒绝修改。

• Delay :如果认为暂时不需要修改或暂时不能修改，则延后修改。

• Closed ：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。

• Reopen ：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

无效的bug：open->closed open-rejected-closed

基本的流程图：

bug解决的流程

执行测试时处理要做到测试用例和需求的覆盖外，还要有临时发挥的能力。根据自己的经验、对测试的
感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷。
不能拘泥于测试用例或者已经有的测试方法，在测试执行过程中要不断总结测试方法和测试故障模型。
真正优秀的测试人员在执行测试时是想着做，做着想，这样的测试效果才好，尤其是在测试过程中，对
程序的处理相当了解的情况下，测试的思路会更加清晰和全面。

现在我们开始进行测试了：

1. 打开待测试的系统

2. 打开测试管理工具用例模块，开始执行用例

3. 发现bug！进行复现并确认bug的复现步骤

4. 记录bug

5. 沟通bug

6. 验证以前提交的bug

7. 确认本次测试完成

8. 编写测试报告

如何发现更多的bug？

1. 软件测试存在二八原则，80%的故障集中于20%的模块，某部分问题较多，加强测试广度和深度！

2. 开发人员存在二八原则，80%的故障集中于20%的开发人员，某些开发人员的bug较多，加强测试他开发模块的测试广度和深度！

3. 多进行逆向思维和发散性的思维

4. 不要局限于用例和需求文档

5. 尽早介入项目, 不要等到开发的差不多了再介入项目

bug有争执怎么办?

原则： 对事不对人\遵循文档\多角度思考问题

• 自我反思

是不是bug创建的时候描述不太清楚？或者对需求理解不够？

如果是自己问题就及时更改。

如果prd有争议点，就问一下产品，并让产品同步一下prd，以让项目参与人员都知道有完善的地方。

• 开发对bug定级不满意？

bug定级要有理有据，明确企业bug定级规范，可以拿规范沟通

可以拿出以前相似的bug案例，给研发看。

• 研发不认为是bug？

可以从 bug的定义，产品的质量把控、对用户的影响、对公司效益的影响等方面来进行沟通。

• bug的定义：拿出prd，有和prd不符的就是不符，prd有争议的可以找一下产品

• 质量的把控：有时候的bug是很小的问题，但也影响用户体验，可以问他“如果你是用户..”

• 对用户的影响：这点就不用说了，产品细节不到位，用户是最直观感受的人

• 对公司的效益：举个例子，一个促销活动命中人群有误，公司能够少挣多少钱？

• 研发说没有时间改？

有的时候时间已经很少了，但是这个bug要有较大的改动才能修好，而较大的改动可能会产生更多的新问题，所以这个时候我们要自己评估一下，如果只是研发的借口，这时候可以催一催。

如果确实如初，则需要及时找产品沟通，如果影响不大，则可以放到下一个迭代进行。

• 补充

不仅能够发现问题，最好也能够提出解决方案(注意只是供开发参考，不能喧宾夺主)

比如在提bug的时候把链路给研发就是一个很好的习惯

• bug评审

注意如果 bug很严重、争执较大、需求有问题，我们可以召开bug评审会议，邀请产品、开发来讨论

• bug评审参与人员：产品代表\开发代表\测试代表...

• bug评审讨论问题：如果解决问题\以后如何避免...

• 注意你不是孤身一身

测试是一个团队，研发也是一个团队，如果有问题无法解决，及时找mentor或者leader，或者和对方的leader沟通。