现在做大数据的测试的人群还是比较少一些，属于较小众的职位。 主要是因为之前测试人员都不具备相应的技术能力，并且大数据的测试场景确实不好测。 所以一般公司都是主要由研发自己来保证这部分的质量， 测试人员就在 UI 上测个皮儿的现状。 但是现在行业里对测试人员看法的转变，以及大家的技术能力越来越高的趋势 已经开始改变这个现状了。 我看不少公司的 JD 里已经要求 QA 有大数据技术栈的能力了， 同行们也都开始在讨论怎么测试大数据的场景了。 尤其是近些年软件架构的变化和互联网数据量的暴增，AI 火了也是变相的带动了大数据的发展（AI 离不开大数据）， 所以我相信会有越来越多的大数据测试岗位的， 而且待遇都不错， 从现在看我沟通的一些要求大数据技术栈的职位，薪资都不低。

你要是想学习的话， 自己搭个 hadoop， 用 spark 或者 flink 去写一些大数据的任务， 先学会大数据的一些基本开发的技能， 了解大数据生态是怎么运作的。 后面要针对这个生态里各个环节的点进行开发上的学习。 包括批处理场景，流计算场景， 流计算场景中还设计到了各个中间件， 比如 kafka。 再然后就是要学习这些东西的一些底层原理。 比如什么是数据倾斜， checkpoint 是怎么回事， 窗口是用来处理什么场景的， 数据一致性要怎么保证，精准一次性语义又是什么等等。 大数据测试的特点就是没有大数据开发能力的话就基本上没办法测， 因为它大部分的业务逻辑都在底层， 这也是为什么以前都是研发自己来保证的原因， 毕竟测试人员很少有具备这种能力的人出现。

真是巧了， 我们的 cdh 集群的命名跟你截图的一样。。。。 还有 kafka 不是有 java，python，golang 的客户端么，你需要的不是这个么？

你这个语气，观点还有行文习惯， 我差不多能猜到你是谁了。你还是这么狂妄的认为天下你最强其他人都是小白。 而既然你已经开始人身攻击直接说大家都是小白了， 那我也就不打算回应你了。 只盼你这个唯一不是 “小白” 的大高手有空能开始写点干货文章， 别在我帖子下刷存在感了 ， 88.

就 postman 最友好了吧

虽然吧我没觉得我做的东西有多高大上，我说受众小不代表高大上， 只是做这个领域的人少。 但你要说这些东西只是对小白来说是故弄玄虚，随便做过几年测试就很 接地气。 你这不是骂人呢么， 合着你觉得社区里这么多人都是没几年经验的小白， 只有你是 做过几年测试的。 你想贬低我 + 抬高自己，我能理解，但能别捎带着别人么。

我是不是该考虑考虑写点接地气的了， 老写大数据，k8s，混沌工程的是不是受众太小了，毕竟搞的人不多。

加油

建议楼主学学 markdown。。。。。。 这个排版是在让人没有仔细看的欲望

我现在快 1 年没碰 UI 自动化了， 好多我自己都忘了~~
第一点那个如果是返回的当前 page 类的话， 返回 this 就行， 我 new 了一个 page 可能是返回的别的 page 吧。 或者是我当时忘了返回 this 了。
第二点是我其实真的是一开始写 UI 自动化的时候就设计了这些设计模式了， 是因为我在以前做项目的时候有了经验了， 所以做新的项目就上来就按以前的经验搞了。
第三点我是真的忘了咋回事了。。。我都不知道我开源过一个 UI 自动化框架。。。我甚至不知道我自己有微信公众号。。。。 你确定是我开源的？

我的点其实不是说哪个岗位有重复劳动。。。。 我其实是想说任何东西都是一开始学的时候新鲜， 等学会了就都变成重复劳动了。 大家要习惯这一点， 不是永远都有新的挑战迎接你。 平平淡淡才是日常。 当然了还是要积极的去发掘新的挑战来避免这种情况， 只是我们在心里预期上别觉得永远有新东西做是常态就好了。

楼主想多了， 测开也会有重复工作， 比如开发一个测试平台， 可能就是刚学 django 和 vue 的时候新鲜点， 到后面都是 curd， 这就是另一个形式的重复劳动而已。 测开的蛋糕也就那么多， 各种场景的测试工具你都开发完一遍以后， 你就会发现干啥都是重复劳动。 除非是找个新的场景，新的挑战。

