软件测试工程师必会：BUG分类及推进解决方案

Bug，中文名缺陷。一个让软件测试员兴奋，让开发人员头疼的词。来源二次大战期间，一个称为“马克二型”的计算机，由于天气过热，硬件跟不上导致死机。最后发现是因为飞蛾，被继电器电死，将其注明“第一个发现虫子的实例”。人们将计算机错误戏称为虫子（bug），而把找寻错误的工作称为debug，即捉虫子！

软件bug可以分为几个类别：

第一类bug可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些bug可能由于其随机性很难预防，但是，适当的分析将有助于避免这些bug。自动化测试工具TestWriter进行用例测试，实现无需值守，实时查看执行情况。

另一类的bug来自于需求的误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术。这类bug共同的特点是都来自于开发人员。除非被发现，否则这些bug将一直存在。如果bug发现和修正越早，开发成本越少，那么在第一时间就避免bug引入是不是成本消耗得更少？如果bug可以被完全预防，那么在开发过程中就不会出现重复工作的情况。

那么bug又分为哪些类呢？

有一些初始的小测试团队，对BUG单可能会进行重要程度的划分，但并不会进行类型划分，其实，如果不对BUG进行错误类型定义，项目经理或测试经理并不好确认后续质量提升在哪方面进行改进，具体研发的哪个环节更需要进行改进。故此合理的对BUG单进行分类也是提交BUG的前提。以下是我整理的BUG类型分类情况：

 

进行BUG类型分类仅是第一步，作为WEB类的项目，一般情况下，明面上的二、三类问题，自测时容易发现且会完成修改，留到测试去提出的机率相对会少一点；而其它类问题常常因为开发时间不够或不重视等原因，大量的留给了测试阶段去提出；对于这类现象，负责的项目经理有时候是心有余而力不足；而不太负责的项目经理，有可能就睁一只眼闭一只眼；作为测试团队，想要提高提交版本质量，可以用以下几种方式去做尝试：

1.与项目组，确认清楚接收版本的准则，即让项目组成员都清楚存在哪些问题，版本是会打被回。

2.提供P0用例给到开发，提高开发的自测质量；

3.整理不同开发重复出现的问题，与项目经理商议每个问题的具体代码上的处理方案，整理为项目组内的知识点，在开发团队中进行宣导或组织专题会议进行讲解。

4.对于严重影响测试工作效率或反复出现的问题单，可以适当的提高问题单的严重程度，以引起项目组的重视。

以上，是个人愚见，欢迎大家一起留言交流！