浅谈如何做好Bug回归验证？

我们都希望自己不仅有敏锐的洞察力能够全面的找出隐藏在软件中的bug，还希望自己有系统的分析能力能够准确的分析出每个bug的原因以至于能正确、全面的解决修复bug。这也是一个优秀的测试工程师应该具备的基本能力。那么对于回归验证bug这个环节就是对前面两项工作是否合格的体现及验证。bug回归到不到位, 关系到发现bug本身有没有修复正确, ?同样也关系到bug修复过程中可能引起新的bug。接下来我们就讲讲如何做好bug的回归验证：
在自己不能准确定位bug产生原因的时候，一定找开发确认产生bug的具体原因。是业务逻辑错误还是代码实现方法错误等等。这个不仅有助于测试分析, 从bug产生的原因可以触类旁通。其他的功能模块是不是也可能存在这种问题,或者这种问题是不是典型易犯错的类型,还可以从bug中得出一些经验积累, 对缺陷预防的工作有积极作用。在了解清楚bug产生的原因后,进一步了解清楚开发是如何修复bug的。修复当前的bug往往很简单,有些开发只是针对当前的问题现象进行修改而不是从问题产生原因进行修复。还有可能修改的代码会影响到其他模块。比如说，修改的是一些公共的函数或算法,这是一个"非常危险"的信号。很有可能就会影响到其他功能。
这个bug的原因是：只在进入签约页面时判断了绑卡与否，而RN界面无法获取从其它页面返回的状态，所以返回时无法重新获取。
解决办法是：点击保存时再次判断用户绑卡与否，如未绑卡再次提示。
这个bug本身的影响只有当前签名业务页面，但从bug出现的原因看，是因为RN界面无法获取从其它页面返回时的状态，那我们就可以深入考虑我们有哪些业务是用的RN，然后业务中存在需要获取返回状态的业务又有哪些，而这些业务是否也存在这个问题呢？
三、确认bug的回归范围及用例。
在了解清楚bug产生的原因及修复方法基础上，再根据业务关联、功能模块关联确认回归范围及用例，确保bug修复全面且没有引起新的bug。这里需要测试人员非常熟悉业务逻辑及功能模块的关联关系，能够准确全面的分析出每个业务功能点所影响的范围。比如说，bug原因是某个函数或算法错误，那修改这个函数或算法后我们就要回归所有会用到这个函数或算法的业务及功能模块。例如，购买理财时预计利息计算错误。
有些bug管理工具并不是有一定的必现的操作，或者说我们找不到比较好的必现步骤。对于这种非必现的bug，可以视bug的重现概率而定。比如说一个操作，操作10次肯定会出现一次，这种bug基本上可以说是可以重现。这种概率较高的,回归的时候，可以通过多次操作来完成。比如说，执行必现的操作30次以上，均未出现问题。这个时候基本可以认为bug修复啦。
还有一种当出现的概率较小而且很难掌握重现方法的时候，怎么回归呢?首先这种可能开发也不能100%确定是什么原因造成的，只不过发现了一些可疑的代码。猜测是这些可疑代码造成的，进行了修复提交给测试人员回归。这种情况下，可以跟开发确认代码修改的影响范围及逻辑后对代码的改动部分进行部分的验证。
bug的状态可以先不要关闭。可以在后续的测试中持续关注。当这个bug在经过几轮的测试后未出现过,那么可以认为bug修复了。虽然这种不能100%保证bug的真正原因修复,但是起码可以认为就算有问题也是概率较小的。
还可以就是根据bug的等级，确定采用自动化的方式进行bug复现验证。根据发现bug所在的模块，生成自动化测试用例，进行自动化测试，通过重复触发去复现bug。另外还可以尝试通过给出现bug的模块功能所涉及的参数赋值为非法值，看是否能复现bug。这里也要再次提到我们在测试的时候要养成随时录制log的习惯，这样对于非发现bug来说及时录制的日志就是bug发生的证据也是开发解决bug的重要依据。
从开发解决修复完这个bug后就进入了bug回归过程中。为了确保测试人员能够且有全面准确的回归验证bug是否真的被修复。我们可以制定一些规范来确保bug回归的效率及正确性。比如，开发在提测bug时附加上bug产生的原因，修复方法，修复影响范围，开发自测的用例，bug可验证版本号等。测试在回归时备注好验证的版本号，验证结果，回归用例等，这样如果bug修复不完整，这些信息都有助于开发及测试人员跟踪bug。对于后续bug分析总结也提供了更有效的数据。