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

做为测试人员，咱们都知道Bug的生命周期是：

 

　　咱们都但愿本身不只有敏锐的洞察力可以全面的找出隐藏在软件中的bug，还但愿本身有系统的分析能力可以准确的分析出每一个bug的缘由以致于能正确、全面的解决修复bug。这也是一个优秀的测试工程师应该具有的基本能力。那么对于回归验证bug这个环节就是对前面两项工做是否合格的体现及验证。bug回归到不到位, 关系到发现bug自己有没有修复正确, ?一样也关系到bug修复过程当中可能引发新的bug。接下来咱们就讲讲如何作好bug的回归验证：

　　1、确认好bug的复现前说起操做步骤。

　　通常状况下对于必现bug，咱们在提交bug的时候会写上必现前说起操做步骤。对于本人提的bug及操做步骤描述清楚的状况下，回归时复现操做出现误差的可能性不大。可是遇到要回归别人的bug且描述不够清楚或理解可能存在歧义的时候，咱们必定要先跟发现bug的同事确认清楚bug的复现方法。不然极可能就出现了bug验证步骤的误差，从而没法确保bug是否真正修复。这里咱们先要在源头解决这个事，因此在提bug时就必定描述清楚，下面给出一个咱们平时写的比较详细的bug作为参考：

　　【版本V1.1.0】【ANDROID】【银行卡】【功能问题】绑定银行卡时提示通联验证码验证失败，或验证码发送失败，或网络超时【复现率80%】

　　【测试机型】HTC M10U/6.0.1

　　【测试环境】MA

　　【测试版本】0929

　　【步长】1

　　【复现步骤】

　　一、登陆花生理财

　　二、银行卡管理-添加银行卡，输入交易密码，身份信息，选择华夏银行，输入卡号为623020xxxxxxxxx2及开户城市信息

　　三、验证手机页面输入手机 号点击获取验证码。输入校验码点击肯定 ，观察页面显示

　　【预期结果】

　　点击肯定后若是验证码正确提示绑上成功

　　【实际问题】

　　点击确认后提示通联验证码验证失败，或验证码发送失败，或网络超时

　　【备注】

　　详情见附件图

　　2、确认清楚bug产生的缘由及修复方法。

　　在本身不能准肯定位bug产生缘由的时候，必定找开发确认产生bug的具体缘由。是业务逻辑错误仍是代码实现方法错误等等。这个不只有助于测试分析, 从bug产生的缘由能够举一反三。其余的功能模块是否是也可能存在这种问题,或者这种问题是否是典型易犯错的类型,还能够从bug中得出一些经验积累, 对缺陷预防的工做有积极做用。在了解清楚bug产生的缘由后,进一步了解清楚开发是如何修复bug的。修复当前的bug每每很简单,有些开发只是针对当前的问题现象进行修改而不是从问题产生缘由进行修复。还有可能修改的代码会影响到其余模块。好比说，修改的是一些公共的函数或算法,这是一个"很是危险"的信号。颇有可能就会影响到其余功能。

　　好比bug#43213：【版本V1.4.0】【RN】【电子签名约定】小白用户签约时走绑卡未走完返回，再点击赞成签约肯定时会弹出密码输入框【必现】。

　　这个bug的缘由是：只在进入签约页面时判断了绑卡与否，而RN界面没法获取从其它页面返回的状态，因此返回时没法从新获取。

　　解决办法是：点击保存时再次判断用户绑卡与否，如未绑卡再次提示。

　　这个bug自己的影响只有当前签名业务页面，但从bug出现的缘由看，是由于RN界面没法获取从其它页面返回时的状态，那咱们就能够深刻考虑咱们有哪些业务是用的RN，而后业务中存在须要获取返回状态的业务又有哪些，而这些业务是否也存在这个问题呢？

　　3、确认bug的回归范围及用例。

　　在了解清楚bug产生的缘由及修复方法基础上，再根据业务关联、功能模块关联确认回归范围及用例，确保bug修复全面且没有引发新的bug。这里须要测试人员很是熟悉业务逻辑及功能模块的关联关系，可以准确全面的分析出每一个业务功能点所影响的范围。好比说，bug缘由是某个函数或算法错误，那修改这个函数或算法后咱们就要回归全部会用到这个函数或算法的业务及功能模块。例如，购买理财时预计利息计算错误。

　　【测试机型】iPhone5s/8.3;oppoR7/4.4.4

　　【测试环境】测试环境

　　【测试版本】Android:20322,ios20847

　　【步长】2

　　【测试步骤】

　　1.登陆高门帐号后进入振惠存

　　2.在存入金额输入页输入100

　　3.查看存入金额输入框下方利息

　　【预期】利息的值=最高年化收益率*本金，即1.95

　　【实际】实际展现的值是9.75

　　回归这类问题时咱们要考虑哪些地方会涉及利息计算？如：理财计算器，利息预计算等。他们是否用的同一个公式?回归的时候就要覆盖全部存在利息计算的场景。

　　4、非必现bug的回归验证。

　　有些bug并非有必定的必现的操做，或者说咱们找不到比较好的必现步骤。对于这种非必现的bug，能够视bug的重现几率而定。好比说一个操做，操做10次确定会出现一次，这种bug基本上能够说是能够重现。这种几率较高的,回归的时候，能够经过屡次操做来完成。好比说，执行必现的操做30次以上，均未出现问题。这个时候基本能够认为bug修复啦。

　　还有一种当出现的几率较小并且很难掌握重现方法的时候，怎么回归呢?首先这种可能开发也不能100%肯定是什么缘由形成的，只不过发现了一些可疑的代码。猜想是这些可疑代码形成的，进行了修复提交给测试人员回归。这种状况下，能够跟开发确认代码修改的影响范围及逻辑后对代码的改动部分进行部分的验证。

　　bug的状态能够先不要关闭。能够在后续的测试中持续关注。当这个bug在通过几轮的测试后未出现过,那么能够认为bug修复了。虽然这种不能100%保证bug的真正缘由修复,可是起码能够认为就算有问题也是几率较小的。

　　还能够就是根据bug的等级，肯定采用自动化的方式进行bug复现验证。根据发现bug所在的模块，生成自动化测试用例，进行自动化测试，经过重复触发去复现bug。另外还能够尝试经过给出现bug的模块功能所涉及的参数赋值为非法值，看是否能复现bug。这里也要再次提到咱们在测试的时候要养成随时录制log的习惯，这样对于非发现bug来讲及时录制的日志就是bug发生的证据也是开发解决bug的重要依据。

　　5、Bug回归规范化。

　　从开发解决修复完这个bug后就进入了bug回归过程当中。为了确保测试人员可以且有全面准确的回归验证bug是否真的被修复。咱们能够制定一些规范来确保bug回归的效率及正确性。好比，开发在提测bug时附加上bug产生的缘由，修复方法，修复影响范围，开发自测的用例，bug可验证版本号等。测试在回归时备注好验证的版本号，验证结果，回归用例等，这样若是bug修复不完整，这些信息都有助于开发及测试人员跟踪bug。对于后续bug分析总结也提供了更有效的数据。