需求评审一结束测试团队最重的活往往不是执行而是把PRD里的一堆业务描述转成可执行的接口用例。我这边团队之前一直靠人肉完成直到我们把AI接进这条链路才真正感觉到自动化测试流程里那块“动手不动脑”的环节可以被省掉。今天想聊的不是PPT里的AI自动化测试概念而是我们实际跑通的一条路线从需求文档输入经过结构化抽取、用例生成、规则校验三层处理最终产出可直接入库的接口用例。这中间有真实收益也有不少坑我把能复用的细节尽量都写出来。1. 先想清楚AI在“需求文档到接口用例”这条链路上到底扮演谁1.1 绝大多数团队卡在“预期太高”一聊到AI自动化测试很多人第一反应是AI读PRD、AI出用例、AI执行用例、AI出报告整个测试环节全自动。我跟几个想引入AI的团队交流过大家最初的预期基本都这样。但真跑过一轮之后你会发现如果哪个方案商跟你承诺“全自动”那大概率没跑过真实项目。原因不复杂PRD写得好不好、字段全不全、接口文档准不准直接决定了AI的上限。AI不是神它是在你给的材料基础上做理解和转换。材料本身是残缺的那输出一定有大量需要人工修补的地方。我后来和团队把预期调整成一句话AI不是替代测试而是替代从需求到用例这条链路上最耗时的“转译”环节。读PRD、总结业务规则、把规则映射成接口参数这四件事里有两件半是AI能干的剩下那半件才是真正的测试设计。1.2 把链路拆开才知道该在哪个环节加AI我习惯先把一条人肉链路拆成粒度更小的步骤通读PRD找到业务规则和边界条件。把规则转成测试场景比如正常、边界、异常。把场景映射到接口参数比如路径、方法、请求体字段。为每条场景写前置条件和预期结果。人工查漏看有没有规则被漏掉。我们用一个中等复杂度的注册模块做过一次粗略计时人工从PRD到产出50条接口用例大约需要4小时其中“找规则”和“转接口参数”两个步骤占掉2.5小时以上。剩下的时间才是测试设计本身。这样拆完加AI的点就很明确了让AI做规则抽取、场景草拟、参数转换人工做规则确认、用例审核、查漏补缺。这里我画了一条人机分工的边界实际用起来比较舒服环节谁来做AI能替代多少替代后省下的时间占比通读PRD并理解业务人 AI能替代大部分阅读和总结动作40%提炼业务规则AI起草人确认AI能列出候选规则清单60%设计覆盖场景人以AI草稿为基础调整部分AI容易漏隐性规则30%场景到接口参数的转换AI 脚本校验AI能输出结构化参数体70%判断预期结果是否合理人不能替代AI可能编造状态码60%需求变更后的用例维护AI 人AI能做增量差异分析40%1.3 我给AI的定位一个阅读能力强但不懂业务的实习生如果一个实习生刚入职你让他读PRD出用例他会怎么做他会读得很快能提炼出一堆字面上的规则也能按模板把用例写出来但遇到“这里产品其实想表达的是XXX”这种潜台词他就抓瞎了。AI现在的状态就是这个。所以我在团队里反复强调一个原则AI出第一稿人做最后一公里。任何没有被校验过的AI用例都不能直接进用例库。这个定位看起来保守但恰恰是它能稳定落地到项目里的原因。2. 需求文档进模型之前先把它拆成一张“业务规则清单”2.1 为什么不能把PRD直接扔给模型很多人实验的时候喜欢直接把整篇PRD丢给模型然后问一句“请帮我生成测试用例”。这么玩的产出基本不能直接用因为PRD的噪声太多了里面有一大段用户流程图文字描述跟接口测试没关系有原型图的说明模型会把视觉元素当成接口字段有历史遗留的“本版本暂不支持”这类描述模型可能把废弃逻辑也生成用例真正关键的规则往往只有几句话但它们淹没在大量描述文字中。举个例子PRD里写了一句“验证码5分钟内有效过期后需重新获取”。这句话夹在第三段里的不起眼位置。直接把PRD扔给模型生成用例它很容易漏掉这条边界规则但如果我们先让AI把规则清单抽出来这条规则就会出现在结构化清单里后面逐条设计用例时不可能漏。2.2 第一层抽取让AI输出结构化规则JSON我们第一步做的不是生成用例而是让AI把PRD里的内容抽成一份“业务规则清单”。这个清单的结构要固定否则后面没法用。我要求AI输出的JSON里至少包含三块业务规则、字段定义、接口交互点。给一个简化例子。假设PRD里有这么一段用户通过手机号注册手机号需为11位大陆手机号。用户输入手机号后系统发送6位数字验证码验证码5分钟内有效。密码必须同时包含大写字母、小写字母和数字长度8到20位。若手机号已注册则提示“该手机号已注册”。AI抽取后的结果大概是{ module: 注册模块, business_rules: [ {rule_id: R001, type: normal, desc: 合法手机号正确验证码合规密码注册成功}, {rule_id: R002, type: boundary, desc: 手机号少于11位或超过11位注册失败}, {rule_id: R003, type: boundary, desc: 验证码超过5分钟有效期注册失败}, {rule_id: R004, type: exception, desc: 手机号已注册返回业务错误提示}, {rule_id: R005, type: boundary, desc: 密码长度小于8位或大于20位注册失败}, {rule_id: R006, type: exception, desc: 密码缺少大写字母/小写字母/数字注册失败} ], fields: [ {name: mobile, alias: [手机号, phone], constraint: 11位数字以1开头}, {name: code, alias: [验证码], constraint: 6位数字有效期5分钟}, {name: password, alias: [密码], constraint: 8-20位含大写字母、小写字母、数字} ], interfaces: [ {request_path: /api/v1/register, method: POST} ] }这里有一个细节值得注意fields里的alias字段是我们被坑过之后才加上的。PRD里写的是“手机号”到了接口文档里字段名可能叫mobile也可能叫phone。让AI抽取时把别名也保留下来后面做用例生成的时候就有了一条清晰的字段映射链路不然AI会在PRD字段和接口字段之间疯狂猜。2.3 人工确认规则清单最便宜的质量保障规则清单抽取出来后先让人完整看一遍再进入下一步不要急着生成用例。这一步在流程上看起来多了一道但实际非常轻一个中等模块的规则清单通常也就二三十条人扫一遍二三十分钟搞定。但如果不做这一步让AI直接基于PRD生成用例等用例全部出来再校对的返工成本是这一步的好几倍。我们第一次跑的时候图省事跳过确认结果AI把一条“同一手机号30天内只能注册一次”的规则理解成“同一手机号永远不能重复注册”后面20多条受影响的用例全要改。所以从那以后无论多急这条人工确认都保留。3. 提示词工程给AI的不是问句是一份用例设计图纸3.1 开放式提问为什么效果差“请为注册接口生成用例”这种问法我相信很多人都试过。模型确实会给你生成用例但生成出来的往往是一堆看不出体系的东西场景之间没有层级关系边界条件东一个西一个前置条件基本是空的请求体也可能和接口文档对不上。这种用例拿去执行十条里能真正跑通两三条就算不错了。问题不在模型笨而在于你给它的是一道开放题而不是一张带约束的图纸。AI擅长在你给定框架的前提下做填充和扩展你不给它框架它就按照自己的“平均经验”自由发挥而这种发挥往往是一种理想化的、和你的业务对不上的状态。3.2 用例生成提示词的四个组成部分我们后来把生成用例的提示词收敛成四个固定组成部分业务规则清单第2章的结构化产物。接口契约信息包括方法、路径、参数类型、必填校验等。输出模板也就是每条用例必须包含哪些字段。两条few-shot示例让AI知道我们想要的是什么风格。提示词结构大概是你是接口测试用例设计专家。请根据以下业务规则和接口定义设计接口测试用例。 要求 1. 每条用例必须包含case_id、scenario、preconditions、request、expected。 2. request必须包含method、path、headers、body。 3. expected必须包含status_code、business_code、assert_fields。 4. 场景需覆盖normal、boundary、exception三类。 5. 预期结果只能使用接口定义或业务规则中出现的字段禁止自行编造状态码和错误码。 6. 输出格式为JSON数组。 业务规则 {此处粘贴第2章的规则清单} 接口定义 {此处粘贴接口契约} 请开始生成。这个提示词看起来平平无奇但里面两个“禁止”非常关键禁止编造状态码、禁止编造字段。不加这两句AI就会给你编一整套不存在的错误码体系出来。3.3 一个具体的生成结果长什么样AI按这个提示词生成的用例大概是这样的[ { case_id: REG_001, scenario: 合法手机号正确验证码合规密码注册成功, preconditions: 通过数据工厂预置手机号13800138000的未注册状态在验证码存储中写入验证码123456, request: { method: POST, path: /api/v1/register, headers: {Content-Type: application/json}, body: {mobile: 13800138000, code: 123456, password: Passw0rd} }, expected: { status_code: 200, business_code: 0, assert_fields: [user_id, token] } } ]注意到preconditions这个字段没有这是我们后来加进去的。第一版让AI生成用例时它只输出“正例注册成功”这种和没写没区别的用例。真实接口测试里99%的场景都需要准备数据验证码要先写入Redis、用户状态要先重置、风控标记要先清除。所以我们在输出模板里强制加了preconditions让它把“这条用例执行前需要准备什么”写清楚。加了这一项以后用例的可执行度提高了非常多。3.4 一次别生成太多分批反而快如果你把几百条规则一次性塞给模型让它生成所有用例结果通常很差。原因有两个一是模型上下文窗口有限塞太多内容之后它会“忘记”前面的规则二是审核者一次看五十条用例和看十条用例审核质量完全不一样。我们现在的做法是按模块分批一次生成10到15条。生成之前还会加一个小技巧让AI先把规则编号R001、R002这样列一遍然后再按规则逐条对应场景。这样无论从生成结果还是审核节奏上都更可控遗漏率明显下降。4. 校验层设计把AI的“一本正经胡说八道”挡住4.1 翻车现场一AI会编造接口字段AI一个很典型的毛病是你给的接口定义里根本没有某个参数但它会依据自己的“常识”把参数补进去。比如接口文档里手机号字段是mobile生成时它写成了phoneNumber或者业务里根本没提渠道它给body里加了一个channel字段。这种问题在没有校验层的时候非常隐蔽因为人浏览用例的时候容易被“看起来像那么回事”带过去。我们的解法是做一个字段白名单校验从接口契约里抽出一个所有合法字段的集合生成的每条用例的body和query参数都必须在这个集合里凡是白名单之外的字段直接标红。4.2 翻车现场二AI会编造预期结果另一个高频问题出现在expected里。业务规则只写了“手机号已注册提示报错”AI就自己猜了一个400状态码甚至编了一个企业根本用不到的错误码E1001。如果这种用例直接进入执行阶段请求发出去以后收到的实际返回和预期对不上你根本分不清是接口Bug还是用例本身写错了。解法是状态码和业务码白名单。在提示词里就限定AI只能从我们提供的枚举里选择状态码和业务码并且给一个固定取值表。取值表内容类似类型允许值说明HTTP状态码200, 400, 401, 404, 409, 422, 500对应成功、参数错误、未认证、不存在、冲突、校验失败、服务异常业务码0, 10001, 10002, 100030为成功10001参数错误10002业务冲突10003验证码错误AI只要敢输出表里没有的值校验脚本直接打回重写。4.3 翻车现场三规则漏掉导致覆盖不到位这个问题的隐蔽程度比前两个高。前两个是“写错了字段/写错了预期”肉眼能看出来但漏场景是“该有的用例根本没出现”你如果不知道业务里有这条规则你就永远不会觉得它漏了。比如PRD里写着“同一手机号30天内只能注册一次”如果规则抽取环节没有把它捞出来那AI生成的用例里就永远不会有这个场景。为了解决这个问题我们加了一步覆盖率反检用规则清单逐条问“哪条用例覆盖了R003”凡是找不到对应用例的规则立即补生成。4.4 一套简单的自动化校验脚本就够了很多人以为这块要上很复杂的平台其实一段二三十行的Python脚本就能挡住80%的翻车。核心就是三个函数字段白名单校验、状态码枚举校验、规则覆盖反检。字段校验的框架大概是class FieldWhitelistValidator: def __init__(self, allowed_fields: set): self.allowed_fields allowed_fields def validate(self, case: dict) - list: errors [] body case.get(request, {}).get(body, {}) for key in body.keys(): if key not in self.allowed_fields: errors.append(fcase {case.get(case_id)}: 字段 {key} 不在白名单中) return errors状态码校验就是直接比对枚举规则覆盖反检就是拿规则ID与用例的tag字段做关联。跑完三个检查输出一份校验报告哪条用例哪有问题一目了然。这一步的价值不是追求“完美AI”而是把错误尽早暴露在进入用例库之前。4.5 人工还是得看但看的姿势变了有了校验层之后人工审核的负担减轻不少但并没有消失。现在审核的人不再从零设计用例重点看三件事业务规则理解得对不对、边界条件是否覆盖到、预期结果是否符合产品逻辑。我自己团队跑下来的感觉是50条AI生成的用例人工审核后真正需要调整的大概是10到15条主要集中在业务语义上。省下的是从无到有的设计时间留下的还是人的业务判断这种分工比纯人工或者纯AI都健康。5. 从验证到落地流程嵌入、工具选型与效果度量5.1 接在哪个节点需求评审通过后、开发提测前要把这个流程真正落地到团队里不是写个脚本自己玩玩而是要找个稳定的触发时机。我们选择的是需求评审通过之后、开发提测之前。具体流程是PRD评审通过。测试负责人把PRD交给AI做规则抽取。AI输出业务规则清单人工确认。确认后调用用例生成跑校验脚本。测试人员审核用例修正业务语义。用例入库存入用例管理系统后续关联执行。比起原来的流程前期只多了一个“规则清单确认”的环节后期却少了一整个下午或一整天的“埋头写用例”时间。整体节奏变化不大但人的精力被释放了出来。5.2 技术栈怎么选别一上来就追求平台化我们在技术选型上走过一点弯路一开始想得很宏大甚至考虑过自研一个AI测试平台后面发现完全没必要。第一版落地其实只要几个组件组件作用我们用的方案模型调用规则抽取和用例生成调用兼容OpenAI格式的API也试过开源模型流程编排串联抽取、生成、校验一个简单的Python脚本结构校验保证输出符合预期Pydantic用例管理版本管理和入库Git 现有用例管理平台接口如果团队有条件模型部分可以用开源方案本地部署但从实际效果看多数团队的瓶颈不在模型而在提示词设计和规则清单质量。模型的选择只要能力在中等偏上具体哪家都不是决定性因素。5.3 效果度量别只看生成速度要看采纳率和缺陷发现率我们团队跑了两个迭代之后汇总了几个数据指标落地前落地后一个中等模块的接口用例生成时间约4小时约1.5小时含审核用例采纳率不修改直接可用100%人工第一周约65%规则清单调顺后约80%需求覆盖率靠人记忆经常漏规则清单反检覆盖明显更完整上线前缺陷发现部分漏测接口用例提前拦下两个逻辑错误有一点必须提醒不要只盯着生成速度。AI生成100条但100条都要改等于没省。真正应该看的是采纳率也就是不修改直接能用的比例。采纳率低大概率是规则清单写得不好或者接口契约信息不完整这时候该回头调上游而不是继续调模型。5.4 需求变更后怎么维护增量更新而不是全量重跑这是我认为整个链路里最容易被忽略的环节。需求变了界面、接口可能都会变如果此时把整份PRD重新丢给AI全量再生成一遍用例结果一定是灾难之前人工审核过的用例被AI悄悄改了写法评审过的基线被冲掉了。我们的做法是增量更新。需求变更时把变更的那段PRD单独摘出来喂给AI让它对比旧规则清单输出三样东西新增的规则、删除的规则、受影响的用例编号。然后只对受影响的那部分用例重新生成其他保持原样。这个“变更影响分析”功能实现起来也不复杂本质上也是提示词设计问题。但它的价值很大因为需求变更才是团队常态处理不好这套流程很快就会废掉。6. 如果想在自己团队复制这套做法我的三条建议6.1 先找一个需求最稳定的模块做POC不要一上来就拿核心支付、账务这类高风险模块试。压力大不说模型一旦出错被放大和质疑的概率也大。我们当时选的是一个权限管理模块规则相对固化字段不多历史用例齐全特别适合做对照实验。跑两周之后数据一出来团队内部自然就信了后续推广阻力小很多。6.2 把“规则清单”当成流程资产而不是中间产物我跑完这套流程最大的体会是哪怕AI生成的用例最后不能用抽出来的规则清单本身已经是巨大的价值。因为它是需求的结构化表达评审的时候可以用开发提测的时候可以用后面写自动化脚本还是要用。所以不要让规则清单成为一个临时产物。它应该入库应该有版本应该和需求变更联动。把它当成团队的一项资产来维护AI用例生成只是它的一项应用而已。6.3 维护一张“AI生成质量错误类型记录表”最后分享一个实战小习惯。落地AI生成用例的前几周我让每个审核的测试同学随手记录一下AI的错误类型比如“字段写错”“状态码编造”“边界场景漏掉”“业务理解偏差”。每周汇总一次看趋势。这个表看起来很小用处却很大当错误类型总体在下降说明规则清单和提示词已经调顺了如果某个错误类型一直降不下来说明不是模型问题而是源头输入有问题。有了这张表你就能判断这个流程做得到底好不好而不是靠感觉。