关于数据测试，已有不少同学写过这方面的文章或者开发过工具。为了系统化，我的想法是从数据质量模型入手，分析数据测试的抓手，然后找出数据测试中需要什么样的工具来支撑。这里我也不会过于强调我们做的平台，或与其他平台作比较，而是想把平台或者工具背后的思考过程总结和分享下。

一、数据质量模型的探寻

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 数据。不同数据源的例子，比如为了计算性能考虑，部分数据会从行式数据库同步到列式数据库进行计算，那行式数据库中的数值应该和列式数据库中的数值应该是相等的；
最后一种是和系统外的数据进行比较，比如 BI 系统、其他业务后台系统比较。这种方法用起来受限制较多，因为从安全角度考虑，常规的 BI 系统或者其他业务后台系统都不太可能将数据开放出来，所以该方法只作为一种可能的思路。

3）测试执行时机

关于测试执行时机方面，和传统测试相同，有如下几个测试时机：自测时、提测后、线上数据修改、线上数据新增。

无论是自测还是提测，关注的都是线下，而线下数据测试是有一定局限性的。如果不采用输入数据构造的方法，那开发一般只提测一部分数据，比如某天的数据，但也正是由于提测数据的片面性，即使提测数据没问题也不能代表数据处理规则就完全没有问题；如果采用输入数据构造的方法，虽然能在线下发现更多的因为输入数据异常导致的输出数据异常，但因为线上生产环境本身稳定性等治本问题，仍然不能代表后续线上就没有问题。

正是因为线下数据的局限性，所以当线上数据修改或者线上数据新增时，仍需要持续进行测试。线上测试 case 有可能完全使用线下的 case，也有可能对线下 case 进行简单修改后使用。

将测试时机独立出来讨论的一个好处是，如果将一系列测试 case 组成任务的话，无论是线下还是线上，只要有合适的触发条件，就可以用合适的触发方法运行这些测试case。触发方法包括条件触发和定时触发。一般来讲，线下使用的是条件触发，即当开发完成需要自测或者提测后测试需要测试时，通过 API 或者界面触发执行。

而线上则要区分使用场景：对于线上数据修改来说，这种操作并不是常规操作，是当需求出现问题或者修复 Bug 时才会出现的操作，所以一般情况下也需要用条件触发。对于线上数据新增来说，一般是每天定期产出新数据。这种既可以采用条件触发（即生成新数据后触发测试），也可以采用定时触发（即定时轮询是否有新数据生成并测试）。条件触发的好处是类似于持续集成中，持续测试的概念，只要涉及数据改动就要触发测试，但它并不能很好的关注及时性；而定时触发的好处是可以及时关注及时性，但对于及时性要求不是很高的数据（比如有时候8点产出，有时候10点产出），那定时触发就会导致很多的误报。

在不同测试时机上，虽然用到的测试 case 大部分都是可复用的，但是也会有些不同。

在自测时，主要是开发团队进行测试。测试 case 更关注数据基础质量的测试，比如完整性和准确性中的自身检查。这部分 case 不需要太多发散性思维。

在提测后，主要是测试团队进行测试。除了数据的基础质量测试外，测试 case 更关注“快照”，即准确性中的空间维度和时间维度的不同批次的对比上，尽可能通过辅证的方式发现数据准确性中的问题。而在同一批次的时间维度方面，往往开发不会提测很多时间点的数据，所以一般情况来说，辅证难度会更大。

在线上数据修改时，基本上可以复用提测后使用的 case。

在线上数据新增时，除了数据的基础质量测试外，绝大部分可以复用提测后使用的 case，但会弱化一部分具有探索性思路的 case 或者是运行时间过长的 case。比如测试值的分布 case 就不适合每天新增时测试，因为每天的数据分布可能有所不同，并不是稳态，加入这种 case 会造成误报率的提升。再比如测试数据量过大的 case，尤其是上下游对比测试，往往下游数据量会很大，每天定时测试一方面会消耗太多时间和资源，另一方面也没有必要，因为这种问题产生的原因往往是数据处理逻辑的问题，一般线下一次测试就可以发现。线上测试会添加时间维度中，同一数据批次中不同时间的波动性的对比。

因此，测试时机对测试的影响可以概括成一张表。

4）CR

虽然在测试方法一节中介绍了通过输出数据发现问题的方法，但发现问题最直接有效的方法还是 CR，尤其是对类 SQL 数据库的准确性问题来说。下面是 SQL CR 中经常用到的一些 CR 规则。

