-- 转自挖数网 自己备份用 这个网貌似挂掉了
数据质量是数据应用的核心基础，数据测试是非常重要的一环，若质量把控不够严格，后续所有的行为都可能有偏差甚至错误，所以做好数据测试很关键，如下是针对怎样做好数据测试的一些总结
核心理论
以小博大，即用小部分数据验证全部数据，所以如何选择小去验证大呢，主要是构成结果数据的维度和度量组合，从中找到可覆盖全部的小部分数据
对比对象
对比对象指结果数据同哪些数据进行比对，从而验证数据的准确，即一方数据是准确的，另一方基于其进行的二次计算，测试二次计算的过程是否存在问题。数据测试的主要场景是数仓模型、应用层报表、临时数据，这三块对比对象有所不同
（1）数仓模型
数据来自业务系统，经过处理整合成数仓模型，便于应用于更复杂的数据场景，因此假设业务系统数据正确，数仓模型的数据与其对上即可
（2）应用层报表
数据是基于数仓模型开发的结果，中间可能会有DM、RPT层等，此处统称为应用层，假设数仓模型数据正确，应用层和数仓模型对上即可
补充：若在已开发好的应用层上迭代，部分未改变任何逻辑的数据可同报表原有数据比对，修改逻辑的数据和数仓模型对比即可
（3）临时数据
数据都有临时的逻辑和数据来源，和来源的数据对应上即可
*如何测试呢？*数仓模型、应用层、临时数据有各自的特色，分别展开讨论
“数仓模型”
需测试的目标表格式如下
image.png
步骤一 大数校验
测试主题：目标表和源表的数据条数是否一致
如源数据有10000条，目标表中是否有10000条(前提是源数据没有脏数据的前提下)
步骤二 预知校验
测试主题：各维度存在的枚举值是已知的，检验数仓中各维度枚举值是否完整，如门店是否包含全部门店、渠道是否包含全部渠道等
**
**
步骤三 各维度-度量值的明细数据测试
测试主题：针对具体的维度、度量值的测试
（1）设计表格，协助测试
数据可看的维度视角非常多，通过测试表格把思路梳理清楚，避免想到什么测试什么造成的遗漏，且记录测试的过程，便于回顾总结，看似很麻烦，但数据质量是首要保证，且执行起来非常清晰，磨刀不误砍柴工
格式如下
image.png
注释：
a.指标是需要测试数据表的度量值，全部需测试
b.组合维度指确定好的以小博大的小，由结果表中各种不同维度组合而成的数据，具体后续有详细说明
（2）确定需测试的组合维度
方法：数据模型保存的是最细颗粒度的数据，因此粒度是一个，但每个维度的枚举值却有多 个，因此需基于各维度的枚举值，找到可代表全部数据的枚举值互相组合，从而确定测试的组合维度
案例：维度枚举值如下
image.png
基于上表确认测试的组合维度值，基于选择的枚举值互相组合后仍很多，可选择任意交叉组合，筛选原则是尽可能保证每个维度的枚举值出现的频率均等
*此处选择组合成9组不同的值作为“组合维度”*
- 门店1&天猫&生鲜的商品1&当日配送&是退货单&是预售
- 门店2&京东&食品的商品1&日次配送&不是退货单&不是预售
- 门店3&唯品会&用品的商品1&自提&是退货单&是预售
- 门店1&自营&加工的商品1&次日配送&不是退货单&不是预售
- 门店2&天猫&食品的商品2&当日配送&是退货单&不是预售
- 门店3&京东&生鲜的商品2&次日配送&不是退货单&是预售
- 门店1&唯品会&用品的商品2&自提&不是退货单&不是预售
- 门店2&自营&加工的商品2&自提&是退货单&不是预售
- 门店3&天猫&食品的商品2&次日配送&不是退货单&是预售
（3）测试方法
数据在业务系统有最直接的结果，对应条件筛选好后，直接比对两者的度量值(如销售额)是否一致，结果记录在测试表中，完善的记录可帮助全面的看出问题在哪，需如何完善
“应用层报表”
结果数据是经过各种聚合计算得来，因此不需数仓的“条数比对”
步骤一 预知校验
测试主题：每个维度的枚举值是否完整
如全国/区域，是否应该出现的区域都出现了，比如全国/区域/门店，是否每家门店都出现了
步骤二 各维度-度量值的明细数据测试
测试主题：针对具体的维度、度量值的测试
（1）设计表格，协助测试
和数仓类似，此处不再重复
（2）确定需测试的组合维度
方法：应用表的维度是事先约定好的，需针对每个维度选择合适的枚举值，枚举值和数仓的确认过程是一样的，此处不再复述
补充：枚举值的选择和数仓有差别，因数仓是一个维度粒度，但应用层在维度上存在很多组合，粒度不是最细的，有很多层次的归属关系，如：全国累计、全国各区域累计、全国各区域各门店累计，这三者之间还有从属关系，所以测试粒度的枚举值选择，和数仓不同
案例：
image.png
每个维度最少选择3个枚举值参与测试，若时间充裕可把数量提升，由此可确保更完整
选择如下由不同枚举值组合而成的组合维度参与测试
image.png
（3）测试方法
方法1：把原始数据导出到excel进行各种规则组合和结果数据计算对比
• 优点1：看数据时，非常直观了解原始数据的模样，或许可让测试者发现一些之前忽略的盲点，毕竟真实数据中藏着什么其他数据，我们是没办法预知的
• 优点2：excel处理起来很便捷，筛选过滤加工，但有个很明显的缺点就是没办法快速高效的处理很大批量的数据，所以适用于数量小的场景下进行测试
方法2：基于计算规则编辑好SQL，从数仓直接计算的结果和结果数据对比
• 方法1的优点是方法2的缺点，方法2的缺点就是方法1的优点
上述方式在实际中可灵活互相组合应用，不是限定死
步骤三 具有从属关系维度之间的度量数据要一致
测试主题：结果表中，不同维度粒度之间是有从属关系的，这类数据必须保持一致。本处的从属关系指主维度的数据可由从维度的累积而成，祥见后续“确认从属维度关系”
（1）设计表格
image.png
（2）确认从属维度关系
什么是从属关系
如组合维度有 全国、全国/省、全国/省/门店，其中区域的累计是全国，区域对应门店的累计是区域的累计，所以这三者之间的数据需一致
从属关系确立的规则
“主维度”属于汇总方的数据，“从维度”属于主维度数据进行进一步的拆分
确定好不同维度之间的从属关系，针对每个从属关系验证数据是否对的上
案例：
image.png
注意：部分度量值，在具有从属关系的维度上，是不能直接累加匹配的，如订单量，如果是累加的关系，就是错误的，需独立计算，需特别注意下
（3）测试数据
针对从属关系的数据需进行全部匹配校验
如：主维度“全国”对应的所有“从维度”，在“度量值：销售额”上，需全部进行累计校验，确保完全一致。将结果记录在测试表中，可清晰明了的看到测试过程的问题和全局
“临时数据测试”
临时数据的特点是完全基于新的规则获取的数据，相当于把开发干的活都做了一遍，但好处是维度少、数据少，需验证的数据不多，因此无需那么复杂的设计测试表格。因抽数据的SQL脚本是自己写的，自检相对来说比较难，所以分两步走
步骤一 给业务看
因长久地观察跟踪研究，业务对自己负责业务板块的数据敏感度很高，明显错误的数据大多数情况下一眼是看得出来，所以让对方帮忙做一手的判断效率比较高
如，某个门店的SKU，最多4000上下，初次提供的数据是10000，业务看到后直接提出来了疑问，倒逼数据提供者快速查找问题出在哪里
步骤二 自校验
针对部分数据导出其对应的底层明细数据，抽样检查与结果进行匹配校验
补充重点
上述步骤要做好，还有一些关键细节，在此处提一下，后续也会尝试针对关键点进行展开分享，看如何可以做得更好
（1）数据产品(or分析师)与数据开发间合理的协作方式
协作方式是否合理非常重要，很多细节开发更清楚，但业务逻辑产品分析师更清楚，需互相更融洽渗透，做好分工协作
（2）让业务开发更好的理解数据产品的真实诉求
如何与业务系统的开发和产品沟通的更好，让他们更好的理解数据产品的真实诉求，可以和他们分享数仓的建设过程，帮助更好的理解自己的某些行为可能会给数据开发带来什么样的后果
（3）底层表摸底
对底层表结构在正式开工之前进行摸底工作，这样可以便于加深熟悉，避免走坑
写在最后
数据测试是一门需要耐心细心的辛苦活，方法也是需要持续优化，非常欢迎有自己方法的你来补充，一起来完善
网友评论