首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >侦探养成技:如何追溯分析一个线上缺陷

侦探养成技:如何追溯分析一个线上缺陷

作者头像
腾讯移动品质中心TMQ
发布2018-02-06 15:47:11
1K0
发布2018-02-06 15:47:11
举报

前言

对于数学问题,自己想出答案和确认别人的答案是否正确,哪一个更简单,或者困难到何种程度。拟一个别人无法解答的问题和解开那个问题,何者更困难?——东野圭吾 《嫌疑人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再狡猾再如何伪装成迷,始终会显露真相,关键是有技巧和方法论,且有锲而不舍的精神,才能挖掘出真相。

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-09-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯移动品质中心TMQ 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • 一. 破案技巧揭密
  • 二. 案例分析—WiFi不能上网误判之谜
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档