+ 首页>>技能>>内容

技能[我做大数据QA]ETL介绍及一些测试场景的总结373次围观

ETL介绍及一些测试场景的总结

[我做大数据QA]ETL介绍及一些测试场景的总结

预备知识小结

数据流

做为数据类系统的QA人员,读懂Data Flow是一个必备的要求,数据流程是我们在宏观上把握数据来龙去脉的方式。

我们在做数据时应用到的相关系统

在此之前,请各位读者把一个做后台大数据的环节想象成一个工厂,数据作为我们的原材料,从采集,到加工,然后出品,这一系列环节都类同于工厂的生产流程。

数据采集系统 — 我们公司会通过各种渠道,从第三方购买到一些数据原始素材,这些数据提供商我们称之为Vendor

数据预处理系统 — 进来的数据会通过此系统做一些初级的处理,比如:因为合同原则,一些敏感信息我们是不具备发布权的,那么我们会对敏感信息做屏蔽移除的处理;还比如凡是进入到我们公司内部的数据,我们需要给这些数据做标识来提供内部的Key值,这也是预处理的一部分。

数据深加工系统(笔者所在的部门的主要负责系统)— 预处理后,我们会根据各方的业务需求,对数据进行一系列的深层次加工,如数据的筛选,数据的格式转换,数据的组装,数据的计算等。

数据输出系统 — 当数据被处理完成后,我们会根据用户的要求(对于我们而言,用户包括:内部的前端产品组,外部的数据需求方等等),以不同形式将数据提供给用户。

注意: 其实在每个环节中,我们都有不同形式的存储环节,在笔者的公司里,常见的数据存储有:传统的数据库(关系型数据库,或者No SQL类数据库),File System,数据缓存器 , 数据仓库,Data API(Web service Interface)等等

下面在不涉及敏感信息的前提下,贴一个我们的一个Data Flow Pic在这里,给大家一点稍微直观的感受,我做了简单的标注

[我做大数据QA]ETL介绍及一些测试场景的总结

ETL是什么?

ETL:代表的是数据处理的三个环节。

E(Extract):数据抽取(数据从哪里来?)

T(Transformation):数据转换加工清洗(数据应该被加工成什么样子?)

L(Load): 装载(数据到哪里去?)

和网上已有的其他博文不同,在这里我认为其实关于ETL的概念并不值得深究,那么更多的概念就没有必要过多的在这里展开了,其实也没有什么特殊的概念在这里,ETL仅代表数据在加工的过程中经历的三个环节,而且ETL的组合可以是多样的,比如可以有:TETL,EL,TLETL… …组合根据需要千变万化,在这里我隆重推出一个商业ETL工具给各位认识一下,针对于ETL的流程,笔者所在的公司正在使用一个商业的ETL开发工具—Informatica,给各位一个链接,百度百科的简单介绍:  http://baike.baidu.com/view/2109992.htm?fr=aladdin#1

下面给各位show一下Informatica的Designer的截图,从视觉上直观感受一下:

[我做大数据QA]ETL介绍及一些测试场景的总结

工具的截图展示的是一个Informatica的Designer中的Mapping设计环节,此套工具有独立的服务端,常用的数据集成,尤其是ETL环节中可能用到的功能全部做成了组件化,减少了开发的coding量,提高开发效率,可视化的设计界面,截图仅是一个客户端的示例,Informatica主要包括四大客户端套件,Repository,Designer,WorkFlow,Monitor,并且支持内嵌JAVA代码来拓展特殊的需要,非常强大的一款商业ETL专业工具类软件,当然价格也不菲,如果您感兴趣,不妨也可以在网上搜索一下各数据解决方案厂商的ETL工具测试比对和评测结果。

针对于ELT环节,我们常见的测试场景及相应的测试点有哪些?

下面我将通过ETL的三个环节来分别简单直观的介绍一些我么在测试中关注的部分。

