深入探讨数据测试

|0x00 数据测试模型

通过之前的两篇文章，我们已经对数据测试有了一个初步的刻画，本文讲述一些更进阶的内容。因为测试通常要对研发环节有一定的入侵，如果测试的内容越多，势必影响到研发效率的提升，很容易造成测试与研发之间的对立，但如果不去做测试，那么数据的质量就会失去最后一道保护的屏障，同样不可取。

数据质量是数据研发的生命红线，研发效率是数据研发的价值增量，都是需要兼顾的部分。

因此，我们需要把数据测试进行切分，识别其中必要与非必要环节，通过保障必要的研发过程来实现落地，搞清楚谁、在什么时间、做了怎样的研发动作，然后将质量的监控，平铺到核心的研发阶段中去。下一步，我们需要考虑的内容，就是数据测试的“抓手”在哪里，也就是我们通过怎样的措施，能够保障数据的质量，为数据做“兜底”。回看质量体系的6个一级特性，会发现，几乎所有的问题，都会归因到“功能性”测试上，并通过“功能”对数据问题做最后的“兜底”。因此，我们可以任务，数据测试，重心就是做好功能性测试，同时选择性的评估其他几个方面。

那么，我们便可以通过如下的模型，来初步刻画数据测试模型：

数据测试 = 必要测试（功能性） + 选择测试（可靠性、易用性、维护性）。

必要测试指一定要做的测试，无论项目大小，而选择测试则可以根据工作量饱和程度、产品重要性等进行自由选择。效率与可移植性，可以不在数据测试中体现，但可以作为辅助参考，看是否需要进行选择测试。

|0x01 功能性测试

接下来，我们讲一讲必要的功能性测试问题，主要谈自动化测试的问题。

对于软件工程领域的测试，主要方法在于通过配置化的接口，构造输入数据，检查输出结果是否正确，这个过程对于数据测试同样适用。一旦有了标准化的检测方法，“自动化”就可以提上日程了。

我们先谈输入数据构造。并不是所有的数据都需要构造输入数据，如果是一些比较成熟的业务，我们只需要测试输出数据就好了。但如果是数据安全要求比较高，或者是新业务数据量不足的情况下，就需要测试同学去构造一些符合客观事实的数据，输入到业务过程里，再测试数据结果。

再谈测试输出数据，这个是重头戏。我们看一下功能性的几个二级特性：适合、准确、互操作和保密安全，其中准确就是对输出数据的要求。那么什么是准确呢？通常而言，就是不多、不少、范围、分布、可叠加、多表对比、上下游对比、badcase等特性。

• 不多：统计链路上相关的数据表，是否都遵循了主键唯一，枚举值是否有空值等多余情况。
• 不少：对重要字段进行检查，比如品牌、类目、行业等是否都涵盖了，通过对比历史波动查看是否正常。
• 范围：检查数值是否在正常范围内，例如比例/比率这一类的指标，结果应该在0-1之间；例如某个产品的用户量不应该超过全局用户量，等等。
• 分布：检测数值的分布特性，例如某个阶段的转化率通常在5%左右，那么统计结果在1%-10%之间都是符合认知的；或者查看统计数据的正态分布，对于极端的case进行特定的分析。
• 可叠加：子维度的统计结果相加应该等于父维度，例如子订单的金额总和应该等于父订单。
• 多表对比：如果统计指标在多个表出现，它们的结果理论上是应该一致的。
• 上下游对比：公共层的统计结果，理论上应该与应用层相等，当然特殊业务场景除外。
• badcase：挑选具体的case查看结果。

其他的验证方法，需要自己在实践中总结了。数据开发通常先进行数据的自测，保证没有基础问题之后，再提交给数据测试进行提测。

|0x02 CodeReview

虽然自动化的测试能够发现很多问题，但静态代码的CodeReview仍然是必不可少的，因为CR是最能解决根本问题的检查手段。

举个例子，测试用例有两种时间属性，一种是创建测试用例时间，一种是修改测试用例时间，我们想统计单位周期内测试用例的数量，来衡量测试同学的工作量。如果需求没有特别的要求，很多同学就会用创建测试用例时间来做统计，但实际上应该用修改测试用例时间，因为修改情况能够比创建情况，更准确的反应测试同学的工作量。但这种情况在测试的时候很难发现，因为不论从哪个角度来测试，结果都是OK的，只有在理解业务逻辑的情况下，通过CodeReview，才能发现这个问题，而一旦发现，过去所有的统计结果都会发生变化，如果数据已经透出，会造成大范围的影响，直接导致别人对数据质量的质疑。

尽管只是口径不同，但在具体的业务处场景下，是没有标准可以遵循，但又需要选择最合理的口径，这些都是自动化测试无法发现的。

CodeReview的测试，能够与数据模型的质量规范挂钩起来，如果建模的时候没有遵循规范，例如主键没有唯一，没有配置检查任务，导致下游数据出错，这时候测试出了问题，开发同学的责任就跑不了了。

关于CodeReview关注的重点，大致可以分成如下几个：

• 字段顺序；
• join条件；
• 空值情况；
• 结果精度；
• where过滤条件；
• 分区；
• 去重。

更多的经验，可以自己摸索。

|0xFF 经验的累积复用

数据测试要沉淀什么，大概可以分成如下几种：

• 与团队的协作：对开发同学晓之以理，划清各自的责任边界，即减少对业务开发的侵入，就可以最大程度上保障数据质量；
• 测试Case的编写与复用：每一次测试，都可以把经验总结出来，沉淀到Case的复用中；
• 反映经验的积累情况：绝大多数的测试场景，都是经验的积累复用，很难有标准化的体系思路，因此测试的越多，我们积累的经验就要越丰富；
• 底层表摸底：在正式测试前，把底层的数据表摸底一遍，一方面了解业务的复杂程度，另一方面避免走一些弯路；
• 让开发更好的了解业务诉求：并不是说数据测试就可以不关心业务了，因为结果的准确与否，有很多因素是直接跟业务挂钩的，测试结果能够提升开发对于业务的重视，帮助也很大。

经验的积累，拼的就是一个“熟能生巧”，拼的就是一个“无规矩不成方圆”，从量变积累到质变，最终从作坊式的开发，进化到工厂式的开发，最后到智能化的开发。没有什么能够一蹴而就，只有默默的锻炼内功。