不杠了， 你高兴就好

你确定现在大厂高 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 也都有对应的数据驱动功能， 你直接用就好了。

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

就比如混沌工程的工具~~ 以前没开发出来之前是手动注入故障， 就是用 k8s 的命令行去杀 pod 或者登陆到容器里面用 iptables 和 tc 命令与模拟断网和延迟的故障。 验证故障影响也是注入故障的同时手动去跑 case，这种就只能测试几个主要的场景。 后面开发工具了以后都是几十个模块的故障注入和累计 1 百多轮测试全自动化搞了。

实际上， 其实我现在一部分工作就是做运维开发。 但是讲道理论天花板和工资， 妥妥的正经八本的企业的后端开发最强， 可以一路做到 CTO 的程度。

小团队没有钱养专职人员，所以我干的活比较杂， 测试和 devops 的活我都干， 除了搞运维开发的东西以外，其实测试工具什么的我也搞了一大堆。

我觉得我们团队的现状算是比较贴近大部分的情况了： 公司小团队也小， 所以没有资本养专职的测开，都得花一部分时间跟业务。 所以我们的做法大家可以借鉴一下， 我们也就是在 16 年的时候吧， 其实根本就没想测开不测开的事， 也没想着开发什么高大上的工具平台。 我们开发的所有工具， 写的自动化代码， 都只有一个目的就是解放我们 QA 的时间， 因为我们那时候就 2 个半 QA 在干活，解决效率问题是第一优先的。 所以我其实当时好大的精力就是在积累 case， 一个 case 一个 case 的写， 功能全回归测试从一周时间缩短到 3 天再到 1 天。 当然我估时的时候肯定不是按一天估的， 我会估个 2，3 天的留做 buff， 如果自动化出了问题 (环境,代码) 那么有 buff 去解决, 如果没出问题那么我就多了 2 天时间做自己要开发的工具。 自动化越给力我自己的时间就越多，然后我才能去开发别的东西。

所以建议大家一开始别纠结测试开发这个 title， 先以解放自己的人力为目的去行动。 不要嫌弃写 UI 自动化，接口自动化 low，因为你不做好这些基础的，你就没时间去做那些高大上的。 连我自己在那 2，3 年时间里的一半精力都在写 UI 自动化这种大家都觉得 low 的东西，甚至今年有一段时间我也在写。 所以心态放平和一些， 先做对自己最有用的再去想其他。

其实就是这样的， 而且自动化本身被发明出来的时候，更多的主要就为了提升效率节省时间的， 我的理念是只有解放了 QA 的时间， QA 才能去思考更多的提升质量的手段。

一开始做自动化就自己的小组用， 只减轻我们自己的压力。 我那段时间忙的要死，哪有闲心去管其他团队的 QA。 这玩意就是别一开始就胃口那么大， 上来就要整合所有团队的。 先把自己的问题解决了再说。

我入职当前公司已经快 5 年时间了， 头 4 年其实都是一边做业务测试， 一边开发工具和写自动化测试的。 这种情况避免不了吧， 对于大部分团队来说还没奢侈到专门能养一批只开发工具不做测试的专职人员。 所以很多人包括我自己都会遇到楼主这种情况， 业务太忙，没有多少时间来做自动化测试和工具开发。

所以我建议楼主跟我当时一样， 就集中加班一段时间， 把自动化测试补上， 这段时间虽然你会很痛苦， 很累。 但是如果熬过去了， 你的自动化测试能节省你很多的时间了。 那么你就进入了良性循环了， 可以有更多的时间去做技术相关的东西， 同时技术相关的东西又给你带来更多的效率提升节省更多的时间。 这样你就越来越有时间去做测试开发的东西。 其实我当时就是这样的。 当然如果你极其的忙，天天忙业务都要加班到很晚，周末也加班，根本没得休息时间。。。。。那当我没说吧。。。。那就没什么办法。。。

我们的业务没有录制回放的需求， 所以没太研究， 你能分享一下么？ PS: 创建这个期望的代码能贴一下么

还有这个坑呢。 我还没碰见

应该是配置错了吧，我这是可以路由的

是这个 mock server 直接具备的功能，不用二次开发， 它启动的时候可以设置 proxy 模式， 填写真实服务的 ip 地址和端口号。 我 go 的代码只是把 mock server 注入到了我们 k8s 集群里了，只做了这一个事而已。

看你的描述我觉得它的能力是符合你的需求的。 不过你们是什么场景需要这个能力的？