可以，但没必要。把数据库校验放在 API 测试这一层会导致耦合比较严重，好的做法是把数据库验证放在单元测试这一层，API 测试的所有验证操作都通过 API 进行（API 写入之后，再通过 API 查询去验证）。不过现在国内很多公司并没有单元测试这一步，导致大家在做自动化的时候，把很多东西都糅杂在一起了。

在社区看到部分接口测试用例，只校验了 code message。

数据库用的什么框架吗？我现在用的 pymysql 模块

我在测试过程中还是看到字段值插入错误；取值错误；由于查询条件过滤不严谨，导致记录数与预计结果不一致的情况发生

可以看接口级别，比如

• p1 验证接口
• p2 验证数据库
• p3 验证服务器日志

我也认为这一步很重要，而且这一块工作量在整个写 case 过程中是占时较多的

小司接口没有这么规范，甚至连接口文档字段都只阐述部分字段含义，导致前端经常出现取值错误的情况

我一般写数据的接口会对 redis 和数据库检查

搞着搞着，你会觉得这是工作倒退，弄回到了业务测试。然后质疑自己在干什么

我觉着 code 码验证加 data 非空验证可以满足大部分情况

如果是对于查询接口，可以验证 response 是否符合预期就行；
如果是对于增、删、改接口，需要验证 db

你好，P3 服务器日志你们是如何验证的？能解答下吗

看应用阶段，校验开关配置是要有的
开发集成阶段可以关闭校验，大量实施 mock，只验证连通性和接口定义一致性
系统和回归阶段都必须打开，当然如果你有大量稳定可靠的 UI 自动化 case，这一步也可以关掉甚至选择性地不跑

接口的返回关键字段和字段值是肯定要校验的，不然接口测试就没有意义了
一般有两种方式：1、数据库预置数据，接口校验返回 2、接口调用，比对数据库查询结果

上面说的差不多了，通用性补充一条，会验证回包中包含某个字段，数据就会落地；验证执行后回包计时器和数据库入地数量。

我用的是 cx_Oracle

如果数据库和返回的 response 不一致的话，那这个开发应该是大水 B 了。目前我还没遇到过不一致的

可以校验

会