+ 首页>>技能>>内容

技能[我做大数据QA]数据抽取部分QA实践分享一 陶醉测者系列323次围观

[我做大数据QA]数据抽取部分QA实践分享一 陶醉测者系列

背景

上一篇简单介绍了一下笔者接触的数据ETL环节的概念及一些可能的测试场景,再次强调一下,数据挖掘部分笔者并不接触,关于这一块的测试不知道是否有同行在做,感觉一直很好奇这一块的测试实践是如何开展的,如果遇到爱分享的大侠,不妨也能开版分享一下,DiggerPlus欢迎原创分享。今天将根据上回中介绍到E部分的测试场景,拿出一些实例和我自己做的小工具给各位,由于后台数据部分的测试其实特殊性比较强,所以有时候我们经常在不断的改工具做工具或者写一些小程序(后续考虑单独开一个GitHub给大家一起分享,同样需要贡献者的加入),在针对于RobotFramework的测试库的封装的过程中,我们只能就目前可能的需求做了封装,实际上这将是一个持续的过程,当然不是什么东西我都能拿出来分享,涉及到个别业务信息的地方,笔者的确无法分享。请各位测友见谅(我担心哪天我们公司的XX发现我在这里show了不该show的东西,结果大家懂的~)

实战

是否需要抽取的数据被完整的从源端抽取到?

例举项目

举一个相对简单的实例,数据源头和数据目标都为DB的Table

[我做大数据QA]数据抽取部分QA实践分享一 陶醉测者系列

测试分析:

  1. 源表中,我们只需要IdentifierType为1,2,4,5,6的数据。
  2. 我们这些数据有一个叫SecId的东西用于唯一标识我们的数据,那么我们需要发散一下,在不了解开发究竟是如何处理他们的抽取逻辑的前提下,作为QA我们应该要意识到我们不需要SecId为null的情况的数据被copy过来,这种数据一旦被复制过来,将是一种“垃圾”数据;实际上null值的处理是数据测试中经常要考虑的测试点。
  3. 还需要注意什么呢?那就是首先必须要确保在测试时,上下关系table必须是“静止”状态,也就是说不应该有实时的数据处理流程对待测试表进行处理以此来避免不必要的干扰,这点在测试环境中是可以人为做到的。
  4. 有了上面的关注后,我们再发散一下,这个时候您可能就会想到去看看table的隔离机制的设置情况了,因此在我们的DBA团队创建这些表的时候,隔离机制的设置是否合理,是否能做到“锁表”也是我们QA需要关注的。

OK,截图为一个我们针对于此测试需求而利用RobotFramework的测试用例脚本,利用的是RF的RIDE的脚本编写环境

[我做大数据QA]数据抽取部分QA实践分享一 陶醉测者系列

说明一下:以上测试用例的关键字是笔者用JAVA自己封装的,其实细心的测友会发现,类似于这种DB Table中的E部分的测试,关键在于SQL的语句实现,那么自动化测试部分其实需要实现一个自动连接数据库并且执行语句的方法,在此我使用的是JDBC去操作数据库,当然为了更好的管理连接资源,我采用了Hibernate中使用的第三方DB Pool帮我托管连接和session–c3p0,下面分享一个我自己做的数据库操作相关的RobotFramework的关键字封装源码–Github源码,关于RobotFramework,请前往– http://robotframework.org/

抽取过程中是否不会破坏到原数据生态环境,对数据隔离机制的检测?

