网易严选如何建设埋点质量保障体系？

随着业务的高速发展，对于精细化流量运营的需求不断提升，埋点量级也在不断提升，埋点数据的质量问题是绕不过去的一个点。

但埋点质量保障又是个老大难问题：

• 首先，由于埋点是非结构化的数据，不像数据库本身对结构化数据的结构由系统的保障；
• 其次，严选 C 端有多端 (ios、android、web、各小程序等)，多端埋点有不同开发人员开发，保障正确性、一致性又会更麻烦；
• 从埋点的需求、开发、测试、数据采集加工校验这一整条链路上，涉及业务、分析师、产品、开发（客户端、服务端、数据）、QA 多个团队的角色；
• 需求不清、客户端和服务端上报出错、数据加工不正确，这任意一个环节出错，都导致埋点数据质量问题，而且往往问题发现不及时、排查难。

针对这样的一个长链路的保障，我们主要围绕“埋点管理”（定义管理和流程控制）、“埋点线下保障”、“埋点线上保障”这三个环节展开。改造流程、优化策略，打造相应的工具平台来固化流程和辅助测试，保障埋点开发正确性的同时，也提高协作效率。在实施的过程中，我们也充分的利用了现有的各种能力，寻求各方合作（避免重复造轮子），快速的构建起一套能够跑得通的实操方案。

先来一张大图，描述一下此方案在各个环节的内容和工具平台建设（如下）。再详细地分三个小章节来描述各个点的实践细节；最后附录中会对各个平台系统的简介。

1、埋点管理

本着规范先行的思路，我们制定了一些的“流程规范”和具体的“研发规范”，比如：

• 从需求提报 & 评审、开发、测试、发布的整体流程规范，明确了各环节负责人的职责。
• 细化了在研发过程中能够指导各角色实战操作的各类规范和示范，比如“埋点开发规范”、“埋点事件定义规范”、“jira 流程规范”、“数据埋点研发规范”等等，这些规范也的确起到了基石的作用。

“流程规范都在哪里找啊？新人来了谁培训（各个角色都要培训）？埋点定义在哪找，变更的维护很不及时，同一个埋点有好几个 excel 版本中不一样啊！？” 于是我们开始“夸父 – 埋点管理平台”的建设来固化流程、提高协作正确性和效率。

• 通过平台，我们将埋点的元信息线上化，统一管理，告别口口相传，避免多个 excel、wiki 到处找埋点需求 / 定义的尴尬局面。
• 其次，将埋点研发流程固化在此平台上。从“产品经理”录入埋点详细需求 –>到“开发”根据定义开发埋点 –>提测通知“QA”介入验收 –>修改埋点状态为“发布”，整个流程都在埋点定义平台上完成。
• 充分利用和兼容了现有的开发任务管理习惯，联动 jira 来管理各项任务（需求任务、开发任务）和具体排期，尽可能地减少流程落地带来的额外理解和操作成本。

2、埋点测试

一方面，从思路上还是沿用了通用的测试思路，线下测试（新功能 & 回归）+ 线上监控。

新埋点测试

思路：手工触发、人工校验；新埋点需求可能比较碎片化，自动化的投入产出比不高

落地：依靠“夸父 – 埋点管理平台”提供的 2 个功能，“手动测试” 和 “自动测试方案”

回归测试

思路：利用 UI 自动化触发埋点 + 数据校验

落地：依靠“埋点自动化测试平台”

线上埋点监控

思路：监控线上埋点的实际上报情况

落地：依靠“夸父 – 埋点管理平台”提供的“埋点进度监控”能力

另一方面，也将埋点测试和现有研发流程进行了集成：

思路：策略制定 –> 触发测试 –> 度量结果 –> 上线门禁

落地：整体依靠“严选质量平台”控制全流程

埋点手工测试支持

为了支持埋点的手工测试，开发了 2 个能力来支持：

• 首先是“埋点数据实时展示”，可以根据用户提供的账号、期望关注的页面、行为、计划执行时间段等等信息，展示、校验、统计相关的埋点信息。避免去通过手机抓包来看数据，在通过大数据平台查询工具去数仓里查落表数据的麻烦。
• 其次，提供“执行集”的概念，来圈定本次测试需要执行的测试内容来判断执行的进度和测试覆盖情况。

埋点上报数据的实时展示

随着用户的操作，能够实时展示上报并落入数仓的埋点数据详细信息。端到端的测试（不仅仅只测客户端是否正确）。

埋点执行集

有的放矢，统计测试覆盖。筛选需要测试的埋点列表 -> 测试执行（手工或自动化）-> 覆盖情况统计

• 如何筛选所需要测试的埋点列表？
• 提供多个筛选维度（页面、行为、版本、端、状态、名字）
• 提供核心埋点列表：
  • 固定设置的筛选维度：核心的页面、行为所对应的埋点，比如“首页的点击 xxx”埋点
  • 人工设置的黑 / 白名单：某个非核心页面的重要埋点
  • 线上实际的埋点流量：最近 XX 日流量占页面流量的比重大于 x%

