1、对调用如参数组合进行覆盖，观察数据表读写是都正常（功能验收）
2、尝试输入错误入参数，注入异常，观察数据的一致性和事务的是否正常（异常验收）
3、尝试高频调用，观察 DB 测内存 CPU 开销，及早发现定位性能瓶颈，这样可以为上层调用推荐合理的并发和隔离策略（性能验收）

以我的经验一个自动化测试平台的定位很重要，尤其是你需要 “破局” 的时候。首先，不要大而全，找准自己的定位，然后切进去，比如接口自动化平台最大的收益在于回归、监控、巡检，相比传统的 coding，可维护性高、传承性好，劣势也很明显：编写用例、迁移成本高。其次，明确劣势了就要最大可能的消除这种门槛提供一种平滑的过度，要立标杆看价值。

一个平台有多 NB 不是功能有多么厉害多么全，而是说平台本身的包容性、无缝对接的能力能让用户真正的 “爽”。

加油～ 2020 共勉

工作四年有余，经历或多或少和楼主有些相似，有时候也喜欢瞎折腾，回过头来我会思考一个问题：我们搭了很多框架、实践来很多主流的模式，但是否就是最贴合业务的呢？我思索的答案是：不是！很多东西打心底里想来都是为了上手实践一把，太离散了，最终能形成体系才是一个长期的目标，相信这样也能减少几分迷茫～

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

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