作者:——emilyxlchen
前言

对于数学问题,自己想出答案和确认别人的答案是否正确,哪一个更简单,或者困难到何种程度。拟一个别人无法解答的问题和解开那个问题,何者更困难?” ——东野圭吾《嫌疑人 X 的献身》

前段时间看了一部小说,印象中最深刻的就是上面的这句话。百年一遇的数学天才石神,在暗恋的邻居靖子错手杀了前夫后,布了一个匪夷所思的局,让警方一直陷入迷局无法破案。当时看完的感悟就是 “有时你以为的正确答案,其实也会欺骗你。”

一直觉得作为测试人员,在追溯分析线上的用户反馈的问题的时候,跟侦探破案有异曲同工之妙——都需要分析案情现场(定位 Bug 场景)、尝试重现每一步(复现 Bug)、找出关键线索(分析 Bug),最终破案(解决 Bug)。不可避免的,我们也很容易被 “嫌疑人” 布下的局团团绕住了,找不到方向和正确答案。

那么我们如何跟大侦探一样,敏锐去破开迷局,去追溯一个线上用户反馈的 bug 呢?

一.破案技巧揭密

经多次实践,小编总结了一套 “Bug 追溯大法”,迄今已成功破获多起难以追溯的用户反馈的缺陷问题。这套追溯大法的精髓现公开如下:

1.明确追溯对象,了解事件原貌

好的开端是成功的一半。若你仔细去浏览过用户用户反馈的问题(如下表所示),你会发现用户的反馈描述很多是口语化的、从主观出发的、较少明确操作步骤,甚至现象的描述都相对含糊的。与平时测试人员去描述 Bug 的方式有较大区别。故收到用户反馈的问题,第一步不是行动,应该是仔细看清描述,去确认你所追溯分析的对象具体是哪个,缺陷发生的背景/场景究竟如何。

2.猜想 - 设计场景 - 实践

善于用理论和经验,与用户做准确的沟通,找出问题关键因子

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.查找嫌疑犯 -- 分析模块逻辑,从整体到部分去定位

在这里,推荐的分析模块的方式,是画出整体逻辑流程图,再从局部的分支去筛选过滤出可能引起问题的逻辑。

4.确认元凶

从第 3 步过滤出来的疑似有问题的模块着手,确认真正引起问题的元凶。可用的确认方法不限于以下两个:

1)善用日志记录:遇到暂无思绪的谜题时,通过打 log 方式输出整个流程,看与预期不同的地方在哪儿;

2)推断错误信息:通过系统打印的错误堆栈信息来推测错误原因并加以解决。

5.破案,解决案件

找到 Bug 根因后,解决 Bug,结案。

二.案例分析—WiFi 不能上网误判之谜

不能用于实践的理论都是耍流氓。上述讲的理论知识,遇到真实案件,我们究竟应该如何运用 Bug 追溯大法?

不要迷茫,请跟随小编脚步,开始真实的线上案例分析——“嫌疑人 CONNECTIVITY_ACTION 的献身:破开 wifi 不能上网误判的迷局”。

一).事件原貌

在 WiFi 管家 1.x 版本发布后,一直有用户出现如下反馈,内部用户也在一个夜里提了这个问题:连接一个可上网的 WiFi,WiFi 管家却提示不能上网,现象诡异。

这一步只能确定 App 的版本以及问题场景,但不能得知机型、具体操作的信息。

二).案情重现思路

1.收集出现异常现象的用户 “口供”

经过沟通,得出用户的具体描述:
“安卓 5.0 的小米 note,在三楼到 10 楼走动过程开屏后容易重现误判不能上网的问题”

2.分析线索,尝试重现

注:LP:需求对象 ;MO:模态词 ;UV:不明确动词; SD:简单省略 ;CE:触发和响应

根据 NLP,提炼出几个问题:机型是否有影响?Android 版本一定要 5.0?三楼到十楼走动过程主要是什么在变化?误判的重现率大概是多高?

根据上述提炼出的几个问题,本侦探跟相应产品、开发沟通后,提炼几个关键因素实地进行重现,同时结合大盘用户反馈的机型、安卓版本的数据进行分析:

机型、安卓系统、动作(跟 wifi 切换相关)

辅助分析数据:大盘用户反馈列表中,机型、安卓版本信息
机型覆盖各个品牌,安卓版本占比如下:

3.根据重现结果,提取案情关键因子

根据上表的重现结果,我们可以根据现象推断以下几点:

也就是说,关键因素是:动作(跟 wifi 切换相关)

三).查找嫌疑犯

已经梳理了关键因子,那么我们来仔细捋一捋当前的 WiFi 检测机制,看看是哪里可能出了问题,为什么 wifi 切换重新连接会容易出现能上网误判成不能上网的现象呢?

#### 1.WiFi 上网检测主流程图分析
当前的检测主流程:
连接上 WiFi 后,等待系统事件 CONNECTIVITY_ACTION 的广播之后开始做上网检测,根据当前检测的结果做下一步操作:可以上网会直接终止流程,超时或不能上网会进行重试 N 次的检测,最后终止流程。

说明:CONNECTIVITY_ACTION:系统广播的 action,注册监听后,在当前网络变化状态变化后,便可以收到网络变化的广播。

eg:从 GPRS 到 WIFI,程序至少会收到 3 个 Broadcast

2.嫌疑犯在哪儿?作案动机是什么?

和开发同学一起 revie 完流程,嫌疑初步定位在主流程的 CONNECTIVITY_ACTION 事件这里,但是转念一想,这就是系统给我们的答案了,我们一直觉得 WiFi 连接结果要与系统对齐,系统的答案应该是最正确的,难道它也会骗人?

四).嫌疑人 CONNECTIVITY_ACTION 的现身

案件陷入更深的迷局中,于是我们采用关键步骤打 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 再狡猾再如何伪装成迷,始终会显露真相,关键是有技巧和方法论,且有锲而不舍的精神,才能挖掘出真相。

就是侦探养成技——如何追溯分析一个线上缺陷的方法解密和运用。若对你也有启发,那就一起运用起来吧。

本章完~

原文链接:http://tmq.cs0309.3g.qq.com/2016/09/detective-to-develop-skills-how-to-trace-analysis-of-an-online-flaw/


TMQ(腾讯移动品质中心)是腾讯最早专注在移动 APP 测试的团队
我们专注于移动测试技术精华,饱含腾讯多款亿级 APP 的品质秘密,文章皆独家原创,我们不谈虚的,只谈干货!

扫码关注我们

扫一扫 关注 TMQ
精彩分享不断


↙↙↙阅读原文可查看相关链接,并与作者交流