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

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

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

轮询，加一个轮询阈值

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

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

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

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

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

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

看了下评论，结合自己的思考，说说自己的看法
自动化测试主要作用有 2 个方面：
1.前端联调之前发现问题，这个我们之前是这样的做的，作用一般
2.回归测试，这个上面有个评论点到了，如果你的脚本的某个接口出现报错，是因为改字段出现的问题，这件事本身已经发现问题了，开发在写代码可能会遗漏一些场景，脚本发现了你再去改这个过程并不是一个无效的事务。功能测试每次回归测试漏跑了根本不知道，也没有数据支撑。
项目重构、合库等等，手工测试的效率的纵向测试面试不足的

查询数据库虽然有效
但不是真实的校验手段，
最终我们对外暴露的是提供给用户的接口，
表里查出来的结果不一定是接口反映的结果，
我觉得接口校验是理想结果，数据库校验是手段

接口校验的原则是不走数据库，为什么呢。因为你可能有测试环境和预发布环境的操作权限，但是线上是一定没有的。所以必须用接口去验接口。所有接口分为 2 类，操作接口和查询接口，查询接口一定是根据操作接口的信息做反馈的。
那么你查询接口的时候与你操作接口的参数不一致怎么办，一般我的做法是拼 json，从所有你能获取的上文中取值拼 json，取值的维度是避免从查询接口取。脚本设计最好是单例模式，这样你的上下文逻辑就非常清晰，还有校验对时间字段不做重点校验，因为操作时间和数据库时间存在一定误差