记一次bug分析过程，并随之引发的思考
写在前面
我们常常会看到一些问题或讨论：测试需不需要定位bug？测试需不需要了解bug的深层次原因？测试如何在不知道开发代码实现逻辑的情况下定位到bug？测试定位bug的好处是什么？
刚好昨天在测试过程中，遇到了一个业务上的bug，并开展了分析、定位，提单，遂将详细过程中记录于此。最后，带着以上问题，分析“测试定位bug所带来的优缺点”，以及相关的思考与总结。
bug 描述：A系统上的企业数据，解析字段有误，导致同步至B系统进行数量统计和展示时数量对不上
1、先说一下这个需求的业务背景和测试背景：
1）业务背景
现A系统上有车队和货主两种企业类型，现需要把A系统上的企业数据解析同步至B系统的数据库，在B系统进行数量统计，并在页面进行展示，展示效果类似下图：
2）测试背景：
- 本次项目没有需求澄清，没有简单的概要设计(原因暂不展开讨论)；
- 测试事先并不知道开发代码实现逻辑；
为了便于用肉眼校验数据，在测试前已将A系统上的企业数据全部清空。由于我的测试重点是企业数据解析及同步后的数据统计，因此添加企业的过程、添加的方式并不需要过多关心，只要重点关注：
① 在A系统上、成功添加到了这两种企业类型的数据；
② 代码解析A系统数据库中的企业数据时，解析的逻辑是正确的；
③ 解析后的企业数据，成功同步至了B系统的数据库，且数量正确；
④ 页面企业数量展示正确；
2、发现bug的过程
为了便于构造数据，我写了一个添加企业的脚本方法，业类型节点传入参数G表示货主，T表示车队，当操作：
① 传入T，添加一个车队企业时，A系统数据库中插入了这条数据，module字段值为T，同时同步至了B系统数据库中，上图所示页面上的总数和车队数分别+1(目前表面看起来没什么问题)；
② 传入G，添加一个货主企业时，A系统数据库中插入了这条数据，module字段值为G，同时同步至了B系统数据库中，上图所示页面上的总数+1，但是货主数量未+1，而是车队数量+1了(此处应该有bug)；
通常来说，遇到此问题，就可以提bug单了，问题可以描述为“A系统添加货主企业，B系统货主统计数量未+1，车队数量+1”，但这里只描述了问题表象，并未阐明是何种原因导致的什么bug现象。所以往往需要开发自己再去造数据、看日志、查SQL等去定位问题。
为了进一步弄清bug产生的原因以及提高修复效率，在不了解代码实现逻辑的情况下，测试也可以进行分析定位bug。
3、分析、定位bug的过程：
① 推测这块的数据解析或是统计逻辑有问题，为了进一步验证推测，需要知道：
- 研发代码解析的是A系统企业表中的哪个字段来区分是货主还是车队的；
- 同步至B系统企业表中，是通过哪个字段来区分货主还是车队的；
② 先从最表象的现象进行反推，查看B系统企业表：
企业表中，有且只有type字段看起来像是做类型区分的，并且DDL中也有标注：1-车队，2-货主，但通过再次数据对比发现，无论添加何种类型的企业数据，同步至B系统时，type字段始终都为1，而当我把某条数据的type字段值改为2，页面数量统计和展示则正确。由此，基本可以断定数据统计的逻辑没有错误；那么，问题大概率是出在了数据解析和数据同步上；
③ 根据判断进一步反推，查看A系统数据表：
- 通常情况下，数据同步也只是执行SQL将解析后的结果插入到B系统中的过程，出现问题的几率不大，重点可以放在数据解析上；
- 由于前面添加企业时，企业类型节点传入G、T参数分别表示货主和车队，且写入数据表中的module字段值正确，可以判断，此处并不是解析module字段来区分企业类型；
- 通过查看A系统数据表发现，里面有个type字段，DDL中标注：1-普通企业，2-租户。结合页面操作发现：将企业类型设置为租户，type字段值就会记为2，此时B系统的type字段也同步为2，页面上的货主统计数据也会+1；不设置，直接审核通过，type字段值就会记为1，页面上的车队统计数据就会+1；由此可以断定：研发的代码逻辑，在解析企业类型时，解析的是type字段，而不是module字段；
- 综上，在A系统中，module字段表示的是企业类型(货主、车队)，type字段表示的是企业类型(普通企业、租户)，而B系统统计的是货主、车队的数量。因此，解析type字段来区分货主车队是错误的；
至此，bug描述即可以修改为：A系统上的企业数据，解析字段有误，导致同步至B系统进行数量统计和展示时数量对不上，提完bug单后，研发很快就修复了bug；
4、测试定位bug这一行为的优缺点：
以上即是测试在没有足够了解研发代码逻辑、表结构设计的情况下，通过“倒推法”来分析和定位bug的全过程，下面分析一下测试定位bug这一行为的优缺点：
优点：
- 加深对业务、系统架构、数据库、表结构的了解，可以发现一些其他潜在的bug；
- 在提单bug时更能抓住重点，阐明具体原因，提出修复方案，节约开发人员修复bug的时间(当然如果你对代码逻辑足够了解、并且具有编码能力，就可以直接修复的bug了，但这样的人毕竟少数)；
- 增加相互合作的认同感，我想没有开发会不喜欢可以直接帮他定位到bug的测试人员；
缺点：
- 严重耗费时间和精力，尤其是在不了解系统架构、数据库表结构、代码逻辑的情况下，想要定位一个bug只能靠和研发不断交流，自己不断摸索，如果是在项目时间紧任务重的情况下，这种做法会严重拖慢测试进度；
- 可能会打击到自信，以上只是一个比较简单的案例，如果遇到复杂的系统，或者不配合的开发，那么定位的过程会更加雪上加霜，甚至会打击到测试人员的自信心；
5、总结与思考
或许细心的同学会发现，如果项目在开始前做了概要设计和概要设计评审，那么测试人员不就可以了解到研发的实现方案、表结构设计，从而更加快速地定位到bug了吗？
其实很多时候，我们在测试过程中发现的很多bug，并不是由于开发人员编码能力不好，或者粗心大意造成，而是在项目开发实施过程中，没有遵循一些必要的项目流程，没有充分认识到质量的重要性；如果能做好这方面的工作，关注流程，而不是喊口号，人人重视质量，人人为结果负责，那么，会有很多问题、不只是bug，都将“被扼杀在摇篮里”......