用户行为数据采集──埋点，是用户行为分析中非常重要的环节，直接决定数据广度、深度、质量，影响后续所有的环节。就埋点本身来说，技术实现的难度并不高，但是整个埋点的过程可以说十分的复杂繁琐，有非常多细节和流程需要考虑，不同类型客户端如何采集，数据如何统一，哪些信息需要在客户端采集，哪些信息需要在后端采集，如何减少数据上报的延时和漏报，如何对成千上万个埋点进行统一的管理？这一系列文章基于用户行为分析数据平台一年的工作经验，会对埋点的全过程进行思考和讨论，涉及对埋点基础知识的介绍，讨论如何从 0 到 1 开始用户行为数据采集工作，分享负责项目的埋点方案，介绍埋点管理系统，梳理整个埋点协作流程等方面。
上篇文章讨论了将采集规范线上化的埋点管理系统，点击查看。本文是系列文章的第四篇，关注埋点测试环节，思考如何通过高效的小工具帮助研发测试同学开发埋点，提升工作效率。
如何让研发同学愉快地埋点
参与过埋点开发上线的同学应该都知道，一般来说开发测试人员都不喜欢做埋点需求。因为埋点就是一个体力活，非常繁琐，随着产品的迭代，越到后期埋的点越来越多，维护起来十分麻烦。为了改善生产关系，需要想办法让研发愿意去埋点。如何让研发测试同学愉快地埋点呢？基本的思路还是要简化埋点的工作流，提升开发测试的效率，降低沟通的成本。根据实践的经验，有两个事情可以做。一方面，要建立统一规范的埋点流程，并尽量让流程线上化，这部分的内容已经在《【用户行为采集】（二）建立埋点采集规范》、《【用户行为采集】（三）埋点管理系统》中详细讨论过；另一方面，需要提供一些高效的小工具，帮助开发同学进行埋点测试、校验，让研发测试同学能够用更少的时间，完成高质量的埋点。
原始的测试方法
在我负责的项目中，和埋点管理功能一样的情况，埋点测试功能也是在后期迭代中添加的功能。就开始的时候，我们提供了一种相当原始的测试埋点的方法。大致是这样的：
- 研发测试人员触发待验证的埋点，数据上报到大数据测试环境
- 研发测试人员用抓包工具记录下刚才上报的埋点的日志 ID
- 数据团队将收到的测试埋点数据切片，按时间倒序排列，将切片放到一个 FTP 服务上
- 研发测试人员访问 FTP 服务，在最新的切片，通过日志 ID 找到要验证的数据，按照埋点需求进行验证。
感受下这样的测试方法，对研发测试同学是非常不友好的。比如，为了定位要测试的数据，需要使用抓包工具，比较繁琐；需要登录另外的系统访问上报的测试数据；如果同时有大量的测试数据上报，要定位的数据可能不在最新的切片中，查找困难；另外，一个埋点的字段可能多达几十个，如果不做格式化处理，阅读起来很反人类。总之没有人愿意用这样的方式验证埋点，研发测试同学也多次提出需求，希望提供一些功能帮助他们校验埋点。
改进后的测试功能
针对原始测试方法中存在的痛点，我们设计了相应的解决方案。改进后的测试流程如下:
- QA登录系统，进入埋点测试模块，扫描二维码获取设备ID
- 输入设备ID，开始监听后，在测试客户端操作触发埋点上报
- 系统按时间顺序展示收到的埋点数据，QA查看上报埋点以及埋点属性字段是否符合预期
查询测试设备二维码
系统按时间顺序展示收到的埋点数据
通过这样的埋点测试功能，基本解决了测试研发同学验证埋点的需求。不再需要使用抓包工具，获取日志ID定位待测试的埋点，只需要登录系统输入测试设备ID，就可以开始收取上报的测试埋点数据，并且系统做了格式化的数据呈现，校对起来也比以前方便了许多。
