情人（测试人员）眼里出西施（BUG）

作为一名软件测试人员，平时工作中面对最多的一个就是Bug，Bug有很多方面，接下来细说下我眼中的Bug：

bug的分类：

我一般分为三类：

错误的。这种bug 是指系统功能没有被正确的实现，与预期指定的需求不符，没有完成产品人员提出的功能要求。

遗漏的。这种bug是指系统功能中不具有我们指定或预期的需求，它可能与产品需求说明不符，或者是有些指定的功能没有被实现，亦或是在测试过程中或之后才被确定下来的需求。

超额的。功能中包含了需求里没有的内容，这与原始需求不符，不过这也可能需求中没有指明，导致开发时理解有误。但无论如何，这最初也被认为是bug。当然这种bug最终也有可能会被产品人员接受然后当成需求变更进行处理。

Bug处理

Bug的提交：如何正确的提交Bug？以前曾经遇到过这样的情况，一个页面上的几个样式或数据问题提了几个Bug，事后开发又要求这样的问题可以提交一个Bug，说是Bug不是越多越好。

其实我也不想分成好多个问题进行提bug单。主要是因为之前遇到过把几个类似的Bug提到一个里面，结果开发只改一处就把Bug 关了，因为Bug没有修复完整，那么我只能reopen了它。

但是这样又导致了高的reopen率，有点难搞哦！那怎样提交Bug才能把这两个方面平衡到呢？

我后来采用的方式，提了一个Bug，在备注中说明，共有多少个问题，请仔细修复后再关bug。因为现在要求每个开发在修复Bug后一定要填写备注，他在填写时必定会看到我写的内容。

还有就是如果一个页面的问题会涉及到多个开发人员，比如前端需要修改页面展示，后端需要进行代码修改，那我会分别给对应开发提一个bug单，这样确保他们都知道这件事。但如果仍有这样的情况发生，那只能再提交多个Bug来进行Bug跟进，免得出现Bug被遗漏，然后发布到线上。

Bug的级别：因为这个字段有可能会影响到开发的KPI，某个开发同学的严重Bug率及容易发现的Bug率是多少，会多多少少影响到开发的KPI等，所以当我们选择这些时要慎重，原则就是公平，是就是，不是就不是，不要带有私人情感，比如我跟某某开发关系不错，还是不要这样选择了类似的，这样会对其他同学很不公平。不公平处理的话有可能还会激发一些矛盾。

Bug的流转：某些情况下，我们的Bug并不会很顺利的关闭，验证之后没有修复的reopen掉；提交之后开发无法重现的，会rejected掉；由于一些环境或脏数据等情况的可能会产生一些无效Bug；多人测试时又可能是重复的Bug；林林总总的情况，导致我们提交Bug时也要非常小心，毕竟测试产生过多的无效Bug也是一种测试技能的缺失，无法重现或很难重现的也算是测试在提交Bug时未能找到规律导致的，也是要尽量避免的。

那么说到Bug流转，最需要关注的就是流转到later和rejected状态的Bug，本来later意味着本次项目中不修复，以后再修复，但是很多时候会忘记掉还有这样一个Bug在，等到出了问题才又想起来，这个是很坏的一种情况。好的做法是在项目之后及时梳理Bug，提早安排在后续工作中修复。而rejected状态的则要根据实际情况进行分析，到底是环境问题，还是数据或个人理解的问题。尽量去确定该bug是否真的是无效bug，而不是开发点了rejected，你就认为是这个bug是无效的。

Bug的原因：有些同学在提交Bug时，习惯只描述问题现象，等着开发验证。但是我倒是希望不管是新手还是老手，能分析Bug的根因是很重要的，这不但弄提升你个人能力，还能让开发减少排查问题的时间。从某个方面也可以看出来你所对应的开发在开发习惯上会有哪些陋习，一般会有规律可循，再有就是寻找Bug的根因对理解系统实现是非常有帮助的。

Bug的统计和分析：不管是做项目也好，季度总结也好，有时间可以阶段性的对Bug进行统计分析是非常必要的，从几个方面讲：一是将Bug归类，总体哪个类型的Bug比较多，Bug归类可以从多方面（比如按功能模块分）。二是提炼某类Bug可以找出解决此类Bug的方案，以保证后续中不再发生这样的Bug，可能更多需要从不同的角度去做这件事情。三是找到发现某类Bug的统一解决方案。个人认为Bug统计是可以提高后续质量很重要的手段。

                                    长按下方二维码，即可了解新贝学院更多内容