作为测试人员，我们都知道Bug的生命周期是：
我们都希望自己不仅有敏锐的洞察力能够全面的找出隐藏在软件中的bug，还希望自己有系统的分析能力能够准确的分析出每个bug的原因以至于能正确、全面的解决修复bug。这也是一个优秀的测试工程师应该具备的基本能力。那么对于回归验证bug这个环节就是对前面两项工作是否合格的体现及验证。bug回归到不到位, 关系到发现bug本身有没有修复正确, ?同样也关系到bug修复过程中可能引起新的bug。接下来我们就讲讲如何做好bug的回归验证：
一、确认好bug的复现前提及操作步骤。
一般情况下对于必现bug，我们在提交bug的时候会写上必现前提及操作步骤。对于本人提的bug及操作步骤描述清楚的情况下，回归时复现操作出现偏差的可能性不大。但是遇到要回归别人的bug且描述不够清楚或理解可能存在歧义的时候，我们一定要先跟发现bug的同事确认清楚bug的复现方法。否则很可能就出现了bug验证步骤的偏差，从而无法确保bug是否真正修复。这里我们先要在源头解决这个事，所以在提bug时就一定描述清楚，下面给出一个我们平时写的比较详细的bug做为参考：
【版本V1.1.0】【ANDROID】【银行卡】【功能问题】绑定银行卡时提示通联验证码验证失败，或验证码发送失败，或网络超时【复现率80%】
【测试机型】HTC M10U/6.0.1
【测试环境】MA
【测试版本】0929
【步长】1
【复现步骤】
1、登录花生理财
2、银行卡管理-添加银行卡，输入交易密码，身份信息，选择华夏银行，输入卡号为623020xxxxxxxxx2及开户城市信息
3、验证手机页面输入手机 号点击获取验证码。输入校验码点击确定 ，观察页面显示
【预期结果】
点击确定后如果验证码正确提示绑上成功
【实际问题】
点击确认后提示通联验证码验证失败，或验证码发送失败，或网络超时
【备注】
详情见附件图
二、确认清楚bug产生的原因及修复方法。
在自己不能准确定位bug产生原因的时候，一定找开发确认产生bug的具体原因。是业务逻辑错误还是代码实现方法错误等等。这个不仅有助于测试分析, 从bug产生的原因可以触类旁通。其他的功能模块是不是也可能存在这种问题,或者这种问题是不是典型易犯错的类型,还可以从bug中得出一些经验积累, 对缺陷预防的工作有积极作用。在了解清楚bug产生的原因后,进一步了解清楚开发是如何修复bug的。修复当前的bug往往很简单,有些开发只是针对当前的问题现象进行修改而不是从问题产生原因进行修复。还有可能修改的代码会影响到其他模块。比如说，修改的是一些公共的函数或算法,这是一个"非常危险"的信号。很有可能就会影响到其他功能。
比如bug#43213：【版本V1.4.0】【RN】【电子签名约定】小白用户签约时走绑卡未走完返回，再点击同意签约确定时会弹出密码输入框【必现】。
这个bug的原因是：只在进入签约页面时判断了绑卡与否，而RN界面无法获取从其它页面返回的状态，所以返回时无法重新获取。
解决办法是：点击保存时再次判断用户绑卡与否，如未绑卡再次提示。
这个bug本身的影响只有当前签名业务页面，但从bug出现的原因看，是因为RN界面无法获取从其它页面返回时的状态，那我们就可以深入考虑我们有哪些业务是用的RN，然后业务中存在需要获取返回状态的业务又有哪些，而这些业务是否也存在这个问题呢？
三、确认bug的回归范围及用例。
在了解清楚bug产生的原因及修复方法基础上，再根据业务关联、功能模块关联确认回归范围及用例，确保bug修复全面且没有引起新的bug。这里需要测试人员非常熟悉业务逻辑及功能模块的关联关系，能够准确全面的分析出每个业务功能点所影响的范围。比如说，bug原因是某个函数或算法错误，那修改这个函数或算法后我们就要回归所有会用到这个函数或算法的业务及功能模块。例如，购买理财时预计利息计算错误。
【测试机型】iPhone5s/8.3;oppoR7/4.4.4
【测试环境】测试环境
【测试版本】Android:20322,ios20847
【步长】2
【测试步骤】
1.登录高门账号后进入振惠存
2.在存入金额输入页输入100
3.查看存入金额输入框下方利息
【预期】利息的值=最高年化收益率*本金，即1.95
【实际】实际展示的值是9.75
回归这类问题时我们要考虑哪些地方会涉及利息计算？如：理财计算器，利息预计算等。他们是否用的同一个公式?回归的时候就要覆盖所有存在利息计算的场景。
四、非必现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。对于后续bug分析总结也提供了更有效的数据。
