BUG回归的一点看法 （转帖）

　　bug回归到不到位，关系到发现bug本身有没有修复好，同样也关系的因为修复bug而改动的代码对其他功能的影响。

　　bug回归的几点心得：

　　1、首先弄清楚bug必现的配置和操作过程

　　因为有时候回归的bug并不是测试人员自己提的，有可能工作时间的原因，安排你回归部分别人发现的bug。

　　对于回归别人的bug时候，我的建议是首先大概了解bug后，直接去问提bug的测试人员了解情况。我一直认为，面对面的沟通比文字来的直接。

　　对于非必现的bug，要弄清楚重现概率大的操作步骤。

　　2、找开发弄明白bug的产生原因及如何修改

　　1）先搞清楚，代码那里有问题

　　找开发问清楚，原来那个地方出了问题导致出bug。

　　这个有助于测试分析，从bug产生的原因可以触类旁通。其他的软件模块是不是也可能存在这种问题啊，或者这种问题是不是典型易犯错的类型，以及从bug中得出一些经验积累，对缺陷预防的工作有积极作用。

　　2）在搞清楚，怎么修复这个问题

　　弄清楚原因后，进一部搞明白开发是如何修改的。

　　修复当前的bug往往很简单，有些开发只是针对当前的问题进行修改。这也的话有可能，修改的代码会影响到其他模块。

　　比如说修改的是一些公共的函数，是一个“非常危险”的信号。极其就会影响到其他功能。

　　3、注意bug回归的测试关联点

　　一些新员工在进行bug回归的时候，往往只是从当前bug的产生操作步骤进行回归验证而已，往往没有考虑到修复这个bug有可能会影响其他的功能。

　　回归bug有2个基本要素：首先bug是否已经修复好，其次就是是否影响其他功能。

　　当然，有些修复的bug不好分析对那些模块，那些子系统造成影响。这就需要前面第二点要对bug的原因以及修改进行了解，这个涉及到测试人员对系统的熟悉程度。

　　这个过程可以找开发协助，一般开发都会给出一些测试建议，可能会对那些功能造成影响的。开发没有给出的话，就要找开发沟通啦。

　　如果发现没有修复成功的，要重新修改bug的状态，并且备注你测试了那些测试点。如果是影响了其他功能点，也可以新提一个bug等，具体操作看各个公司流程。

　　4、非必现的bug回归方法（难重现）

　　有些bug并不是有一定的必现的操作，或者说我们找不到比较好的必现方法。因为理论上来说，没有重现不了的bug，只不过我们没有发现。

　　对于这种非必现的bug，可以视bug的重现概率而定。比如说一个操作，操作10次肯定会出现一次，这种bug基本上可以说是可以重现。

　　这种概率较高的，回归的时候，可以通过多次操作来完成。比如说，执行必现的操作30次以上，均为出现问题。这个时候可以认为修复啦。

　　那么假如说，出现的概率较小而且很难掌握重现的手段时候，怎么回归呢？

　　首先这种可能开发也不能100%确定是什么原因造成的，只不过发现了一些可疑的代码。猜测是这些可疑代码造成的，进行了修复提交给测试人员回归。

　　这种情况下，可以针对代码的改动部分进行部分的验证。bug的状态可以先不要关闭。可以在后续的测试中持续关注。

　　比如说，这个bug在经过几轮的测试后，都未出现过，那么可以认为bug修复啦。

　　当然这种不能100%保证bug的真正原因修复，但是起码可以认为就算有问题也是概率较小的。

　　5、自动化&&回归测试

　　有比较全面的自动化用例的话，回归bug就是好办事啦。把所以用例跑一遍，如果没有必要的话，选择关联的用例跑一遍。自动化在回归测试中确实发挥着很大的作用，

　　有时候可能自动化跑不出问题，但是其他有一点作用的是，跑过一遍后可以让人放心。起码可以说基本功能没有影响。