1.bug总结的意义

作为功能测试人员来说，可能有一半的时间都花在了和bug打交道上，比如如何发现bug ，提交bug ，跟踪bug以及回归bug上 。作为测试人员最重要的成果的bug ，我们往往更看重的是它的数量 ，却很少去思考这些它的发现逻辑以及产生原因 。其实在大厂 ，测试人员就很注重bug这座'金矿' .他们常常坐在一起去讨论一些有价值的bug以及这些bug是如何发现的 ？ 通过这样的复盘会，你就能学习到一些bug带来的新方法，然后从而找出更多的bug 。

如上流程一样 ，测试方法和bug是相互可以促进正循环的 ，你的方法越多 ，发现的bug也就越多 ；bug越多 ，能总结出的方法也会越多。依次正向循环 。

在这里也提一下 ，bug还有一个另外一个作用就是通过总结bug，分析bug，可以发现测试过程中遇到的问题 ，从而找到对应的解决方案 。最后通过这些方案应对或规避一些bug 。这个循环在前文已有介绍 ，查看请关注 ：

2.如何总结bug？

那么在众多的bug中，我们该选择那些bug进行总结呢 ？个人觉得，至少以下三个维度的bug是可以总结的，具体如下：

• 发现的bug在目前使用的测试方法是无法覆盖到的，说明我们掌握的测试方法对发现此bug已经失效了，那这类bug你就要进行总结了 ，通过总结它的规律，把它变成你的测试方法 ，然后存放在到你的方法库里 。

• 线上的bug也是要总结的 ，说明我们之前的测试还是存在问题 ，通过bug反推我们测试的不足 ，从而总结相对应的测试方法 。

• 测试后期发现的bug ，尤其是发散测试的后期 ，因为那个时候该用的方法也都使用了 ，哪怕是再发现一个bug都很难了 。那个时候往往会产生一种错觉 ，总以为系统中没有bug了 ，其实仅仅是你没有发现而已，不然的话，怎么在线上还有bug呢 。 像这类型的bug应该去总结 。

接下来我们又改如何总结bug呢 ？这里其实就是用的归纳法 ，通过一个具体的案例抽象成一个通用的方法或规律，然后使用这个方法去发现相同类型功能的bug 。

 

形成的方法往往具有如下特征 ：

1. 具有相同的操作模型，比如操作步骤相同 ，操作时使用的输入相同等 。

2. 产生的结果类似，比如bug提交表单会产生大于等于两条数据 ，你使用这个方法去使其它模块基本也能同样产生此结果 。

3. 复用的前期就是操作模型相同 ，一旦此模块或功能不适用此模型 ，该方法即失效 。

案例 ：添加地址输入地址信息后多次点击保存收货地址就会产生多条记录 。

通过分析这个bug ，点击这个按钮，其实就是向后台提交了一条数据 ，如果点击后没有及时关闭该页面或置灰此按钮 ，就会向后台提交多条数据 ，所以此bug的关键点就在于快速 ，若你能在这个窗口关闭之前多次点击，那么这个bug基本会是出现的 。

所以 ，总结此bug后 ，我们应该会有这样的一个方法：针对表单类的提交功能，只要快速点击 ，就有可能产生多条记录 。，你将此方法应用于其它功能也会发现同样的问题，不信你试试 。

总结的难点就在于抽象 ，我不知道从那些方面总结 ，该如何抽象 ？ 这个你可以考虑一个功能的整个操作流程 。我们往往测试一个功能都是输入数据，然后在点击按钮 ，系统内部进行业务处理 ，最后输出结果 。那么对我们来说，这里的每一步就都可以总结 ，像上面的那个快速提交的方法就是对按钮点击的总结 。

 出现的bug往往都是在这个步骤的某一个环节上出现了问题 ，然后将其总结出一些特点来 ，最后形成了对应的方法 。像这样的情况，如果你细心的话，这个是不难积累的。

3.形成自己方法库

随着你总结的bug越来越多 ，你就需要建立一个单独的bug方法库来管理这些测试方法， 然后将后续总结的都保存到这个方法库 ，方便后续测试时使用 。比如下面的截图 ；

 长此以往，你的bug和方法就会形成正向循环 ，能更快更全的发现bug 。