+ 首页>>技能>>内容

技能[我做大数据QA]开版–陶醉测者系列142次围观

背景

有人说这是一个大数据的时代,也许真的没错,其实我们的世界是可以用数字来描述的。笔者在一家美资投资资讯公司上班,年纪轻轻便和一群“老人”过着养老的生活,工作中时常充斥着寻找工作与生活的平衡点的言论,更有一些可以不工作(但不代表不会发邮件表现自己)整天考试还能报销的同事在一个屋檐下工作,也许有人羡慕,但是冷暖自知,在写前两篇JAVA CODE科普类的博文的时候,小小地去参加了点NB公司的测试开发工程师的面试,知道自己还没有fully prepared~
AnyWay,今天我们先停一下【测试人也CODE】的部分,我想介绍下我做大数据相关测试的一些点滴,当然会有一些实际的干货东西拿出来分享,干货之前,还是不得不来点概念性的东西来方便可爱的读者们快速进入大数据的测试世界,同时也弥补我的一些遗憾,因为我在工作中想通过无所不能的互联网找到一些和大数据QA相关的分享时,真的是一件难事,概念铺天满地,干货少之又少,不过还是得提一下–百度QA(有一篇他们做数据计算QA的经验分享,有提到他们会封装SQL Procedure来作为计算器去验证开发的各种算法实现) –AliData(不得不感慨一下,Ali在数据这块的投入,尤其他们对于Hadoop的深度认知和应用改造) –其实还有华为,虽然他们在互联网上的分享一直很低调,笔者确实还是得益于一些优秀分享的引路,和团队内的同事一起摸爬滚打的摸索大数据的测试,不一定是对的,也不一定是最优的,只能说我们的团队在利用这些点滴来摸索测试,那么借着这个版块,让我们开始大数据QA的旅程,更期望能够偶遇同行,互相交流… …

大数据测试可能给大家的误区印象

1:是不是一提到大数据测试,就一定要掌握各种算法优化,性能优化的技能和技巧呢?

Answer:当然如果你是这方面的牛人,不一定要做QA了,去做数学建模,系统架构师可能更能发挥你的优势。很显然,我的答案是否定的,为什么这么说,首先数据建模不可能也不应该是由QA人员来做的,QA需要做的就是去了解算法–准确的说是数学公式,然后找一个相对客观的方式去间接验证开发针对于这个数学公式的实现;性能优化方面,我想我们QA更是无能为力,首先有些东西不是我们能做的来的,比如数据库厂商应该是负责数据库性能的最直接的影响因素,我们需要干什么呢?那就是学会好好用他们的东西,事实上绝大多数的性能问题可能真的是因为你压根就不知道如何用它们或者不合理的使用而带来的性能问题。

2:大数据测试很高大上?

Answer:“高大上”?非也,可能因为是陌生,一般未知的东西都显得有些神秘,在其中的人可能并不这么认为,我给大家讲讲我所在的公司曾经做数据QA的行为,如果有人了解一点金融类行业,可能您听说过DA(Data Analyst)这个角色,OK首先不要被Analyst这个词给唬住,再说点现实,大多数的金融专业毕业生去做这份工作可能更多的是在熟悉copy动作和练眼力,很滑稽是吧?!存在即合理,最早的数据类QA工作其实是由他们在主要完成的,换句话说他们也在变相的做手工测试,因为处理数据类的系统有个特点—他们的功能点不是很直观,而是体现在数据的形态上的,也就是说我们是在看数据来评价软件质量的,现在我们作为公司内部的QA Engineer,我们要做的是紧跟开发团队,将DA的手工工作更好的自动化实现(可能我们会更强调开发工具的能力),并且能够解放人力或者无疲劳的验证更多的数据,当然不仅如此~

3:大数据测试一定要自动化?

客观点讲,如果可以,我们期望都能够自动化实现,可能我们在做自动化测试的出发点有别于其他测试对象的自动化初衷—我们做自动化不单纯的是为了提高效率解放人力,事实上很多时候这个不是我们首要关注的,甚至我们压根就不关注这个。

  • 我们做自动化是实现手工几乎无法实现的操作,比如我们有1T的数据量,测试时客户希望我们的质量数据覆盖率达到30%,大家想想这个量其实是不小的,对于数据类型系统而言,处理数据是批量的,但是如果交给人工去检查,除了抽样和追踪人造数据(有时候在生产环境这种行为还被禁止,因为人造数据被认为是一种污染环境的行为)还能怎么做?而且几乎是不可能针对于这个覆盖率全面检查到的,否则真要累的吐血了。
  • 其次我们推行敏捷测试,因此我们期望每个story就有相应的自动化case覆盖到,便于之后的迭代回归,而且我们可以满足经常性测试的原则
  • 数据的趋势和“变异性”有时候是很难把控的,因此这将阻碍我们很好的设计测试用例,因为很多case我们是几乎想不到的,其实客观点说,如果能想到,早就让开发去做special handle了,还等客户发现异常吗?因此,我们只能通过竟可能的全量来达到测试的覆盖率,以避免一些情况的错过

4:做大数据测试是否很需要业务背景?

我觉得呢,这点可能和传统测试相似,业务是能够帮助测试人员很好的理解被处理数据,理解数据系统的业务模块,能够帮助测试人员很好的站在业务角度去设计测试用例,能够很好的帮助测试人员去抽样测试数据的一个基础依据;当然我反对的是一点,我在目前的团队内也很直接的反对过,我不期望有专门的所谓的业务类的测试出现在我们的QA Engineer的团队当中,为什么这么说?如果您认真看了上面的文字,应该还会记得我提到的一类工种—DA,那么我认为这种纯业务性的QA和DA人员完全没有差别,那么为什么还要我们呢?当然一个优秀的测试工程师应该也有义务去了解业务,但没有方向之说,大家怎么看?

我做大数据测试目前遇到的?

在此说明一下,准确的说我主要做的是大数据ETL环节的测试,下一篇我会专门给大家科普一下ETL的概念。

  • 数据的迁移完整度
  • 数据的加工准确性,包括数据的格式变换,数据的计算等等
  • 数据的接口类测试,webservice restfull
  • 各流程之间调度,时效性测试,各消息通知机制的测试,各程序驱动条件的测试等等
  • 性能测试
  • 生产环境中的QA监控工具的开发

如果因为一些特殊原因,可爱的读者懒的看上面的文字,那么这里给几个关键字:

    1 大数据QA不神秘
    2 大数据测试也能做手工测试(行业内称为Data Audit数据审计的方式)
    3 大数据测试对自动化的需求非常强烈,甚至有时候是必须的
    4 优秀的数据QA同样需要有业务知识,但不需要只懂业务的人,因为我们有DA的角色
    5 数据类型软件产品或者系统的功能体现在被处理的数据上,数据作为生产资料,开发负责创造系统来生产和加工这些资料
    6 我只负责大数据ETL的测试

+ 猜你喜欢...

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

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

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

+ 关于本文作者

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

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

+ 已有3个评论

开源中国精彩推送

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