一般来说bug大多数存在于三个模块：
一、前台界面，包括界面的显示，兼容性，数据提交的判断，页面的跳转等等，这些bug基本都是一眼可见的，不太需要定位，当然也不排除一些特殊情况，本身数据传过来的时候就有问题，所以显示会出问题的情况。
二、后台程序，包括前台调用的接口，中间层缓存和转发数据，定时任务脚本异步处理数据，程序之间的关联调用等等，而这些bug往往都是不可见的，可能在功能上体现，也有可能隐藏在深处不易发现，这时候就要通过一些辅助工具以及人工的判断去定位了。
三、数据库，包括表中缺少字段，字段定义错误，字段长度限制，数据重复等等，这些bug需要通过数据库工具以及一些基本的数据库查询语句来定位，当然前提是要对每个表，每个字段提前进行了解.
排除一些显而易见以及可以直接判断的bug，很多不容易判断的bug该如何定位呢?
这就需要借助一些工具来一个个排除了，也许还是会觉得云里雾里，那么就举一个常见的例子来讲解：
比如在提交正常的表单发生了错误导致提交失败，那么如何进行定位呢?
1、首先要打开抓包工具，然后提交正常的表单，看是调用后台接口的时候传的参数是否和之前填写的一致，比如表单填的是数字，而接口需要传的是字符串，那么就是前台传的问题，如果一致说明不是前台问题，继续往下查。
2、需要一方面继续看抓包的数据，接口返回的错误是什么，如果能明确看到错误原因的消息，也就定位到问题，如果不能看到则要继续连接测试服务器查看日志，看是程序处理到哪一步有问题，
3、如果从程序的角度发现没问题，那继续往下查，看是否连接的数据库不对，或是超过数据库字段限制的长度等等。就这样随着程序执行的轨迹一步一步去排查，最终基本都能定位到问题。
案例1: 有一个提现余额的功能，实际提现金额到账了，但余额却没有扣除。
首先要对提现功能做一个拆解:
1、前台发起提现申请
2、后台接受申请后冻结提现金额
3、定时任务处理提现(调用第三方支付转账接口)
4、接受到转账成功回调
5、将余额减去提现冻结的金额
6、前台余额展示提现后的余额
因为实际提现金额到账了，那么基本可以排除3和1了，然后觉得最有可能出问题的是4.就是没有收到转账成功的回调，可以查看后台日志是否收到回调。如果没收到回调，那么基本就是回调地址不对或者网络超时等错误，问题就定位到了。
如果收到回调了，那么最有可能的就是余额未扣除提现冻结金额，那么就是2和5.对于2来说可以查数据库是否提现金额被冻结。
如果未冻结那就是步骤2出错了，如果冻结了，继续查5余额是否扣除了提现冻结金额(这个可能需要开发配合查程序逻辑了)。
如果5也没有问题，那么剩下的可能性只有6了，再对6进行验证。如果还没问题可能就是其他异常导致的，需要更深入去思考有没有遗漏的点或者数据库上的特殊性导致的。
案例2: 有一个BS架构的系统，销售统计报表中的金额不正确?这个时候我们怎么通过流程分析法去精确找到问题的根因呢?
1、分析金额的计算方法
2、分析金额是在那个地方生成的?前台通过js自动计算出来的还是服务器端就生成的?
3、通过抓包工具(如fiddler)检查浏览器请求的参数和返回的结果是否正确?
4、如果这些都没有问题，检查数据库中和金额相关的字段的存储数据是否正确?
5、如果金额不正确，说明我们的问题可能不是报表统计，而是其它地方出现了这个问题
6、如果金额正确，说明服务器内部运算可能出问题了，我们可以检查服务器的日志，查看是否有错误
以上bug定位方式期望能够给大家在工作带来收获!
京公网安备 11010802030320号