说明

本文以文字为主,会讲解到理论及具体工作思路,因当时没有保存代码,因此代码部分不贴,也懒得写了;
因内容过多,途中会插入部分表情包,阅读时长5-10分钟;

前言

这篇文章修改很多次,各种推倒重写,原因是,一开始只想写自己做过的东西,但是写着写着,觉得太局面,因此想换个大点的角度,能力有限,写的不好或不够,欢迎讨论;

去年8月份,做了线上问题跟进的事情,持续到去年年底,后来因进度问题,以及采用的底层方案有点问题,就让研发负责了,从某种意义上,这是第一个完全自主负责的项目;
image.png-98.6kB

整个项目对于Jb来说是个挑战,同时是一个明显的成长点,后来找工作面试的时候,很多企业对这个感兴趣,问的东西比较细,到现在为止,依然很感恩有这个机会;

一年后的今天,如果要问自己,同样的问题,有没有更好的解决方案?目前来看,没特别的想法,总感觉今年在测试这方面,有点退步了,毕竟今年都在不务正业;

日常骚操作

废话一大堆,来谈主题吧;

相信每一位测试&研发,都会有这日常工作:
跟进线上问题

无论是PC、M端、小程序,只要是面向C端的产品,发布后,肯定会有用户反馈问题;

相信很多同学都会遇到这些问题,遇到问题别慌,这类问题一般都会有一套应急流程,因不同公司而异,这里只说知道的;
image.png-121.7kB

一般来说,线上反馈分两类:
紧急&非紧急

紧急问题处理流程

一般的紧急问题处理流程如下:

大致上是说,就是这么一个流程;

非紧急问题处理流程

而对于非紧急的问题,一般如下:

基本上,这两套流程就能用了,很普通的流程,尤其非紧急流程,内部反馈问题也大概是这样,只是内部反馈,可以及时要现场重现;

一般来说,紧急情况,如果实在找不到解决方案,回滚是最后的方案;

而对于非紧急情况,现实往往是测试折腾半天,无法重现,然后放一边,毕竟工作繁忙,而且反馈的问题也比较多,没可能过多投入;

一旦形成习惯,这类情况一般都会说,无法重现,完,然后没下文了,这也是测试日常的骚操作;
image.png-67.2kB

其实从用户角度想想,蛮累的,之前简单统计过,用户主动反馈问题的比例是万分之一,而这万分之一的用户反馈问题过来,测试却说,无法重现就完了,而且也没个交代,犹如石沉大海一般,很打击积极性;

到这里,要知道一点,不能挑战用户,有用户反馈,就说明用户想这个产品越来越好,然而现实很残酷,他明明爱着你,但是你却不知道,舔狗不得house;
image.png-232.8kB

吹下理论吧

上文得知,一条用户反馈来自不易,那如何有效利用用户反馈,以及把没反馈的用户也利用起来,就是需要思考的问题了;

需要注意,用户不反馈问题并不代表没问题,也许用户想反馈问题直接crash了,无法反馈,或者有问题模块不影响用户日常使用,jb也是用户,看到软件有bug,懒得反馈,反正可替代品那么多,不行就换一个罗;
image.png-21.5kB

上面说到的,这里都不介绍,主要想说说自己对质量保障的看法,可能比较片面,但是想增加对线上质量的关注;

目前整个质量环节大致是这样:

当然,上面说的只是大致环节,还有很多小环节没有暴露,比如上车检查(代码检查)、monkey、核心数据、集体试用等环节;

看到这里,不得不问,如何在敏捷项目中做好质量管理?

质量管理是一个大环节,并不单单是测试找bug,而是贯穿项目立项到结项整个过程,比如产品文档规范等都是一环,比如,产品文档模棱两可,研发测试也没有核实,结果成品跟产品要的效果不一致或者有很多BUG,导致项目延期;

怎么做好质量管理,目前想到两个环节:预防&测试分级

预防

预防,在项目初期就可以有一定的计划,让项目避免出现已知或可能出现的风险。
提前规避,是检验项目经理对整体项目把控程度好坏的重要考量标准。