★ 投影操作

字段顺序、类型与表声明一致
表中字段的业务含义是否是业务要求的含义
业务上是否要求数据去重
是否可能存在异常情况，如除数为0、Null、空的情况
是否对数据精度有明确要求。

★ 关联关系

关联表使用 outer join 还是 join，要看数据做不做过滤
关联关系 on 字句中，左右值类型是否一致
关联关系如果是1：1，那么对方表的关联键是否唯一。

★ 过滤条件

有没有分区过滤，是在 where 过滤还是在 on 过滤，分区用 max_pt 还是 ds
涉及字符串的等号注意大小写及正确性
有没有考虑到 Null、0、空等异常值的过滤
有没有数据的限定来源

★ 数据同步任务测试

字段相等
在从 OLAP 导入 OLTP 之前，需不需要做预处理，比如 delete。
在主键相同时，主键相同的数据如何处理。

2.4. 数据测试中的容灾性评估方法

容灾性评估主要是当数据未产出或者数据出现大面积问题时，如何快速止损。比较典型的做法是做可用数据的快速切换，比如快速切换成前一天的数据或者上一个版本的数据。这种情况一般需要服务端配合来完成。

2.5. 数据测试中的其他特性的评估方法

剩下一些特性，开发同学可能会有更加详细的文章阐述，这里只是从测试角度简单描述。

1）效率评估方法：效率评估主要是当前数据的计算资源是否满足当前产品的时间要求。需要分三种情况：一是用户直接触发的计算请求是否过大；二是用户数据是否过多，从而造成计算量过大的情况；三是程序本身效率是否低下，性能过低，导致资源消耗过大。第一种情况往往通过构造请求流量，进行压测评估。后两种一般会通过大盘的方式，找出哪张表运行时间最长，最影响效率，来逐步进行优化。

2）可靠&可维护性评估方法：可靠&可维护性的评估，开发参与较多，测试相对参与较少。比较典型的几个思路是：

可靠性上对任务的强弱依赖进行检查。
可维护性上，尽可能将体系化的开发工作集成化或者平台化。比如，将数据的接入模式从烟囱型的模式转为星型的集市模式，从而只负责接入数据的 ETL，尽可能减少开发工作就是集成化的一种思路。平台化的思路就是将流程化的开发工作，通过平台的方式进行配置来完成，一方面提高开发效率，另一方面减少出错成本，提升开发质量。

3）安全性评估方法：关于安全性评估，我暂时没有经验和案例，有的同学可以一起讨论。

三、依托数据测试方法论的测试工具建设

二中已经阐述了数据测试方法论，那在这样一种方法论下，需要什么样的数据测试工具呢？接下来主要介绍下以类 SQL 数据库为基础的数据测试工具规划思路。

从测试工具的功能上看，数据的功能性特性测试应该是最重的一个环节，它需要涵盖输入数据的构造、输出数据的测试方法、测试执行时机的支持、CR 等功能。而容灾、效率、可靠&可维护性、安全性等特性，相对测试人员来说，开发在这方面积累的更深，所以测试工具可以做到支持对其他特性的测试扩展，加入到工具中来。

从测试工具的效率上看，数据测试天生就是有自动化属性的，因为测试人员不可能肉眼一条条对数据进行 check。所以对数据测试工具的效率讨论，理论上不集中在是否要自动化，而是在对数据测试方法流程的改进上。数据测试方法流程包括测试case的编写和积累、测试 case 的无监督执行、测试结果的自动分析。将整个的数据测试工作通过一套工具进行串联，同时也将已有的 case 进行快速复用，对数据测试效率的提高是很有帮助的。

从整个数据测试的发展来看，数据测试比传统软件测试所不同的是，它的模式性会更强，模式性强的原因是因为本身数据的开发使用语言都是相对模式化的，开发的模式化也意味着测试的模式化。对于一个有丰富经验的数据测试人员来说，会更容易将经验进行下沉，传递给其他测试人员，甚至开发人员。所以我的一个预测是，数据测试虽然发展比传统软件晚，但是在强模式性的背景下，它做到0测试人员介入，是相对容易实现的。所以在这个背景下，测试工具应该具备将经验传承进行汇总并传承的能力，从刚开始的只解放测试人员，逐步发展到到解放研发流程。

所以总结下数据测试工具的需求有这么几个：

