经验分享：如何快速定位问题(BUG)

让我掉下眼泪的 不止内存泄漏

让我夜夜不眠的 不止你的需求

明天还要改多久 你攥着个人手

让我感到为难的 是善变的需求

发布老是在半夜 回滚是永远的愁

错误(Bug)随时的暴漏 困扰着我心头

做为程序员，以上这些场景你必定都经历过。今天就来聊聊如何快速定位问题。

先划重点，下文所写都是一家之言，本人工做经验很少，语言表达能力有限，若是写的很差，还望轻喷。另外，本文所讲都是站在Java后端开发者的角度。

背景

下文所讲内容，都会围绕如下几个真实案例来作举例分析，先描述一下具体案例：

• 案例1：App首页白屏。

  详细描述：App、H五、小程序首页都是由同一个后端接口负责提供数据。测试大佬反馈说，App首页白屏了。

• 案例2：小程序商品会员价显示不正确。

  详细描述：测试大佬反馈，某商品会员价显示不正确，客户端展现会员价为0元。为何会员价0元是不正确的呢？由于咱们在系统中作了限制，会员价必须大于0元。

• 案例3：优惠券领取不了了，弹窗显示“领取失败，该优惠券仅限新人领取”！

  详细描述：这是一个领取优惠券的功能。用户能够经过该活动领取优惠券。用户在领取优惠券时，页面弹窗提示：”领取失败，该优惠券仅限新人领取“。同时，测试大佬反馈说，这个帐号就是一个新人帐号，是刚刚注册的用户。

• 案例4：某用户购买的xx评测专栏的评测课没法打开。

  详细描述：评测专栏是我司的一个特点专栏，在这个专栏中，有一节评测课。评测课就是让用户作在线试题，用户先进行测试，了解本身状态。测试完成以后，系统会根据用户的答题状况，向用户推荐合适的专栏课程表，供用户学习。

背景交代完毕，那若是是你，在遇到这几个问题的时候，会怎么处理呢？

复现问题

当测试大佬反馈问题时，首先要作的就是复现问题。若是问题能复现，好嘛，已经解决一大半了，做为开发，我以为仍是要有这个自信的。能复现的问题，那就必定能修复（修复成本有高低，这个不在本文讨论范围以内哦），实在是找不到Bug代码，我能够一行一行的调试嘛！因此，遇到问题不用慌，淡定淡定。

那若是问题不能复现呢？怎么办？

这个时候，我通常的作法是去查日志。若是日志中有错误信息，咱们即可以根据错误信息快速定位到Bug所在的具体代码。那若是这个时候也没有错误信息呢？嗯...我想一想，好像也没有别的办法了。问题不能复现，程序没有报错，那只能麻烦测试大佬再多测试一下，看看能不能复现吧。

快速定位

通过上一步骤，咱们已经可让Bug复现了，那接下来要作的就是快速定位。快速定位？定位什么呢？

通常公司项目开发，都会分后端开发、前端开发、APP开发，这里说的快速定位，指的就是要快速定位到是三端中的哪一端出的问题。

那如何快速定位呢？

若是你熟悉这个功能的总体流程，清楚整个功能会经历哪些步骤、哪些模块，这对你去快速定位问题是很是有帮助的。固然，也有一些监控工具能够来帮助开发者作快速定位，帮助开发了解整个流程。例如：sentry、skywalking等。

举个栗：

案例1：App首页白屏。

案例2：小程序商品会员价显示不正确

这两个问题反馈过来的时候，我打开app、H五、小程序都看了一下，发现：只有app的首页白屏了，H5和小程序的首页都是好的，考虑到App、H五、小程序首页都是由同一个后端接口负责提供数据，那这个问题大几率是app那边的问题，因而请app开发同事帮忙定位一下问题。

而app、H五、小程序这三端都出现了商品会员价显示不正确这个问题，因而我判定，这大几率是一个后端的逻辑问题。三端都写错代码取错了会员价这个几率应该不大。

案例4：某用户购买的xx评测专栏的评测课没法打开。

这是一个产品反馈的线上问题，由测试大佬提到开发这边的时候，测试大佬当时并不能复现。因为评测课的特殊性，它是须要由用户作题输入到系统，系统解析用户答题状况，而后作系统推荐。

这是一个典型的与用户行为数据相关的问题，可能只有具备某些特性行为、数据的用户才会遇到。遇到这种问题，测试也是很难复现的。能够查一下日志，看看有没有报错信息。

当时遇到这个问题的时候，因为项目接入了sentry平台，开发这边也是收到了系统异常报错的邮件提醒，很快速的就找到了缘由。

定位接口

