8. 接口测试中怎么做数据库断言？
接口测试如果只断言状态码和响应字段，是不够的。很多接口返回 code=0，只能说明接口表面处理成功，不代表数据库里的业务结果正确。真正有价值的接口测试，应该根据接口类型和业务场景，验证数据库中的数据变化是否符合预期。
数据库断言是接口测试从“浅层校验”走向“业务校验”的关键能力。比如新增接口，要看数据是否插入；修改接口，要看字段是否更新；删除接口，要看逻辑删除标记是否变化；支付接口，要看订单状态、支付流水、库存、优惠券是否一致。只有把接口响应和数据库结果结合起来，才能真正验证接口质量。
一、什么时候需要数据库断言
不是所有接口都必须查数据库。比如纯查询接口，如果响应字段已经完整，数据库断言可以视情况使用。但以下接口强烈建议做数据库断言。
1. 新增类接口
例如新增用户、新增地址、创建订单、提交工单、创建优惠券。断言重点是数据库是否插入记录，字段是否正确。
select id, mobile, status, create_time
from t_user
where mobile = '13800000000';
2. 修改类接口
例如修改手机号、编辑地址、更新工单状态、审批通过。断言重点是目标字段是否更新，更新时间和更新人是否正确。
3. 删除类接口
删除可能是真删除，也可能是逻辑删除。数据库断言要根据需求判断。
select id, is_deleted, update_time
from t_address
where id = 1001;
4. 状态流转接口
订单支付、取消订单、审批通过、退款审核都属于状态流转。断言重点是状态是否按规则变化，不能非法跳转。
5. 金额和库存接口
支付、退款、下单、优惠券使用、积分扣减都涉及金额或库存，必须查数据库多表一致性。
二、接口断言的层次
接口测试断言可以分成三层。
第一层：协议层断言
包括 HTTP 状态码、响应时间、Content-Type 等。
第二层：响应体断言
包括 code、message、业务字段、数据类型、字段是否为空。
第三层：数据库断言
验证接口调用后数据库是否发生正确变化。数据库断言最能体现业务测试深度。
一个高质量接口用例通常至少包含前两层；关键写操作接口要加入第三层。
三、新增接口怎么做数据库断言
以新增收货地址接口为例。
请求：
{
"receiverName": "张三",
"mobile": "13800000000",
"province": "广东省",
"city": "深圳市",
"detail": "南山区科技园"
}
响应断言：
- HTTP 状态码为 200；
code=0；- 返回地址 ID；
- message 为 success。
数据库断言：
select receiver_name, mobile, province, city, detail, is_default
from t_user_address
where id = 2001;
验证字段是否和请求一致，默认值是否正确，例如 is_default 是否符合需求。
四、修改接口怎么做数据库断言
以修改订单备注为例：
select order_no, remark, update_time
from t_order
where order_no = 'NO202604300001';
断言点：
- 备注字段变成新值；
- 其他字段不应被误改；
- 更新时间发生变化；
- 更新人字段正确。
修改类接口要特别关注“误更新”。接口只改手机号，不能把用户状态、角色、创建时间改了。
五、删除接口怎么做数据库断言
删除接口首先要确认需求是真删除还是逻辑删除。
逻辑删除断言：
select id, is_deleted, update_time
from t_address
where id = 1001;
预期：记录仍存在，is_deleted=1。
真删除断言：
select count(*)
from t_address
where id = 1001;
预期：结果为 0。
同时要验证删除后查询接口是否不再返回这条数据。
六、状态流转接口怎么断言
以取消订单接口为例。
接口调用前：
select order_no, status
from t_order
where order_no = 'NO202604300001';
确认状态是待支付。
调用取消接口后：
select order_no, status, cancel_time
from t_order
where order_no = 'NO202604300001';
预期状态变成已取消，取消时间不为空。
还要补充异常断言：已支付订单不能取消，已取消订单不能重复取消，不存在订单返回错误。
七、支付接口数据库断言
支付接口是数据库断言最典型场景。
支付成功后至少要查：
select order_no, status, pay_status, total_amount
from t_order
where order_no = 'NO202604300001';
select pay_no, order_no, pay_amount, pay_status
from t_pay_record
where order_no = 'NO202604300001';
断言点：
- 订单状态为已支付；
- 支付状态为成功；
- 支付流水存在；
- 支付金额等于订单金额；
- 重复支付不会生成多条成功流水；
- 如果涉及优惠券和库存，还要查关联表。
八、自动化中如何做数据库断言
在接口自动化中，数据库断言一般步骤是：
- 准备测试数据；
- 调用接口；
- 获取响应中的业务 ID；
- 连接测试数据库；
- 执行 SQL 查询；
- 对查询结果做断言；
- 清理测试数据。
伪代码示例：
response = api.create_order(product_id=101, quantity=1)
assert response["code"] == 0
order_no = response["data"]["orderNo"]
order = db.query_one("select status,total_amount from t_order where order_no=%s", order_no)
assert order["status"] == "WAIT_PAY"
assert order["total_amount"] == 199
测试自动化中要注意不要把 SQL 写得太散，可以封装数据库查询方法和业务断言方法。
九、数据库断言的注意事项
1. 避免依赖脏数据
测试前要准备明确数据，避免查到历史数据。最好用唯一手机号、唯一订单号、唯一测试标识。
2. 注意环境隔离
自动化不要连错库，尤其不要误连生产库。数据库配置要区分测试环境和预发环境。
3. 注意异步处理
有些接口返回成功后，数据库不是立即更新，而是通过消息队列异步处理。这时断言要加等待或轮询，但不能无限等待。
4. 不要过度断言实现细节
数据库断言要围绕业务结果，不要把实现细节绑死。否则开发重构表结构时，测试用例会大量失败。
5. 测试后清理数据
自动化测试产生的数据要能清理，否则会污染后续用例。
十、面试回答模板
如果面试官问“接口测试中怎么做数据库断言”，可以这样回答：
我做接口测试不会只断言状态码和 code，还会根据接口类型判断是否需要数据库断言。新增类接口会查数据库确认记录是否插入，字段是否和请求一致；修改类接口会查目标字段是否更新，并确认其他字段没有误改；删除类接口会确认是真删除还是逻辑删除；订单支付这类状态流转接口，会查订单表、支付流水表、库存表和优惠券表，验证状态和金额一致。自动化里我会用接口返回的业务 ID 去数据库查询，再对关键字段断言，同时注意测试数据隔离、异步等待和数据清理。
十一、常见追问
追问：所有接口都要查数据库吗？
不是。查询类接口可以主要断言响应内容；关键写操作和状态流转接口更需要数据库断言。
追问：接口返回成功但数据库没数据怎么办？
先确认是否异步处理；再确认查库条件和环境是否正确；然后看服务端日志、事务回滚、消息队列和异常信息。
追问：自动化数据库断言不稳定怎么办？
检查是否有异步延迟、脏数据、环境共享、数据未清理、SQL 条件不唯一。可以用唯一测试数据、轮询等待和数据清理提升稳定性。
十二、练习清单
- 为新增用户接口设计数据库断言；
- 为修改地址接口设计数据库断言；
- 为删除地址接口区分真删除和逻辑删除；
- 为创建订单接口断言订单和明细；
- 为支付接口断言订单和支付流水；
- 为取消订单接口断言状态流转；
- 为优惠券使用接口断言优惠券状态；
- 为库存扣减接口断言库存变化；
- 在自动化脚本中封装数据库查询；
- 设计异步接口的数据库轮询断言。
数据库断言不是为了炫技，而是为了证明接口真的完成了业务动作。接口测试越深入，越离不开数据库验证。
配套刷题：
