作者：——emilyxlchen
前言
对于数学问题，自己想出答案和确认别人的答案是否正确，哪一个更简单，或者困难到何种程度。拟一个别人无法解答的问题和解开那个问题，何者更困难？” ——东野圭吾《嫌疑人 X 的献身》
前段时间看了一部小说，印象中最深刻的就是上面的这句话。百年一遇的数学天才石神，在暗恋的邻居靖子错手杀了前夫后，布了一个匪夷所思的局，让警方一直陷入迷局无法破案。当时看完的感悟就是 “有时你以为的正确答案，其实也会欺骗你。”
一直觉得作为测试人员，在追溯分析线上的用户反馈的问题的时候，跟侦探破案有异曲同工之妙——都需要分析案情现场（定位 Bug 场景）、尝试重现每一步（复现 Bug）、找出关键线索（分析 Bug），最终破案（解决 Bug）。不可避免的，我们也很容易被 “嫌疑人” 布下的局团团绕住了，找不到方向和正确答案。
那么我们如何跟大侦探一样，敏锐去破开迷局，去追溯一个线上用户反馈的 bug 呢？
经多次实践，小编总结了一套 “Bug 追溯大法”，迄今已成功破获多起难以追溯的用户反馈的缺陷问题。这套追溯大法的精髓现公开如下：
好的开端是成功的一半。若你仔细去浏览过用户用户反馈的问题（如下表所示），你会发现用户的反馈描述很多是口语化的、从主观出发的、较少明确操作步骤，甚至现象的描述都相对含糊的。与平时测试人员去描述 Bug 的方式有较大区别。故收到用户反馈的问题，第一步不是行动，应该是仔细看清描述，去确认你所追溯分析的对象具体是哪个，缺陷发生的背景/场景究竟如何。
善于用理论和经验，与用户做准确的沟通，找出问题关键因子
1）收集出现异常现象的用户 “口供”
当用户反馈描述的信息不足以给出具体操作步骤等信息时，此时需要我们从专业角度出发，去评估当前还需要补充的信息，直接与用户沟通，从而得到完整的 “口供”。例如下面的例子:
2）分析线索，尝试重现
得到用户完整的 “口供” 后，如何去分析案子，找出线索呢？
在这里本侦探推荐运用测试分析——NLP 元模型建模法去提炼问题，来帮助我们科学、有条不紊地分析。
注：NLP:Neuro Linguistic Programming 是人工智能 AI 的一个子领域，是帮助我们以批判式思维理解语言的一种模型，NLP 元模型：用于探究、发掘交流沟通中那些容易产生歧义的点的一套系统。
这个模型的重点，是在于分析句子结构，询问自己以下几个问题：what / how / how often / contain what / from where Based on what 。
Eg：如何分析一个描述：
根据上述的元素，通过提问，我们可以分析的内容有：
涉及多少个系统？如何启动?每日交易文件是放在哪儿？如何处理？5s 是如何计算？若 5 秒内没处理完会如何？处理具体是什么操作？完毕又是怎样定义？......
3）根据重现结果，提取案情关键因子
在上一步所述的 NLP 元模型提炼的问题里，选出可能影响的因素，进行重现。根据重现结果，归纳真正影响案件的因子。
在这里，推荐的分析模块的方式，是画出整体逻辑流程图，再从局部的分支去筛选过滤出可能引起问题的逻辑。
从第 3 步过滤出来的疑似有问题的模块着手，确认真正引起问题的元凶。可用的确认方法不限于以下两个：
1）善用日志记录：遇到暂无思绪的谜题时，通过打 log 方式输出整个流程，看与预期不同的地方在哪儿；
2）推断错误信息：通过系统打印的错误堆栈信息来推测错误原因并加以解决。
找到 Bug 根因后，解决 Bug，结案。
不能用于实践的理论都是耍流氓。上述讲的理论知识，遇到真实案件，我们究竟应该如何运用 Bug 追溯大法?
不要迷茫，请跟随小编脚步，开始真实的线上案例分析——“嫌疑人 CONNECTIVITY_ACTION 的献身：破开 wifi 不能上网误判的迷局”。
在 WiFi 管家 1.x 版本发布后，一直有用户出现如下反馈，内部用户也在一个夜里提了这个问题：连接一个可上网的 WiFi，WiFi 管家却提示不能上网，现象诡异。
这一步只能确定 App 的版本以及问题场景，但不能得知机型、具体操作的信息。
经过沟通，得出用户的具体描述：
“安卓 5.0 的小米 note，在三楼到 10 楼走动过程开屏后容易重现误判不能上网的问题”
注：LP:需求对象 ；MO：模态词 ；UV：不明确动词； SD:简单省略 ；CE：触发和响应
根据 NLP，提炼出几个问题：机型是否有影响？Android 版本一定要 5.0？三楼到十楼走动过程主要是什么在变化？误判的重现率大概是多高？
根据上述提炼出的几个问题，本侦探跟相应产品、开发沟通后，提炼几个关键因素实地进行重现，同时结合大盘用户反馈的机型、安卓版本的数据进行分析：
机型、安卓系统、动作（跟 wifi 切换相关）
辅助分析数据：大盘用户反馈列表中，机型、安卓版本信息
机型覆盖各个品牌，安卓版本占比如下：
根据上表的重现结果，我们可以根据现象推断以下几点：
也就是说，关键因素是：动作（跟 wifi 切换相关）
已经梳理了关键因子，那么我们来仔细捋一捋当前的 WiFi 检测机制，看看是哪里可能出了问题，为什么 wifi 切换重新连接会容易出现能上网误判成不能上网的现象呢？
#### 1.WiFi 上网检测主流程图分析
当前的检测主流程：
连接上 WiFi 后，等待系统事件 CONNECTIVITY_ACTION 的广播之后开始做上网检测，根据当前检测的结果做下一步操作：可以上网会直接终止流程，超时或不能上网会进行重试 N 次的检测，最后终止流程。
说明：CONNECTIVITY_ACTION：系统广播的 action，注册监听后，在当前网络变化状态变化后，便可以收到网络变化的广播。
eg:从 GPRS 到 WIFI，程序至少会收到 3 个 Broadcast
和开发同学一起 revie 完流程，嫌疑初步定位在主流程的 CONNECTIVITY_ACTION 事件这里，但是转念一想，这就是系统给我们的答案了，我们一直觉得 WiFi 连接结果要与系统对齐，系统的答案应该是最正确的，难道它也会骗人？
案件陷入更深的迷局中，于是我们采用关键步骤打 log 方式，重现后对 log 进行分析。
06-07 20:14:27.544: I/check_network(26783): networkError java.net.UnknownHostException: Unable to resolve host "xx.com": No address associated with hostname
06-07 20:14:27.544: I/check_network(26783): sRedirectLocation empty, httpRet.contentLength:-1 returnBodyLenthRq:4
06-07 20:14:27.544: I/check_network(26783): respone code:-1 bodyLength:-1
checkNetworkAviable, finish. result.avilable:false
See？检测结果是不能上网，原因是域名解释失败，一般来说这种错误出现在 wifi 没连上的情况。
嫌疑人总算浮出水面，案件的根因就是——依赖 CONNECTIVITY_ACTION 结果作为触发网络检测时机原来在部分机型上是不可靠的。
自己想出答案和确认别人的答案是否正确，哪一个更简单？
相信看到这里你也已有体会。Bug 再狡猾再如何伪装成迷，始终会显露真相，关键是有技巧和方法论，且有锲而不舍的精神，才能挖掘出真相。
这
就是侦探养成技——如何追溯分析一个线上缺陷的方法解密和运用。若对你也有启发，那就一起运用起来吧。
本章完~
扫码关注我们
