疑难问题排查方法之“埋点法”

前言

复现问题是对一个测试人员最基本的能力要求，通过复现问题，总结一套适用的问题复现方法，有利于提高测试人员发现问题，解决问题的能力。 常用的定位问题方法：埋点法，流程图法，log日志方法，抓包法，alert弹窗法，排除法，debug包验证法，模拟法等（后续小编会分系列一一给大家介绍）。

方法介绍

埋点法。是在逻辑层面增加数据埋点，通过客户端上传服务端数据，分析服务端收集上来的数据定位问题原因，评估影响范围和修复价值的一种定位问题方法。 埋点法不是单纯的在可能有问题的逻辑点进行数据埋点，而是必须熟悉功能逻辑处理细节。若不熟悉功能逻辑细节，即逻辑流程，埋点法不适合。 埋点法适用于复现率低，不影响上线，优先级不高，影响范围大小不定的问题排查。

具体事例

实例一：锁屏通知在设备未锁屏的情况下异常弹出。 问题复现率： 偶现。且未收到线上大范围用户反馈。 排查思路： 1、锁屏通知弹出的限制条件有哪些； 2、锁屏通知从获取数据到展示通知整个逻辑流程； 3、可能出现的原因有哪些； 4、实践排查； 排查经过： 1、锁屏或者未锁屏，调用的系统API，且同样的手机并未必现，因此排除是客户端对于某些Android系统锁屏与未锁屏的状态获取有误的情况； 2、通过打log的方式，且找了线上的应用包，找了三四款机型验证，如果是客户端自身的逻辑出现问题，那么就不可能是个别机型出现这样的问题，应该所有的机型都会存在问题，因此通过log逻辑验证，发现并没有问题； 3、对于某些同类产品的排查，则是通过代码层以及对通知service服务注册细节进行梳理，经过排查也与此种场景无关； 4、最后，梳理锁屏通知的实现流程，发现在满足锁屏通知各项条件之后，客户端通过广播的方式通知客户端展现锁屏通知，那么问题来了，如果广播延迟通知，那么锁屏通知会不会就出现异常展现； 针对这个疑问，进行场景复现，果然在一定的时候会偶现，但是概率不高，为了查清这样的影响范围，我查找了线上的用户反馈，发现反馈的人很少，后经过思考，决定通过埋点的方式进行排查。 排查结果： 通过线上数据反馈，在解锁之后，此时通过广播的方式告知显示通知，但是广播受不同的设备影响存在一定的滞后性，因此导致部分用户出现了该问题。 实例二：资讯详情页概率性的不显示新闻标题。 问题复现率： 偶现。且未收到线上大范围用户反馈。 排查思路： 1、资讯详情页title的数据来源； 2、前端是如何处理传回来的数据源，处理流程是怎么样的； 3、title中是否存在对特殊字符处理不当的情况； 4、实践排查； 排查经过： 1、通过对详情页title为空的逻辑进行整理，总结出title为空的原因有两点，服务端返回的title为空，前端解析数据出现问题，导致title为空； 2、服务端返回的数据title为空，尝试手动复现，经过半个小时的努力，并未复现，且费时费力，该方案作废； 3、通过自动化的校验，编写获取资讯详情页数据的脚本，对返回的title信息做校验，查看是否存在问题，通过2个多小时的数据获取处理，并未发现异常，该方案作废； 4、怀疑是服务端返回的第三方数据源有问题，后经过对比，发现并未存在异常，且返回的数据杂乱，编码格式复杂，数据分析花费了好多时间； 5、经过以上排查，暂未发现服务端返回数据的异常，但是也不能排除服务端的问题，搁置； 6、对前端title处理逻辑进行排查，查看title为空的数据是否有共性，通过查看怀疑是前端对于特殊字符的编码格式出现问题，后经过数据排查，并未发现异常。 7、经过以上的问题跟进，一无所获，但是我们能肯定的是，要么是前端逻辑处理问题，要么就是搜索侧返回的数据问题。前端处理title为空的逻辑是直接读取搜索侧返回的title数据，然后对数据进行解析，由于读取数据是一个开源的公共方法，因此问题出现的可能性不大； 因此，在解析数据之后埋点，当解析出来的title数据为空的情况下，发送异常pingback，将前端读取和解析的结果一并发送到服务端数据组，然后对上传的数据进行分析。 排查结果： 最后通过埋点法发现是由于服务端返回的数据资源中概率性没有title字段，因此导致前端读取到的是空，进而页面不展现title信息。

总结

通过以上案例实践，在使用埋点法跟进问题时，重中之重是要了解问题所属功能的逻辑实现，埋点不意味着盲无目的，而是有理有据，所以大家在运用埋点法时，可以和流程图法并用。（关于疑难问题排查方法之“流程图法”，下次给大家介绍）