浅谈大数据测试

调到数据组测试好几个月了,最近看了一篇系统介绍数据测试的文章,看完之后确实有产生一些共鸣,结合自己在数据测试中遇到的问题和思考,谈谈我对数据测试的理解

1.数据测试测的是什么

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

你可能感兴趣的:(浅谈大数据测试)