而定期检查和调整是保证产品质量的关键,定期召开评审会/晨会,及时同步信息,在此显得尤为重要;

那研发侧怎么预防?目前大众的方案就是静态代码检查、lint、代码覆盖率(jacoco较多),从以往经验来说,静态代码、lint的检查,能发现不少编码、性能问题;
image.png-20.9kB

测试分级

一般说的测试,大部分指功能测试,但是靠功能测试,不足以保障质量,因此需要对测试进行分级,拆分出更细的测试维度;

自动化验证和持续交付

互联网的节奏非常快,想在高强度的氛围保障质量,是一件很有挑战性的事情,换个角度,是否有不需要测试就可以直接上线的情况?

如果想达到这种情况,要做什么?

这个话题就更大了,jb也还在学习ing,但上面有提及到,静态代码检查、看研发代码等,除此,代码覆盖率、自动化都是提高质量的一环;

但有一点是肯定的,要做这块,必须要懂代码,记得前前前老大跟jb说过一句,好的测试,编码能力应该要比最差的研发要强;

上面说的都是台前,那我们也要关注幕后,因为质量并不是一环;

那幕后有什么?打包效率、提测质量、上线部署、线上质量监控,这里不像详细说明,直接贴一个图;
image.png-145.6kB

从性价比看,发布部署是性价比最高的,直接弄个jenkins,写点具体发布脚本即可,收益是最高的;

别少看打包效率这类问题,一人打包10分钟,2人打包20分钟,如果提高到5分钟,那1人就节省5分钟,100人就节省500分钟了,亲身经历,这类问题不能轻视;

其他的提测质量、线上监控,都是很大的点,这里不说;

质量管理优化

不管什么公司,多多少少都会有不同的问题,只是,在大公司里面,往往通过协助平台、流程规范等方式把问题解决或屏蔽,但是在小公司,问题就会暴露出来;

做质量管理不容易,需要强大的内心,而且,公司资源向你倾斜,只有这样才能真正推行,否则如石沉大海;

遇到问题,不要慌,这里介绍三步走:

体系状况,分析梳理

古人云:工欲善其事,必先利其器,想优化,必须得先知道病在哪里,那不妨从以下几个维度去了解问题;

质量流程,优化设计

上面给出了初步改善建议,那接下来就要规定流程,针对具体问题制定规范,明确每个职能部门的分工;

质量规范,部署实施

定下规范,就去试试吧;

业界也有个词,叫测试左移,简单说,就是让测试提前介入所有流程:

更详细的,自行上网查询;

大家怎么玩

上面啪啪啪的一大堆废话,本文的重点在于线上质量,那就聊正经事情吧;

问题一般分两类,性能问题、功能问题,体验问题不算在这里;

性能问题能通过一定的规则来抓取,比如获取当前APP的内存,是比较固定的内容:

那,在跟进线上反馈的时候,到底遇到什么问题?
image.png-30.7kB

记得是在去年2月份,上testerhome发帖子问,幸运得到部分大佬答复,看到的方式有2种:

很不好,当时就是处于第二种,只是觉得,即使是联系不上的用户,也不能浪费;

怀着这份激情,跟老大反馈多次,逐渐的,老大们也开始关注到这块,因此就立了个专项,让jb去负责处理这个事情,因此,这个事情的开端就是:如何跟进线上问题;

这里更多指的是,无法联系,或者联系了重现不了之类的用户;

既然大家都是依赖log来玩,那我们也这么玩吧;

题外话:虽然很不喜欢处理线上反馈,但遇到暖心的用户真的很感动,幸运的是,jb遇到不少,远程各种协助跟进问题,好人还是不少的;
image.png-27.6kB

独乐乐不如众乐乐

既然问题核心是没有log,导致无法跟进问题,那换个角度,有怎样的log才能跟进问题?

因此,有了以下的内容:

这就是第一期的目标-发现问题

上面的问题如何解决?

Q:如何在release版本开启收集日志功能?并且支持动态关闭?
Apush,产品本身支持push,有独立push通道,即使用户退出APP也能收到push消息,
因此,针对不同模块(用户行为日志、卡顿、启动速度、内存等)做独立的标记,定好协议,客户端收到push消息后做协议解析,然后修改对应模块的标记,APP重启后做判断,这样就可以达到动态开启\关闭的效果;

