还是要具体问题具体分析，有一些没什么逻辑的接口可以这样去实现，
大部分接口是有业务逻辑的，涉及到上下文接口，这些造数如果全是这样跑出来，应该是不能用的，这样的话前后端联调就没有必要了，
然后为了实现这个独特的逻辑，你需要再花数倍的时间实现这个通用逻辑，然后又遇到另一种不同类型的接口...
如果遇到一些后台全局配置类的接口，那就会更加糟糕
我是没想到什么好办法，希望楼主有所突破吧

最重要的时区测试没提到，比如中国【东八区】是 3:00，英国【0 时区】，那么切换至英国应该是 3-8=19:00

改接口几种情况：
1.加必传参数，自动化脚本构建的报错就知道了
2.删除无用参数，脚本跑不出来，你多传了也不影响，不影响业务
3.逻辑变更，脚本报错 -> 排查问题 -> 发现问题 -> 修复脚本

轮询，加一个轮询阈值

我的建议是重测一遍，不能保证质量的情况下，只能依赖自己（甲方测试）。外包可以视为保底测试，然后在适当时机把自己（甲方测试）发现的问题同步给外包测试，修复完毕后要求重测；多次发现重大问题的，可以把压力给到他们

小丑是主动小丑，牛马是被动牛马，没办法决定自己不是牛马

你说的大类确实可以，提到点上了

感觉这样比较接地气，其实每种都不太一样，按大类分感觉描述不到

补充 2 种：
16.资讯类
17.CRM（触发线索类）

像宫崎英高的作品碎片化支线，很多判断没走到直接触发不了，看攻略十几个小时才能做一个支线的，这种感觉很难测啊