腾讯科技鲁万林谈如何通过线上数据挖掘，提升用户品质满意度

鲁万林：大家好，我来自腾讯, 从2011年开始做安卓浏览器一直做到现在，今天过来和大家交流一下我们在线上数据这块怎么去做的。我主要分享两方面，一个是背景，另外就是我们的案例，来讲解一下我们整个做的过程。

这是我们很多年前遇到的问题，相信在座各位都会遇到，就是用户反馈平台上提了一个问题，希望把问题修改一下，其实对我们来讲我们非常想把用户问题尽快解决，从用户反馈的简短信息来讲，我们能不能把问题解决？这其实很难，不管从内部数据还是从外部数据其实很少的，所以这种情况下，相信很多同学操作方式都会这样，就是用QQ联系用户，实际上联系用户成功率非常低，输入验证码会抛掉一定用户，还会拒绝你，还有的加了以后无响应，还有的就是无法复现，这就是我们以前遇到的问题。这样解决问题的效率是非常低效的，所以我们后来做了线上解决方案，这个是2015年开始做的，现在这种方案不仅是解决线上用户问题，还有其他的几个方面，等下介绍下。

我想提一个问题给大家思考一下，比如说之前是测试一个APP，现在一个新APP过来的时候，你之前测试经验能够给你带来什么东西？或者你以前测试经验能给你提升效率多少？或者再换种方式，你带的测试团队，你怎么使得测试团队可以快速把这个新产品质量快速保障好？我觉得大家可以思考一下这个问题，这个问题也是两年前我们遇到的，我们做了好几年，我们遇到新APP的时候，我们想我们之前经验对于我现在APP测试有什么？能提升我们多少的效率，能直接应用到新app的有哪些？基于这个的话，我想做个调查，在座各位应该有知道bugly的吧，那个是我们部门开发的，这块以前大家做稳定性测试的时候，大家怎么做的？可能很多人就是monkey或者控件遍历等等这些东西。但bugly出来后，基本不需要稳定性测试，就不怎么需要专门的测试同学来做这块测试，而且非常快速解决了线上crash问题。

今天给大家分享带来我们做的另外领域的实践，我们这块包含三方面，第一是我们刚才讲到线上用户的问题怎么解决，第二个就是我们需求的选型。大家都知道用户增长已经非常低了，基本上很少的增长，怎么在用户很少的增长时候给用户提供更好的服务？来使得用户对你产品的品质，满意度更高，所以说现在很多需求都会有A、B、C三种方案，通过我们的系统能够快速的知道用户对哪种方案是最优的，是能选择的，这是我们第二个。

第三个性能监控，就像刚才讲的一样，用户反馈新的问题说卡顿，实际上你不知道怎么解决，你的数据很少，还有用户出现问题，其实并不一定来反馈，怎么解决不反馈问题的用户问题呢，所以我们做了这个性能的监控。 这是我们大概的系统。

我讲一下大概系统的架构，我们系统分三方面，一个是终端这块。第二个Server这块，第三个是我们会跟周边系统打通。我先讲终端这块，终端这块我们主要是SDK嵌入APP，SDK有两个作用，第一个作用：有一些API，这个API做什么呢？大家知道我们要去测试的话，其实就是一个数据的输入，输入到系统当中，系统的话最后回来验证结果，我们这块其实就是数据采集。数据采集包含三方面，一个是监控，第二个是埋点，埋点有业务埋点和技术埋点，第三个就是云控，云控是做什么的呢？因为我们涉及很多方面，我们对于数据需求是不同层面的，所以云控就可以做到根据我的需要来获取到我需要的数据就可以了，复杂问题需要详细数据，简单问题简单数据就好，这样会减少对我们众测用户和热心用户性能的影响。

下面这块就是我们的数据埋点和这种数据已经有了以后，我们需要存储，存储这块我们采用微信的Xlog，这块他们做的非常厉害，就是对用户性能影响非常低的。这个是我们客户端，客户端到Server这层，Server这层主要分四方面。第一个方面是接入层，第二层分析层，第三层是查询，是给web和其他提供开放的API。第一层负责文件传输存储，为什么分三个方式？其实是这样的，因为我们数据分不同层面的，不同层面的话其实为我们后续的分析更加精准，我们是把我们数据放在三个不同地方存储。这个主要是存储我们原始的数据，这个主要是存储我们格式化数据，比如说我们版本号，我们系统信息，这个主要是存储我们的埋点，还有监控的数据。

