优酷客户端埋点质量保障三步曲

一、背景

优酷客户端在埋点的质量保障过程中，遇到了一些困难和挑战，我们从项目流程、测试方案、业务深入度 3 个方面进行改造，经历多个版本的迭代，形成了一套客户端埋点质量保障方案，这里和大家分享一下。

二、改造之前的我们

先来了解下优酷客户端埋点，它使用的是阿里巴巴的 UT（UserTrack）埋点，把不同的用户行为分成不同埋点事件，常见的事件有：页面事件、点击 / 曝光事件、播放事件，不同的事件又有基于位置和内容等多维度统计的埋点字段。

在实际的埋点测试工作中，不同事件和字段组合，一个版本的埋点数据需求量很大，而且需要面对枯燥的数据，辛苦测试完成，发布上线后却是“大问题偶尔有、小问题不间断”的状况，是不是很崩溃？

为什么会有这种状况？是因为整个环节存在诸多问题：比如，业务上，埋点需求延续性差，容易漏测；测试同学无法将埋点和业务的数据指标关联，排查问题无从下手；手工测试，效率稍低。流程上，常常是多个大项目项目同时进行，问题处理不及时。

三、埋点质量保障改造之路

针对上面的问题，围绕质量效率的目标，我们开启了埋点质量保障的 3 步改造之路：

1. 构建完备测试体系

1）解源头：优化埋点需求管理

如何高效的管理埋点需求，是构建完备测试体系的前提，我们开发了埋点管理平台，抛弃了原始的 Excel 埋点管理方式，统一将埋点录入平台来管理，在此基础上，还可以进行自动化等提效改造。

平台设计的初衷有 3 点：

a) 能够支持优酷内容分发、视频播放这种特有业务的数据需求；

b) 服务优酷，对于内部不同业务模块的多种需求，能够快速支持并上线；

c) 和质量部其他平台打通，能够进行质量效能统一管理。

平台覆盖 4 个维度，规则、需求、方案、报告，支持 5 类埋点事件，6 种埋点字段匹配能力：

a) 规则：埋点事件中不同字段的组合，方便埋点事件的字段录入；

b) 需求：单个埋点事件，包含不同字段；

c) 方案：多条埋点需求集合；

d) 报告：埋点测试报告；

e) 支持的埋点事件：页面、点击、曝光、播放、自定义；

f) 埋点字段匹配能力：等于、非空、包含、正则、枚举、自定义

“规则”和“需求”维度是针对埋点需求管理：我们为每条埋点需求制定了唯一 ID，

将具有不同规则的埋点需求单条或批量导入到平台，实现埋点的统一管理。

埋点管理平台设计框架

2）测试提效：自动化测试

埋点管理平台的后两个维度“方案”和“报告”，是针对埋点测试：借助埋点管理平台的日志匹配能力，我们设计了手动验证、自动验证功能，来解决测试手段单一，效率低的问题。

手动测试，是对统一录入的需求集合（即方案）实现手动测试、自动匹配。主要在需求功能测试阶段使用，只要保证设备和平台连通，业务测试的同时，平台就会进行埋点匹配验证。

自动测试，前提是要和设备实验室打通，通过 Jenkins 定时任务自动触发埋点自动化测试。主要在全量回归阶段使用，优点是可多业务大方案同时验证。

两种测试方式的结果埋点监控平台以报告形式展示，同时有钉钉和邮件通知。

自动化验证实现设计图

3）测试右移：埋点灰度 / 线上监控

埋点管理平台解决了埋点需求管理和线下埋点测试的问题，但是版本发布后的埋点质量如何跟进，漏测、多报 / 少报的场景如何能尽早发现？我们的答案是通过埋点监控平台。

埋点监控平台分为 3 层，业务层、计算层、数据层：

a) 业务层：主要是前端的业务模型。能够做到分钟级的单条埋点通过率查询，支持多版本的埋点波动对比，具备不同维度的埋点通过率概览，支持用户行为查询，方便复杂路径的埋点问题定位；

b) 计算层：是核心层，它利用 Blink 实时计算引擎对线上大数据进行规则匹配，并结合业务层的模型需求，进行多维监控和预警；

c) 数据层：主要是线上大批量用户的埋点日志和埋点平台中录入的埋点规则。

监控平台架构图

平台的业务价值主要体现为两点：

a) 能够及时发现漏测场景：线上用户复杂场景的埋点，会有测试不充分的情况，就可以在版本灰度阶段来发现，避免遗漏到线上；

b) 能够发现多报少报的问题：它是版本测试中很难发现的，通过版本间的波动对比，能够有效的覆盖这类问题。目前监控平台会在 2 个阶段使用，版本灰度阶段和线上发布阶段，灰度阶段更重要。

概览监控图

业务 / 事件监控日报图

版本趋势对比图

借助平台化的能力，从需求管理、埋点测试到埋点监控，埋点测试体系构建完成，我们走出了埋点质量保障的第 1 步。

2. 提升业务深入度

测试体系犹如测试的武器，如何使用好这些武器，对测试同学自身也是有一定的要求，这就是埋点质量保障的第 2 步，深入度提升。

首先，对于测试同学，在埋点测试过程中是否有如下疑问：

“每个版本的产品需求依据是什么？”

“产品周报里的数据指标和实际测试的埋点有什么关联？”

“版本紧急集成要提供的数据从何而来？”

有这些疑问，是因为很多同学将埋点测试和业务孤立开来，只管埋头测埋点，保证上报和产品要求的一致就行，却不关注埋点和对应产品需求的关系与影响。

埋点来源于业务，作为测试，要理解业务，理解埋点对应的业务数据指标，才能理解业务的数据价值，为此，我们进行了一系列的学习和梳理：

3. 优化流程，细化任务

完备的测试体系、深入的业务数据理解是测试内部的自我修炼，埋点需求从确定到最终发布上线，如果没有清晰的流程和明确的分工，内功再好也无用武之地。所以，埋点质量保障的第 3 步是从流程上进行优化，我们联合产品、开发、数据、项目管理团队对整个项目过程进行了细化，明确各角色职责和各阶段任务，各司其职，高效协作，版本质量更可控。

四、总结 & 规划

埋点质量保障顺利完成了 3 步改造，客户端埋点测试效率提升近 50%，连续多个版本线上无重大数据问题，在一些线上问题排查过程中测试也体现了较好的业务理解。数据质量保障任重道远，我们将不断优化，未来希望现有平台能够支持 UT 之外的埋点，并和开发侧的提效工具结合，实现测试左移，同时，监控报警和问题响应机制上继续优化。