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

大数据是愈来愈多咱们所听到的词汇，那么如何作好大数据测试？
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=2020032四、date=2020032三、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，尽量减小开发工做就是集成化的一种思路。平台化的思路就是将流程化的开发工做，经过平台的方式进行配置来完成，一方面提升开发效率，另外一方面减小出错成本，提高开发质量