比如说我们用户出现卡顿以后，后面会讲我们抓回的堆栈，这个堆栈大小各方面都不一样，所以存在这里面。上面我们会有一些分析，我们第一个会做数据清洗，然后会做文件的操作，路径的分析，特征提取等等。这块也是采用的一些AI技术，我们采用的AI技术根据我们需要做，不是一股脑就上去的，主要是提升我们的效率和分析能力的，再上面我们就是提供接口，再上面是展示，后面会给大家看一下我们做的案例的展示，这里提供给外面的接口，这边是给Bug系统打通，邮件系统打通，所以整个客户端到后台全部打通。举个例子，线上我们监控用户卡顿了，我们经过后台分析，分析这是一个Bug，然后给打通的Bug系统，给开发提了Bug，开发把Bug修了，修了以后回到系统，回到系统后接下来我们会用线上，或者是众测用户和热心用户来验证问题有没有修改，所以下一个版本时候也会通过这样方式来看，我们这个问题是不是修改了，来自线上也回归于线上，这是我们的一个整体架构。

我们涉及三个方面，而时间有限，我们本次以一个方面进行交流，如果大家对其他两个方面有兴趣的话，可以下来交流，接下来讲一下卡顿监控案例，以前我们是通过测试人员不断测试功能，采取各种办法来测试卡顿，而我们现在没有测试人员做卡顿测试，全部通过这套系统完成。我们有一个用户体系，由众测用户，有热心用户，还有少量灰度用户。通过这个用户体系，监控用户在使用过程中，是否存在卡顿情况，如果存在后通过系统分析，判断确实是卡顿，就提单给到开发，由开发修改，然后我们再通过用户体系进行验证问题是否解决。

然后我们讲一下卡顿这块。这是我们数据采集的总体流程，以前我们测试这个卡顿都是测试人员不停的操作来的。现在我们这一套流程是什么？用户使用的过程中，我们监控到是否卡顿。我们用户操作APP的时候，这是我们开始，然后我们会间隔30毫秒获取瞬时堆栈。当卡顿大于3000毫秒的时候，假如说用户3000毫秒还卡顿，我们就开启获取Trace，大于5000毫秒的时候我们就上报回来了。瞬时堆栈信息比较少，性能影响很低，trace信息量很大，性能影响大，所以我们为了避免我们程序给用户体系的用户带来卡顿，我们是根据卡顿的情况来合理获取对应数据，解决用户卡顿的问题。

下面我们讲一下我们具体的操作。这是我们第一版的数据采集，大家可能对这个安卓的卡顿和绘制这套比较熟悉，卡顿最顺畅的话就是1秒60帧，这个大家应该都OK。我们后来想想说我们去做这个卡顿监控的话，那我们怎么知道用户卡顿了？还是说怎么知道用户出现了问题，其实我们分析了以后，网上也有很多，其实是利用了安卓这个Choreographer，这个主要做什么用呢？大家网上可以查一下，我们讲一下原理，安卓绘制一帧的时候会调用这个Choreographer里的接口，理论16.6毫秒绘一帧，那这个会16.6毫秒执行一次，如果两次执行大于16.6毫秒就说明已经丢帧了。掉帧是不是就感觉到卡顿了？只有连续出现掉帧的情况，用户会感知到，这里我们其实采用了一个法则，就是当用户100毫秒，就是这两个的间隔大于100毫秒我们认为丢帧了，也就是连续丢6帧，这个FPS值54我们就认为卡顿了，但是这个标准非常严格，我们大家可以下去测试下，其实人感知卡顿大概是40多帧才会有感知，其实56帧还是比较顺畅的，所以我们为了追求更好的，我们把这个值定得非常严格。

当这个大于100毫秒的时候我们获取一次瞬时堆栈，在我们第一个版本做完以后，我们解决的比原来方式好很多，但实际上还是存在着解决率比较低的问题，大家想想为什么，因为我们是在100毫秒时候才获取一次瞬时堆栈，有可能其实是在之前已经存在问题，但实际上我们获取点的时候没有踩到正确位置上，所以我们解决率还是不高，这是第一版。

第二版我们想解决获取的数据不全的问题，所以我们进入到第二版。第二版和以前的区别是说，我们在用户的启动时候，用户操作界面时候我们就去获取瞬时堆栈，这个是最开始的30毫秒，我们测试时间间隔多少，对用户影响是最低的，我们就取得了一个30。我们会不断的取，第一次的时间，第二次时间大于100毫秒我们认为是卡顿的，这样我们就获取卡顿过程中比较多的数据了，所以比之前要多很多数据。那这样对我们分析和开发解决问题是非常有利的。

第三版是这样的，其实我们发现有用户卡顿是在5秒以上的，我们就想把这些用户卡顿解决掉，提升用户的流畅度，我们操作是当大于3000毫秒我们就获取trace，5000毫秒时候就停止，这样我们获取信息非常全，对解决用户困难是会起到非常好作用的，解决了因机器等问题导致的卡顿影响。

