pm.response.responseTime 是唯一可靠的响应时间读取方式，因旧版全局变量 responseTime 已废弃，在 Collection Runner 或 Newman 中必然报错，其失效源于Postman执行上下文变更与生命周期重构。
pm.response.responseTime 是唯一可靠的响应时间读取方式，别用 responseTime 全局变量——它在新版 Postman 中已废弃，且在 Collection Runner 或 Newman 环境下必然报错。
为什么 responseTime 会失效
旧版脚本里常见 tests["响应时间 ，这依赖全局变量 responseTime。但它不是标准 API，而是 Postman 早期为简化脚本临时注入的只读值，不保证跨版本、跨执行环境（如命令行运行 Newman）可用。
- Postman v10+ 已移除该变量的自动注入逻辑
- 使用
pm.response.responseTime才是官方支持路径，返回毫秒数（number 类型），精度到小数点后一位 - 若仍写
responseTime，你会看到ReferenceError: responseTime is not defined
pm.response.responseTime 的正确用法
必须配合 pm.expect() + Chai 断言链，不能直接比较布尔值。Chai 提供 .below()、.above()、.within() 等语义化方法，比 更健壮。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 基础写法：
pm.expect(pm.response.responseTime).to.be.below(500) - 带容差的区间校验：
pm.expect(pm.response.responseTime).to.be.within(100, 800) - 多条件组合（比如“不能超 500ms，也不能快得离谱低于 10ms”，防缓存假象）：
pm.expect(pm.response.responseTime).to.be.above(10).and.below(500) - 注意：不要写成
pm.response.responseTime —— 这不会被识别为断言，Test Results 里根本不会显示这条测试
响应时间断言容易被忽略的三个细节
时间值本身只是数字，但它的含义受上下文强影响：
-
pm.response.responseTime从发送请求那一刻开始计时，到收到完整响应体（含所有 chunk）结束，**不包含 DNS 查询、TCP 握手、SSL 协商等前置耗时**（这些属于网络层，Postman 不暴露） - 若接口返回流式响应（如 SSE、分块传输），
responseTime计的是首字节到达时间，不是末字节——这点和浏览器 DevTools 的「Waterfall」中 TTFB 不同，别混用 - 在 CI/CD 中用 Newman 执行时，务必确认机器时钟同步；若宿主机时间漂移 >100ms，可能造成偶发性断言失败，尤其当阈值设得很紧（如
below(200)）
真正卡住人的往往不是语法，而是没意识到 responseTime 和 pm.response.responseTime 根本不是一回事，以及时间指标背后隐含的测量边界。