需求一：支持输入数据的构造、支持 CR。
需求二：支持输出数据的功能性测试。
需求三：支持对其他测试方法的低耦合式接入。
需求四：支持测试执行时机的灵活选择。
需求五：支持测试case的快速编写和重复利用。
需求六：支持对测试过程的串联。
需求七：支持测试经验的下沉和复用。

根据上述需求，一个典型的数据测试框架应该包含以下几个部分。

测试时机触发能力：支持需求四。数据测试框架应该包含API层，无论是条件触发还是定时触发，都会调用 API 完成任务的触发。条件触发根据数据库不同，可以看是否可以和数据库本身的消息系统做对接，即数据发生变动后，通知消息系统，消息系统调用API触发整个测试任务；定时触发可以采用 crontab 封装一个 job，在 job 中调用 api 触发。

测试过程串联能力：支持需求六。测试过程能力是将整个的测试活动进行管理的能力。典型的测试活动管理能力包括以下几部分：任务生成、任务拆分、任务执行、结果分析。当新建测试活动时，调用任务生成模块去生成测试任务，支持对不同特性的测试。任务拆分的作用是在任务执行的时候，对异构任务进行拆分或者对同构任务进行并行化拆分。任务执行的作用是将任务实际提交到对应的数据源进行计算。结果分析的作用是对数据源的结果进行回流，并对结果进行分析。

测试经验复用&积累能力：支持需求七。需求七理论上不仅仅是只通过 AI 的方式进行测试经验的推荐，而是也想把测试人员已有经验进行总结下沉的过程。

功能性测试能力：支持需求二、需求五。如何支持测试 case 的快速编写？我们的思路是当用户通过功能测试方法进行测试的时候，会调用一个个的指标。指标实际上可以理解成一个函数，它是对功能性测试中一些典型 case 的抽象。当用户调用某指标时，给出指标参数，系统就可以自动翻译成类 sql。这样不仅减少了用户写 sql 的时间，又能很快速地将 case 和作用对应起来，同时在进行测试经验积累和复用的时候，就可以通过指标的概念进行。为什么翻译成类 sql 而不是真正的 sql 实例？是考虑到适配的问题。如何能在 ODPS 上和 ADS 上都能执行呢？通过将类 SQL 通过翻译引擎转化成实际的 SQL 就可以做到。

其他特性测试扩展能力：支持需求三。看图可以知道，这部分采用组件扩展能力是最好的。为什么？之前也说过，在容灾、效率等特性的评估上，集团里已经有很多很好的工具，同时开发在这方面也有很多积累，没有必要另起炉灶去做这方面的事情。唯一需要的就是将其他特性的测试容纳进任务中，和功能测试一起，作为一套完成的测试解决方案，方便后续追溯、沉淀和复用。

输入数据构造&CR 能力：支持需求一。CR 能力方面，如果有类似 Intellij 上，自动提示或者警醒开发同学可能 SQL 在哪方面有问题，这种模式实际上是最好的。不过比较困难的是，SQL 可能能沉淀出来的通用代码检查规则会比较少，大部分还是需要根据对业务的理解来进行，所以如果测试工具能将业务上对 SQL review 的经验保存下来，并提示给用户，在 CR 上也能起到一定的作用。在输入数据构造方面，有其他同学在做类似的工具，我本身因为产品线的关系暂时没有做过相关工作，所以在此只是列举出来，大家有兴趣可以查看相关文章。

质量大盘能力：质量大盘并不是推导出的需求。但是在以结果导向为主的今天，我们做的事情到底现在是什么样的情况，没有质量大盘数据的支持，往往无法知道。所以质量大盘需要收集测试活动中的数据，包括任务执行成功率、Case 覆盖率、线上新增数据的监控覆盖率等，指导后续数据测试的提升工作。

四、写在最后

写这篇长文的过程中，重要的是通过对个人思路进行了一次系统梳理，将现在乃至之前的工作经验都容纳在了该方法中。目前已经完成了部分模型实践和平台开发工作，希望接下来还是继续深入落地数据测试的相关事项，将目前我们做的数据测试工具按思路完善起来。也期待与业界同仁共同交流，一起进步。

本文转载自公众号阿里技术（ID：ali_tech）。

原文链接：

https://mp.weixin.qq.com/s/Ti5YCZSQbugkQZlzlDnQ8Q

创作场景

对数据测试的系统性思考：“做好大数据测试，我是认真的！”