首先获得这方面的工作机会:
我这个人是主张工作驱动技术成长的类型。选定一个方向,然后拼命的学习这个方向的知识,之后不管是求是骗还是去忽悠都要进入做这个方向的公司去锻炼,任何一公司都需要初级人员来打杂的,我们争的就是这个机会。技能的增长不是一厢情愿的事,我再之前写的一篇文章中写到过。没上过战场的士兵就算在训练中再优秀也是菜鸟。我们需要真正的战场磨炼我们的技能。所以自学到一定程度以后一定要去实际去用,如果你的公司没有这种业务环境,那么就跳槽。这时候别犹豫,你必须要有一个环境来做你想做的事情,如果这个时候拖下去,自学而来的东西会很快的被忘掉,之后你面试的时候可能什么都答不上来了。这时候争的就是一个机会,一个跑到对方公司打杂的机会。
然后想尽所有办法找应用场景:
当有环境以后剩下的就是自我驱动。主动去挖掘我们学到的知识的运用场景。测试应用这边咱们确实空白很多,我几乎找不到多少可以跟我一起聊分布式计算的测试同行。所以自己要善于发现和思考。
大数据方面的实际测试是什么样子的
先举个数据测试的例子,常出现在做BI和机器学习的公司。你可以参考我在测试大会上的演讲稿,这类型的业务每天都会有很大的数据被采集过来,我们需要测试这些数据,由于数据大,对测试速度要求高。所以也必然要使用spark,mr,hbase这些大数据处理框架去扫描数据。这个更详细内容你可以去看我的演讲稿。关于数据统计分析类的工作也跟这个差不多。
![](https://i-blog.csdnimg.cn/blog_migrate/749cb31a3e31dec2d452a93a8e402add.jpeg)
然后是造数, 大数据相关产品,尤其是to b业务的产品要给客户提供一个比较专业的性能测试报告。在各种数据量,数据分布,数据类型下产品的计算性能是什么样的需要有一个量化指标。而客户的数据是不会给你的, 所以我们要开发一个工具能够生成大数据量的,各种不同数据类型,各种不同数据分布的造数工具。还是由于数据量大,同样需要用大数据处理技术去做。我再演讲稿里也有提到过。
再举一个yarn集群管理的例子
一切都始于我们的UI自动化,我们的产品是做机器学习的么,产品要把计算任务放到hadoop集群上运行,而集群是用yarn管理的。当我们case越来越多,我的UI自动化也就必须用分布式的方式来执行(浏览器的分布式属于docker+k8s的范畴这里我不跟你说了,目前我们启动了30个浏览器),当初我们发现在测试集群上15个小任务的并发能力就是极限了,多了就得排队,连20个浏览器的并发都支撑不起来,更不要说集群不只是给自动化测试用的,开发,产品,测试用的集群都是一个。所以对集群的调参是必要的,只是大家都不熟悉,测试环境的事也不爱管,这事就没有人搞。所以我买了hadoop技术内幕中的yarn的那一本开始啃。之后在测试集群上各种折腾,更换公平调度器,重设vcore,提高AM限制, 分队列,分用户,设定资源抢占,队列权重等等等等。一套下来现在集群抗个百十个小任务并发是没问题的。所以这方面的工作又多了一个测试集群管理。
很多建立在大数据基础上的产品都跟hadoop深度耦合,尤其是TO B业务的产品,要测试到hadoop的各种情况。各种hadoop的版本与产品的兼容是不是好的(很多客户有自己的hadoop), 以及hadoop的各种配置是不是与产品兼容的。例如我们曾经出现的问题是在jdk1.8下的hadoop2.7.2版本在我们的产品中会出现虚拟内存计算不正确的情况,而测试集群是开了虚拟内存check的,所以某一个算子运行失败。这是jdk1.8的一个bug,需要我们在该算子的配置中增加内存参数绕过去。再比如hadoop集群的多租户实现,很多地方是用yarn的fair调度器或者capacity调度器中的queue的概念去做,那么产品如何跟hadoop的配置协调? 假如产品提交到错的queue上去了? 假如产品提交到了不存在的queue? 产品使用了hadoop不存在的user?这些东西我们就会要测试到。其实不仅仅是多租户,产品跟hadoop集群耦合的地方都要测试。因为我们是做产品,而不是自家公司自己用,任何与hadoop的配置冲突的地方产品都应该做出相应的处理。
应该还有一些场景,只是我们的业务暂时没碰到,看看之后有没有同学补充一下。
区别大数据测试和运维的角色
别再纠结纯运维和纯测试了,devops流行的今天,开发,运维和测试这三个职位都互相渗透了。互相都干了以前对方的活是很常见的。
总结
建议大家去TO B的公司看看,现在做大数据的还是TO B的比较多。互联网里能接触到这些的公司不多。对于投向这方面的学习我觉得也是不亏的。不论是BI 还是 现在非常火的人工智能。大数据都是基础。这方面的平台和产品也越来越多。而这些行业的测试门槛还都很高,所以如果你再这方面有经验,都不用多厉害,就可以找到一个不错的工作。