功能测试中Bug 如何定位与分析

lsekfe

之所以写这一篇文章，是突然想起来曾经在测试过程中被开发嘲讽过，事情是这样的，当时发现了一个疑似前端的Bug就草草提交到了禅道，结果刚来的女前端看到了就有点生气地问我为啥不查清到底是前后端问题就直接派给她前端了，因为那个问题其实是后端的。而且她还抛出了一句，她们以前公司的测试都是能准确分清前后端的问题再指派的。从那之后我就长了个记性，凡是遇到的Bug都尽量搞清楚到底是前后端哪边的问题再具体指派到开发。相信很多人应该也有过类似的经历，但是可能为了快速测试或者因为不太会定位前后端问题而直接将Bug随便挂到了某个开发头上，聪明一点的呢直接挂到了开发组长头上让他重新指派！其实这样对自身的成长以及塑造自己专业测试的形象都是不利的，如果刚开始做测试还好，做的久了必须是要像老中医一样把脉把准了才“开药”！
而且还有一点就是有些团队缺乏有效的管理，如果测试人员不区分前后端问题直接指派，可能导致前后端人员踢皮球，都说不是自己的问题，浪费很多时间在这种相互消耗上。再退一步说，即使指派对了人，可是测试人员并未准确指明具体问题的原因，比如接口传参错误，那么对于有些新手开发来说也可能修改不到正确的地方，这种情况我也遇到过，最后导致一个Bug来来回回修改了多次，耽误了时间也累了双方，而且你会发现到最后有些问题其实是同一个原因导致的，如果你不能够找出具体“症结”，可能会导致将同一个问题提交多个Bug，这也会浪费掉很多宝贵的测试时间，所以说测试人员自己能够清楚地辨别前后端问题且能分析出具体原因，是利人利己之事！
上了写了这一堆，我相信凡是做过测试的人肯定深有体会，所以很多测试小伙伴也开始意识到Bug的定位与分析是非常重要的，它需要很强的综合素质，是整个测试过程中的核心能力，需要很强的逻辑判断力，敏锐的观察力，丰富的经验等，虽然是功能测试，可是有时候也需要其它测试领域的技能辅助，因为这门功夫要懂的实在太多，限于篇幅此文章仅围绕Bug的定位与分析简单聊聊，希望能够起到抛砖引玉的作用。

我们先从Bug的定位说起，一般来说bug大多数存在于3个模块中：
前台的界面，也就是UI层面的，包括界面的显示，兼容性，数据提交的判断，页面的跳转，信息的收发等等，这些bug基本都是很直观的，不太需要定位，刚开始做测试的小白也能一眼辨认。当然也不排除一些特殊情况，本身数据传过来的时候就有问题，所以显示会出问题的情况。
后台的程序，包括代码逻辑的实现，前台调用的接口，中间层缓存和转发数据，定时任务脚本异步处理数据，程序之间的相互调用等等，而这些bug往往都是不可见的，大部分还好，可能从功能上就能发现，但是还有些藏得比较深，这就需要凭借一些开发经验和辅助工具去定位了。
数据库，包括数据库无法连接，表中缺少字段，字段定义错误，数据重复，字段长度限制等等，这些bug需要通过数据库工具（如Navicat等数据库管理工具）以及一些基本的数据库查询语句来定位，当然前提是要遍历到每个表，每个字段甚至每一个值。

以上提到很多问题是显而易见的，但是还有一些藏的较深的问题，那么这些隐藏较深的bug该如何定位呢?
像此类Bug其实也很多，只是有时候由于各种原因我们放跑了它们，现在就举个最常见的例子：比如我们偶尔会遇到提交表单会发现正常的数据提交时会失败，那么如何定位呢？
1.首先要打开抓包工具，随便你用Fiddler还是Wireshark等，然后提交正常的表单，看是调用后台接口的时候传的参数是否和之前填写的一致，比如表单填的是数字，而接口需要传的是字符串，那么就是前台传的问题，如果一致说明不是前台问题，继续往下排查；
2.需要一方面继续看抓包的数据，接口返回的错误是什么，如果能明确看到错误原因的消息，也就能定位到问题，如果不能看到则要继续连接测试服务器查看日志，看是程序处理到哪一步有问题；
3.如果程序是正常的，那继续往下查，看是否数据库字段定义错误，亦或是超过数据库字段限制的长度，字段定义错误等等。就这样追寻着程序执行的轨迹一步一步去排查，基本上都能定位到问题所在。
4.有时候前端和服务端的交互都正确，但是从测试的角度看不合理，这个时候我们应该翻翻需求文档。如果和需求文档不符，那么就要看下改什么比较合理，是改前端，还是改服务端，或者两者都要改。这里有一个原则，就是前端尽可能少地去承担逻辑，只负责渲染展现。
5.常见的bug可能还有构建方面的原因，比如代码本身没错，但是合并代码到主干后出现了问题，比如代码存在冲突时手动解决的情况，如果排除了各种情况还是查不到原因，可以从这个层面考虑！

以上只是举了一个简单的表单提交遇到问题如何定位的例子，其实现实中测试遇到稀奇古怪的问题是层出不穷的，比这复杂的问题也多的是，所以我们还是要学会分析问题可能出现的地方，在这个过程中不断去验证自己的猜想，反复排查缩小问题原因存在的半径。只有掌握了这种思路才能以不变应万变。当然本文只是建立在最基础的网络架构下的定位与分析，如果对于复杂的架构定位就更加棘手了，有机会我再写一篇关于复杂网络定位与分析的文章与各位分享。

oliver.tang

感谢分享