埋点数据自动化校验

随着埋点数量的不断增加，QA 和开发同学在校验埋点数据的工作量越来越大。也常常因为回归不充分，出现一些比较“低级”的错误，比如必填字段为空、字段缺失或者 Key 不对等等。

为了避免这些问题出现且又能降低人工测试的成本，我们抽取了一些通用的校验规则来对收到的埋点数据进行自动稽核。比如：

• 格式校验：上报埋点的格式和埋点定义是否一致，是否存在缺失的字段
• 非空校验：from_seq、seq_list、app_v 等数据是否为空
• 自定义规则校验：不符合枚举值、数值的阈值校验、连续性校验（同上一个埋点的递增组成部分校验）等等

这个数据自动化校验能力，在下面提到的手工测试、自动化回归、线上监控都会被应用到。

客户端埋点回归的自动化

埋点回归和普通的功能回归相同，它主要的痛点是耗时耗力。

• 埋点多（核心埋点 300+），一次回归需要耗时不短，且一旦碰到 hotfix 的时候更是要命。
• 埋点散落在各个页面，涉及到多个业务，需要分派给多位同学来测试，这里的协作问题可想而知。
• 测试沉淀，人员流动、功能变更等等。

因此实际情况下，草草的部分回归是家常便饭，全回归的成本实在太高（哪怕是核心埋点的全回归）。为了解决这个问题，2019 年下半年，开始共建埋点自动化测试平台，利用 SmartAuto 的 UI 自动化能力和夸父平台原有的埋点校验能力，解决客户端核心埋点的回归问题。

首先，大致介绍一下严选埋点上报的流程：

其次，看一下埋点自动化测试的流程，以及它和其他现有平台的交互

最后，我们来介绍一下严选和杭研 QA 部一起合作开发的埋点自动化测试平台的使用姿势。把大（埋）象（点）装进冰箱（自动化回归）一共需要 3 步：

第一步：建立自动化测试“用例”：

1. 配置需要执行的 UI 自动化用例
2. 配置每一步所需要校验的哪些埋点（这里第三步也可以先不操作，系统会提供 2 种类型的规则一些自动匹配的可能需要验证的埋点）

• 匹配规则 1 –> 根据 ui 自动化执行记录 vs 上报的埋点数据，时间戳、页面 / 行为来粗略匹配
• 匹配规则 2–> 其他历史用例（其他的用例中也存在同样的操作，且已经配置过该步骤需要验证什么埋点，则系统会自动化获取）

第二步：执行验证（平台自动执行，不需要人工干预）

调用夸父平台接口，开启埋点上报的监控（因为目前严选埋点自动化校验，大部分依靠夸父平台对埋点正确性的校验能力）

触发 smartAuto 平台上的 UI 自动化用例执行

根据“验证模型”来确定 app 上的操作和期望的埋点是否“出现”&“正确”

第三步：结果分析 & 统计

验证概述：验证的埋点数量、埋点验证成功 / 失败的情况

验证详情：

• 执行明细：执行人、关联账号、app 版本、执行时间（开始 & 总共耗时）
• 步骤详情：自动化操作步骤 vs 期望校验的埋点明细（包含 ui 自动化操作的截图）

3、埋点线上监控

说完线下，再说说线上。客户端兼容性问题、线下无法完整覆盖所有的场景。作为对线下测试的补充，线上的埋点监控也是不可或缺。

因此我们也在夸父平台上提供针对每一个埋点的线上数据统计能力，当新增的 / 变更的埋点发布以后，QA、开发、产品同学可检查这些埋点线上的实际数据。

• 埋点“进度”监控：统计的是最近此埋点在各端的上报数量、成功、失败数量；一般当新埋点或变更埋点发布后，我们会关注这个信息（上报数量是否有明显异常？是否线上存在明显的数据异常、比如格式错误、字段缺失等等）
• 埋点“分析”：和用户行为分析平台联通，提供更多维度的数据统计信息；比如，观察埋点的数量趋势、和其他埋点向结合来分析它的正确性等等

最后，针对缺失埋点可以利用热修复来保障及时修复，形成整个线上埋点保障的闭环。

4、在路上

优化埋点回归的测试

• 埋点用例维护。让用例结构更加优化，降低维护成本
• 提高 UI 行为和期望埋点关联关系自动化匹配的精准度

埋点数据自动化校验

• 针对埋点具体参数的数值的校验，如何更自动化
• 针对场景化的埋点校验，比如埋点中有些数据是从其他埋点里透传的

埋点线上问题处理闭环加强

• 线上问题采集能力加强（现有埋点监控 + 人工上报问题）

公众号：架构头条，InfoQ旗下，专注于软件开发基础技术的专业公众号。 在这里，你可以看到涵盖架构、云计算、运维、数据库、安全、编程语言、程序员周边等全领域的干货内容。

文章来源：https://mp.weixin.qq.com/s/uJd9wo9Ftsv_qXW64_yvzg