你说的也没错吧，你会遇到这样或者那样的公司。针对你说的这种，我的建议是开摆啊，或者自己走人啊，这个自己衡量了。如果你是测试的话，最烦的是测试这句我理解是你的测试工作做的太好，对他们提出了很多的 bug，或者流程提出了很多问题，那说明你的质量管控工作做的好，那是公司或者你的领导不识货呗，不用置气，直接开摆或者换啊，你的人生你自己做主哟。

当然，也可能是你的工作做的不是他们想要的，这个跟测试还是开发还是产品没有关系了，这是单纯烦你这个人，这个要自己区别一下。

总结;如果你感受到的烦是针对整个测试组，那你趁早走人；如果只是针对你，那你自己可能需要再判定下是你太积极太优秀还是你太菜。不知道这样说在不在点子上

感谢大佬补充这块的内容

大佬方便在文章中，简单描述下这个平台可干啥吗，或者说 满足哪些自动化测试场景吗？

如果测试时间可以被压缩，说明本身这个管理层对测试的认知无非就是 “点点点” 了，我的建议是直接开摆，你的后果无非就是换一家，有啥呢！

因为你呗压缩了 1 次，2 次、3 次，这个之前的债原来越多，甚至觉得测试本来就不需要那么多时间。我觉得要反向思考一下，为什么不可以考虑不上某些不成熟的项目。

补充下这种问题明显是管理问题，只是个人一次，那就是列好各方责任就跟文章说的一样，但是常态化就算了。

我随便补充几个场景吧：
1.偏用例设计的：信用卡的数量、使用顺序，是不是还要考虑：0 张？N 张？（比如默认招行，OK，如果招行的被关了，或者接口异常，系统要如何处理），整个接口那边的计算逻辑可能都要考虑下改动大不大，比如应收和实收之类。
2.如果是场景思维：如果把这个算法展示给客户，对的，产品是这么要求的，但是要说明为什么，或者是不是有更好的方案，如果你的目的是想说让客户多往余额里存钱，那就要让更多的客户通过这个设计来更多的存入余额，而不止是说算好这个优惠吧。可能开发也实现了这个功能，逻辑也对了，但是并没有很多人来使用余额，那这时候这个功能设计是不是就不够完善了。
3.我个人认为功能测试从需求分析开始介入，从用例设计可能就有点晚，这是我理解的功能测试人的价值，不是针对那个怎么设计 3% 优惠计算对不对的问题。总的来说就是确保产品出去是有意义的、程序正确的、业务闭环的、还有用户体验。