API契约、请求与故障定位

对照请求与响应契约

需能阅读 HTTP 请求与 JSON。本文对照离线笔记接口资料：GET /notes/1、/notes/999、/notes/0 分别约定 200、404、400，并提供 OpenAPI 3.1 与响应样本；example.invalid 是占位地址，阅读不需要服务、Postman 或账号。 示例未在本轮执行。

API 契约优先

API契约优先指先确定方法、路径、输入约束和响应语义，再准备请求。OpenAPI描述接口，HTTP文件保存具体样例；二者应使用相同字段与状态码，本课不启动服务器或发送请求。

API 请求组成

API请求组成包括方法、URL、请求头和消息体。Content-Type说明发送格式，Accept表达期望响应格式；JSON正文不是查询字符串，GET请求示例避免依赖服务器对消息体的特殊解释。

API 状态码

API状态码与业务字段分别表达传输约定和业务结果。本例200返回记录，404返回application/problem+json问题文档；不要把HTTP200和任意code字段混为同一层，错误体也需有稳定结构。

依据与适用范围

• 本课官方依据，资料核对日2026-10-17。

以上依据用于解释本文列明的规则；示例未执行，不代表产品全部能力或跨平台验证。历史资料的版本、账号与界面位置需按目标环境确认。

检查变量、字段与请求依赖

API 环境变量

API环境变量将基础地址和凭据与请求分离。文档地址使用example.invalid，凭据只写占位符；共享环境前检查实际解析后的变量，旧Postman界面中的初始值与当前值术语不直接当作现行同步规则。

API schema 必填

API schema必填由required数组表达，properties中声明字段不等于必填。本例id为正整数，title为非空字符串，additionalProperties为false拒绝意外字段；JSON能解析并不能证明符合该schema。

API 幂等与重试

API幂等与重试需要区分读请求和写请求。超时不能证明写操作没有生效；写请求需由服务契约定义幂等键、保留期限和冲突语义，本GET样例不假装实现服务端去重。

环境变量、响应取值与请求串联

旧 Postman 7.27.1 例子把 URL、page、pageSize、uid、releaseTime 放在环境中：基础地址切换目标环境，分页和用户字段形成业务输入，releaseTime 从响应中提取后用于后续请求。迁移时先写变量清单、类型、来源和有效期，再检查选中的环境及同名变量遮蔽；不能只看请求编辑框中的占位符。

旧界面 Initial Value 用于共享而 Current Value 保存在本地，是该版本的历史记录，不能当所有版本的同步保证。共享或导出前逐项检查实际值，凭据使用占位符和受控秘密来源；旧私网地址、账号 ID、令牌和导出 UUID 不再作为公开可复制输入。

Postman HTTP 200 和业务 code 断言有什么区别？Postman 环境变量串联 releaseTime 为什么不能循环覆盖？串联先验证 HTTP 状态与媒体类型，再安全解析 JSON，检查业务 code 和 data.infos 形状；只有满足契约才取字段。旧脚本在循环内反复 set releaseTime，得到的是数组最后一个元素，不必然是最大时间，也不是稳定分页游标。先确定排序、空列表和同时间决胜键，再选择尾项；失败时清掉旧派生变量或显式终止，避免下一请求沿用过期值。令牌取值同样要验证存在及类型，不向日志打印完整响应或凭据。

JSON 正文不能在数字占位符外套 JavaScript 反引号；渲染后的 page/pageSize 应是契约要求的数字，uid 应是字符串。HTTP 200 与业务 code=0 是两个层次，应分别断言；只写控制台日志不等于测试失败。旧 tests[...]、具体菜单路径和完整业务响应只作版本快照撤下；这里只整理变量与依赖语义，没有调用 Postman、接口或实现服务。

区分连接、响应与负载问题

API TLS 校验

API的TLS校验失败应核对主机名、证书链和本机时间。关闭证书验证会丢失对端身份保障，不能用作默认修复；代理证书需要可信来源和正确作用域，本例未进行握手。

API 响应比较

API响应比较先看状态、媒体类型和契约字段，再看耗时。不同环境的数据值可不同，但字段类型和必填约定需一致；把脱敏原始响应与解析结果一起保存有助于区分网关HTML错误和业务JSON。

API 功能与压测

API功能与压测回答不同问题：功能验证关注契约正确性，压测关注给定负载下的延迟和错误分布。本课不发负载；旧ab/JMeter命令不能证明当前容量，也不能在未知授权环境照抄。

从旧工具清单区分功能、契约与负载证据

API 功能测试和 JMeter 压力测试证明什么？旧资料列举 Postman、SoapUI、Swagger UI、JMeter、Rest-Assured、Karate、HTTPie 处理请求和断言，也列举 Gatling、LoadRunner、Artillery、Tsung、Locust、k6 等负载工具。这些名称仅记录当时分类，不是当前功能、价格或排名推荐；Swagger/OpenAPI 描述契约也不等于服务器已正确实现。

Postman SoapUI JMeter 历史工具教程怎样迁移？功能检查至少保留方法、URL、头、输入及响应，分别断言 HTTP 状态、媒体类型、字段类型与业务结果。可把“发送请求→查看响应”变成成功、无效输入、不存在资源及权限失败等明确案例；数据驱动检查对每行写预期，不能把循环请求数量当覆盖率。变量、环境及响应取值应有来源和清理规则，分享文件前移除凭据。

负载测试先定义请求组合、并发用户/到达率、升压与持续时长、超时和成功判据，再看延迟分位数、错误率与服务资源。JMeter 线程数是负载配置，单个请求的 200 或聚合平均时间不能证明容量。客户端自身饱和、服务排队、网络与数据库瓶颈要分开定位。原“安装→第一个请求→断言→线程组→报告”的学习顺序可保留，逐步菜单、工具导出格式及产品能力未核验，不再作为现行操作承诺。本次仅整理文字，未安装工具或发压。

Postman 应用

postman 入门

第一步第二步第三步

官网参考