应该挺不错的吧， 很多大厂的 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 上，然后用批处理的方式计算再更新到数据库里。

有个不成熟的想法，你们能不能设置一个非常长的迟到时间， 只要不超过这个时间，数据到来后就会触发算子把最新的数据更新到窗口里进行计算。 这样就可以影响大屏上的计算结果了，当然这也不实时的， 毕竟数据迟到了， 但是可以在后面对计算结果进行重新计算。

我举个例子， 如果是批处理，比如我们的产品中有一个算子是拆分算子， 可以配置不同的参数来把一份数据拆分成 2 份。 比如先排序在拆分这个逻辑就是，先按某个字段排序然后再按比例进行拆分。 这样的话测试的逻辑就比较简单了， 那我们就可以去写一个 spark 脚本， 扫描这两个拆分出来的数据。 验证那个时间字段是否是有序的， 再验证两份数据中的数据行数是否满足算子设置的比例。 这个比较好实现， 一个比较简单的 spark 脚本就可以了。 所以测试方式就是以大数据的方式测试大数据。

那你们实际的业务场景里也不能要求那么高了吧， 应该是设置个迟到事件， 超过 sideOutputLateData 设置，这样迟到的数据应该都不在窗口里处理了。 通过 window.getSideOutput(outputTag) 在流的外面拿到这些迟到事件再做处理。

恩恩，因为是在写 demo 就没顾及那么多。 保序的事能用 kafka 自己机制保证一部分么， 或者你们消息的字段里有能作为 eventtime 的时间字段么， 这样在 flink 里设置一下 watermark 的策略应该就还好吧。 毕竟 flink 是能在一定程度上处理乱序的流的。

多谢~~

测试一下

我们现在有个产品线 UI 自动化已经 2000 多了， 以前手动测试需要跑一周， 有了 UI 自动化后现在一天时间跑完。 你觉得是做 UI 自动化浪费生命还是不做浪费生命呢？

我上面其实提到过的。 原来要 5 天的测试时间， 加入了自动化变成只需要 2 天了， 那你就按 3 天或者 4 天估时。 让大家知道你的自动化有成果就可以了， 你别这么实在的真可丁可卯的估时。 要知道10 分能耐用 8 分， 能耐一下子都用尽了你以后怎么办？

我们的 case 大多数都没加入数据驱动， 也就是你说的参数化。 因为现在业内的单元测试框架中对于并发的支持，最细粒度也是方法级别的，同一个方法中的不同参数是串行的，没办法并行。 一般情况下这是没问题的，并发模式不需要细粒度这种程度， 但是我们的 case 比较特殊，都是大数据和机器学习的训练算子， 一个 case 跑上几十分钟都是有可能的。 所以要是用数据驱动的话，那一组参数都是串行跑就没办法接受了。 所以我只能是放弃数据驱动， 拆成多个方法来提升并发能力了。 这个是我们项目的特殊情况。 对于你说的参数化，我们其实是直接用了 testng 的 dataprovider 来写的小工具完成的。

其实如果你用的是 pytest 那么 pytest 的 parameters 也是可以完成你说的参数化的， java 的 junit 和 testng 也都有对应的数据驱动功能， 你直接用就好了。

我觉得挺好的啊， 我有一部分工作搞这个