好，通过上面几轮的大体判断，这大几率就是一个后端Bug了。如今咱们须要作的就是，快速定位到出问题的具体接口。若是移动端，就用Charles抓个包，H5端就直接打开Chrome控制台。

so easy~~ 妈妈不再用担忧我找不到接口啦~~ 固然了，在实际操做过程当中，可能并无这么简单。前端渲染页面可能请求了N多个接口。

举栗子

案例2：小程序商品会员价显示不正确。

由于app、H五、小程序三端使用的是同一个接口来获取商品相关信息，我会优先在H5平台调试，毕竟不用开Charles，方便嘛~~

遇到问题，快速响应和解决才是重点，特别的线上问题。因此有时候这个功能可能不是你开发的，那么如何在这么多请求中如何快速定位找个具体接口呢？这就要靠你的经验和聪明的大脑了。

这里就分享一个个人经验吧，不必定适合全部场景。就拿这个案例来讲：打开商品详情页，打开控制台。基于我对系统的总体了解，我确信必定会有一个接口返回商品的会员价，具体哪一个接口我也不知道。

好，这个时候怎么办呢？猜接口！固然了，也不是乱猜。获取商品会员价，那这个接口大几率须要前端传给后端一个商品id，那商品id在哪里呢？商品id通常都会出如今当前页面的URL里。因而，在控制台的filter框中（图中已标红）输入商品id。这个时候已经能够过滤掉大部分的请求了。

接下来你要作的，仍是猜！看看剩下这些请求地址名称，猜一下他的做用；看看接口返回的字段名称，有没有名称像“会员价”字段，有没有返回值和前端显示的会员价同样的字段。最后，通过大胆猜测以后，咱们要作的就是当心求证，确认咱们定位的接口是否正确。

定位代码

定位到接口以后，咱们就能够准备看代码，修Bug啦！

不知道你有没有遇到过这样的状况。打开代码，一眼望去，这个代码这么长，并且以前也不是我写的，我该怎么办呢？下面咱们就来说一下如何来快速定位Bug代码。

举栗子：

案例2：小程序商品会员价显示不正确。

通过咱们以前一顿猛如虎的操做，终于定位到了问题。

//接口返回数据
{
    "price":9900,
    "discountPrice":8900,
    "vipPrice":0,
}
复制代码

会员价显示不正确，也就是"vipPrice":0这个字段有问题。

打开代码，找到该接口对应Controller，找到该Controller返回的VO，找到VO中的vipPrice字段的setter方法，鼠标右键find Usages。恭喜你，这个时候你已经找到了这个vipPrice的值是在哪一行被设置的了，将重点聚焦于此便可，Bug就在这个代码附近了。看一下这个vipPrice的值是怎么计算出来的，是否是计算逻辑写错了。

若是这个时候，很不幸Controller的VO是经过BeanUtils这些工具类将属性映射过去的，那么你运行find Usages可能就找不到属性是在哪里被设置的了。唉，写代码时用的爽，出问题时泪汪汪。那只能查这个VO是在哪里被用到了，而后去代码里查了。

案例3：案例3：优惠券领取不了了，弹窗显示“领取失败，该优惠券仅限新人领取”！

若是“领取失败，该优惠券仅限新人领取”这个文案，是你的接口返回给客户端的，那么，这个时候你要作的就是，IDEA全局查找这个关键词。

哈哈哈，恭喜你，快速定位了，在PayUserRuleChecker的第51行，是否是很简单？

修复问题

既然已经定位到具体的代码了，那么就能够进行问题修复了。这个时候就要看我的经验啦，有经验的程序员可能一眼就能看出来问题。

这里列举一些须要注意的点：

• 学会聚焦。整个service方法的逻辑代码可能不少，可是像”会员价显示不正确“这种问题，必定是之和计算会员价相关，你只须要聚焦这一块的逻辑便可。
• 学会debug。有些状况下，即便发现了问题代码，却仍是发现不了问题（好比说，报错日志说第xx行有问题，打开xx行一看，懵，这里怎么可能会有问题呢）。这个时候，你应该尝试去debug代码，经过运行时debug，分析数据，来发现问题。

如何避免

借用测试大佬的一句话："没bug是不可能的，这辈子都不可能没bug的"。

而咱们要作的，一是要尽量的减小Bug，避免问题重复出现；二是要遇到问题，快速修复。千万不要惧怕Bug，更不要担忧出Bug就不敢写代码。

简单总结

最后的最后，就来作个简单总结：

1. 遇到问题不要慌，只要能复现，就能修复

2. APP、H五、小程序三端快速定位，找到问题负责人

3. 定位问题接口，找到问题代码

   • 如何快速定位问题接口
   • 如何快速定位问题代码

4. debug then fix

5. 总结经验，避免再犯

---

欢迎关注公众号：