测试开发干的主要不就是提升效率么？ 难道在其他地方不是这个定义？

这个问题怎么说呢， 不管在哪个领域都是必然的发展路线。 任何领域内都是先不计成本的把事给做出来， 然后是再绞尽脑汁的把成本降低到普通人也能做的程度。 这是科技进步的直接结果， 就好像我小时候谁家要是有个大哥大那就牛逼坏了， 那玩意当年贵的要死，是有钱人才能用的东西。 然后你看现在基本上人手一台智能机了吧。 这是在任何领域都无法避免的， 不说测试领域， 就说研发领域也一样的， 10 年前想写个 web 项目是很难的， 光前端你要精通各种原生 js，css，html。 现在 3 大框架出现 + 开源组件库， 基本是个能写代码的就能开发出来一个比较精美的网站了。 技术在一步步进步， 就像已经有了 mysql 为什么还需要 MongoDB？ 已经有了 msapreduce 为什么还要 spark， 有了 spark 为什么还出现一个 flink？ 再比如已经有物理机了为什么要搞出一个虚拟机出来， 有了虚拟机了为什么还要搞出个 openstack， 有了 openstack 为什么还有开发 docker，有了 docker 为什么还要开发 k8s？ 技术的进步是阻止不了的， 而技术进步带来的必然结果，就势必是在各方面降低门槛。

所以这是必然的， 阻止也阻止不了的趋势。 我们能做的就是站在巨人的肩膀上，继续让技术进步，去开发更好的东西出来。

不论在任何地方，只要它已经没有可以让你进步的空间了， 你都该考虑考虑是不是要离开。

测试一下

已更新

如果你不排斥在研发的 repo 里以写 UT 的形式去做集成测试的话， 可以去测一测 UDF， 我们这边开发了有百余个 UDF， 大多都是 QA 来负责编写测试用例的。 UDF 测试完可以测 stream， 都是属于深入研发的代码中进行测试的手段了， 目前这是我们这边主要的功能测试方法了， 我下一篇文章里会写。

这个文章我还没写完， 后面会写一些功能测试的东西， 现在这一个主要还是讲一致性。 我是不建议自己写 spark 或者 flink 把产品功能开发一遍再跟研发对比的， 还是使用你后面说的自造数据， 验证数据计算的结果是否是正确的。 至于你说的面对复杂业务时该怎么办， 我认为是没有捷径的， 你只能去了解这个复杂的业务然后根据业务需求造数据， 再验证计算结果。

当然你也可以看一个叫做 flink-spector 的东西。 专门给 flink 做测试的框架， 需要在研发的 repo 里用 unit test 的形式编写

就是针对端到端的每个点都注入故障么， 比如我输入的数据和预期的数据计算的结果都已经固定到 case 中了， 那么就循环跑这些 case， 在跑 case 的同时， 挨个的去给每一个端注入故障， 最后验证 case 不失败就行了。

有点没太 get 到你的点， 你应该是研发同学吧？ Flink 有个单测框架你可以试试看行不行~ 其他的我看你的描述里也有往数据源 push 数据然后验证计算出的结果是不是对的。 你也说了你会模拟异常场景， 我理解的就是注入故障吧。

保存中间值的这个操作说的是 save point 吧， 这个就是 flink 的命令行工具， 一般为了保护正在计算的数据， 都避免不了吧。 不过理论上应该能自动化， 只是我也没操作过， 毕竟我不是运维

应该挺不错的吧， 很多大厂的 JD 里都开始出现有要大数据技术栈的技术需求了。 能面上一般都是差不多 p7 的级别了

原来如此。。。八股文就是各种概念理论

顺便弱弱的问一句。。。。八股文是个啥。。。。

企业文化的问题吧，有些公司面试就比较注重考核算法。 换下一家面吧， 还是有很多地方不会拿 leetcode 难为人的。 再一个就是尽量找贴合自己经历的团队进行面试吧， 这样你们的技术栈类似， 能避免面试官不懂你做的东西的窘境。 我做面试官的时候也遇见过做硬件或者做音频视频测试的候选人， 我就基本什么都问不出来， 直接跟 hr 商量换人来做面试官了。