分类目录归档：接口测试
2026年3月记录，分类「接口测试」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
接口字段新增看起来兼容，但可能影响前端展示、导出、搜索、三方调用和缓存结构，所以快照回归要判断变化是否符合预期。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
{"id":"number","status":"enum:pending2025年8月记录，分类「接口测试」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
异步任务不能只看接口返回已提交。真正要验证的是任务入队、执行、失败重试、状态回写和重复提交。
记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。
result = app.send_task('tasks.sync_order', args=[order_id])
assert wait_2023年12月记录，分类「接口测试」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。
线上流量回放适合发现真实用户路径里的兼容问题，但不能直接把生产请求拿来跑。脱敏、过滤和幂等处理必须先做好。
我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。
过滤规则:
- 写接口转影子库
- 用户标识脱敏
- 幂等键重新生成
2023年11月记录，分类「接口测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
前后端联调很多争议来自字段理解不一致。Pact 这类契约测试适合把消费者期望固定下来，让接口变化提前暴露。
对测试来说，最后要落到可复现、可验证、可交接，文章也是按这个思路写的。
provider.addInteraction({
state: 'order exists',
2023年6月记录，分类「接口测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
缓存一致性问题最麻烦的是偶现。页面看起来正常，但接口、数据库、缓存可能在短时间内不一致，所以测试要把时间线拉出来。
我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。
redis-cli GET order:10001
redis-cli TTL order:10001
redis-2023年3月记录，分类「接口测试」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。
Mock Server 不是为了逃避真实联调，而是在下游未完成、异常场景难构造时，先把前端和主流程推进起来。
我更关注它在真实提测流程里怎么落地，而不是单独演示一个命令或脚本。
{
"code": 0,
"data": {&quo2022年12月记录，分类「接口测试」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
年底做接口巡检，我不会把所有接口平均扫一遍，而是优先看高频、资金、权限、导出、批量操作这些风险更高的接口。
我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。
接口分级: P0资金 / P1核心流程 / P2普通查询
巡检维度: 调用量、缺陷数、告警数、最近变更
2022年2月记录，分类「接口测试」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
最开始我写接口脚本就是 requests.get/post 到处飞，能跑，但维护很痛。接口多了以后，鉴权、超时、日志、重试、断言都重复，所以我把它收敛成一个小客户端。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。