根据需要来。你说了算

固定参数固定的返回值可以全部效验，较为灵活的就效验固定的例如 code 码，全部效验比较稳当，但维护成本较高

全校验的校验优点：结果校验更精确
缺点：太精确了，有些字段如果是动态的用例会不稳定
折中方案：全校验 + 自定义排除动态字段

注意降噪噢

这个也是一直困扰的问题。。。

这个问题的本质是在讨论接口自动化的精度问题。个人理解接口自动化本质是一种回归/冒烟测试，检验每个字段应该功能测试阶段保证。而回归测试的 crae，应尽可能覆盖多的测试点。因此接口自动化，检验两三个关键字段即可。

以我之经验，接口自动化的稳定性和全面性需要做一个折衷，往往校验的越精确，稳定性也会相应地有所下降（环境、数据、场景不同而定）在项目中我则遵循以下的一些规则

1、多系统依赖的核心接口需要校验返回结构，值范围区间、核心值等，在持续回归中，可以接口变更可以第一时间知晓
2、功能测试阶段应尝试覆盖更多的场景，不仅需要对返回结果进行校验，还要对涉及的资源进行校验（db/cache）等
3、回归测试阶段则从功能用例 case 抽取核心逻辑、业务组成执行集可保证很好的收益