BUG的定位与分析思路

一般来说bug大多数存在于3个模块：

1、前台界面，包括界面的显示，兼容性，数据提交的判断，页面的跳转等等，这些bug基本都是一眼可见的，不太需要定位，当然也不排除一些特殊情况，本身数据传过来的时候就有问题，所以显示会出问题的情况（这个后面会说到）。

2、后台程序，包括前台调用的接口，中间层缓存和转发数据，定时任务脚本异步处理数据，程序之间的相互调用等等，而这些bug往往都是不可见的，有可能在功能上体现，也有可能隐藏的深处不易发现，这时候就要通过一些辅助工具以及人工的判断去定位了。

3、数据库，包括表中缺少字段，字段定义错误，字段长度限制，数据重复等等，这些bug需要通过数据库工具以及一些基本的数据库查询语句来定位，当然前提是要对每个表，每个字段甚至每一个值代表什么意思有一定的了解（一些常用的重要的表，字段，值就可以了）。

排除一些显而易见以及可以直接判断的bug，很多不容易判断的bug该如何定位呢?

这就需要借助一些工具来一个个排除了，也许还是会觉得雨里雾里，那么就举一个常见的例子来讲解：

比如在提交正常的表单发生了错误导致提交失败，那么如何从定位呢？

1、首先要打开抓包工具，然后提交正常的表单，看是调用后台接口的时候传的参数是否和之前填写的一致，比如表单填的是数字，而接口需要传的是字符串，那么就是前台传的问题，如果一致说明不是前台问题，继续往下查。

2、需要一方面继续看抓包的数据，接口返回的错误是什么，如果能明确看到错误原因的消息，也就定位到问题，如果不能看到则要继续连接测试服务器查看日志，看是程序处理到哪一步有问题，

3、如果从程序的角度发现没问题，那继续往下查，看是否连接的数据库不对，亦或是超过数据库字段限制的长度等等。就这样追寻着程序执行的轨迹一步一步去排查，最终基本都能定位到问题。

******************************************

比有一个提现余额的功能，实际提现金额到账了，但余额却没有扣除。首先要对提现功能做一个拆解

1、前台发起提现申请

2、后台接受申请后冻结提现金额

3、定时任务处理提现（调用第三方支付转账接口）

4、接受到转账成功回调

5、将余额减去提现冻结的金额

6、前台余额展示提现后的余额

因为实际提现金额到账了，那么基本可以排除3和1了，然后通过猜想觉得最有可能出问题的是4，就是没有收到转账成功的回调，可以查看后台日志是否收到回调。如果没收到回调，那么基本就是回调地址不对或者网络超时等错误，问题就定位到了。

如果收到回调了，那么最有可能的就是余额未扣除提现冻结金额，那么就是2和5，对于2来说可以查数据库是否提现金额被冻结。

如果未冻结那就是步骤2出错了，如果冻结了，继续查5余额是否扣除了提现冻结金额（这个可能需要开发配合查程序逻辑了）。

如果5也没有问题，那么剩下的可能性只有6了，再对6进行验证。如果还没问题可能就是其他异常导致的，需要更深入去思考有没有遗漏的点或者数据库上的特殊性导致的。