浅谈数据测试

|0x00 “大数据测试”

有一些人会有困惑:“大数据大数据,都这么大了,怎么测试?”过去的大数据开发,确实很少有测试,究其根本,数据是为业务服务的,而且数据量之大,往往不能像工程团队那样,构建一套完整的测试环境,只有上了生产才有数据可测。
所以,我们通常情况下理解的数据测试,除了保障数据准时产出,也就是规范任务优先级之外,最常用的,就是给数据表配置监控任务,通常有这么几个规则:
  • 数据不为空:需要产出的数据分区下不能没有数据;
  • 字段不为空:某个字段在某个分区里,全部都是null,可能就是问题;
  • 主键唯一:通常情况下,大家都是用维度建模的,因此主键唯一很重要,能第一时间发现错误数据;
  • 波动监控:如果分区条数的数量,或者是某个统计结果的值,发生了大幅度波动,那么数据很有可能就是有问题的;
  • 基础逻辑监控:比如金额不为负,子订单之和等于父订单,等等,这一类的逻辑是业务强相关的;
  • 自定义业务监控:测试同学配置的一些特性监控,比如数值应该在某个范围内,等等。
通过这些基础的监控,我们就可以初步判断,某段数据脚本,或者是某张数据表,在大数据环境下的运行,是否是正确的

|0x01 数据准确性

但是,仅仅保证了以上的措施,还不够,因为这些措施都是从全局的角度来考虑的,而用户看到的,是属于他专属的那一份,是一个范围很小的子集,这时候大数据测试,就很难发现这些问题。
例如,某个重要的广告主发现没有昨天的数据,投诉了过来,而我们查了一遍数据检查的流程,发现都是正确的,再向上游找,发现有一台机器数据上报延迟了,数量很小,所以波动性监控没有发现,而丢的数据恰恰又是重要的广告主,因此问题一下子被放大。
因为一些“恰好”的严重后果,导致了我们做测试的时候,更需要加倍的小心。因此,有必要设计一套更精细的测试方法,不能说百分之百的避免,但至少可以覆盖95%以上的场景。
有了以上的案例,重新思考数据的准确性,我们可以发现,数据的准确性,其实有三个方面的内容:数据的含义要准确,数据的数值要准确,数据的结果要准确。
  • 数据的含义要准确:在做需求之前,至少自己要对于指标的概念,有一个清晰的理解,在需求评审的时候,就要格外注意。例如,我们统计ctr,根据场景的不同,分成了ctr1、ctr2、ctr3、ctr4、ctr5…… 我们看着需求文档,一通开发,做完了,但某天有人追问过来了,问这些ctr有什么区别,有一个ctr为什么数值是0,你就蒙圈了,然后再回去翻代码看逻辑,这就有问题了。因此,数据的测试,是需要邀请一些不同角色的用户,来看这些指标,对于有问题或者有歧义的部分,是否能够正确解答,至少保证逻辑是自洽的。
  • 数据的数值要准确:从数据采集到计算的整个过程,看作是一个阶段,叫数据的数值准确,需要一些测试流程来覆盖,这里就可以用到刚才的配置监控任务,或者是CR这一类的静态代码检查,或者是校验最大、最小、均值、空值、互斥等常见的数据逻辑。
  • 数据的结果要准确:这个听起来比较费解,其实就是我们要对数据进行抽样检查,至少保证重要用户的数据是OK的。虽然前两步能够把绝大多数的情况覆盖,但总有一些意外,是需要抽象的时候,才能看出来的。这个过程,我们可以当作“灰度”阶段。

|0x02 测试的自动化

在如今自动化测试越来越完善的今天,如果依旧通过人工的方式来测试数据,成本是很高的。因为,一来测试从业者数量有限,分配给数据的测试就更少了;另一方面,现在业务逻辑通常都会很复杂,要想做好数据测试,就需要懂业务逻辑,不然代码里写了1、2、3,自以为看起来清楚的很,但其他人看起来蒙圈的很。
所以,有必要将一些通用的过程,完善起来,像“测试用例”一样,能够让测试的效率也提高起来。
当然,要想把数据测试自动化之前,首先有一个可靠的数据口径描述方式
数据口径简单考虑起来,就是客观描述这个指标做了什么,例如:
  • 时间:创建时间、修改时间还是统计时间;
  • 地点:日志系统、数据库还是经纬度、产品上的位置;
  • 人物:用户、应用还是系统状态;
  • 事件:点击、展现、计费还是某种操作过程。
从测试的角度上,并不一定需要非常完美的描述,但需要理解这个指标是为了统计个什么。
其次,我们就需要考虑全局数据的准确性,这里就会用到非常多的业务逻辑监控,在本文的第一部分有产出。尽可能多的收集业务逻辑,并将它们做成系统的形式,当其他同学需要用到相同的功能测试时,就可以复用这些测试的用例。
再次,我们需要考虑抽样数据的准确性,这里有一点像A/B测试,也就是将数据进行分组,随机抽取统计结果,然后逐个结果与业务系统进行对比,检查结果是否一致。
例如,针对明细数据进行对比,当指标是统计某个标签下的用户数量,可以将业务系统涉及到的用户清单拉出来,与统计表进行对比,对于每个被过滤的用户,检查他们的属性与过滤条件是否一致。这些过程做成自动化的结果,通常也不是很困难的事情。
最后,就是产品层面的测试了。这里其实不一定是对数据结果的测试,也可以是对页面功能的测试,例如点击交互,是否会产生结果,因为很多空数据会导致交互失效;再例如某个字段的描述文案,是否与统计指标能够对应起来,等等。在产品层面上,测试可以像一个小白一样,完整的体检产品的使用过程,从最终交付的层面上来保障数据结果的准确可靠。
当我们测试用例和自动化做的越好,监控项目总结的越多,就可以考虑测试平台的产品化了,尽管这个平台面向的群体比较单一,但对于数据质量的最终保障,帮助却是非常大的。从测试的角度上来说,不管什么类型的测试,其测试过程都是通用的,测试方法都是可借鉴的,当我们储备了足够多的测试基础和测试方法,就可以轻松应对各种不同的测试。

|0xFF 价值的体现

数据测试是一门需要耐心和细心的工作,有点像财务一样,大概率处女座的性格,是最合适的。
同时,测试是一个非常看重协作的岗位,很多业务细节都埋在代码里,不去看,不去听最初的需求沟通,很难理解会为什么。因此当数据测试提过来很多问题之后,数据同学大概率心理是崩溃的,因为很多业务要重新讲一遍,会导致内心有很大的抵触。
所以,数据质量的保障,不仅仅需要依靠数据测试,也不仅仅依靠数据规范,甚至是架构能力,而是需要一种宣导。
更大的范围上来说,软件的开发、交付、效率、质量都有一些比较好的沉淀,因此问题都是可控的,但数据领域,还没有形成比较好的沉淀。之前有个段子说:某位商业间谍,潜伏到一家公司,窃取数据,但窃取了几次,发现数据口径都对不上,被迫做数据治理去了。。这未来,或许是数据仓库/数据开发这些岗位的归属,是为了数据的质量而服务,并非是业务价值。
继续阅读
阅读原文