E部分 — 数据抽取环节中的常见测试点

  • 是否需要抽取的数据被完整的从源端抽取到?
  • 抽取过程中是否不会破坏源数据端的“生态环境”? 如一些数据保护和隔离机制的检测,这样也可以避免数据的“脏”抽取
  • 抽取过程中是否对被抽取数据造成了破坏? 如小数点精度的暴力调整,数据的强制切片等。
  • 抽取过程中是否同时夹杂了不需要的数据? 如过滤逻辑设计不当而造成的数据污染。
  • 抽取过程是否具备一定的防务机制?如在异常情况下,程序是否支持数据的回滚机制。
  • 抽取过程需要考虑一定的性能开销问题,这一块谈不上是真正的在做性能测试,而是根据实际环境下的性能相关的统计信息,给相关人员作为参考数值,来决定是否需要优化和改善数据抽取方案(常见数据统计包括:处理了多少数量级的数据,单位时间处理量,数据处理复杂度,从处理到通知相关流程的总耗时,相关环节的网络情况,相关系统所在的设备的配置,CPU消耗,内存消耗等)。

T(业务体现最强的部分)部分 — 数据转换环节的常见测试点

非计算类数据转换 — 我们的开发会根据业务方的需求,有针对性的对数据做出相应的加工,这里不一一列出究竟有多少种可能的数据转换方式,以后将会以一些实例分享一下我们的测试方式,常见的数据转换模式及相关测试代码的实现。

计算类数据 — 目前我们是利用Excel的公式,由我们的投资分析团队(因为对于我们而言,这些人才是最专业的,让专业的人做专业事),根据产品及公司的计算方式,将计算模板化(由于涉及到敏感信息,在此不能贴出公司的一些数据点的算法公式,请各位读者谅解),我们QA人员将利用这些模板作为我们的计算器,我们只负责实现数据的自动化IO,通过Excel公式的计算结果去比对开发无论是用代码还是借助数据库等一些内置数学函数的实现。这里插个题外话,我们不建议相关QA人员自己去实现一套算法,比如大家可能都知道每种语言其实都有一套完善的Math类库,但是并不代表你也要去自己实现一套去验收开发的成果,一个很简单的理由就是:凭什么QA做的算法程序是对的?

L部分 — 数据装载部分的常见测试点

这个地方其实是非常类似E部分的用例场景的,在此不再一一赘述。

