浅谈数据测试

浅谈数据测试

|0x00 “大数据测试”

有一些人会有困惑：“大数据大数据，都这么大了，怎么测试？”过去的大数据开发，确实很少有测试，究其根本，数据是为业务服务的，而且数据量之大，往往不能像工程团队那样，构建一套完整的测试环境，只有上了生产才有数据可测。

所以，我们通常情况下理解的数据测试，除了保障数据准时产出，也就是规范任务优先级之外，最常用的，就是给数据表配置监控任务，通常有这么几个规则：

• 数据不为空：需要产出的数据分区下不能没有数据；
• 字段不为空：某个字段在某个分区里，全部都是null，可能就是问题；
• 主键唯一：通常情况下，大家都是用维度建模的，因此主键唯一很重要，能第一时间发现错误数据；
• 波动监控：如果分区条数的数量，或者是某个统计结果的值，发生了大幅度波动，那么数据很有可能就是有问题的；
• 基础逻辑监控：比如金额不为负，子订单之和等于父订单，等等，这一类的逻辑是业务强相关的；
• 自定义业务监控：测试同学配置的一些特性监控，比如数值应该在某个范围内，等等。

通过这些基础的监控，我们就可以初步判断，某段数据脚本，或者是某张数据表，在大数据环境下的运行，是否是正确的。

|0x01 数据准确性

但是，仅仅保证了以上的措施，还不够，因为这些措施都是从全局的角度来考虑的，而用户看到的，是属于他专属的那一份，是一个范围很小的子集，这时候大数据测试，就很难发现这些问题。

例如，某个重要的广告主发现没有昨天的数据，投诉了过来，而我们查了一遍数据检查的流程，发现都是正确的，再向上游找，发现有一台机器数据上报延迟了，数量很小，所以波动性监控没有发现，而丢的数据恰恰又是重要的广告主，因此问题一下子被放大。

因为一些“恰好”的严重后果，导致了我们做测试的时候，更需要加倍的小心。因此，有必要设计一套更精细的测试方法，不能说百分之百的避免，但至少可以覆盖95%以上的场景。

有了以上的案例，重新思考数据的准确性，我们可以发现，数据的准确性，其实有三个方面的内容：数据的含义要准确，数据的数值要准确，数据的结果要准确。

• 数据的含义要准确：在做需求之前，至少自己要对于指标的概念，有一个清晰的理解，在需求评审的时候，就要格外注意。例如，我们统计ctr，根据场景的不同，分成了ctr1、ctr2、ctr3、ctr4、ctr5…… 我们看着需求文档，一通开发，做完了，但某天有人追问过来了，问这些ctr有什么区别，有一个ctr为什么数值是0，你就蒙圈了，然后再回去翻代码看逻辑，这就有问题了。因此，数据的测试，是需要邀请一些不同角色的用户，来看这些指标，对于有问题或者有歧义的部分，是否能够正确解答，至少保证逻辑是自洽的。
• 数据的数值要准确：从数据采集到计算的整个过程，看作是一个阶段，叫数据的数值准确，需要一些测试流程来覆盖，这里就可以用到刚才的配置监控任务，或者是CR这一类的静态代码检查，或者是校验最大、最小、均值、空值、互斥等常见的数据逻辑。
• 数据的结果要准确：这个听起来比较费解，其实就是我们要对数据进行抽样检查，至少保证重要用户的数据是OK的。虽然前两步能够把绝大多数的情况覆盖，但总有一些意外，是需要抽象的时候，才能看出来的。这个过程，我们可以当作“灰度”阶段。

|0x02 测试的自动化

在如今自动化测试越来越完善的今天，如果依旧通过人工的方式来测试数据，成本是很高的。因为，一来测试从业者数量有限，分配给数据的测试就更少了；另一方面，现在业务逻辑通常都会很复杂，要想做好数据测试，就需要懂业务逻辑，不然代码里写了1、2、3，自以为看起来清楚的很，但其他人看起来蒙圈的很。

所以，有必要将一些通用的过程，完善起来，像“测试用例”一样，能够让测试的效率也提高起来。

当然，要想把数据测试自动化之前，首先有一个可靠的数据口径描述方式。

数据口径简单考虑起来，就是客观描述这个指标做了什么，例如：

• 时间：创建时间、修改时间还是统计时间；
• 地点：日志系统、数据库还是经纬度、产品上的位置；
• 人物：用户、应用还是系统状态；
• 事件：点击、展现、计费还是某种操作过程。

从测试的角度上，并不一定需要非常完美的描述，但需要理解这个指标是为了统计个什么。

其次，我们就需要考虑全局数据的准确性，这里就会用到非常多的业务逻辑监控，在本文的第一部分有产出。尽可能多的收集业务逻辑，并将它们做成系统的形式，当其他同学需要用到相同的功能测试时，就可以复用这些测试的用例。

再次，我们需要考虑抽样数据的准确性，这里有一点像A/B测试，也就是将数据进行分组，随机抽取统计结果，然后逐个结果与业务系统进行对比，检查结果是否一致。

例如，针对明细数据进行对比，当指标是统计某个标签下的用户数量，可以将业务系统涉及到的用户清单拉出来，与统计表进行对比，对于每个被过滤的用户，检查他们的属性与过滤条件是否一致。这些过程做成自动化的结果，通常也不是很困难的事情。

最后，就是产品层面的测试了。这里其实不一定是对数据结果的测试，也可以是对页面功能的测试，例如点击交互，是否会产生结果，因为很多空数据会导致交互失效；再例如某个字段的描述文案，是否与统计指标能够对应起来，等等。在产品层面上，测试可以像一个小白一样，完整的体检产品的使用过程，从最终交付的层面上来保障数据结果的准确可靠。

当我们测试用例和自动化做的越好，监控项目总结的越多，就可以考虑测试平台的产品化了，尽管这个平台面向的群体比较单一，但对于数据质量的最终保障，帮助却是非常大的。从测试的角度上来说，不管什么类型的测试，其测试过程都是通用的，测试方法都是可借鉴的，当我们储备了足够多的测试基础和测试方法，就可以轻松应对各种不同的测试。

|0xFF 价值的体现

数据测试是一门需要耐心和细心的工作，有点像财务一样，大概率处女座的性格，是最合适的。

同时，测试是一个非常看重协作的岗位，很多业务细节都埋在代码里，不去看，不去听最初的需求沟通，很难理解会为什么。因此当数据测试提过来很多问题之后，数据同学大概率心理是崩溃的，因为很多业务要重新讲一遍，会导致内心有很大的抵触。

所以，数据质量的保障，不仅仅需要依靠数据测试，也不仅仅依靠数据规范，甚至是架构能力，而是需要一种宣导。

更大的范围上来说，软件的开发、交付、效率、质量都有一些比较好的沉淀，因此问题都是可控的，但数据领域，还没有形成比较好的沉淀。之前有个段子说：某位商业间谍，潜伏到一家公司，窃取数据，但窃取了几次，发现数据口径都对不上，被迫做数据治理去了。。这未来，或许是数据仓库/数据开发这些岗位的归属，是为了数据的质量而服务，并非是业务价值。

标签：逻辑,浅谈,测试,数据测试,业务,监控,数据
来源： https://blog.51cto.com/u_15291990/2978709