Postman测试后自动执行DELETE清理需在Tests脚本中用pm.sendRequest发起，依赖接口幂等性及安全提取ID；须复用环境变量、避免Pre-request清空、启用Runner“Stop on Failure”，并配合Newman外置脚本兜底。
Postman测试结束后自动执行DELETE清理
Postman本身不提供“测试后自动清理”的原生钩子，但可以通过 Tests 标签页里的脚本，在收到响应后立即发起反向操作（如 DELETE）。这要求接口本身支持幂等删除，且返回的资源 ID 可被可靠提取。
常见错误现象：pm.sendRequest 被误写成同步调用、未处理 404 或 401 导致清理失败但测试仍显示通过、清理请求没加 Authorization 头被拒绝。
- 确保清理逻辑放在
Tests脚本末尾，而非Pre-request Script - 用
pm.response.code === 201或pm.response.code === 200判断创建是否成功，再决定是否清理 - 从响应体安全取 ID：优先用
responseJSON.id，避免正则匹配出错；若字段嵌套深，先做typeof responseJSON.data === 'object'检查 - 清理请求必须复用当前环境变量，比如 URL 写成
{{base_url}}/users/{{created_id}}，而不是硬编码
用 pm.environment.clear() 清理临时变量防污染
测试中常把 token、ID、时间戳存进环境变量（pm.environment.set("user_id", "123")），但下个测试可能读到上一轮残留值，导致 404 或越权。手动清空不可靠，应主动在关键节点清理。
使用场景：一个 Collection 包含「创建用户 → 修改用户 → 删除用户」三步，第二步依赖第一步设的 user_id，但第三步执行完就该失效。
- 在「删除用户」请求的
Tests里加pm.environment.clear()，清空全部环境变量（适合单流程闭环） - 若只需删个别变量，用
pm.environment.unset("user_id")，比clear()更精准 - 注意：
pm.globals.unset()影响全局作用域，跨 Collection 也生效，慎用 - 不要在
Pre-request Script里清空，否则每次发送前都重置，变量根本存不住
Collection Runner 中启用「Stop on Failure」避免脏数据堆积
批量运行时，如果第 2 个请求失败（比如创建失败），后续依赖它的清理请求（第 5 个）大概率也失败，但 Runner 默认继续执行，造成部分数据残留、部分未删，排查困难。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
性能影响不大，但能显著降低收尾阶段的不确定性。
- 打开 Collection Runner → 勾选
Stop on Failure（位置在「Run」按钮上方区域） - 配合每个请求的
Tests加断言，例如tests["Status code is 201"] = responseCode.code === 201; - 失败后手动检查已创建 ID，再单独发一次清理请求，比盲跑更可控
- 不推荐依赖「Continue on Error」+ 全量清理脚本，因为无法判断哪些资源实际落地了
用 Newman + shell 脚本兜底清理（CI/CD 场景必需）
Postman UI 里做的清理只在本地有效；CI 环境（如 Jenkins）跑 Newman 时，pm.sendRequest 发起的清理请求可能因网络策略、权限或环境缺失而静默失败，必须有外部验证机制。
容易被忽略的地方：Newman 执行完就退出，不会等异步清理完成；Node.js 的 setTimeout 在 Newman 里不生效；清理失败也不会中断流水线。
- 在 Newman 命令后追加 shell 脚本，例如：
newman run collection.json && ./cleanup.sh -
cleanup.sh应调用真实 curl 或 Python 脚本，直连数据库或管理 API 删除测试前缀数据（如WHERE name LIKE 'test_%'） - 脚本内加重试逻辑（
curl -f --retry 3）和超时控制（--max-time 30） - 所有清理操作记录日志，哪怕失败也要输出
cleanup failed for user_id=123, status=403，方便人工介入
真正可靠的收尾不是靠 Postman 单点执行，而是分层设防：请求级用 pm.sendRequest 快速清理，流程级用 Runner 控制执行流，系统级用外部脚本兜底。三者缺一不可，尤其当测试数据涉及数据库外键、缓存、消息队列时，仅靠接口 DELETE 很难真正归零。
