可以校验
会
在社区看到部分接口测试用例，只校验了 code message。
如果数据库和返回的 response 不一致的话，那这个开发应该是大水 B 了。目前我还没遇到过不一致的
可以看接口级别，比如
- p1 验证接口
- p2 验证数据库
- p3 验证服务器日志
可以，但没必要。把数据库校验放在 API 测试这一层会导致耦合比较严重，好的做法是把数据库验证放在单元测试这一层，API 测试的所有验证操作都通过 API 进行（API 写入之后，再通过 API 查询去验证）。不过现在国内很多公司并没有单元测试这一步，导致大家在做自动化的时候，把很多东西都糅杂在一起了。
小司接口没有这么规范，甚至连接口文档字段都只阐述部分字段含义，导致前端经常出现取值错误的情况
我一般写数据的接口会对 redis 和数据库检查
搞着搞着，你会觉得这是工作倒退，弄回到了业务测试。然后质疑自己在干什么
我觉着 code 码验证加 data 非空验证可以满足大部分情况
如果是对于查询接口，可以验证 response 是否符合预期就行；
如果是对于增、删、改接口，需要验证 db
看应用阶段，校验开关配置是要有的
开发集成阶段可以关闭校验，大量实施 mock，只验证连通性和接口定义一致性
系统和回归阶段都必须打开，当然如果你有大量稳定可靠的 UI 自动化 case，这一步也可以关掉甚至选择性地不跑
接口的返回关键字段和字段值是肯定要校验的，不然接口测试就没有意义了
一般有两种方式：1、数据库预置数据，接口校验返回 2、接口调用，比对数据库查询结果
上面说的差不多了，通用性补充一条，会验证回包中包含某个字段，数据就会落地；验证执行后回包计时器和数据库入地数量。
