【编测编学】如何做好大数据测试

大数据是越来越多我们所听到的词汇，那么如何做好大数据测试？

1，从数据质量模型入手，分析数据展现的规律

什么是数据的质量模型？

传统的质量模型有ISO9126，这个是一个典型的软件质量模型，无论是开发还是测试，无论是每个终端的质量，还是服务端的质量，大的方向都不会跳出9126的模型；

当然，国外还有ISO8000是数据质量方面炒的比较热的一个标准，但是缺点也显而易见。1，不免费提供。2，标准太重。3，国内对这个的资料少的可怜。

那么我们可以尝试套用9126的标准移植到大数据质量？

先介绍下9126：

对比上面的质量模型，我们推演一下数据质量模型

我们通过上面的分析不难看出测试数据的相关case了

及时性：相对来说测试方法较为简单，需要做到的就是有没有在规定的时间内产出数据，可以通过检查全表条数或者检查分区条数来判断。

完整性：完整性重点评估的两点是：数据不多，数据不少。

不多：一般是检查全表数据、重要枚举值数据有没有重复或者数据主键是否唯一。

不少：一般是对全表数据或业务相关的重要字段（比如日期、枚举值、品牌、类目等）进行检查。如果数据规模是可以被知晓的，比如知道表中品牌有x条，那每次检查x条即可。如果数据规模本身变动较大导致不可被知晓（比如表中的品牌数会开通或关闭），常用的方法就是通过对比历史数据，看整体波动是否正常。

准确性：准确性相比来说，是比较不容易测试的一种特性，为什么？因为很难去找一个理性的参照物，来说明数据有多准，大部分都存在于认知中。正是因此，准确性测试也是在数据质量模型体系化过程中思维相对发散的一个例子。于是我在发散的思维中从自身、时间、空间的维度试图总结下准确性的测试方法。虽然也总结出了一些方向性思路，但是每种思路还是要依赖于个人的发散性思维以及对业务的理解才能最终将其用好。

a.自身检查：是指在不和其他数据比较的前提下，用自身数据来检查准确的情况，属于最基本的一种检查。自身检查的测试方法只能将数据正确的概率提高，但受限于信息量，提高程度有限。有三种比较典型的方法。

第一种方法是该值是否在常规范围内，举个例子，比如男女占比，理论上都会在[0,1]之间，属于对值进行最基本的检查；

第二种方法是该值是否在业务范围内，一般是对该值业务属性了解后的一个判断，比如如果我测试的是某产品搜索人数，如果触发渠道唯一的话，理论上该产品的搜索人数>=该产品的购买人数，这种就是在了解值背后的业务之后的判断；

第三种方法是该值的分布，如果对某个值的业务特性有明确的了解，通过观察值分布也可以测试其准确性。比如如果测试“购买人数中的会员占比”这个值，可以观察其在数据中分布，认知该比例应该在0.3左右。 如果测试完分布，结果发现80%大致在0.2-0.4之间，那就符合认知。如果结果发现80%在0.8-0.9之间，那就不符合认知。

b.时间维度上的比较：如果把数据放到时间维度上比较，可以继续提升数据准确的概率。有两种方法：一种方法是在同一数据批次内观察同一个数据不同时间的情况，一种方法是在不同数据批次内观察同一数据的情况。

同一批次：比如开发线下提测了一批数据，这就是同一数据批次，在该批次下，可以比较 date=20200324、date=20200323、date=20200322等不同日期的数据的波动。

不同批次：这种相对来说比较难找，因为对于数据来说，很少有保留好几个数据版本的情况，但有一个比较典型的案例，就是线上线下的数据 diff。如果认为线下的版本是 N，那可以认为线上的版本就是 N-1。通过线上线下的数据 diff，能将确定不会改变的数据进行diff检查。

c.空间维度上的比较：空间维度上的比较，是指固定了时间维度，将当前数值和其他数据进行比较，进一步辅助正确性。也有三种基本思路：

一种是上下游比较，尤其是重要字段在上下游的加工过程中有没有信息丢失；

一种是和除上下游外的其他数据进行比较，比如和同一数据源下的兄弟表进行比较，或者和不同数据源下的表进行比较。同一数据源的例子，比如表 A 是某个一级类目的销售数据，表 B 是该一级类目下二级类目的销售数据，那么表 B 的数值相加=表 A 数据。不同数据源的例子，比如为了计算性能考虑，部分数据会从行式数据库同步到列式数据库进行计算，那行式数据库中的数值应该和列式数据库中的数值应该是相等的；

最后一种是和系统外的数据进行比较，比如 BI 系统、其他业务后台系统比较。这种方法用起来受限制较多，因为从安全角度考虑，常规的 BI 系统或者其他业务后台系统都不太可能将数据开放出来，所以该方法只作为一种可能的思路。

3）测试执行时机

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

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

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

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

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

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

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

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

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

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

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

4）CR

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

投影操作

字段顺序、类型与表声明一致

表中字段的业务含义是否是业务要求的含义

业务上是否要求数据去重

是否可能存在异常情况，如除数为0、Null、空的情况

是否对数据精度有明确要求。

★ 关联关系

关联表使用 outer join 还是 join，或者inner join，要看数据做不做过滤

关联关系 on 字句中，左右值类型是否一致

★ 过滤条件

涉及字符串的等号注意大小写及正确性

有没有考虑到 Null、0、空等异常值的过滤

有没有数据的限定来源

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

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

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

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

可靠性上对任务的强弱依赖进行检查。

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