Q:怎样的日志内容能满足不同业务进行跟进问题?
A:这是个问题,一开始想着做全家桶,但是后来发现不适合,原因是业务方只会关注自己业务的出错日志,如果弄全家桶,业务方过滤日志需要大量成本;

因此觉得,封装一层提供接口,提供一个写日志的接口,业务方根据协议来传对应的内容即可;

这样,一份日志可能会有多个业务方的内容,没关系,因为格式是固定的,日志回传到服务器后,服务器脚本做解析,最终会把一个日志根据格式内容拆分出N个日志,这样拆分出来的日志就是对应一个业务方的日志;

********************************************
#此处公共模块信息
版本号:XXXX
子版本号:XXXXX
流水号:XXXX
时间:XXX
模块:小说
********************************************
#具体业务日志内容
********************************************

********************************************
#此处公共模块信息
版本号:XXXX
子版本号:XXXXX
流水号:XXXX
时间:XXX
模块:搜索
********************************************
#具体业务日志内容
********************************************

Q:日志什么时候保存?保存在哪里?什么时候回传?回传到哪里?回传到怎么处理?
A:这里面,只有日志什么时候保存是关键;但是这里不细说过程,最终选择的是xlog;

微信开源的一个收集日志库,好处就是,不需要自己处理各种逻辑(比如日志文件限制多少M后拆分等),直接初始化,然后XLog.d就可以用了;

xlog是后面换的,一开始是自己折腾的,浪费不少时间,所以,造轮子之前,想看看有没有好轮子,避免浪费时间;

因为有个业务是联网业务,因此选择软件启动后就异步初始化,只要业务方一调用XLog.d,就会有文件生成;

Q:什么时候回传日志?
A:这里要解释下,一般情况下,日志不会回传,上面都说了,要解决两个场景,

如果是用户主动反馈,则在点击反馈的时候,先把日志上传,得到一个地址,然后再把地址传给客服系统的接口,

这样就能在具体反馈里面看到具体日志,当然这个是原始日志,需要解密处理,因此会再传一个解密后的地址,跟解密服务器约定好的格式;

如果用户没反馈问题,那就在业务出错时把日志上传,业务出错的时机交给业务方自行判断;

部分业务是没办法识别到出错的,比如联网业务,因此这类业务采用日志先落地不上传的策略,需要时通过push拉取日志;

至此,第一阶段,发现问题,到此结束;
image.png-11.3kB

看看干了啥

既然有日志了,那对于测试同学来说,比较方便了,如果没记错,问题解决率在30%左右,看上去觉得很低,但实际是因为,很多功能研发还没埋点,算是一个不错的效果;

点对点的问题解决了,那点对面了?从项目的角度,想知道线上什么情况,怎么搞?

因此专项第二阶段就是监控问题

其实,监控问题,没有太多的内容可以说,无非就是把日志如何解析,聚合,数据处理再显示而已,最终的效果就是,点击某一个版本,选择某一个模块,就可以知道这个模块收集到的日志排名,研发根据这个排名依序解决问题就好了;

换种方式踩坑

做完上面2个阶段,时间到了10月初,期间从立项,方案,调研,编码,灰度,推行都花了不少时间,尤其在推行这一环节,要有具体数据来吸引业务方来使用,不然做出来没人用是很尴尬的事情;

这时候,既然产品有这样的功能,想让用户有意识使用,说白就是想增加曝光,有如下的想法:

但是1、2被产品经理打回,原因是,用户反馈这个功能不是每个用户都必须的,为了那点人而浪费一个新手引导位,不合适;

当时听到很不舒服,但是事后回去站在场景的时候思考,有点道理,打脸了吧~
image.png-42.9kB

那就想办法简化用户进行反馈的路径吧,经过思维的碰撞,内部觉得,在产品上三指长按一定时间弹出反馈界面,是一个不错的场景;

