十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

3 步搞定 Bruno 跨时区 API 测试:时区变量、时间戳注入与时间差断言

3 步搞定 Bruno 跨时区 API 测试:时区变量、时间戳注入与时间差断言 3 步搞定 Bruno 跨时区 API 测试时区变量、时间戳注入与时间差断言【免费下载链接】brunoOpensource IDE For Exploring and Testing APIs (lightweight alternative to Postman/Insomnia)项目地址: https://gitcode.com/GitHub_Trending/br/bruno上周的联调翻了个跟头美国同事上午跑同一套用例全绿我们下午在国内重放断言全红。查了半天问题不在接口在时间——两边各自用了本地时间当基准时间戳对不上。用 Bruno 做 API 测试时间同步思路其实很简单统一基准、变量注入、断言兜底。先说清 Bruno 的默认行为它不管时区动手之前你得知道 Bruno 默认怎么对待时间相关的数据免得把它的默认行为当成 bug。响应耗时是时区无关的原始数据每个请求发出去Bruno 都会记录响应耗时responseTime单位是毫秒就是从发起到收到完整响应过了多久。脚本里可以直接拿到// 请求后的测试脚本中 test(response time under 1s, () { expect(res.responseTime).to.be.below(1000); });这是一个纯时长数字不带时区全球任何机器上算出来都一样是后面做时间分析最可靠的原料。环境变量只是键值对不做任何转换Bruno 的环境变量environments/目录下的.bru文件本质就是一堆键值对你可以往里放任何字符串、数字。它不会自动帮你做时区换算也不会按你所在的时区变形。多环境机制同一份集合多套变量一个集合可以挂多套环境文件UI 顶部随时切换。这就是我们后面做北京时区一套变量、纽约时区一套变量的现成容器不用改任何请求本身。说白了官方没有现成的时区管理模块但默认行为留了口子——变量可以随便放切换随时切脚本随便写。我们就是用这三样东西拼出时区方案。动手前的准备一份排雷清单时区问题最容易配完才发现不对所以准备工作放在前面做能省掉后面 80% 的返工。环境规划一个时区一个环境文件别把三个时区塞进一个环境里。environments/目录下建三个文件UTC.bru、Beijing.bru、NewYork.bru。以后切环境就是切时区互不污染。变量约定名字里写清单位约定两条硬规则写进团队 wiki 或者集合的说明里所有时间戳变量统一用毫秒名字带ms后缀比如nowMs所有人类可读的时间字符串统一用 UTC 的 ISO 格式就是2026-08-30T02:00:00Z这种结尾的 Z 表示 UTC名字带Utc后缀比如nowUtc单位写进名字别人接手时不用猜。用 Git 管住这些文件时区配置是团队共识不是个人偏好。环境文件、集合文件都放 Git 里谁改了什么偏移量、为什么改都有记录。核心流程变量 → 时间戳注入 → 断言闭环准备工作就绪按这个顺序推进最后一步的断言是闭环。第一步配多环境时区变量每个环境文件里放一个 UTC 基准变量。.bru的写法就是一个vars块// environments/Beijing.bru vars { nowMs: {{ Date.now() }} timezone: Asia/Shanghai utcBase: true }关键就一条无论哪个环境基准一律指向 UTC。北京比 UTC 早 8 小时这种换算留给脚本做不写死在变量里——原因下面坑 1 会讲。第二步在请求里注入时间戳用 Bruno 的预请求脚本pre-request脚本发请求前把时间戳算好塞进请求变量URL 或参数里用{{ nowMs }}直接引用// pre-request 脚本 bru.setVar(nowMs, Date.now()); bru.setVar(nowUtc, new Date().toISOString());为什么不在请求里直接写表达式而要先setVar因为这样时间戳只计算一次URL、参数、请求体引用的是同一个值不会这一行取到 10:00:00.999那一行取到 10:00:01.001。第三步用断言验证时间差最后一步在测试脚本里验证服务器返回的时间是否和基准对得上。断言assertion就是给结果设一个及格线不达标就红灯// tests 脚本 test(server time within 5s of client, () { const serverTime new Date(res.body.timestamp).getTime(); const drift Math.abs(serverTime - Date.now()); expect(drift).to.be.below(5000); });服务器时间在 body 的timestamp字段、容差 5 秒。这条断言跑通说明服务器时钟正常和我的基准没配错两件事同时成立。顺手放一个时区转换函数需要把 UTC 展示成某地时间时用比如报告里给人看function toTimezone(ms, timeZone) { return new Intl.DateTimeFormat(en-US, { timeZone, hour: 2-digit, minute: 2-digit, second: 2-digit }).format(new Date(ms)); } // toTimezone(Date.now(), Asia/Shanghai) → 上海本地时间更多变量和脚本细节可以参考仓库里的 docs/readme/readme_cn.md。常见坑与排查思路方案落地后真正耗时的是这几个坑。坑 1写死 8 小时夏令时一到就漂纽约 UTC-4是冬季的值夏季是 UTC-5。只要有人手算固定偏移每年两次偏移切换时断言就会集体飘 1 小时。定位思路先对比失败时间和夏令时切换日期3 月第二个周日 / 11 月第一个周日再检查代码里有没有写死的±N*3600*1000。正确做法是像上面那样存 IANA 时区名America/New_York换算交给Intl.DateTimeFormat它会自动处理夏令时。坑 2毫秒和秒混用一个变量存毫秒、另一个存秒Math.abs(a - b)出来必然爆炸。定位思路看断言的 actual 值数量级。1.75e12是毫秒1.75e9是秒一眼能分辨。这就是单位写进变量名约定存在的意义。坑 3服务器时钟没校准断言先怪自己时间差断言红了别急着改容差。先用同一个脚本里已有的响应耗时和 URL 变量确认请求确实打到了你以为的那台服务器环境切错是常客再直接查目标机器的系统时间。服务器时钟漂了 30 秒你的断言写得再对也是红灯。坑 4把 ISO 字符串的尾巴 Z 当成东八区toISOString()永远输出 UTC 且结尾带 Z。新人常拿这个字符串当本地时间去比对结果差 8 小时。定位思路看到Z结尾就按 UTC 对待要本地时间就走转换函数。现在就动手别等联调再翻车——打开你的 Bruno 集合给environments/加一个 UTC 基准变量跑一条时间差断言。十分钟的事下次跨时区协作绿灯就是你自己的。更多用法细节见 docs/readme/readme_cn.md。【免费下载链接】brunoOpensource IDE For Exploring and Testing APIs (lightweight alternative to Postman/Insomnia)项目地址: https://gitcode.com/GitHub_Trending/br/bruno创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表