数据指标的意义

所谓的“数据指标”，简单来说就是可将某个事件量化，且可形成数字，来衡量目标，在日常工作中大家都会应用的到。在一定程度上，“数据指标”能揭示出产品用户的行为和业务水平状况。

大数据与业务数据交互图

image.png

指标测试

初识指标测试

在初次接触指标测试时，测试的指标内容是由开发敲定的，测试只是一个无情的执行工具。
没有进行任何的思考，表与字段的取值，数据的实效，均没有顾及，导致指标准确性不高，甚至出现数据丢失的情况。同时在数据测试过程中，采取逐步准备数据，准备一波同步一波数据的方式，导致时间线拉的很长，版本质量也不佳

测试分层

由于指标类项目，并不只是单一的数据指标，同时还会有相应的前端页面，对数据进行展示。
因此为了降低数据的复杂程度，采取指标开发类似的测试思路，即测试分层。
将原本冗余在一起的指标与页面功能剥离开，分为数据验证测试与功能验证测试。并分配给不同的人执行，提升测试效率，减少测试之间的耦合：

  • 指标验证测试：负责从业务数据到ADS层的指标准确性
  • 功能验证测试：负责ADS数据至前端页面的展示

指标验证测试

指标验证测试共涉及4个环节，即明确指标口径，验证脚本准备，数据构造脚本准备和数据验证

  1. 明确指标口径
    1. 指标的口径一定要定义清晰，无歧义。避免个人认知差造成的误解
    2. 在指标开发前，产品/开发/测试需要对指标涉及的表、字段取值达成一致。从源头上减少bug的产生。
  2. 验证脚本准备
    1. 在指标口径定义与表、字段确认以后，就到了测试准备环节。首先指标测试不可能想功能测试一样，根据指标的不同情况，逐个查看数据的正确性。因此，我们需要准备测试脚本，一般使用SQL对数据进行验证
    2. 测试需要根据指标定义，按照自己的理解，将该指标查询SQL准备出来，并在业务库验证SQL正确无误
    3. 由于大数据会将计算结果放在ADS层的表中。因此，我们还需要准备ADS表的验证SQL
  3. 数据构造脚本准备
    1. 在数据验证SQL准备完成后，我们就需要针对指标数据进行准备了
    2. 数据构造
      1. 如果对指标的业务表极为熟悉，甚至对业务上下游的影响范围都牢记在心。那么我们可以采取直接插入SQL的方式，进行数据准备，保留SQL脚本
      2. 如果对指标的库表不熟悉，那么我们就只能通过接口的方式进行构造数据，在数据创建后针对时间进行修改，确保数据在统计时效内
    3. 由于数据具有实效性，我们需要将自己准备数据的脚本保留下来。便于快速准备数据
  4. 数据验证
    1. 当验证脚本与构造脚本均已经完成时，此时验证工作就极为简单了，我们只需要将脚本执行一下，统计是否数据一致即可
    2. 当数据验证完成后，在回过头来看看自己是否有数据遗漏的情况，再次检查一下就好

功能验证测试

与指标的测试不同，功能验证的测试，只需要关注从ADS层到页面前端的展示，即数据准备、数据展示验证和功能验证。

  1. 数据准备
    1. 直接对ADS层的库表进行插入数据操作，确保数据覆盖了业务统计范围
  2. 数据展示验证
    1. 在ADS插入数据以后，直接在前端或接口查看相应的数据是否展示，是否一致
  3. 功能验证
    1. 指标类项目虽然交互单一，但由于涉及数据的统计，功能也不能忽视，常见的异常为：组织架构统计错误，人员信息变更统计出错。

指标测试困境

缘由

数据指标是高度依赖于业务数据，当业务方进行改造时，难免会影响历史指标。体现在如下方面

  • 业务指标口径变更
  • 业务数据表结构变更
  • 基础业务数据变更(刷数据)

从现阶段来看，当业务指标口径变更与表结构变更时，对于测试人员来讲，基本等同于历史指标重测，会造成较大的人力成本。而基础业务数据变更，则会直接影响线上数据的准确性，导致用户对数据不信任。

解决思路

  1. 保留历史数据构造脚本与验证脚本
    1. 该方式可以从解决一部分重测问题。但是又会引入新的问题，数据脚本都是分散的由个人维护，无版本控制，很容易导致缺失，最后不得不重新准备
  2. 提高线上数据的日常检查
    1. 线上数据并不能随意访问，因此基础业务数据变更的问题，只能通过管理流程来规范，无法通过技术手段来解决
  3. 搭建相应的自动化框架
    1. 可通过Git来管理历史脚本数据信息，并将构建验证脚本统一管理，理想情况下可以迅速完成测试
    2. 需要投入一定的成本，当使用次数较少时，投入成本难以回收。