跟产品沟通后,产品觉得可以,那需求就为:用户三指同时长按屏幕2S,弹出意见反馈页面;

从此,跌入深渊,自己给自己挖了一个大坑;

跌入深渊

需求很简单:用户在app内使用三指长按屏幕2s,APP执行某操作;

挖坑

需求关键字:三指,长按,2s,执行(这不是需求原话么)
image.png-29.1kB

当时的处理逻辑是这样的:

(懂的大神已经笑了~)

当时信心满满的上线后,发现使用的uv\pv都非常高,非常不合理,因为app上没有功能引导,用户也没有三指的行为习惯,所以肯定是出bug了;
image.png-30.3kB

跟进这问题2个步骤,

问题到底在哪里?
新增了用户的场景统计,发现部分用户在色情网站会连续出现打点,本地尝试没发现问题,就让其他同学帮忙用用,结果发现问题了!!(一个人的力量是有限的,理解也是有限的~)
image.png-1.1kB

原来用户是有多指(3指及以上)进行缩放的习惯,如果用户是使用三指进行缩放,而且还是一直在屏幕不停缩放(即没有手指离开屏幕),就会出现问题了;

因为代码只判断触发前后的手指个数,中招了!(事后跟产品沟通,这种用户可能是平时有用iPad的习惯。。而色情网站是用户在看图片或者漫画,为了看得更清晰,所以需要缩放,就出现问题了,但是还是没想懂如此明显问题,居然没用户反馈?)

噗,多明显的设计问题啊~!

二遇坑

重现后问题就好办了,逻辑重写,处理event事件,触发逻辑不变:

1)当用户手指个数为3个且每只手指按下时间差不大于50ms(防止用户是一只手指点击后再放第二只手指,这种场景是无效的,因此设定个两个手指的时间差),就会设置一个runnable 2S后执行;

2)其他情况,长按后,产生up事件(有手指抬起)、move事件大于一定距离(认为用户在滑动)、大于3只手指,这些场景都会把执行removeRunnable操作,则把runnable取消,避免触发操作a逻辑;

这样算是把门槛调高了,上线后,误触发的占比大幅下降,但是,仍然有百分之一的用户误触发,虽然人均pv大部分为1!!

对比原来动不动误触发,的确是有优化效果的,但是,百分之一的uv也是很困扰~

经过好几轮灰度,最终发现一个问题,问题用户的event常规统计数对不上,那说明有其他没有统计到事件在一直执行,最终发现是cancel事件!!!

再次懵逼,cancel事件理论上是不会触发,至少自己本地用几台机器都没出现。

android文档的说明很简短,想看明白很难。国外一网页说的还比较详细,写在这里分享给大家:

原文是这样的:

You receive this when a parent takes possession of the motion, for example when the user has dragged enough across a list view or scroll view that it will start scrolling instead of letting you press the buttons inside of it.

意思是这样的:

当你的手指(或者其它)移动屏幕的时候会触发这个事件,比如当你的手指在屏幕上拖动一个listView或者一个ScrollView而不是去按上面的按钮时会触发这个事件。”

当时懵逼,我们的场景没有这种行为,为什么还会有cancel事件,肯定有其他原因,最终终于找到了:

“当控件收到前驱事件(什么叫前驱事件?一个从DOWN一直到UP的所有事件组合称为完整的手势,中间的任意一次事件对于下一个事件而言就是它的前驱事件)之后,后面的事件如果被父控件拦截,那么当前控件就会收到一个CANCEL事件,并且把这个事件会传递给它的子事件”;

划重点:被父控件拦截!!

最后经过多次验证,的确是被拦截了,但是,是被rom拦截了!

通过统计数据,发现oppo r9及以上机器很容易出现该问题,人均pv高达几十次,后来找来机器验证,发现问题了:

原来这些手机系统上自带了一个三指上/下滑动进行手机截屏的功能,而原理就是监听event事件,如果发现手指个数等于3,操作系统层直接返回cancel事件;

而客户端没有针对cancel事件做处理,因此导致逻辑继续跑,意味着用户执行系统三指截图功能时,顺带把app的这个三指功能也触发了~

