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

这个问题怎么说呢， 不管在哪个领域都是必然的发展路线。 任何领域内都是先不计成本的把事给做出来， 然后是再绞尽脑汁的把成本降低到普通人也能做的程度。 这是科技进步的直接结果， 就好像我小时候谁家要是有个大哥大那就牛逼坏了， 那玩意当年贵的要死，是有钱人才能用的东西。 然后你看现在基本上人手一台智能机了吧。 这是在任何领域都无法避免的， 不说测试领域， 就说研发领域也一样的， 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 商量换人来做面试官了。

已经过了有信心的阶段，而是到了已经大范围落地并取得了很好的效果的阶段。每个团队都有自己拿手的特长， 在没有了解前不要随意的否定。 在某些公司 UI 自动化没做起来不代表其他地方 UI 自动化也做不起来。 你可以分享一下你们那边 UI 自动化遇到的困难，我们讨论一下是否是某些产品形态或者团队迭代方式不太适合 UI 自动化， 一起总结一下经验。 UI 自动化这个技术发明出来到现在已经 10 多年了，selenium 官方团队到现在也一直迭代更新，就说明他是有使用空间的， 我们别把同行都当傻子，如果 UI 自动化真那么不堪同行们还会傻乎乎的一直在上面使劲么， 老板们会真的人傻钱多的往里投钱么。 官方团队还会坚持开发 10 几年么。

那我们这个业务线自动化覆盖率在 95% 左右， 刚才刚问了一下测试 leader，他的回复是基本都覆盖了， 但是考虑到实际的情况可能不会那么理想，所以我觉得 95% 这个数字比较合理。

你又来杠了，那杠就是你赢，你开心就行。既然跟上次一样一杆子就否定了包括白盒测试在内的各种测试理论。那注定咱俩谁都说服不了谁， 你继续在你的业务上做黑盒测试， 我继续在我的业务上做测试开发， 咱们井水不犯河水， 没必要非争出个子丑寅卯出来。 让时间来证明谁的观点会走的更高更远。 文章和评论也都放在这里，让同行们来自选选择走哪一条路

这个 “x” 是什么情况。。。。

新版本新需求来了的话，就去写新的 case， 没有新需求或者新需求不适合自动化就放那。 自动化覆盖率你指的是哪种统计方式？

检测出来了啊， 凡是被自动化覆盖过的场景， 人工都不在去重新运行了

不杠了， 你高兴就好

你确定现在大厂高 P 测试的面试题简单么。。。。

对于第一个问题是，如果你不了解复杂的业务， 那么给你什么测试工具和测试方法你都是测不了的。
对于第二个问题是，大数据测试就是有门槛的， 不懂大数据还硬要来测本身就是不行的。

最后我感觉你已经钻进牛角尖里了，不想懂业务也不想懂技术就能保证产品质量这事本身就是不可能的。 碰到难点了要去解决难点，而不是通过降低测试人员的责任范围来骗自己。 就像我们招聘一定是招聘懂大数据的测试人员而不是说这个大数据场景我们就测个皮，深入的我们不测了所以就招一些不懂大数据也不懂业务的人来做。

PS： 不要再用 test oracle 这种看上去高大上实际上没什么用的名词了。 老拽这些词本身就会引起他人反感的。

那就只能用 window.getSideOutput(outputTag) 后续把迟到事件都拿到然后再做处理吧，当然就做不到跟窗口里的数据一起计算的能力了。 可以把整体数据保存到 HDFS 上，然后用批处理的方式计算再更新到数据库里。