浅谈大数据测试
调到数据组测试好几个月了，最近看了一篇系统介绍数据测试的文章，看完之后确实有产生一些共鸣，结合自己在数据测试中遇到的问题和思考，谈谈我对数据测试的理解
1.数据测试测的是什么
1.1数据测试的目的
刚进入数据组测试的时候非常茫然，不知道从何测起，但是数据测试的目标其实还是很明确的，最根本的就是要保证数据产出的质量要高，为此我们还特地成立了一个数据治理项目；现在已经测了几个月了，大概写一下我们数据测试主要分哪些：
- 数据脚本逻辑测试 2. 数据迁移测试
数据脚本逻辑测试就是输出数据是否符合需求方所提要求，数据质量是否符合业务逻辑；
数据迁移指的是在业务逻辑不更改的情况下，数据从某类数据库迁移至另一类数据库，例如mysql中的数据迁移至hive或者postgresql库，保证迁移后数据和原库一致。
一句话，数据测试的目的就是保证数据质量。
1.2数据质量
数据质量是一个宽泛的概念，其实可以类比我们所说的软件质量，主要从功能、性能、可靠性等方面考虑。
功能：数据的功能指的输出数据要准确，以业务方要求为准。数据量上不能多也不能少；数值要准确；
性能：当数据量增大或者资源不足时，数据是否还能及时输出；
可靠性：当数据产出过程中某个环节出问题时，数据是否还能输出，例如上游数据未定时给出，如果依赖设置有问题就会导致数据产不出来。
2.数据测试该如何测
2.1数据脚本逻辑测试
数据的质量主要从功能、性能和可靠性考虑，而性能和可靠性问题最终导致的是数据功能上的问题，因此我们主要从数据功能性上着手测试数据。
2.1.1 根据输出数据测试
第一种数据测试方法就是直接根据输出数据来测试，其实和传统的接口测试还是很相似的，输入值经过系统得到输出值，最后判断输出值是否符合我们的要求。只是将接口测试的输入字段值变为输入数据，输出值变为输出的数据，最后看输出数据的准确性。
这个方法最关键的是要有输入数据，我们可以根据业务需求构造输入数据，然后拿着开发脚本跑出输出数据。但是当脚本脚本依赖的表数量较多，并且表之间又有数据关联时，输入数据的构造还是挺麻烦的。因此如何快速构造测试数据是这个方法遇到的最大问题。目前，我们因为依赖的表比较多，输入数据的来源不是采用数据构造方法，而是直接根据原表数据快照来验证逻辑；数据快照记录的是某一时刻的数据，因此存在的局限就是会漏掉异常数据的逻辑处理。
那该如何判断输出数据是否准确呢？
- 与参考值做对比
1 . 如果有参考值，那直接检查是否和参考值一致就可以，包括数据量和数据值
2 . 测试人员根据对业务逻辑的理解编写sql脚本，将sql脚本执行结果作为参考值。不管是数据量的测试还是数据值的测试，我们的sql脚本都是一个套路：
假如原表有A，B，C表，开发提供的输出表为D，测试人员通过编写sql处理A，B，C表得到E表后，我们可以采取以下sql得到不一致的数据
select *from E left join D on E.主键=D.主键 where E.字段 is not null and D.字段 is null or E.字段 <> D.字段；
然后再去原表分析为啥不一致，是开发脚本逻辑上的问题还是抽数时间导致的。
所以这种测试方法关键是测试sql脚本的编写，对测试人员的sql能力和业务能力要求都是很高的。
- 从业务角度测试
对数值进行基本的检查，是否在业务要求的数值范围内，比如某个值在100左右浮动，突然这个值变得很大，那应该是某个环节出问题了；还有就是是否符合业务计算公式，比如资产是否等于负债加所有者权益 - 从不同数据源或者不同系统
1 .不同数据源：由于一些不可避免的因素，不同数据源得到的同一个业务字段的值会不一样，但是差异不会很大，因此可以通过不同数据源的结果对比测试，如果在差异不在接受范围内，那数据就是异常。
2.不同系统：同一个数据源的数据，可能会推送到不同系统，我们可以拿其他系统出来的数据做比较。例如最近在测的一个数据表，数据来源于上游系统A，而A每天也会将数据推给第三方系统B，那我们测的表的数据应该和A、B都能核对上。 - code review，直接看开发的代码
1.取的字段是否是业务要求的
2.是否需要去重
3.对异常数据是否有特殊处理
4.关联表的时候用inner join，还是left join，主表选择是否有问题
5.过滤条件是否正确
3.测试过程中遇到的问题
3.1 问题
- 如果采用测试数据构造的方法，当依赖表数量很多时，输入数据不能快速构造
- 如果采用数据快照作为输入数据（比如某一天的数据），数据具有局限性，异常情况会遗漏测试；另外，线上生产环境本身稳定性等根本问题（比如上游数据出问题），仍然不能保证后续线上就没有问题，因此还需线上持续观察测试。
3.2如何解决
- 问题一：暂时还未解决
- 问题二：我们的数据上线已经一段时间，算比较稳定，但是有时候上游出了点问题就会导致数据异常，如果没有人及时发现，那就需要消耗大量资源去修复很多天的数据，因此我做了一个能线上监控脚本（通过不同数据源上数值总额比较）每天去跑，如果差额比较大就自动钉钉发告警。
以上都是自己在测的时候的一些感悟，还不够透彻，等我再沉淀一些经验之后再来更新。
附上我觉得写的很好的一个链接：https://blog.csdn.net/b0Q8cpra539haFS7/article/details/97842555