这个问题已经跟oppo的研发沟通,的确如此,而且一加、小米、魅族等新机器都有此功能,如果手动在系统设置把系统的三指功能关闭,则app的三指功能恢复正常,再次验证这个假设;

虽然发现了问题,但是开心不起来,因为后来发现不同厂商虽然都有这功能,但是实现的方案不一样,这里不细聊,后面权衡后,决定对oppo的手机做兼容处理;

(系统逻辑是三指长按后滑动,我们的逻辑是三指长按2s,其实还有区别,但是被系统强奸了。。)
image.png-31.6kB

处理方案讨论了好久,也好了好多大神沟通,纷纷表示没办法,毕竟是操作系统返回的,你能怎么办?话虽这么说,但是后来还是针对cancel事件做了特殊的处理

通过调试发现,一旦触发这种cancel事件,oppo系统会一直返回cancel事件(原理是触发move,系统把所有事件触发都返回cancel,对于系统而言,move是很高频的且很短,而如果真的触发了系统的截屏,每次截屏耗时基本在200ms以上,针对这一特性做手脚)

1)在收到cancel事件时,判断之前触发的runnable是否已经存在;如果存在,则手动把runnable取消;

2)如果每次cancel事件大于200ms,则认为触发了系统的截屏,则把这个事件相加保存起来,原因是排除move事件的影响;并且执行次数+1;

3)当执行次数少于15次且时长大于2s,则认为满足条件,此时判断是否为3只手指且没明显滑动操作,如果是,则立即触发执行操作a;(设置次数是为了提高门槛,不然随着次数的增加,肯定会有达到2s的情况,这样就没意义了)

代码上线了,虽然不是百分百杜绝误触发,但是占比再次下降,基本达到万分之一,这事后来就不折腾了~

如果有更好的解决办法,欢迎一起讨论,这个方案并非合理方案,只是简单处理,而整个功能虽然一句话,但是从编码到最后发现,用了一个月多点,而不停灰度收集统计是时间的大头~

小小结:

爱理不理

既然用户反馈这么重要,是不是每条都需要跟进?

答案也是否定的,给自动化一样,自动化很重要,那是不是所有项目都要做自动化?同理而已;

有一类产品,不需要做过多的线上闭环这么一个流程,是跟钱相关的,比如P2P,理财类;

为什么?因为用户的钱在你那里,再大的bug的,用户的也得忍受,而工具类产品不一样,比如新闻资讯类,有问题,换一个,很现实;

这也不代表用理财这类产品不需要管线上反馈,只是不需要做到那么细的地步,遇到线上问题,还是要处理的哦;
image.png-113.5kB

吧唧下线上跟进流程

谁没有过跟进线上问题的经历,下面就介绍下跟进线上问题的流程吧:
image.png-19.4kB

影响范围评估

QQ截图20181108135838.jpg-44kB
拿到问题,肯定是先要评估影响面,根据影响面的不同以及影响时间,采取不同的修复策略;

问题定位

QQ截图20181108140504.jpg-64.2kB

修复方案

QQ截图20181108140943.jpg-48.3kB

复盘

关于复盘,不想多说,可以来这看,之前写过一篇关于复盘的总结;

1629b91cb8d982d5-40kB

撒花

写了将近1天的时候,本来三指那块是重点,但是想着既然都要写了,就从一个大的角度去说说吧,对自己来说,算是巩固了这块的知识了,算一个知识回顾吧;

看到这里,感谢您的坚持,纯文字的文档,居然能坚持看到这里,兄弟,不容易吧;
image.png-32.7kB

小结

常规流程,来个小结;

而质量管理优化,有以下三步:

剩下的,就是收集log的工作,大概思路如下:

接着就是安卓三指遇到的坑,总结下:

题外话

以前见识到手淘的黑科技,具体链接忘记的,大致流程如下:

这样,就可以把用户的操作一览无遗,高级玩家高级玩家;
image.png-36.4kB

最后,欢迎大家一起探讨,毕竟一个人的力量是有限的,jb只是在无知的世界里漫游而已;

最后的最后,谢谢大家~
1-140R3154U8.jpg-9kB


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