AI Postman 这个组合如果只看标题很多人会以为是用 AI 自动生成一堆接口测试用例然后一键跑完。真正上手以后我更愿意把它理解成用 AI 把接口测试的学习和落地周期压缩下来。以前从看懂接口文档到写出断言脚本可能要翻半天文档再对着参数试半天现在可以先让 AI 生成一版可运行的请求和断言再由人来判断、修改、补充边界。这篇文章准备按 90 分钟的练习路径来拆每一段都有明确的输入、操作和验证结果。适合刚接触接口测试、想在短时间里把 Postman 用起来的人也适合已经有手工测试经验但脚本能力偏弱、想快速产出自动化用例的同学。文章不堆概念尽量把每一步怎么执行、为什么这么执行、遇到问题先查哪里都说清楚。1. 先搞清楚 AI 在接口测试里的真实位置很多人把“AI 赋能接口测试”想得太神秘。其实放到 Postman 这个日常工具里AI 做的事情非常具体帮你理解接口文档、生成请求结构、写断言脚本、做测试数据、排查报错。它像一个非常熟悉接口测试套路、但完全不了解项目业务的助手能缩短从想法到代码的距离但不能替你拍板。1.1 AI 在接口测试里能做什么先列几个我实测下来最实用的方向解析接口文档。把接口文档、抓包结果、甚至一段 curl 命令丢给 AI它能帮你转成 Postman 能理解的请求结构。生成断言脚本。包括状态码断言、响应字段断言、响应时间断言、JSON Schema 校验。生成测试数据。比如需要一批用户名的边界值空字符串、超长字符串、特殊字符、重复数据、正常数据。AI 能很快列出一份可导入的 CSV 或 JSON 数据文件。排查报错。把请求体、响应体、错误日志贴给 AI它能按常见接口问题给出排查方向。注意是方向不是结论。编写接口测试点。让 AI 根据接口的功能描述列出这个接口可能需要验证的维度比如参数必填、参数类型、权限、异常输入、返回值一致性。这些能力对新手特别友好。因为新手在接口测试里卡住的往往不是“工具不会用”而是“不知道要断言什么”“不知道脚本怎么写”“不知道报错是什么意思”。AI 正好补上这三大块。1.2 AI 在接口测试里不能做什么我在多次练习里发现AI 的能力边界也很清晰第一它不真正理解你的业务。同一个状态码 200在订单查询接口和文件上传接口里的业务含义完全不同。AI 不知道这个接口的返回结果到底算不算“正确”。第二它不了解你的权限体系。接口有没有做签名、加密字段怎么拼接、token 多久过期、哪些请求头是网关要求加的这些信息来自项目代码和运维配置AI 看不到。第三它生成脚本的错误需要人工识别。AI 生成的断言可能引用了不存在的字段也可能把数组写成了对象更可能在签名算法上完全跑偏。所以AI 生成的任何脚本都必须先在 Postman 里跑一遍再人工看一眼逻辑。第四它不能做验收判断。接口返回是否符合业务预期最终要靠人确认。AI 帮你把“不知道怎么验证”变成了“有东西可以验证”但验证结果是否通过还是人来定。记住这句话AI 在接口测试里的价值是压缩时间而不是替代判断。谁要是说 AI 全能自动搞定接口测试那多半是没在真实环境里被 401、签名错误、字段缺失折磨过。2. 90 分钟第一段先把 Postman 的请求和断言跑通不管 AI 多强Postman 基础操作不能省。因为后续 AI 生成的脚本最终都要落到 Postman 里执行。如果连请求怎么发、断言在哪里写、变量怎么用都不清楚AI 生成的代码出了问题你都不知道去哪里看。2.1 环境准备装好 Postman准备一个可用的测试接口第一步安装 Postman。直接去官网下载对应系统的安装包Windows、macOS、Linux 都支持。安装后用邮箱注册一个账号就可以开始也可以先以游客模式体验基础功能。这里不必纠结版本用的功能都集中在“请求编辑区”“集管理”“环境管理”“Runner”这些常用区域。第二步准备测试接口。最好的选择是你们项目里的开发环境接口因为你知道业务预期还能判断 AI 生成的断言对不对。如果没有现成接口也可以用公开的接口测试服务比如常见的 echo 类服务请求什么就返回什么。这种方式适合练习不适合断言具体业务字段。第三步确认接口连通性。在 Postman 里新建一个 GET 请求填上接口地址点击 Send。如果返回 200说明工具和网络都没问题如果超时或报错先检查地址、端口、网络和代理设置再继续往下走。2.2 第一个可验证的用例请求参数对齐再写第一个断言很多人学接口测试一上来就想着写脚本结果请求本身都没调通。正确顺序是先手工确认请求参数。Path 参数、Query 参数、Header、Body 都要和接口文档完全一致。发送请求确认服务端返回什么。看清返回结构是普通 JSON、嵌套 JSON还是数组还是文本。再打开 Tests 标签页写一个最简单的断言。Postman 的断言脚本用 JavaScript 写最常用的是pm.test和pm.response。下面这个断言就是检查状态码是否为 200pm.test(状态码是 200, function () { pm.response.to.have.status(200); });发送请求后Tests 结果标签页会显示这个断言通过还是失败。先不要写复杂逻辑把状态码跑通确认断言机制生效。2.3 配置变量和环境让接口测试具备复用能力如果每个接口地址都直接写死换一个测试环境就要改一堆请求非常痛苦。所以第二步要立刻引入 Postman 的变量机制。在 Postman 右上角打开环境管理新建一个“开发环境”添加两个变量变量名示例值用途baseUrlhttp://your-service.example.com接口服务根地址token空登录后动态写入请求地址就可以写成{{baseUrl}}/api/v1/users这样从一个环境切换到另一个环境只需要修改环境变量不需要改每个请求。更进阶的用法是在“登录”接口的 Tests 脚本里把返回的 token 自动写入环境变量const responseJson pm.response.json(); pm.environment.set(token, responseJson.data.token);后续接口的请求头里就可以直接引用{{token}}。这个机制非常关键因为它让接口测试不再依赖“每次手工复制 token”也为后面集合批量运行打下了基础。3. 90 分钟第二段用 AI 生成断言脚本和测试数据基础请求跑通之后可以正式引入 AI。这里有一个很重要的认知AI 是生成器你是审查者。生成得越快审查越要严格。下面我按三个最常用场景展开。3.1 提示词模板把接口需求说清楚想让 AI 生成靠谱的 Postman 断言第一步是给它足够多的信息。很多 AI 生成的脚本不能用不是模型不行而是提示词里没有说明接口的具体返回结构。我一般用这个结构你是一名接口测试工程师请帮我在 Postman 的 Tests 里写断言脚本。 接口信息 - 接口名称用户列表查询 - 请求方法GET - 请求路径/api/v1/users - 请求参数page整数默认1、size整数默认20 - 成功响应 { code: 0, message: success, data: { total: 100, list: [ {id: 1, username: alice, status: 1} ] } } 请断言 1. 状态码是 200 2. 响应中的 code 等于 0 3. data.total 是数字类型且大于等于 0 4. data.list 是数组且每个元素都有 id、username、status 三个字段这样写AI 能明确知道接口结构是什么、要断言哪些字段、每个字段是什么类型。相比一句“帮我写测试脚本”成功率会高很多。3.2 用 AI 生成断言脚本再人工检查一遍把上面这个提示词发给 AI 后得到的结果大概是这样pm.test(状态码是 200, function () { pm.response.to.have.status(200); }); pm.test(业务 code 为 0, function () { const json pm.response.json(); pm.expect(json.code).to.eql(0); }); pm.test(data.total 是非负数字, function () { const json pm.response.json(); pm.expect(json.data.total).to.be.a(number); pm.expect(json.data.total).to.be.at.least(0); }); pm.test(list 数组字段完整, function () { const json pm.response.json(); const list json.data.list; pm.expect(list).to.be.an(array); list.forEach(item { pm.expect(item).to.have.property(id); pm.expect(item).to.have.property(username); pm.expect(item).to.have.property(status); }); });生成之后不要直接复制按下面顺序检查一遍看字段路径对不对。data.total和data.list是否与真实响应一致。看类型断言是否合理。有些接口的数字是字符串返回断言成 number 会直接失败。看 forEach 里是否有空数组风险。如果list为空forEach 不会执行这条断言看起来是通过的但可能没有覆盖元素字段。检查完再把脚本粘贴到 Tests 里发送请求看断言结果。通过不代表一定正确但至少说明脚本和当前响应结构匹配。3.3 用 AI 生成测试数据让一个用例跑多组数据接口测试里最花时间的不是写断言而是准备测试数据。比如用户注册接口要测用户名必填、用户名重复、用户名超长、邮箱格式错误、密码强度不够等等。手工写十组数据至少十分钟AI 可能一分钟就生成好了。拿 CSV 文件举例Postman 的数据驱动依赖 CSV 或 JSON。让 AI 生成一份用户注册的测试数据username,email,password,expected_code,expected_msg ,aliceexample.com,abc123456,400,用户名不能为空 alice,aliceexample.com,abc123456,200,注册成功 alice,aliceexample.com,abc123456,400,用户名已存在 abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz,aliceexample.com,abc123456,400,用户名长度超限 alice,invalid-email,abc123456,400,邮箱格式错误 alice,aliceexample.com,123456,400,密码强度不足生成后要人工确认用户名重复的用例看起来和正常用例完全一样区别在于执行顺序。真实评测时要保证“重复注册”用例排在“正常注册”用例之后或者先通过脚本提前插入一条用户数据。这种业务前提 AI 不一定能完全理解需要测试人员自己把控。CSV 数据准备后在 Postman Collection Runner 里选择这个数据文件接口请求参数用{{username}}、{{email}}、{{password}}引用断言里再对比expected_code和expected_msg。这样一个接口就能跑好多组数据。4. 90 分钟第三段从单接口到集合解决顺序和批量问题单接口测试跑通只是开始。真实接口测试里往往是一个业务流程串起来登录拿 token用 token 查列表查详情提交数据最后验证结果。把这组接口放到同一个集合里才能体现接口测试的价值。4.1 用集合管理接口处理接口依赖在 Postman 左侧新建一个 Collection把相关接口按业务顺序放进去。比如登录获取 token查询用户列表查询用户详情创建新用户验证新用户存在这里的依赖关系很明确第 2、3、4 个接口需要用到第 1 个接口返回的 token。如果你在前面已经写了 token 写入环境变量的脚本那么集合运行时第 1 个接口执行后 token 已经自动更新后续接口直接引用{{token}}即可。还有一个容易忽略的依赖接口 B 需要接口 A 返回的某个 ID。可以在接口 A 的 Tests 脚本里把这个 ID 存成环境变量接口 B 的请求路径或请求体里再引用。const json pm.response.json(); pm.environment.set(createdUserId, json.data.id);接口 B 的请求体里写{ userId: {{createdUserId}} }这样集合运行时每个接口拿到的都是上一个接口真实产生的数据而不是写死的假数据。4.2 批量执行与结果判断在 Collection 页面点击 Runner选择集合、迭代次数、数据文件就能批量执行。运行时注意看三个指标指标判断标准失败时先检查通过率至少 95% 以上才算稳定断言字段路径、接口返回结构响应时间与单接口时对比波动是否过大网络、服务端负载、参数是否有超大数据量失败用例连续执行多次是否集中在同一接口参数依赖、token 过期、数据污染我建议不要只盯“全部通过”。如果所有用例都通过但响应时间从 500ms 涨到了 3000ms说明性能已经发生变化。接口测试不只是功能测试还要关注时间、稳定性、状态码分布。4.3 判断接口测试是否稳定不能只看一次结果新手最容易犯的错误跑一次全绿就认为测试通过。我一般会连续跑 3 次重点看两个问题第一失败是否随机。第一次跑挂在第 3 个接口第二次挂在第 5 个接口那大概率是数据依赖或者竞态条件不是断言逻辑问题。第二失败是否可解释。如果某个接口在批量环境下总是失败但单接口跑完全正常优先检查 token 是否共享、数据文件是否有重复、前置接口执行顺序是否正确。批量接口测试的稳定不是指零失败。而是每次失败都能被日志和断言解释清楚复现路径明确不会出现“这轮过了下轮又挂”的玄学问题。5. 报错别慌让 AI 变成排查搭档接口测试里一半时间花在排错上。AI 在这里的价值是帮你快速缩小范围但不负责最终的判断。下面按最常见的报错类型拆一遍。5.1 常见报错类型与排查方向现象可能原因排查方向401 Unauthorized没带 token、token 过期、token 类型错确认请求头 Authorization 是否正确填写并引用变量403 Forbidden权限不足、无访问该接口的权限确认当前账号角色是否被允许访问404 Not Found路径错、接口不存在、服务未部署确认 baseUrl 和接口路径是否一致405 Method Not Allowed请求方法不对把 GET 改成 POST或查文档确认真实方法500 Internal Server Error服务端逻辑异常提取服务端日志看参数是否导致空指针或数据异常请求超时网络慢、服务端长时间无响应先确认服务是否存活再考虑增加超时时间JSON 解析失败响应不是 JSON、内容被截断先看响应原文再检查编码和网络代理5.2 排查链路从现象到根因遇到报错后我建议按固定顺序排查不要跳着猜。第一步看现象本身。先确认这个问题是功能错误、数据错误、还是环境错误。功能错误是接口逻辑有问题数据错误是输入数据和业务约束冲突环境错误是网络、配置、权限、服务端状态导致的。第二步看输入。请求参数、请求头、请求体是否和文档一致。这里最容易忽略的是 Content-Type。有的接口要求application/json你填了text/plain服务端解析不出来返回 500 或 400。第三步看上下文。批量运行时报错要看是这个接口的问题还是上一个接口影响了它。比如上一个接口超时导致 token 没有写入环境变量当前接口拿到的就是空 token自然 401。第四步看日志。服务端日志是最终答案。如果权限允许把日志级别调成 debug看服务端到底接收到什么参数、在哪里抛异常。这是很多人跳过的一步但它往往是最直接的一步。5.3 把报错信息交给 AI但别盲目执行当你确认了现象、输入、上下文之后可以用 AI 辅助分析。比如我的 Postman 请求返回 500请求路径是 POST /api/v1/users请求体是 { username: alice, email: aliceexample.com, password: abc123456 } 响应体是{message: Internal Server Error} 这个接口在单接口调试时成功过但是放在集合里批量执行就失败。 请帮我列出可能导致这个现象的原因按概率从高到低排序。AI 可能会给出几个方向比如“前一个接口执行失败导致环境变量未更新”“数据文件里存在重复数据触发唯一约束”“批量执行时 token 过期”“顺序不对导致依赖数据不存在”。这些方向基本靠谱但需要你一条条对照日志和实际数据去验证。不要因为 AI 说“大概率是 token 过期”你就直接把所有超时都归因到 token。在我自己的排查经验里AI 最大的作用是帮我把遗漏的方向补全。比如它可能提醒我去检查 Cookie、代理、网关配置这些点单靠自己容易漏掉。但最终定位还是要结合项目代码、日志和可复现实验。6. 90 分钟怎么分配最合理以及这套方法能走多远前面把核心操作都过了一遍最后回到标题90 分钟。这个时间其实不长所以更要聚焦。不是所有 Postman 功能都要学也不是所有接口测试理论都要看关键是先把一条最小链路跑通请求、断言、变量、集合、批量、排查。6.1 时间分配建议时间段任务验证标准0-15 分钟安装 Postman连通测试接口成功发送一次请求并返回预期结果15-30 分钟写第一个状态码断言配置环境和变量断言能在测试面板显示通过30-50 分钟用 AI 生成字段断言、Schema 校验和数据文件脚本可以运行测试数据覆盖至少 5 组50-70 分钟建集合处理 token 和 ID 依赖批量执行集合能一次跑通通过率可观察70-80 分钟人为制造一个错误改错参数用 AI 辅助排查能定位到根因并修复80-90 分钟复盘测试点、断言项、数据用例列表形成可复用的接口测试清单为什么这样分配因为前 30 分钟如果只讲概念后面 AI 生成的脚本就没办法落地。后半段必须用“能跑的东西”来练不然 90 分钟结束你还是只会看文档、不会动手。6.2 适用场景和边界这套方法适合个人要快速产出接口测试脚本不想从零搭建框架。项目里没有现成接口测试平台先用 Postman 做基础验证。新手学习接口测试想通过真实请求理解接口行为。接口数量不多、业务逻辑不复杂的阶段可以快速覆盖。这套方法不适合大规模自动化回归持续集成里需要稳定调度、报告、告警。复杂业务状态机一个接口的输入依赖大量前置状态。对数据和权限非常敏感的项目每一步都需要严格审计。Postman 可以导出集合你在进阶阶段可以把它迁移到更完整的自动化体系里但这不是 90 分钟要解决的问题。6.3 下一步进阶方向如果你把 90 分钟的内容练完并且想继续深入我建议按这个顺序走第一补接口测试理论。把等价类、边界值、状态码、鉴权、幂等性这些概念和你刚写过的断言对应起来。第二学接口协议细节。HTTP 方法、状态码语义、请求头、响应头、编码格式这些是排查问题的基础。第三整理自己的提示词库。把项目中常见的接口类型、断言模板、数据生成模板保存下来。以后再遇到类似接口直接把模板丢给 AI能省很多时间。第四把测试用例和项目文档对应起来。让接口测试不仅验证“接口能调通”还要验证“接口行为符合业务预期”。最后说一句这套方法真正跑通之后你会发现 AI 帮你省掉的不是写代码的时间而是从“不知道怎么测”到“能写出第一版可运行用例”的探索时间。接口测试的核心判断还在人这里但起步的速度可以快很多。 
长河君 · 2026/8/30 17:57:47 · 阅读 1.2k AI + Postman 实战：90 分钟从接口测试入门到批量断言
AI Postman 这个组合如果只看标题很多人会以为是用 AI 自动生成一堆接口测试用例然后一键跑完。真正上手以后我更愿意把它理解成用 AI 把接口测试的学习和落地周期压缩下来。以前从看懂接口文档到写出断言脚本可能要翻半天文档再对着参数试半天现在可以先让 AI 生成一版可运行的请求和断言再由人来判断、修改、补充边界。这篇文章准备按 90 分钟的练习路径来拆每一段都有明确的输入、操作和验证结果。适合刚接触接口测试、想在短时间里把 Postman 用起来的人也适合已经有手工测试经验但脚本能力偏弱、想快速产出自动化用例的同学。文章不堆概念尽量把每一步怎么执行、为什么这么执行、遇到问题先查哪里都说清楚。1. 先搞清楚 AI 在接口测试里的真实位置很多人把“AI 赋能接口测试”想得太神秘。其实放到 Postman 这个日常工具里AI 做的事情非常具体帮你理解接口文档、生成请求结构、写断言脚本、做测试数据、排查报错。它像一个非常熟悉接口测试套路、但完全不了解项目业务的助手能缩短从想法到代码的距离但不能替你拍板。1.1 AI 在接口测试里能做什么先列几个我实测下来最实用的方向解析接口文档。把接口文档、抓包结果、甚至一段 curl 命令丢给 AI它能帮你转成 Postman 能理解的请求结构。生成断言脚本。包括状态码断言、响应字段断言、响应时间断言、JSON Schema 校验。生成测试数据。比如需要一批用户名的边界值空字符串、超长字符串、特殊字符、重复数据、正常数据。AI 能很快列出一份可导入的 CSV 或 JSON 数据文件。排查报错。把请求体、响应体、错误日志贴给 AI它能按常见接口问题给出排查方向。注意是方向不是结论。编写接口测试点。让 AI 根据接口的功能描述列出这个接口可能需要验证的维度比如参数必填、参数类型、权限、异常输入、返回值一致性。这些能力对新手特别友好。因为新手在接口测试里卡住的往往不是“工具不会用”而是“不知道要断言什么”“不知道脚本怎么写”“不知道报错是什么意思”。AI 正好补上这三大块。1.2 AI 在接口测试里不能做什么我在多次练习里发现AI 的能力边界也很清晰第一它不真正理解你的业务。同一个状态码 200在订单查询接口和文件上传接口里的业务含义完全不同。AI 不知道这个接口的返回结果到底算不算“正确”。第二它不了解你的权限体系。接口有没有做签名、加密字段怎么拼接、token 多久过期、哪些请求头是网关要求加的这些信息来自项目代码和运维配置AI 看不到。第三它生成脚本的错误需要人工识别。AI 生成的断言可能引用了不存在的字段也可能把数组写成了对象更可能在签名算法上完全跑偏。所以AI 生成的任何脚本都必须先在 Postman 里跑一遍再人工看一眼逻辑。第四它不能做验收判断。接口返回是否符合业务预期最终要靠人确认。AI 帮你把“不知道怎么验证”变成了“有东西可以验证”但验证结果是否通过还是人来定。记住这句话AI 在接口测试里的价值是压缩时间而不是替代判断。谁要是说 AI 全能自动搞定接口测试那多半是没在真实环境里被 401、签名错误、字段缺失折磨过。2. 90 分钟第一段先把 Postman 的请求和断言跑通不管 AI 多强Postman 基础操作不能省。因为后续 AI 生成的脚本最终都要落到 Postman 里执行。如果连请求怎么发、断言在哪里写、变量怎么用都不清楚AI 生成的代码出了问题你都不知道去哪里看。2.1 环境准备装好 Postman准备一个可用的测试接口第一步安装 Postman。直接去官网下载对应系统的安装包Windows、macOS、Linux 都支持。安装后用邮箱注册一个账号就可以开始也可以先以游客模式体验基础功能。这里不必纠结版本用的功能都集中在“请求编辑区”“集管理”“环境管理”“Runner”这些常用区域。第二步准备测试接口。最好的选择是你们项目里的开发环境接口因为你知道业务预期还能判断 AI 生成的断言对不对。如果没有现成接口也可以用公开的接口测试服务比如常见的 echo 类服务请求什么就返回什么。这种方式适合练习不适合断言具体业务字段。第三步确认接口连通性。在 Postman 里新建一个 GET 请求填上接口地址点击 Send。如果返回 200说明工具和网络都没问题如果超时或报错先检查地址、端口、网络和代理设置再继续往下走。2.2 第一个可验证的用例请求参数对齐再写第一个断言很多人学接口测试一上来就想着写脚本结果请求本身都没调通。正确顺序是先手工确认请求参数。Path 参数、Query 参数、Header、Body 都要和接口文档完全一致。发送请求确认服务端返回什么。看清返回结构是普通 JSON、嵌套 JSON还是数组还是文本。再打开 Tests 标签页写一个最简单的断言。Postman 的断言脚本用 JavaScript 写最常用的是pm.test和pm.response。下面这个断言就是检查状态码是否为 200pm.test(状态码是 200, function () { pm.response.to.have.status(200); });发送请求后Tests 结果标签页会显示这个断言通过还是失败。先不要写复杂逻辑把状态码跑通确认断言机制生效。2.3 配置变量和环境让接口测试具备复用能力如果每个接口地址都直接写死换一个测试环境就要改一堆请求非常痛苦。所以第二步要立刻引入 Postman 的变量机制。在 Postman 右上角打开环境管理新建一个“开发环境”添加两个变量变量名示例值用途baseUrlhttp://your-service.example.com接口服务根地址token空登录后动态写入请求地址就可以写成{{baseUrl}}/api/v1/users这样从一个环境切换到另一个环境只需要修改环境变量不需要改每个请求。更进阶的用法是在“登录”接口的 Tests 脚本里把返回的 token 自动写入环境变量const responseJson pm.response.json(); pm.environment.set(token, responseJson.data.token);后续接口的请求头里就可以直接引用{{token}}。这个机制非常关键因为它让接口测试不再依赖“每次手工复制 token”也为后面集合批量运行打下了基础。3. 90 分钟第二段用 AI 生成断言脚本和测试数据基础请求跑通之后可以正式引入 AI。这里有一个很重要的认知AI 是生成器你是审查者。生成得越快审查越要严格。下面我按三个最常用场景展开。3.1 提示词模板把接口需求说清楚想让 AI 生成靠谱的 Postman 断言第一步是给它足够多的信息。很多 AI 生成的脚本不能用不是模型不行而是提示词里没有说明接口的具体返回结构。我一般用这个结构你是一名接口测试工程师请帮我在 Postman 的 Tests 里写断言脚本。 接口信息 - 接口名称用户列表查询 - 请求方法GET - 请求路径/api/v1/users - 请求参数page整数默认1、size整数默认20 - 成功响应 { code: 0, message: success, data: { total: 100, list: [ {id: 1, username: alice, status: 1} ] } } 请断言 1. 状态码是 200 2. 响应中的 code 等于 0 3. data.total 是数字类型且大于等于 0 4. data.list 是数组且每个元素都有 id、username、status 三个字段这样写AI 能明确知道接口结构是什么、要断言哪些字段、每个字段是什么类型。相比一句“帮我写测试脚本”成功率会高很多。3.2 用 AI 生成断言脚本再人工检查一遍把上面这个提示词发给 AI 后得到的结果大概是这样pm.test(状态码是 200, function () { pm.response.to.have.status(200); }); pm.test(业务 code 为 0, function () { const json pm.response.json(); pm.expect(json.code).to.eql(0); }); pm.test(data.total 是非负数字, function () { const json pm.response.json(); pm.expect(json.data.total).to.be.a(number); pm.expect(json.data.total).to.be.at.least(0); }); pm.test(list 数组字段完整, function () { const json pm.response.json(); const list json.data.list; pm.expect(list).to.be.an(array); list.forEach(item { pm.expect(item).to.have.property(id); pm.expect(item).to.have.property(username); pm.expect(item).to.have.property(status); }); });生成之后不要直接复制按下面顺序检查一遍看字段路径对不对。data.total和data.list是否与真实响应一致。看类型断言是否合理。有些接口的数字是字符串返回断言成 number 会直接失败。看 forEach 里是否有空数组风险。如果list为空forEach 不会执行这条断言看起来是通过的但可能没有覆盖元素字段。检查完再把脚本粘贴到 Tests 里发送请求看断言结果。通过不代表一定正确但至少说明脚本和当前响应结构匹配。3.3 用 AI 生成测试数据让一个用例跑多组数据接口测试里最花时间的不是写断言而是准备测试数据。比如用户注册接口要测用户名必填、用户名重复、用户名超长、邮箱格式错误、密码强度不够等等。手工写十组数据至少十分钟AI 可能一分钟就生成好了。拿 CSV 文件举例Postman 的数据驱动依赖 CSV 或 JSON。让 AI 生成一份用户注册的测试数据username,email,password,expected_code,expected_msg ,aliceexample.com,abc123456,400,用户名不能为空 alice,aliceexample.com,abc123456,200,注册成功 alice,aliceexample.com,abc123456,400,用户名已存在 abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz,aliceexample.com,abc123456,400,用户名长度超限 alice,invalid-email,abc123456,400,邮箱格式错误 alice,aliceexample.com,123456,400,密码强度不足生成后要人工确认用户名重复的用例看起来和正常用例完全一样区别在于执行顺序。真实评测时要保证“重复注册”用例排在“正常注册”用例之后或者先通过脚本提前插入一条用户数据。这种业务前提 AI 不一定能完全理解需要测试人员自己把控。CSV 数据准备后在 Postman Collection Runner 里选择这个数据文件接口请求参数用{{username}}、{{email}}、{{password}}引用断言里再对比expected_code和expected_msg。这样一个接口就能跑好多组数据。4. 90 分钟第三段从单接口到集合解决顺序和批量问题单接口测试跑通只是开始。真实接口测试里往往是一个业务流程串起来登录拿 token用 token 查列表查详情提交数据最后验证结果。把这组接口放到同一个集合里才能体现接口测试的价值。4.1 用集合管理接口处理接口依赖在 Postman 左侧新建一个 Collection把相关接口按业务顺序放进去。比如登录获取 token查询用户列表查询用户详情创建新用户验证新用户存在这里的依赖关系很明确第 2、3、4 个接口需要用到第 1 个接口返回的 token。如果你在前面已经写了 token 写入环境变量的脚本那么集合运行时第 1 个接口执行后 token 已经自动更新后续接口直接引用{{token}}即可。还有一个容易忽略的依赖接口 B 需要接口 A 返回的某个 ID。可以在接口 A 的 Tests 脚本里把这个 ID 存成环境变量接口 B 的请求路径或请求体里再引用。const json pm.response.json(); pm.environment.set(createdUserId, json.data.id);接口 B 的请求体里写{ userId: {{createdUserId}} }这样集合运行时每个接口拿到的都是上一个接口真实产生的数据而不是写死的假数据。4.2 批量执行与结果判断在 Collection 页面点击 Runner选择集合、迭代次数、数据文件就能批量执行。运行时注意看三个指标指标判断标准失败时先检查通过率至少 95% 以上才算稳定断言字段路径、接口返回结构响应时间与单接口时对比波动是否过大网络、服务端负载、参数是否有超大数据量失败用例连续执行多次是否集中在同一接口参数依赖、token 过期、数据污染我建议不要只盯“全部通过”。如果所有用例都通过但响应时间从 500ms 涨到了 3000ms说明性能已经发生变化。接口测试不只是功能测试还要关注时间、稳定性、状态码分布。4.3 判断接口测试是否稳定不能只看一次结果新手最容易犯的错误跑一次全绿就认为测试通过。我一般会连续跑 3 次重点看两个问题第一失败是否随机。第一次跑挂在第 3 个接口第二次挂在第 5 个接口那大概率是数据依赖或者竞态条件不是断言逻辑问题。第二失败是否可解释。如果某个接口在批量环境下总是失败但单接口跑完全正常优先检查 token 是否共享、数据文件是否有重复、前置接口执行顺序是否正确。批量接口测试的稳定不是指零失败。而是每次失败都能被日志和断言解释清楚复现路径明确不会出现“这轮过了下轮又挂”的玄学问题。5. 报错别慌让 AI 变成排查搭档接口测试里一半时间花在排错上。AI 在这里的价值是帮你快速缩小范围但不负责最终的判断。下面按最常见的报错类型拆一遍。5.1 常见报错类型与排查方向现象可能原因排查方向401 Unauthorized没带 token、token 过期、token 类型错确认请求头 Authorization 是否正确填写并引用变量403 Forbidden权限不足、无访问该接口的权限确认当前账号角色是否被允许访问404 Not Found路径错、接口不存在、服务未部署确认 baseUrl 和接口路径是否一致405 Method Not Allowed请求方法不对把 GET 改成 POST或查文档确认真实方法500 Internal Server Error服务端逻辑异常提取服务端日志看参数是否导致空指针或数据异常请求超时网络慢、服务端长时间无响应先确认服务是否存活再考虑增加超时时间JSON 解析失败响应不是 JSON、内容被截断先看响应原文再检查编码和网络代理5.2 排查链路从现象到根因遇到报错后我建议按固定顺序排查不要跳着猜。第一步看现象本身。先确认这个问题是功能错误、数据错误、还是环境错误。功能错误是接口逻辑有问题数据错误是输入数据和业务约束冲突环境错误是网络、配置、权限、服务端状态导致的。第二步看输入。请求参数、请求头、请求体是否和文档一致。这里最容易忽略的是 Content-Type。有的接口要求application/json你填了text/plain服务端解析不出来返回 500 或 400。第三步看上下文。批量运行时报错要看是这个接口的问题还是上一个接口影响了它。比如上一个接口超时导致 token 没有写入环境变量当前接口拿到的就是空 token自然 401。第四步看日志。服务端日志是最终答案。如果权限允许把日志级别调成 debug看服务端到底接收到什么参数、在哪里抛异常。这是很多人跳过的一步但它往往是最直接的一步。5.3 把报错信息交给 AI但别盲目执行当你确认了现象、输入、上下文之后可以用 AI 辅助分析。比如我的 Postman 请求返回 500请求路径是 POST /api/v1/users请求体是 { username: alice, email: aliceexample.com, password: abc123456 } 响应体是{message: Internal Server Error} 这个接口在单接口调试时成功过但是放在集合里批量执行就失败。 请帮我列出可能导致这个现象的原因按概率从高到低排序。AI 可能会给出几个方向比如“前一个接口执行失败导致环境变量未更新”“数据文件里存在重复数据触发唯一约束”“批量执行时 token 过期”“顺序不对导致依赖数据不存在”。这些方向基本靠谱但需要你一条条对照日志和实际数据去验证。不要因为 AI 说“大概率是 token 过期”你就直接把所有超时都归因到 token。在我自己的排查经验里AI 最大的作用是帮我把遗漏的方向补全。比如它可能提醒我去检查 Cookie、代理、网关配置这些点单靠自己容易漏掉。但最终定位还是要结合项目代码、日志和可复现实验。6. 90 分钟怎么分配最合理以及这套方法能走多远前面把核心操作都过了一遍最后回到标题90 分钟。这个时间其实不长所以更要聚焦。不是所有 Postman 功能都要学也不是所有接口测试理论都要看关键是先把一条最小链路跑通请求、断言、变量、集合、批量、排查。6.1 时间分配建议时间段任务验证标准0-15 分钟安装 Postman连通测试接口成功发送一次请求并返回预期结果15-30 分钟写第一个状态码断言配置环境和变量断言能在测试面板显示通过30-50 分钟用 AI 生成字段断言、Schema 校验和数据文件脚本可以运行测试数据覆盖至少 5 组50-70 分钟建集合处理 token 和 ID 依赖批量执行集合能一次跑通通过率可观察70-80 分钟人为制造一个错误改错参数用 AI 辅助排查能定位到根因并修复80-90 分钟复盘测试点、断言项、数据用例列表形成可复用的接口测试清单为什么这样分配因为前 30 分钟如果只讲概念后面 AI 生成的脚本就没办法落地。后半段必须用“能跑的东西”来练不然 90 分钟结束你还是只会看文档、不会动手。6.2 适用场景和边界这套方法适合个人要快速产出接口测试脚本不想从零搭建框架。项目里没有现成接口测试平台先用 Postman 做基础验证。新手学习接口测试想通过真实请求理解接口行为。接口数量不多、业务逻辑不复杂的阶段可以快速覆盖。这套方法不适合大规模自动化回归持续集成里需要稳定调度、报告、告警。复杂业务状态机一个接口的输入依赖大量前置状态。对数据和权限非常敏感的项目每一步都需要严格审计。Postman 可以导出集合你在进阶阶段可以把它迁移到更完整的自动化体系里但这不是 90 分钟要解决的问题。6.3 下一步进阶方向如果你把 90 分钟的内容练完并且想继续深入我建议按这个顺序走第一补接口测试理论。把等价类、边界值、状态码、鉴权、幂等性这些概念和你刚写过的断言对应起来。第二学接口协议细节。HTTP 方法、状态码语义、请求头、响应头、编码格式这些是排查问题的基础。第三整理自己的提示词库。把项目中常见的接口类型、断言模板、数据生成模板保存下来。以后再遇到类似接口直接把模板丢给 AI能省很多时间。第四把测试用例和项目文档对应起来。让接口测试不仅验证“接口能调通”还要验证“接口行为符合业务预期”。最后说一句这套方法真正跑通之后你会发现 AI 帮你省掉的不是写代码的时间而是从“不知道怎么测”到“能写出第一版可运行用例”的探索时间。接口测试的核心判断还在人这里但起步的速度可以快很多。