对于该论述，欢迎读者查阅之前发过的文章
方法汇总
客户端埋点验证
- 很多的数据问题都是因为客户端埋点不正确导致，所以在集成SDK时一定要检查以下项：
- 是否使用了最新版本的 SDK（有些功能所需数据只有新版本SDK才会上报）
- AppKey是否填写正确
- 上报地址是否配置正确，尤其是小程序数据的上报
- 数据是否能正常发送
- 是否选择了合适的SDK，比如有些事件更适合在服务端上报
- 更多检查项：
- 是否覆盖了所有涉及到的页面
- 是否覆盖了位于不同页面的相同事件
- 是否因为页面跳转导致有些事件不能完全上报
数据入库验证
- 通过埋点方案的回数状态验证完整性和正确性
- 上报埋点方案后，系统会根据入库的数据与埋点方案做自动化校验，在列表中可以根据颜色标识直观判断当前埋点的状态
- 埋点状态 = （事件状态 + 事件属性状态） 平台
- 通过错误数据日志查看入库失败数据
- 在错误数据日志中，展示关闭调试模式下（Debug=0）和调试模式下（Debug=2）入库失败的数据。通常这也是部分指标在查询时偏差的原因，所以发现错误时，请及时纠正，避免更大的影响。
- 同 Debug数据验证 的功能相似，同样
- 支持按照事件ID、用户ID、时间来搜索
- 支持筛选可展示的列
- 支持数据的实时更新
- 除此之外，可以筛选某些特定错误类型下的数据；点击行时，可以展示错误的原因
埋点自动化测试
在前几篇文中说明了，埋点测试选择在 埋点入库做卡点校验是最合理的。如果在上报时校验，校验的卡点是在上游，还是可能会出现问题。在入库这个节点校验，会绝对保证数据的一致性、完整性和准确性。
测试方法：
测试埋点时，应该重点关注的是什么：
用户标识是否正确上报，登录用户的行为看 登录用户标识（通常是公司的用户账号）是否正确上报，访问用户的行为 看访问用户标识 （可以按一定规则生成访问用户id，比单一看设备id或者cookie生成的id要更合适）是否正确上报 每次触发是否都入库，重点看上报事件与自己的触发时间是否一致，以及上报的事件名称与自己触发的是否一致；上报的数据中 事件变量，与埋点文档变量是否一致，变量值数据类型是否一致；
测试线上埋点时，应设立测试用户的白名单，方便数据处理时清除测试数据。测试完成测试平台应该生成一个测试报告，描述清楚本次测试结果，并可以方便的关联到开发项目管理中，例如JIRA。
埋点监控
为什么埋点测试通过了，上线了还需要监控？
- 上线前的测试，只测试了有限的设备和有限的用户行为，属于抽样测试。实际业务中，海量用户拥有各种各样的设备类型，网络类型，奇怪用户行为也比比皆是，上线前的测试是不可能覆盖那么全的。因此只能通过线上监控统计数据，通过统计方法与关联数据做分析，才能发现抽样测试不能发现的问题；
- 业务发展迅速，功能迭代速度快，例如页面改版了，交互逻辑变化了等等，埋点的元数据和埋点事件都需要跟着功能更新，负责接收到的就是错误的数据；
可以在埋点元数据管理的基础上，增加订阅预警的能力，埋点负责人和相关关联人员，自行设置监控规则，规则阈值被触发后，通过发邮件或者钉钉机器人提醒等方式做提醒。
保障体系形成
我们形成了一套埋点保障体系框架，如下图，在以后的埋点测试中我们会更加得心应手！
