腾讯移动品质中心TMQ [腾讯 TMQ] 侦探养成技:如何追溯分析一个线上缺陷

腾讯移动品质中心 · 2016年09月28日 · 最后由 恒温 回复于 2016年09月29日 · 759 次阅读

作者:——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.根据重现结果,提取案情关键因子

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

  • 1)机型没有太大影响;
  • 2)Android版本没有太大影响(从上述实地验证以及查看了大盘用户反馈的机型得出);
  • 3)切换WiFi,系统自动连接时,能大概率重现这个问题。

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

三).查找嫌疑犯

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

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

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

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

  • 第一个是连接到WIFI ;
  • 第二个是断开GPRS ;
  • 第三个是连接到WIFI .

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
精彩分享不断
共收到 1 条回复 时间 点赞

非常有趣味性,可以一些列成册了。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册