Postman中正向/反向用例应通过Collection命名（如“用户中心（正向）”）和请求名前置标签（如“[正常] 登录”）区分，配合Pre-request Script动态构造异常参数、差异化断言脚本及Collection Runner兜底逻辑实现可控回归。
Postman里怎么标记正向/反向用例
直接靠Collection文件夹命名和请求名区分最可靠，别依赖颜色或备注——Postman本身不提供“用例类型”元数据字段，所有分类逻辑得人工维护。
常见做法是：在Collection名后加括号标注，比如用户中心（正向）、用户中心（鉴权异常）；单个请求名则前置标签，如[正常] 登录-完整参数、[少参] 登录-缺password。这样在Collection Runner批量执行时，能一眼识别范围，也方便导出报告后筛选。
- 避免用空格或特殊符号开头（如「✅」），某些版本Postman导出CSV时会截断或乱码
- 如果团队共用，建议统一命名规范文档，否则很快会出现
【异常】、[error]、(反例)混用的情况 - 不要把所有用例塞进一个Collection再靠文件夹分组——Postman的子文件夹不参与Runner执行顺序控制，容易漏跑
用Pre-request Script自动注入异常参数
手动改每个请求的Body或Params效率低，且容易漏改。用Pre-request Script动态构造异常输入更可控，尤其适合参数组合类反例（如密码长度边界、特殊字符、空值等）。
例如测试「密码为空」场景，在请求的Pre-request Script里写：
if (pm.info.requestName.includes("密码为空")) {
pm.variables.set("pwd", "");
}
然后在Body里用{{pwd}}引用。这样既保留原始请求结构，又避免重复复制粘贴出错。
- 注意变量作用域：Collection级变量对所有请求生效，慎用于异常场景，容易污染其他用例
- JSON格式Body中直接写
{{pwd}}没问题，但x-www-form-urlencoded需确保键名一致，否则服务器收不到空值 - 别在Script里做随机生成（如随机手机号）——除非你明确需要每次不同，否则会导致断言不可重现
断言怎么写才能区分成功/失败逻辑
正向用例断言重点在「响应内容符合预期」，反向用例断言重点在「错误码和提示语是否合理」，两者不能共用同一套tests脚本。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
比如登录接口，正向用例断言：
pm.test("status code is 200", () => pm.response.to.have.status(200));
pm.test("response has token", () => {
const jsonData = pm.response.json();
pm.expect(jsonData.data.token).to.exist;
});
而「密码错误」反向用例必须换一套：
pm.test("status code is 401", () => pm.response.to.have.status(401));
pm.test("error message is '密码错误'", () => {
const jsonData = pm.response.json();
pm.expect(jsonData.message).to.eql("密码错误");
});
- 别用
pm.response.code === 200这种裸比较——pm.response.to.have.status()自带错误提示，失败时直接标红显示实际状态码 - 反向用例里别断言
data字段存在，很多服务在报错时根本不会返回data层级，断言会直接崩 - 如果接口对同一错误返回多种code（如400/401混用），优先按接口文档约定断言，别自行归类
Collection Runner跑异常用例时怎么不停止
默认情况下，Collection Runner遇到第一个失败请求就终止，这对验证「异常流程是否可控」很不利。必须用脚本绕过这个限制。
在Collection级别的Tests里加一段兜底逻辑：
// 允许单个请求失败不中断后续执行
pm.collectionVariables.set("continueOnFailure", true);
再在每个请求的Tests末尾加：
if (pm.response.code !== 200) {
console.log(`⚠️ ${pm.info.requestName} failed with ${pm.response.code}`);
}
这样Runner会跑完全部迭代，最终报告里仍能看清哪些失败、哪些成功。
- 这个技巧只解决「不停止」问题，不解决「断言失败即用例失败」的本质——你仍需靠断言内容本身判断是否符合预期
- 别在
Pre-request Script里抛错来强制中断，Postman不会捕获JS异常，反而让日志难以排查 - 如果真要跳过某类请求（比如预发布环境禁用黑名单检测），用环境变量开关比删请求更安全
