严选数据质量保障建设（二）：数据指标产品的自动化测试提效

业务决策型数据产品通过数据可视化，为各层级管理者和业务同学提供数据洞察和分析工具，因此指标的质量是数据产品赖以生存的基石。通过严选指标测试平台，可以沉淀出指标测试及回归视角的核心指标集合，解决数据测试中，数据指标数量多、口径多，核对困难的痛点，为数据指标提供自动化测试和回归能力；同时提供数据监控报警的能力提高了线上问题的主动发现率。

1 前言

说起数据质量，业界有一条老生常谈的准则：及时性、完整性、准确性、一致性。

如果一句话概括就是，首先数据要有，其次数据要全，数据要准，最后数据一样。

• 数据要有 -> 数据及时性：数据要按约定时间产出。
• 数据要全 -> 数据完整性：数据不能少、不能缺，当然也不能多。
• 数据要准 -> 数据准确性：数值要准确。
• 数据一样 -> 数据一致性：同一个数据，从不同模型查询出来，数据要是一样的。

严选数据加工的粗粒度层级划分如下图，数据从业务系统中产生，经过同步工具进入数据仓库系统中，在数据仓库中进行一般意义上的清洗、加工、整合、算法、模型等一系列运算输出到数据产品中进行展示。输出的数据需要在整体数据产品迭代周期中，可测试，可回归。

2 数据指标质量保障之指标测试

在上篇《严选数据质量保障建设（一）：测试分层和数仓造数》一文中详细描述过数据产品测试的现状及痛点。脱敏服务建设解决了测试能力分层的问题，数仓造数服务为各个业务线数据相关场景提供了更丰富和贴近线上的造数能力，接下来我们更关注数据指标质量保障本身。

2.1 什么是指标测试？

指标测试是业务决策型数据产品中数据质量保障测试的一大难点和重点。业务决策型数据产品通过数据可视化，为各层级管理者和业务同学提供数据洞察和分析工具，往往需要展示众多的指标作为决策辅助。错误的数据指标不仅不能提供决策辅助，还有可能导致决策错误，因此，指标的质量是数据产品赖以生存的基石。

2.2 数据指标的特点及测试的痛点

• 数据指标多
  从图中可以看到，数据指标数量多（指标+查询维度的组合结果很多）、出口多（相似指标，在不同系统或页面，可能来自不同的数据表和计算口径），目前全域数据产品的指标一共涵盖11个域（用户域、流量域、交易域等），原子指标个数有1307个。在实际的项目中，提测版本的测试周期几乎至少50%以上的时间都被用于指标的人工核对。

• 测试手段和效率，测试手段偏人工，指标的回归测试目前几乎没有开展
• 数据计算分多层，需要在多层均进行测试，测试工作量大

2.3 测试策略

目前数据质量保障的分工和测试策略如下图所示，从数仓层-->数据中台-->数据产品，数仓主要由数开保证质量，依靠code review、配置表的稽核规则、以及一些数据比对工具；数据中台主要依赖于统一查询服务进行接口测试保障；数据产品层，依赖QA的应用功能测试及人工核对指标。

指标的测试可以在模型、表、接口等维度进行测试，由于考虑到接口还涵盖了后端的处理逻辑，是与页面展示的指标完全能一一对应的，因此，指标的测试依赖于接口。我们希望有个系统能提供指标接口层的自动化测试能力，方便地进行指标测试，且可以自动化回归以前的用例。

2.4 指标测试平台

我们希望指标测试平台能为数据产品指标测试提供什么样的能力：

• 提供指标的对比测试以及指标运算测试，支持在模型层和服务层对指标提供测试能力；
• 提供版本迭代周期内数据指标的一键回归能力，具备上线前质量卡点的能力；
• 提供线上巡检能力（用例维度、指标维度）；
• 将指标测试提前至接口和指标刚定义好的阶段与开发工作并行，测试可提前至接口和指标已定义好后，与开发工作并行，缩短测试周期及整个项目周期（TDD数据试点）。

2.4.1 平台架构图

平台录入（手工新建或者同步）数据源，接口和定义指标；应用接入SDK，平台请求鉴权通过，获取接口返回。编排指标至对应场景用例，用例支持公共参数传参，执行校验。通过用例执行集，创建定时执行计划，调用消息推送服务，进行线上巡检报警。离线数据产出通过mdss拿到消息通知，离线数据产出后触发一次执行计划，及时发现离线数据产出是否异常。

2.4.2 系统层级图

整体的思路：定义接口/指标-->写用例(选接口/模型+填参数)-->配置校验规则-->执行-->结果查看-->线上巡检-->监控报警。