关于数据库隔离机制的检测,以下视图为我们的一个相关case,我们通过JDBC获取被测数据库的隔离级别(JDBC能够获得4种隔离机制,具体请参看 http://wenku.baidu.com/link?url=wvlf1GWunkuUkLnd60yuBI2-HGUbOm-XdsrJD3j_Cq-ZFEkYe1og54hptTEgGcWV7-chuZApto7RNedEvz6ghgXPUn7eRXwb4SBynCXdRNe),我们的DBA团队的标准是必须被设置成READ_COMMITED的级别,也就是说在SELECT的时候,只会SELECT到已经COMMIT过的数据,这样就会避免数据脏读的危险,也就是说,当有些table的数据正在被某些程序进行修改数据的时候,只要没有最终的COMMIT,则SELECT不会选择到这些正在被处理的数据,造成数据的脏读取和“假象”数据的抽取。

[我做大数据QA]数据抽取部分QA实践分享一 陶醉测者系列

抽取过程中是否对被抽取数据造成了破坏?

例举项目

下面的截图是我们从开发那里获取的数据抽取SQL的一部分,圈定的部分代表开发对于相关业务列的数据调整和Null值处理:

[我做大数据QA]数据抽取部分QA实践分享一 陶醉测者系列

 测试分析:

  1. 实际上被测数据所在的表共有40多列数据,通过review开发的SQL并且根据相关的业务参考文档,QA人员应该意识到仅有13列数据被处理到,因此仅对于该数据抽取流程抽取到的数据放到目标表时,其他相关列不应该受到影响,且如果以非受影响列作为where子条件不应该有任何结果被搜索到。

以其中一个case为例,同样使用RobotFramework的自动化测试脚本为例,MEXCODE作为条件搜索出来的数据记录应该为0,截图见下:

[我做大数据QA]数据抽取部分QA实践分享一 陶醉测者系列

抽取过程是否夹杂了不需要的数据?

例举项目:

项目业务方规定,当我们从VendorId=106的数据供应商获取数据时,我们只需要交易所信息为伦敦交易所(EX$$$$XLON)的数据。

 测试分析:

  1. 针对此类测试场景,需要知道前置条件是什么?比如此例,我们需要熟知业务方的需求,规则只发生在供应商为106的原始数据素材,其次需求方只期望要伦敦交易所的数据。
  2. 通过分析,QA人员只需要写一个简单的SQL验证脚本在数据抽取后的目标临时缓存Table中进行验证,来检查开发的抽取程序是否是符合业务方需求的。

以一个实际的case为例,截图见下:

[我做大数据QA]数据抽取部分QA实践分享一 陶醉测者系列

数据的抽取过程是否具备一定的防误机制?

实际上,这一部分涉及到QA的实践方面并不多,因为是属于我们发布条件的检查,也就是说QA人员会联合其他产品相关人员,一起检视我们的程序是否有灾难恢复,或者数据回滚方案,在我们公司内部称之为roll back plan,这些东西的完善将作为我们QA Sign Off的base line,如果没有类似的准备环节的加入,QA人员有权拒绝版本发布。

总结:

OK,笔者带着各位耐心的测友回顾一下上面的例子,首先不得不说这些例子显得有点业务化,没错,数据方面的测试场景的确是和业务紧密相连的,我不能说我的这些例子代表了所有情况,但是便于大家理解ETL中E部分的QA实战,我贴出一些实际的简单例子来展开介绍,在实际的QA任务中,场景将会是很多的,比如我们的数据源头可不一定都是数据库相关的东西,这种抽取测试如何QA验证?我只能说,兵来将挡,水来土掩。提升自己的能力,开拓自己的视野,任何测试都是能够想办法解决的,当然我这里没有列出我们关于E部分的性能测试,因为这部分是跨团队的合作实现的,我们QA Engineer Team通过借助系统的日志和Splunk平台,包括Informatica的Monitor来对性能数据进行综合的采样,下面是一个Informatica的Monitor截图:

[我做大数据QA]数据抽取部分QA实践分享一 陶醉测者系列

实际上如果仅是通过一个博文就能把ETL数据抽取部分的场景全部列举出来是几乎不可能的,在这里还是给各位测友一些直观的认识,并谈谈我们的做法,当然还是期望有同行能够分享你们的做法,多多交流,笔者在这里等待更多同行的出现。

+ 猜你喜欢...

===== 关于 DiggerPlus =====
DiggerPlus是国内新锐测试人垂直内容博客,专注于挖掘测试工具,普及测试技术,专注于测试人能力提升,博客上线后就受到广大测试人的热烈追捧;此外,DiggerPlus深度整合评测资源,揭秘科技数据和真相,让读者更懂科技,更好地把玩科技。 我们始终保持"独立,客观,严谨,优秀"的优良作风,努力为读者带来源源不断的优质内容。想访问更多酷毙的测试人网站?赶紧来DiggerPlus测试人网址导航看看吧!

===== DiggerPlus Team =====
DiggerPlus Team是DiggerPlus官方发起的团队,这是一群热爱科技,热爱测试,喜欢深度挖掘的热血测试人,他们是评测师,测试专家。 我们欢迎优秀的测试人加入DiggerPlus Team。 加入DiggerPlus,可以成为我们的认证Dper,认证Dper拥有DiggerPlus独一无二的专栏并得到个人展示。

===== DiggerPlus 官方读者群 =====
DiggerPlus官方读者群(一)

+ 关于本文作者

Python/C/C++/Javascript程序员,持续学习者,目前专注于前端开发。

的专栏 | 专栏作者 | 访问小A的主页

+ 已有4个评论

开源中国精彩推送

基于开源中国OpenAPI开发
  • Copyright © 2014 DiggerPlus. 96 queries in 1.198 seconds.
    使用合作网站账号快速登录,更多精彩等着您: 开源中国