分类标签归档：接口测试
2026年4月记录，分类「AI测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
私有化模型接口除了回答质量，还要测稳定性、租户隔离、权限、审计和资源限制。这类接口更像业务系统，不只是模型服务。
记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。
并发: 20/50/100
观测: p95、失败率、token成本、审计日志、租户隔离
2026年3月记录，分类「接口测试」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
接口字段新增看起来兼容，但可能影响前端展示、导出、搜索、三方调用和缓存结构，所以快照回归要判断变化是否符合预期。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
{"id":"number","status":"enum:pending2026年1月记录，分类「AI测试」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
MCP 类工具接入后，测试重点是能力边界和权限边界：模型能调用什么、不能调用什么、失败时怎么反馈。
记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。
{"tool":"read_ticket","args":{"ticket_id":"Q2025年12月记录，分类「测试工具」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。
质量度量不是为了年底汇报好看，而是找出下一年要重点改进的模块和流程。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
缺陷逃逸率 = 线上缺陷数 / 总缺陷数
自动化有效率 = 有稳定执行记录的用例 / 自动化用例总数
2025年11月记录，分类「性能测试」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。
网关限流测试要确认两个问题：该拦的流量能拦住，正常用户不会被误伤。
整理时我特意把输入、动作、观察点和风险拆开，方便后面补用例。
seq 1 200 | xargs -n1 -P50 -I{} curl -s -o /dev/null -w '%{http_code}\n' https://api.2025年8月记录，分类「接口测试」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
异步任务不能只看接口返回已提交。真正要验证的是任务入队、执行、失败重试、状态回写和重复提交。
记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。
result = app.send_task('tasks.sync_order', args=[order_id])
assert wait_2023年12月记录，分类「接口测试」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。
线上流量回放适合发现真实用户路径里的兼容问题，但不能直接把生产请求拿来跑。脱敏、过滤和幂等处理必须先做好。
我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。
过滤规则:
- 写接口转影子库
- 用户标识脱敏
- 幂等键重新生成
2023年11月记录，分类「接口测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
前后端联调很多争议来自字段理解不一致。Pact 这类契约测试适合把消费者期望固定下来，让接口变化提前暴露。
对测试来说，最后要落到可复现、可验证、可交接，文章也是按这个思路写的。
provider.addInteraction({
state: 'order exists',
2023年9月记录，分类「postman」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
Postman 变量看着简单，实际很容易因为环境变量、集合变量、全局变量混用导致请求跑偏。我这篇主要记录自己的分层习惯。
我更关注它在真实提测流程里怎么落地，而不是单独演示一个命令或脚本。
pm.collectionVariables.set("order_id", pm.response.json2023年6月记录，分类「接口测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
缓存一致性问题最麻烦的是偶现。页面看起来正常，但接口、数据库、缓存可能在短时间内不一致，所以测试要把时间线拉出来。
我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。
redis-cli GET order:10001
redis-cli TTL order:10001
redis-