• Step 1.  “定义”：
  指标（包括用例、执行集），形成指标测试及回归视角的接口定义集合和指标定义集合。
• Step 2. “编写用例”：
  从全域数据产品为出发点，不区分应用，梳理不同应用中同个指标（同模型查询/不同模型查询）的对应关系，进行用例编写。
• Step 3. “执行”：
  通过指标测试平台获取各数据源（统一查询、数据产品的接口）获取指标数据，运行用例。
• Step 4. “校验”：
  用预制的规则对指标数据校验，包含固定阀值校验、历史波动校验、指标关系校验（A指标 = B指标/C指标）等。不同接口/模型间对比：用于测试相同指标在不同（接口或模型），是否存在数据不一致的问题。不同环境对比（线上和线下）：用于底层重构、变更后的回归测试，来发现测试版本和线上稳定版本的数据不一致的问题。

2.4.3 平台具备的能力

• 可以检查不同应用间，相同口径指标的数据一致性，秒级响应，核对出指标之间的相对误差率，跟自定义的误差做校验，反馈出误差在不在可容忍范围内。
• 可以在不同终端、不同用户类型的组合下，对数据指标做运算，并帮你校验运算后的结果。
• 可以自定义测试角度的核心回归集合，一条执行集合，可包含若干条用例，一键执行，返回结果。
• 可以对执行集设置执行计划，定时执行，线上巡检。
• 可以在多环境下（test/online/regression）支持指标的重构场景测试。

2.4.4 平台适用的测试场景

• 数据指标比对   
  某天截了一张流水指标的对比图给数开，数据开发同学反馈说这个流水数据有问题，就算是不同模型的流水，数值差异也不会有0.1（其实我发的是实时的数据，浏览器切换tab的时间+刷新页面也超过两秒了，同一时刻的数据就没那么精准了）。通过指标测试平台，可以以极小的时间误差，去请求不同应用的接口，拿到指标数据，返回比对结果。
• 数据指标运算
  在平台初期调研需求的阶段，V产品说，我每次核对指标，有一项是各BU财务毛利额之和要等于总的财务毛利额的数值。将近二十个BU数据，只能求助计算器，一不小心还容易看错行，将近二十个BU的数据，每次回归需要加和做运算比对的手工工作量很大。
  再来看下，指标平台的一键执行回归后的结果图（11月25号财务毛利额离线数据）：
• 线上环境和测试环境数据对比，应对模型重构的场景（online<---->test）
  因为严选数仓这边没有测试环境，数据产品版本中经常有模型重构的场景，需要比对版本模型跟线上模型数据的一致性。用例可以区分online环境和test环境，进行重构场景的数据比对。
• 创建执行集，执行线上巡检
  目前有两种巡检方式，一般离线数据很稳定，执行巡检的频率不用很高。只有单指标用例（指标监控）需要较高的频率去跑，以便发现500的接口，以及卡住不能及时产出的指标（一般展示为0或者null）。
  指标执行集除了日常巡检外，经由严选质量平台编排和调度，用作日常版本迭代上线前的质量卡点。

2.4.5 落地效果和收益

以目前平台已录入的指标用例的执行速度（当前伏羲核心指标执行集一共涵盖了90个指标，108条用例，执行时间约为30秒），按照人工每天能回归的指标数据上限（每天30个）来算，估算下以下三个重点关注域的人工回归时间和平台执行时间：

接口层返回的指标名，一般不会有变更，除非接口更新，需要在统一的接口列表中相应做更改。整体看工作量对比，指标测试平台效能提升很明显。

2.4.6 线上问题捕捉

平台上线后，每天定时执行用例集巡检。在严选主站省钱卡需求上线后，平台用例巡检发现，主站财务毛利额及财务毛利率数据开始出现偏差。两个指标的实时和离线模型均未计算省钱卡的业务场景。如下图：

从以上数据，可以看出财务毛利额，在多次巡检中误差率越来越大(7%-->8.3%-->13.6%-->14.6%)，经确认，该指标的实时模型和离线模型都有问题，针对主站新增需求省钱卡的数据未增加计算。

引发的思考：严选数据产品的数据来源于严选平台，数据开发流程要怎样跟严选业务链路的新增需求产生更及时的联动关系。

3 总结

大数据测试一直在探索自己的测试方式，数据测试并非完全不能借鉴传统业务测试的思路，指标测试平台的落地就是一个很好的例子，将传统业务测试的思路用于相对较新的数据测试领域，接口自动化的思路也可以借鉴用来做数据指标自动化，两者本质上是相通的。

本文由作者授权严选技术团队发布