关于数据测试，已有不少同学写过这方面的文章或者开发过工具。为了系统化，我的想法是从数据质量模型入手，分析数据测试的抓手，然后找出数据测试中需要什么样的工具来支撑。这里我也不会过于强调我们做的平台，或与其他平台作比较，而是想把平台或者工具背后的思考过程总结和分享下。
一、数据质量模型的探寻
1.1. ISO 9126在数据质量上的移植
在讲到数据测试前，需要先想一个问题，怎么样系统化地阐述数据质量？
我觉得系统化阐述的一个思路就是寻找当下有没有适合数据质量的质量模型。以传统的质量模型为例，ISO 9126是一种典型的软件质量模型，无论是开发还是测试，无论是各端质量还是服务质量，质量上的大方向不会跳出9126的模型。作为互联网行业，虽然现阶段9126中的二级特性不可能完全落地，但作为一个指导性的质量模型，它会确保质量不会有方向性的大纰漏。那数据质量有没有类似9126的模型可以参考呢？
从国外看，已知的 ISO 8000是现在数据质量方面的新兴标准，但该标准一是太重，二是不免费提供，三是国内对该标准的综述也少的可怜，因此并没有太多细节可供参考。从国内来看，大家都会做到一些总结和落地，包括集团内部的ATA文章也不少，有共性也有不同，但系统性的阐述相对少一些。我的一个想法是，既然没有现成的，那是否可以尝试将9126移植到数据质量？
9126的一级特性可以分为以下几个：功能性、易用性、可靠性、效率、维护性、可移植性。那这几个大项对应到数据质量里，会是什么样的呢？
1）功能性：软件提供了用户所需要的功能。二级特性包括：适合性、准确性、互用性、安全性。对数据而言，个人觉得最重要的应该属于准确性和安全性。
a.对于准确率，如果一句话概括就是，首先数据要有，其次数据要全，最后数据要准。对应的，就可以看到该大项下对应的小项：
数据要有 -> 数据及时性：数据要按约定时间产出。
数据要全 -> 数据完整性：数据不能少、不能缺。当然，也不能多。
数据要准 -> 数据准确性：数值要准确。
这几个二级特性，可能很多同学的文章中都写过，也讨论过。这里只是从数据质量整体系统性上再将其阐述一遍。需要说明的一点是，很多文章中也写到了数据一致性这个特性。数据一致性这个概念很广，比如关系数据库中的外键一致性、CAP 理论中的强弱一致性。个人认为，数据不一致最终影响的还是数据的完整或者准确。如果业务上认为不一致性可以接受，那也不是问题。所以我更倾向于将数据一致性作为一种根因，而并不是质量模型的一个子项。
b.对于安全性，尤其是数据安全，命题也很大，这里不再赘述。但需要提的一点是，数据安全涉及到隐私或者差分攻击的预防，也可能是由业务同学考虑的范畴，所以在数据质量模型中不能忽视。
2）易用性：是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。对于数据来说，我认为数据的易用可以分为两方面：是否被理解，是否被需要。它更多的是和日常沟通、产品需求及规划相关。
是否被理解，意思是当前我们对数据的定义是否是行业认可的，是否存在团队与团队之间、用户与开发者之间理解的不一致。
是否被需要，意思是当前我们提供的数据，是否真的能够满足用户需要，数据的真正效果有没有达到。比如，我们给用户提供的是它自己品牌的数据，但用户可能更需要的是行业下的数据来做进一步的市场规划。
3）可靠性：在指定条件下使用时，软件产品维持规定的性能水平的能力。比如上游数据无法定时给出，依赖关系的强弱配置不正确，可能影响的就是数据无法定时产出。可靠性是一种根因，最终影响的还是功能性。
4）效率：是指在规定条件下，相对于所用资源的数量，软件产品是否在规定时间内可提供适当的性能的能力。比如计算倾斜或者计算资源不足导致数据产不出来。效率也是一种根因，最终影响的还是功能性。
5）可维护性：是指是在修改或者新增需求时，当前的开发架构是否足够灵活的支持，是开发阶段主要考虑的。比如在数仓开发中，当新上游到来时，如果从下到上全部采用烟囱式开发，那对新增的需求必定是不友好的。如果改为 Hub 或者集市模式，可能只需要开发接入数据的 ETL 代码，剩下的完全可以复用，就是提升可维护性的一种手段。
6）可移植性：是指软件产品从一种环境迁移到另一种环境的能力，也是开发阶段主要考虑的。服务或者网站的可移植性大家了解比较多，数据的可移植性是指什么？我个人认为可移植性强调的更多是跨技术平台的移植，而不是模块间的数据复用。在数据上可能就是数据直接从一个计算平台迁移到另一个计算平台，或者 SQL 代码从一个计算平台迁移到另一个计算平台。在可移植性方面，我还没有遇到导致质量问题的有说服力的案例，如果大家有相关的例子可以沟通。
综上，如果采用9126的思路，得到的数据质量模型的脑图如下。
1.2. 对移植模型的优化
但是移植过来之后就完事儿了吗？其实细想一下，里面还是有很多的问题，让它不是那么好用。比较典型的问题就是：模型不正交。通俗来讲就是感觉几个特性之间有不同，但也有关系。两个例子：
1）比如无论是可靠性、效率还是可维护性，最终影响的都是功能性，或者可以说是导致功能性问题的部分根因。可以说，功能性是用户最终看到的质量特性，而可靠性、效率、可维护性却是研发看到的质量特性。
2）有些特性又有相同点，又有不同点。比如可靠性和效率，相同点在于，虽然问题产生原因不同，但最终都会导致数据不产出。在不产出的情况下，临时解法可能都会一样，比如切前一天的数据。不同点在于，问题的根本解法有很大的不同，可靠性还是要靠强弱依赖关系检查、架构优化等手段解决，而效率问题要靠资源扩容等手段解决。
怎么样能让模型更好用呢？我在上面的基础上进行了简单的修改。
首先将质量特性分为用户可见的质量特性和研发可见的质量特性。因为导致用户可见的质量特性出现问题的原因，很大程度上取决于研发可见的质量特性。
研发可见的质量特性又分为治标特性和治本特性。所谓治标特性是指兜底，例如，如果数据产出出了问题，那我们有没有快速的兜底恢复方案，是应用降级、限流还是切换旧数据？所谓治本特性是指出问题的根本原因，包括可靠&可维护性、效率、安全。这里把可靠和可维护性合并，是觉得两个联系紧密，都和研发的架构有关。把安全性从功能性移到这里，是觉得安全性对于用户来说可见性没有那么强，但一旦可见，后果非常严重，是需要在研发阶段重点考虑的。通过可见性范围将质量模型进行重构后，在模型正交上会显得比之前相对好些。
二、数据测试方法论探寻
2.1．数据质量模型应用于研发过程
既然数据质量模型有了雏形，接下来需要思考的就是质量模型在研发过程中的落地，也就是由谁在什么时间做什么事情？首先，我们先把质量模型平铺到研发周期中去，x 轴为研发周期，y 轴为质量模型，接下来要做的就是填空题，即每个研发阶段在某个质量特性上该做什么事情，这样就得到了一个二维关系，如下图所示。里面的内容其实是我们根据自己产品线特性以及质量活动经验总结出来的，但总体看下来，大致和传统质量是相似的。
填完内容之后，至于由谁来做就一目了然了。易用性的问题涉及到商业调研、用户需求和产品规划，更多的是 PD 主导的事情。其他几个特性，也就是蓝框中的特性都是开发测试阶段需要考虑的特性。
2.2．数据质量模型中的测试抓手
那测试的抓手主要在哪儿？很明显，如果从代表用户的角度，那最直接的切入点就是功能性这个特性。一方面它是用户可见的特性，测试从用户的角度发现问题；另一方面所有研发可见的特性导致的质量问题最终都会落到功能性上，可以用功能性做问题发现的最后兜底。
除了功能性，还有需要测试重点考虑的特性么？我个人的经验是，容灾性是需要考虑的。因为作为研发修复问题的兜底方法，容灾性的有无或好坏会严重影响到功能性。这也是我把他从质量模型中独立出来的一个考虑。测试在容灾的预案制定上应该起到一定的 review 作用。
至于其他几个特性，效率也好，可靠&可维护性，安全性也好，要根据项目性质是日常还是大促，是功能新增还是功能优化，甚至测试团队是新建还是有所积累有关。对于日常项目、功能新增、团队新建等，在功能性&容灾上的投入是最大的，而功能性测试又是两者中最大的。随着功能性上的完善，会逐渐投入到效率、可靠&可维护性上。而在大促、功能优化、团队积累时，在容灾性、效率、可靠性&可维护性上的投入比功能性要更重。所以我认为数据测试公式应该是：
数据测试 = 基础测试（功能性 + 容灾性） + 选择评估（效率 ||可靠&可维护性 || 安全性）
鉴于功能性测试在整个数据测试中的主体位置，2.3会详细介绍功能性测试的方法。其他几个特性的测试在2.4、2.5中简单描述。
2.3．数据测试中的功能性测试方法
对于传统功能测试或者接口测试来说，就是通过构造输入，检查输出。对于数据测试来说也是如此，只不过最终测试的对象由界面、接口返回换成了数据。如果将数据测试活动分解来看，比较重要的活动有三个：输入数据构造、输出数据的测试方法、测试执行时机。接下来会分别对这三部分的测试方法进行描述。最后，CR 作为一种典型而又有效的检查数据准确性方法，也会做简单介绍。
1）输入数据的构造
并不是所有项目都需要输入数据的构造，像我所在的产品线“数据银行”目前并不是通过输入数据构造的方式进行测试的。什么样的产品线会适合输入数据的构造呢？
我的观点是，如果对线上异常数据十分敏感的业务，是需要做输入数据的构造的。对输入数据进行构造，实际上并不容易，首先需要测试根据要求生成一批数据，然后使用开发提供的业务代码运行这批数据，最终产生输出数据。如果业务代码只依赖一张表还好，但如果依赖多张表的话，那需要考虑到多张表的输入数据的构造。
如果对线上异常数据并没有那么敏感的业务，或者上游数据质量相对高的业务，其实不一定要在测试阶段生成各种输入的异常数据。开发可以提测某份快照数据来重点验证数据处理逻辑的正确性，而因为对输入的异常数据考虑欠佳导致输出数据异常的情况，还是可以采用线上持续监控的方式进行。这一点后面也会说。
2）输出数据的测试方法
在输出数据的测试方法上，根据功能性下的三个二级特性：及时性、完整性、准确性，对应有不同的测试方法。下面的脑图是一个方法汇总。
及时性：相对来说测试方法较为简单，需要做到的就是有没有在规定的时间内产出数据，可以通过检查全表条数或者检查分区条数来判断。
完整性：完整性重点评估的两点是：数据不多，数据不少。
不多：一般是检查全表数据、重要枚举值数据有没有重复或者数据主键是否唯一。
不少：一般是对全表数据或业务相关的重要字段（比如日期、枚举值、品牌、类目等）进行检查。如果数据规模是可以被知晓的，比如知道表中品牌有x条，那每次检查x条即可。如果数据规模本身变动较大导致不可被知晓（比如表中的品牌数会开通或关闭），常用的方法就是通过对比历史数据，看整体波动是否正常。
准确性：准确性相比来说，是比较不容易测试的一种特性，为什么？因为很难去找一个理性的参照物，来说明数据有多准，大部分都存在于认知中。正是因此，准确性测试也是在数据质量模型体系化过程中思维相对发散的一个例子。于是我在发散的思维中从自身、时间、空间的维度试图总结下准确性的测试方法。虽然也总结出了一些方向性思路，但是每种思路还是要依赖于个人的发散性思维以及对业务的理解才能最终将其用好。
a.自身检查：是指在不和其他数据比较的前提下，用自身数据来检查准确的情况，属于最基本的一种检查。自身检查的测试方法只能将数据正确的概率提高，但受限于信息量，提高程度有限。有三种比较典型的方法。
第一种方法是该值是否在常规范围内，举个例子，比如人数占比，理论上都会在[0,1]之间，属于对值进行最基本的检查；
第二种方法是该值是否在业务范围内，一般是对该值业务属性了解后的一个判断，比如如果我测试的是某产品搜索人数，如果触发渠道唯一的话，理论上该产品的搜索人数>=该产品的购买人数，这种就是在了解值背后的业务之后的判断；
第三种方法是该值的分布，如果对某个值的业务特性有明确的了解，通过观察值分布也可以测试其准确性。比如如果测试“购买人数中的会员占比”这个值，可以观察其在数据中分布，认知该比例应该在0.3左右。 如果测试完分布，结果发现80%大致在0.2-0.4之间，那就符合认知。如果结果发现80%在0.8-0.9之间，那就不符合认知。
b.时间维度上的比较：如果把数据放到时间维度上比较，可以继续提升数据准确的概率。有两种方法：一种方法是在同一数据批次内观察同一个数据不同时间的情况，一种方法是在不同数据批次内观察同一数据的情况。
同一批次：比如开发线下提测了一批数据，这就是同一数据批次，在该批次下，可以比较 ds=20180901、ds=20180902、ds=20180903等不同日期的数据的波动。
不同批次：这种相对来说比较难找，因为对于数据来说，很少有保留好几个数据版本的情况，但有一个比较典型的案例，就是线上线下的数据 diff。如果认为线下的版本是 N，那可以认为线上的版本就是 N-1。通过线上线下的数据 diff，能将确定不会改变的数据进行diff检查。
c.空间维度上的比较：空间维度上的比较，是指固定了时间维度，将当前数值和其他数据进行比较，进一步辅助正确性。也有三种基本思路：
一种是上下游比较，尤其是重要字段在上下游的加工过程中有没有信息丢失；
一种是和除上下游外的其他数据进行比较，比如和同一数据源下的兄弟表进行比较，或者和不同数据源下的表进行比较。同一数据源的例子，比如表 A 是某个一级类目的销售数据，表 B 是该一级类目下二级类目的销售数据，那么表 B 的数值相加=表 A 数据。不同数据源的例子，比如为了计算性能考虑，部分数据会从行式数据库同步到列式数据库进行计算，那行式数据库中的数值应该和列式数据库中的数值应该是相等的；