Ok,笔者大致总结下我们的一些测试核心思想和原则,仅供参考,不代表我们的是对的,更不代表我们做的是专业的,更期待同行能够不吝赐教:

  • 如开版中谈到的,对于数据的把控上是很难做到面面俱到的,那么一个原则就是尽可能的多抽样,并且选择生产环境中的数据做到大量的数据的QA检查。
  • 数据测试其实分为宏观和微观两部分,冒烟测试我们多采用宏观方式,也就是对数据总量的统计或借助数据处理系统相关的日志来快速做出测试判断(再插一个题外话,也许大家很熟悉开源免费的CI-Jenkins,也许我们作为测试用的最多的其实是把它作为一个计划任务调度器来使用,我们公司的部署程序调度平台用的是商业级专业复杂逻辑程序调度平台Control-M,并且在很多个小环节中,我们也会应用到一些负载均衡器来实现资源的最大化应用优化局部的调度性能,同时我们使用一套数据采集系统,主要采集相关系统日志-Splunk,实际QA的活动中,我们会借助Splunk来做一些监控程序),并且将这种检测常态化,同开发的单测一起,协作测试;微观部分是针对于每一个细微的小业务需求,无论是抽样实体数据检测,还是人造数据追踪(其实写过长SQL的开发人员也许能体会一件事情,尽管开发人员已经很注意将自己的SQL逻辑简化,并且片段化,但是SQL语言的Debug一直是一个小困难,那么唯一的排错方式就是借助数据来以一种黑盒的思路去检验,这也是数据QA能够发挥的地方)
  • 数据类QA的回归测试:由于我们是采用Agile模式运作项目的,那么在每一个Story中,我们都会有相关的自动化测试用例,并且我们非常鼓励大家优先用自动化的方式去实现测试而不是手工,那么这些已有的用例自然成为了回归测试用例的一种;如果发现了一些问题,主要只一些Data Issue(坏数据),我们会专门增加检查这些坏数据的情况作为回归测试的一种;从策略上考虑,我们会根据数据质量的容忍度,选择Top 100的数据点作为回归的必要用例(比如Microsoft,IBM,Apple,HP等公司股价及收益率或者其他的一些投资银行的数据是容不得有错误的)
  • 全量检测其实是非常的消耗性能和时间的行为(但是是否需要做也要看各方的意见来定夺),因此我们的一些测试比对工具会考虑使用多线程,和借助数据库来做全量的比对,写过代码的人都知道,其实应用高级语言去完成的程序做这种数据比较实际上是把源数据Load到运行程序的机器的内存中进行的,那么内存的消耗也是必须要考虑到的实际问题,特别是笔者一般是用JAVA做这种比对工具,JAVA在性能上的软肋一直是一个头疼的问题,有时候被开发建议让我用C#做工具,C/C++对于测试而言又显的难度大了一些,而且开发效率不高。另外一种方式,就是我们把性能开销和优化交给数据库,如我们会把待测试的数据全部Load到QA用的Table中,这个时候我们QA工程师实际需要完成的就是一个数据导入工具(有现成的,当然也有些特殊需求需要自己做工具),然后通过写SQL及应用一些现成的数据库内置方法来做数据的QA检测,这些实战的分享将会在后续环节中为大家介绍到。
  • 测试策略的清晰,有时候做测试同样需要考虑市场,为什么这么说呢?在时间紧张的前提下,身为测试,其实我们是需要知道到底哪些客户我们是“得罪”不起的,那么在抽样和测试重点的倾向上就做好平衡。
  • 作为数据类QA,一定要警醒自己要不断的提升自己的技术能力,尤其是快速的工具开发能力,请注意,数据QA不需要只懂业务的人,这种人职业生命不会长久。
  • 我们也需要自动化测试框架,目的是统一大家的做事风格,将经验总结通过框架的封装过程来延展下去,并且可以在这个过程中提升团队的技能水平,目前正在努力尝试利用RobotFramework(Python实现的基于关键字驱动理念,并且支持BDD模式的测试框架)进行测试的实践,未来的分享中也会给大家分享一些我们已经有的RF的Test Library的封装源码。实际上在网络上我已经看到了有人说自己有了某某做数据QA的测试框架了,怎么说呢,个人不是很认同那就是框架,首先实际上他们做的东西也只是一个数据比对工具,无非他们都只是借助了UnitTestFramework(有用PhpUnit的,有用JUnit的,有用TestNG的等等)去做用例的管理和执行,因此笔者在此保留意见。其实不仅如此,凡是可以帮助我们实现自动化的方式包括刚才介绍的Informatica ETL开发工具都是我们可以利用到的。想强调一下,如果一个测试工程师的思路或者测试实现方式被限制的话,也是一个头疼的问题,尤其作为我们后台的数据类QA人员,基本就无法发挥出特别好的效果,因为后台测试大家基本都在摸索,没有所谓的成功案例可以效仿,即使是我写这些博文,也仅仅是经验的分享,目的其实是希望有更多的测试人或者同行能够以一种开放的心态,谈谈你们的经验,或者给我们一些建议,有实际分享当然更好,算是抛砖引玉了。
  • 任务调度相应的检查,如每个数据流程的上下游触发关系,这部分作为系统集成的宏观测试部分,我们一般会借助上面提到的Splunk还有Control-M自身的QA可能性功能外,自己也会做一些Monitor类的小程序主动去检查是否消息或者标记数据被成功处理了,这一部分实际上更需要开发,运维,网络,DBA团队的共同配合才行,与其说是一个测试项目,不如说是一个统一协调的事项,而且在做后台类QA的时候,请不要让QA角色独立出来,要具备一种不分角色且大家都能测试的心态去面对质量验收的目标

+ 猜你喜欢...

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

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

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

+ 关于本文作者

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

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

+ 已有8个评论

开源中国精彩推送

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