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

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

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

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