深入探讨数据测试

|0x00 数据测试模型

通过之前的两篇文章,我们已经对数据测试有了一个初步的刻画,本文讲述一些更进阶的内容。因为测试通常要对研发环节有一定的入侵,如果测试的内容越多,势必影响到研发效率的提升,很容易造成测试与研发之间的对立,但如果不去做测试,那么数据的质量就会失去最后一道保护的屏障,同样不可取。
数据质量是数据研发的生命红线,研发效率是数据研发的价值增量,都是需要兼顾的部分。
因此,我们需要把数据测试进行切分,识别其中必要与非必要环节,通过保障必要的研发过程来实现落地,搞清楚谁、在什么时间、做了怎样的研发动作,然后将质量的监控,平铺到核心的研发阶段中去。下一步,我们需要考虑的内容,就是数据测试的“抓手”在哪里,也就是我们通过怎样的措施,能够保障数据的质量,为数据做“兜底”。回看质量体系的6个一级特性,会发现,几乎所有的问题,都会归因到“功能性”测试上,并通过“功能”对数据问题做最后的“兜底”。因此,我们可以任务,数据测试,重心就是做好功能性测试,同时选择性的评估其他几个方面。
那么,我们便可以通过如下的模型,来初步刻画数据测试模型:
数据测试 = 必要测试(功能性) + 选择测试(可靠性、易用性、维护性)
必要测试指一定要做的测试,无论项目大小,而选择测试则可以根据工作量饱和程度、产品重要性等进行自由选择。效率与可移植性,可以不在数据测试中体现,但可以作为辅助参考,看是否需要进行选择测试。

|0x01 功能性测试

接下来,我们讲一讲必要的功能性测试问题,主要谈自动化测试的问题。
对于软件工程领域的测试,主要方法在于通过配置化的接口,构造输入数据,检查输出结果是否正确,这个过程对于数据测试同样适用。一旦有了标准化的检测方法,“自动化”就可以提上日程了。
我们先谈输入数据构造。并不是所有的数据都需要构造输入数据,如果是一些比较成熟的业务,我们只需要测试输出数据就好了。但如果是数据安全要求比较高,或者是新业务数据量不足的情况下,就需要测试同学去构造一些符合客观事实的数据,输入到业务过程里,再测试数据结果。
再谈测试输出数据,这个是重头戏。我们看一下功能性的几个二级特性:适合、准确、互操作和保密安全,其中准确就是对输出数据的要求。那么什么是准确呢?通常而言,就是不多、不少、范围、分布、可叠加、多表对比、上下游对比、badcase等特性。
  • 不多:统计链路上相关的数据表,是否都遵循了主键唯一,枚举值是否有空值等多余情况。
  • 不少:对重要字段进行检查,比如品牌、类目、行业等是否都涵盖了,通过对比历史波动查看是否正常。
  • 范围:检查数值是否在正常范围内,例如比例/比率这一类的指标,结果应该在0-1之间;例如某个产品的用户量不应该超过全局用户量,等等。
  • 分布:检测数值的分布特性,例如某个阶段的转化率通常在5%左右,那么统计结果在1%-10%之间都是符合认知的;或者查看统计数据的正态分布,对于极端的case进行特定的分析。
  • 可叠加:子维度的统计结果相加应该等于父维度,例如子订单的金额总和应该等于父订单。
  • 多表对比:如果统计指标在多个表出现,它们的结果理论上是应该一致的。
  • 上下游对比:公共层的统计结果,理论上应该与应用层相等,当然特殊业务场景除外。
  • badcase:挑选具体的case查看结果。
其他的验证方法,需要自己在实践中总结了。数据开发通常先进行数据的自测,保证没有基础问题之后,再提交给数据测试进行提测。

|0x02 CodeReview

虽然自动化的测试能够发现很多问题,但静态代码的CodeReview仍然是必不可少的,因为CodeReview是最能解决根本问题的检查手段。
举个例子,测试用例有两种时间属性,一种是创建测试用例时间,一种是修改测试用例时间,我们想统计单位周期内测试用例的数量,来衡量测试同学的工作量。如果需求没有特别的要求,很多同学就会用创建测试用例时间来做统计,但实际上应该用修改测试用例时间,因为修改情况能够比创建情况,更准确的反应测试同学的工作量。但这种情况在测试的时候很难发现,因为不论从哪个角度来测试,结果都是OK的,只有在理解业务逻辑的情况下,通过CodeReview,才能发现这个问题,而一旦发现,过去所有的统计结果都会发生变化,如果数据已经透出,会造成大范围的影响,直接导致别人对数据质量的质疑。
尽管只是口径不同,但在具体的业务处场景下,是没有标准可以遵循,但又需要选择最合理的口径,这些都是自动化测试无法发现的。
CodeReview的测试,能够与数据模型的质量规范挂钩起来,如果建模的时候没有遵循规范,例如主键没有唯一,没有配置检查任务,导致下游数据出错,这时候测试出了问题,开发同学的责任就跑不了了。
关于CodeReview关注的重点,大致可以分成如下几个:
  • 字段顺序;
  • join条件;
  • 空值情况;
  • 结果精度;
  • where过滤条件;
  • 分区;
  • 去重。
更多的经验,可以自己摸索。

|0xFF 经验的累积复用

数据测试要沉淀什么,大概可以分成如下几种:
  • 与团队的协作:对开发同学晓之以理,划清各自的责任边界,即减少对业务开发的侵入,就可以最大程度上保障数据质量;
  • 测试Case的编写与复用:每一次测试,都可以把经验总结出来,沉淀到Case的复用中;
  • 反映经验的积累情况:绝大多数的测试场景,都是经验的积累复用,很难有标准化的体系思路,因此测试的越多,我们积累的经验就要越丰富;
  • 底层表摸底:在正式测试前,把底层的数据表摸底一遍,一方面了解业务的复杂程度,另一方面避免走一些弯路;
  • 让开发更好的了解业务诉求:并不是说数据测试就可以不关心业务了,因为结果的准确与否,有很多因素是直接跟业务挂钩的,测试结果能够提升开发对于业务的重视,帮助也很大。
经验的积累,拼的就是一个“熟能生巧”,拼的就是一个“无规矩不成方圆”,从量变积累到质变,最终从作坊式的开发,进化到工厂式的开发,最后到智能化的开发。没有什么能够一蹴而就,只有默默的锻炼内功。
继续阅读
阅读原文