我们讲一下后台分析这块，后台分三部分，第一部分是数据预处理，第二部分是数据分析，第三是结果展示。原始数据这块我们主要做的是数据清洗，因为文件在网络传输过程当中可能存在着丢失或者只有一半的情况，所以这一块我们会先做一些简单清洗。第二个我们做一些聚类，为什么要做聚类呢？因为我们从线上或者从众测用户和热心用户当中获取数据非常多，如果这么大量数据给到开发，对开发来讲一是种负担，怎么可以做到我们把我们应该是哪些类的问题聚在一起就一个问题呢？避免造成开发时间的耽误，本已经解决的问题，再去查看一次。聚类解决了把同类聚合成一个问题。我们实施一些过虑策略，每个项目不一样，会采取不一样策略，假如说上一个版本提过这个问题，这个问题其实是正常问题不是问题，那这个版本有类似问题上报时就会被过虑掉。

反混淆，因为我们数据需要安全，这里我们是在后台做反混淆操作。

第三是特征分析，我们会进行问题的特征分析，比如哪些机型最出现卡顿，哪些系统容易出现卡顿，那些操作会容易导致问题，比如主线程中操作数据库，跨进程调用等等，供我们开发在未来的开发中作为借鉴，这种情况下就不要做这样的事情，避免这样的操作发生，把问题在开发的阶段就暴露出来。

结果展示的话一会儿会给大家展示。这是我们后台分析，然后我们按照场景聚类，刚才讲了我们其实有大于5000毫秒用户和很短的用户，我们可以根据这个做一个Trace的聚类和瞬时堆栈的聚类，这是我们聚类的策略。

大家看这是刚才讲的堆栈怎么聚类，我们用一个相似度来做，比如说这是两个堆栈，我们根据两个堆栈，这是A堆栈这是B堆栈，我们会用A和B交集除A和B并集。这里可能存在一个问题，就是如果不是同一个问题可能聚类到一个问题了，这个其实也问题不大，导致的结果可能是下个版本再来解决，因为问题没有修改，那么在下个版本的时候，这些问题还会继续上报回来，那么下个版本再修改就能解决掉问题，只是延迟一个版本解决了。

刚才说我们说大于5000的话，是用Trace分析的，就看这里面哪一个宽度更宽，说明这个耗时最多，逐步分析宽度宽的，会找到你所存在的问题。

这就是我们的web的展示， 这代表我们以前报过的问题继续上来了，这个代表着这次版本新增加的问题。我们问题上报的次数上报多少次影响我们多少用户，这是我们简单的分成UI和内核问题，这是我们一些类别，这是状态，就是这个问题是已经合并还是已经解决，下面你连到这个就进入到核心堆栈和我们详细堆栈，这个过程当中下面还有一个按钮是提交Bug，直接就连到Bug系统上去了。

看一下这是我们卡顿的首页，进去以后可以看到几个数据，第一个是上报率，这个是指我们上报的影响用户数，除以我们总发布的用户数，来看我们卡顿情况如何，因为我们非常严格只有100毫秒，所以看起来挺严重，但其实不会的。第二个就是我们这个版本总共上报多少次，第三个就是影响的用户数，我们知道把这个去重之后知道影响数多少，版本一共有多少问题，我们也会划分非常明显的区间。比如说100到300有多少卡顿率，300到500卡顿率多少，500到1000，1000到3000，这时候你就知道我们主要用户在什么位置卡顿，重点解决哪个区间。这是两个版本对比数据，很明显下一个版本我们往左边移的，也就是说我们卡顿情况逐步降低的。

刚才我们说特征分析时，会分析bug各种原因，比如说主线操作图片引起的，那下一期就知道主线不要操作图片了。第二个主线程访问数据库，跨线程调用等等这些东西都在这上面，也会给开发者进行参考，这是我们问题的状态。

下面是说我们上一个版本，比如说上个版本提两个问题，那么现在的版本有没有出现这样的问题，也是来自于线上，然后从线上来验证。

这是我们整个的几个版本下来之后的数据变化，一个是从用户反馈的数量，第二个是从卡顿上报率这块，效果都非常不错，这是我们做的卡顿，也彻底释放了我们的测试同学，无需再安排测试人员进行卡顿测试。再讲下我们正在做的，现在我们有用户体系，有众测，热心用户和灰度用户，之前bugly解决了稳定性，我们这套系统解决了性能，那剩下是什么？就是功能这块，我们期望通过我们用户体系，我们在功能上做到比较好的一些埋点，通过逐步放量的过程，我们知道用户用的过程当中是否功能有问题，如果有及时解决，如果这套系统一旦建立好，那么还在做传统测试的同学的未来会怎样，可以值得大家思考的。

本文来自：2018中国首届云测试峰会，举办方：Testin 云测

Testin云测，让应用更有价值：www.testin.cn