对话驱动AI测试用例生成：从翻车到提效的完整实践

上个月项目组排期会领导问我用AI生成测试用例提效到底能在哪个环节省出半天时间我当时愣了一下因为那会儿我们团队刚把“让AI帮忙写用例”从口号推到试用阶段结果远没有想象中顺利——AI确实能哗啦啦吐出一堆用例但真正能落到测试计划里的不到三成。这事让我意识到一个关键问题AI生成测试用例的瓶颈从来不是“能不能生成”而是“怎么生成才靠谱”。后来我们调整了思路把重心从“给AI一个需求让它一次性输出”改成“通过对话逐步澄清需求、修正边界、对齐场景”也就是标题里说的对话驱动用例生成。跑了两个迭代之后用例的有效率明显上来了评审返工也少了很多。这篇文章就把这套实践完整拆开讲包括为什么对话驱动比一次性生成更可靠、四段式对话流程怎么搭、怎么让AI真正理解被测系统、以及我踩过的那些坑。1. 从“提效口号”到“真提效”为什么用例生成必须走对话这条路1.1 我在评审会上被问住的那一次先说说我为什么对“AI生成测试用例”这件事较真。年初我们接了一个订单中心重构项目业务规则多到离谱改地址、改发票、合并支付、部分退款、跨商户退款……光退款这一条分支就能列二十多种状态组合。按老方法测试设计至少得三个工作日评审还要再花两天。团队里当时有个说法能不能让AI先出一版我们在这基础上改我试了一轮结果非常典型——让AI看了需求文档后一次性生成60条用例表面看状态齐全实际一评审就发现问题八成用例集中在“正常流程”和“常见异常”真正刁钻的边界条件几乎没有还有几条用例的预期结果跟业务规则完全对不上。问题不在AI本身而在提问方式。我给AI的输入是一份冗长的需求说明书但需求说明书里有大量隐含假设比如“改地址后已支付订单的运费是否重新计算”“退款金额超过原支付金额时怎么处理”这些规则文档里根本没写清楚AI自然只能靠“猜”。一次对话、一次输出本质上是在用残缺信息做一次性推断出错是必然的。1.2 一句话prompt生成用例的典型翻车现场很多团队第一次尝试“AI生成测试用例”用的prompt是这种风格“你是资深测试工程师请根据以下需求生成完整测试用例用户可以在APP上申请退款退款原路返回支持部分退款。”这种写法看着省事实际翻车方式非常统一。翻车点一AI会把教科书里的模板硬套进来。你让它生成“完整”用例它就给你铺等价类、边界值、错误提示、兼容性测试一套操作猛如虎结果里出现“验证APP在弱网环境下退款按钮的响应时间”——需求方看完直接问这条用例跟当前迭代有什么关系翻车点二AI会编造不存在的规则。比如需求只写了“退款原路返回”AI自动补了一句“若原支付渠道已关闭则退款至用户余额”。这看起来合理但如果产品经理没有这个规则这条用例就不能要。翻车点三没有对齐“什么是完整的”。一次生成结束后AI无法主动追问“你们退款支持部分退款吗”“退款金额是含税还是不含税”“原路返回失败后的兜底逻辑是什么”。这些恰恰是测试用例里最有价值的部分。1.3 对话驱动的本质把隐性需求“挤”出来后来我重新审视这件事发现对话驱动解决的问题恰恰是那些一次生成解决不了的东西。对话驱动的本质不是“多轮聊天”而是把需求里的隐性假设通过结构化追问逐层暴露出来每暴露一层AI生成的用例就往真实业务贴近一层。我做过一个类比一次性生成就像你请一位外包测试工程师看了一小时文档后直接交用例对话驱动则像你把这位工程师拉进评审会需求方、开发、产品在同一个群里互相追问把“没说出来的规则”一条条问出来。后者慢一点但每一条追问都直接产出用例。实际操作里对话驱动还有一个额外好处AI每一轮生成的中间结论可以被复用。比如AI基于“部分退款”生成了十条边界用例你追问“退款金额可以精确到分吗”它会把这十条用例里的金额字段统一修正而不是推翻重来。这种“增量修正”能力靠一次性prompt是拿不到的。2. 一套能直接用的四段式对话流程附提示词和真实对话片段2.1 四段式流程的整体设计我在项目中把对话驱动用例生成的流程固定成了四段每一段解决一个明确问题阶段核心目标输入输出第一段业务认知对齐需求描述、用户故事业务规则清单、理解确认第二段场景枚举与优先级规则清单、角色清单场景列表按P0/P1/P2分级第三段边界与异常挖掘场景列表、接口/页面信息边界值与异常流补充第四段用例落盘前两轮结果、用例模板结构化测试用例这个顺序是刻意设计的先确认AI“理解了业务”再让它“发散场景”然后“钻边界”最后“格式化输出”。前两步是防幻觉第三步是体现测试价值第四步才是真正产出。我自己的经验是第一段和第三段最容易出高质量内容第二段AI容易铺量第四段则要花心思约束格式否则AI生成的用例会五花八门。2.2 第一段业务认知对齐怎么做第一段对话不用急着要用例先让AI复述业务规则。我会这样开场请忘掉你是测试工程师。现在你是一名业务分析师。下面这段描述来自需求文档“用户可以申请订单退款退款方式为原路返回支持整单退款与部分退款退款申请提交后不可取消但可在审核前由客服关闭。”请基于这段描述列出1你理解到的核心业务规则2你发现到的规则不明确之处3需要我补充确认的问题清单。这一段有两个作用。第一AI列出的“规则不明确之处”往往是测试设计的金矿。比如它可能会问“部分退款的金额上限是什么是否允许退款金额超过实付金额”这两个问题如果需求里没有答案你就得去找产品经理确认确认完直接用结论去驱动后续用例生成。第二如果AI复述规则时产生了错误理解比如把“原路返回”理解成“统一退到余额”这时候纠正成本最低。实测下来这一段适合用“角色切换”提示词因为让AI切换角色不是为了好玩而是为了让它调用一套不同的思维框架。业务分析师角色更关注规则完整性直接套测试工程师角色反而会过早跳到“怎么测”。2.3 第二段场景枚举与优先级划分业务对齐后再让AI基于确认过的规则枚举场景。这轮我会明确要求“按用户操作路径”而不是“按测试类型”来枚举因为按“正向、反向、异常”这种套路枚举产出的场景千篇一律按操作路径枚举才能真正贴近用户。实际对话片段大概是基于确认后的规则我会把第一段整理好的规则清单贴进去请以用户操作路径为维度枚举退款申请相关的所有业务场景。要求1每个场景包含触发条件、操作步骤、预期结果2标注优先级P0/P1/P23不要写UI细节聚焦业务逻辑4如果某个场景依赖前置条件如必须先完成支付单独说明。AI这时候通常会给出类似这样的场景列表P0支付成功后申请整单退款原路退回成功。P0申请部分退款退款金额小于实付金额原路退回成功。P1支付成功后申请退款但支付渠道已关闭系统提示联系客服处理。P1退款申请提交后用户尝试取消系统提示不可取消。P2退款申请审核期间客服关闭申请流程终止。到这里我已经能判断哪些场景是“真需求”哪些是“AI脑补”。脑补的场景直接删掉并在回复里明确告诉AI“这条场景不存在不要生成类似逻辑”。这个反馈非常重要AI会在后续轮次里自动避开同类问题。2.4 第三段边界与异常挖掘第二段拿到场景后第三段的核心是让AI针对每个P0/P1场景逐一补边界条件和异常流。这里的关键是一个一个场景地追问不要一上来就说“请补充所有场景的边界值”。我试过一次铺开的结果是AI平均每个场景只给一两条边界深度不够。正确做法是挑最复杂的场景单独问请只针对“部分退款”这一个场景展开以下内容1金额边界最小退款金额、最大退款金额、超过实付金额、精确到小数后几位2状态边界订单处于哪些状态时可发起部分退款哪些状态不可3次数边界同一订单是否支持多次部分退款多次退款的累计上限4异常流原路返回失败、退款处理中订单被关闭、并发退款请求。这样一轮下来单个场景的用例密度明显提高。坏处是对话轮次会增多但这是值得的因为测试用例的价值本来就集中在这些边界和异常上。你花三轮对话把“部分退款”问透比让AI一次性生成五十条同质化用例要有用得多。2.5 第四段用例落盘与格式约束边界挖掘完成后最后再输出完整用例。这个阶段我会给AI贴一个明确的用例模板字段防止它自由发挥请将上述所有场景整理成测试用例表格字段固定为用例编号、所属场景、前置条件、测试步骤、输入数据、预期结果、优先级。其中测试步骤用数字序号列出输入数据必须写具体值不要写“任意合法金额”这类占位符预期结果必须包含状态变化和提示信息。格式约束在这一步极其重要。AI默认生成的用例经常出现两件事输入数据写“有效金额”“无效手机号”这类模糊占位符——这对后续执行没有帮助预期结果写“退款成功”四个字——没有状态变化描述评审根本没法判断这条用例是否真的符合需求。输出之后还有一个必做动作把整个对话过程保存下来连同用例一起放进测试资产库。因为对话过程本身记录了需求澄清的痕迹比如产品经理说过“退款金额含用户实际支付时的优惠分摊”这句话在需求文档里可能没有但在对话里出现了它比最终用例更有追溯价值。3. 把被测系统“喂”给AI上下文设计才是防幻觉的关键3.1 一份靠谱的被测系统描述长什么样对话驱动虽然解决了“追问”的问题但如果AI连被测系统长什么样都不知道追问也无从谈起。很多团队的现状是测试人员自己心里清楚系统逻辑但喂给AI的上下文只有一句话“这是一个订单中心”。AI不知道订单表结构不知道退款状态机不知道支付渠道有哪些自然只能靠通用知识生成“看起来对”的用例。我在项目中总结了一套给AI描述系统的最小上下文清单系统名称、核心业务目标一句话。关键实体与状态机比如订单实体包含待支付、已支付、退款中、已退款、已关闭等状态写明状态流转条件。业务规则列表跟当前迭代相关的规则逐条写清宁可重复也不要让AI猜。外部依赖与边界比如支付渠道、库存系统、发票系统以及这些依赖不可用时的降级策略。非功能约束事务一致性、幂等性要求这些会影响并发类用例。有了这份上下文AI生成用例时的“脑补空间”会被大幅压缩。比如你明确写了“退款中状态下允许客服关闭退款单关闭后订单回到已支付状态”AI就不会再生成“退款中订单可以再次发起退款申请”这种错误用例。3.2 把接口定义和页面元素交给AI的两种方式上下文不止可以是自然语言描述还可以是接口定义和页面元素信息。我常用的两种方式第一种方式是贴接口文档关键字段。直接把接口路径、请求参数、响应码、业务约束贴进对话。例如对于退款申请接口可以贴出字段说明refundAmountBigDecimal必填不超过订单实付金额、refundReasonString必填长度不超过200、requestIdString必填幂等键。AI看到这些字段后生成的用例自然会包含“refundAmount超过实付金额”“requestId重复提交”这类接口级用例。第二种方式是贴页面元素和操作路径。这一步对偏UI的用例有用可以跟Playwright这类自动化工具衔接。如果你准备让AI输出可直接转成脚本的用例可以给它看关键页面的元素定位信息比如“退款申请页包含订单号输入框idorderId、退款金额输入框idrefundAmount、提交按钮idsubmitBtn”。AI生成的用例步骤里就会明确引用这些元素后续转Web自动化时少一层翻译成本。实际使用中接口方式的效果明显好于页面方式。原因也不难理解接口是有严格契约的字段约束就是天然的测试点页面元素信息虽然具体但AI无法从中推断业务规则。所以我建议优先给接口定义页面元素只在需要生成E2E用例时补充。3.3 当AI说出“我假设”时你要警惕什么对话过程中AI会频繁说出“我假设”“通常来说是”“一般系统会”这类表达。我的经验是这类表达就是失败预警。举个例子AI我假设当支付渠道返回失败时系统会将该笔退款标记为失败并允许用户重试。这就是一个没有依据的假设。如果你不纠正它接下来就会生成“重试退款成功”的用例。但这些用例依据的是AI自己的世界模型不是你的系统。想避免这个问题在第二段对话后加一个确认动作把AI生成的每一类场景里出现的“假设”单独挑出来逐个确认确认不了的直接删掉对应场景。另外还有一种隐蔽情况AI不会直接说“假设”而是把假设打包在“常见做法”里比如“按照互联网常见电商逻辑退款一般在24小时内到账”。这类内容也要保持警惕——测试用例里的时间是具体值如果需求没有明确“24小时内到账”这条用例就不应该出现。4. 生成不等于交付我会用这四个硬指标卡用例质量4.1 可执行性检查每条用例都得能跑起来AI生成完用例第一步不是评审覆盖度而是做可执行性检查。我见过最多的问题是用例步骤写得像散文执行人根本不知道下一步做什么。不合格的写法是“验证系统对异常输入给出合理提示”——什么叫异常输入合理提示是什么合格的写法应该是“在退款金额输入框填写-10点击提交断言页面提示‘退款金额不能小于0’提交按钮不可二次点击”。可执行性检查我一般逐条看三个点前置条件是否完整、步骤是否有明确操作对象和输入值、预期结果是否可观察。三条都过这条用例才算“能跑”。为了让AI一次通过这项检查我在落盘阶段的提示词里加了硬性要求步骤必须包含“输入具体值”“点击哪个按钮”“断言什么现象”三要素。4.2 需求覆盖核对拿需求清单逐条打勾可执行性之后是覆盖度检查。这一步我用最笨但最有效的方法拿需求清单逐条打勾。把需求文档里的业务规则拆成一条条可验证的规则然后对着AI生成的用例一条条找“有没有用例覆盖到”。比如需求里有这么一条“退款金额只支持原路返回且退款成功后订单状态变更为已退款退款单状态变更为已完成。”你需要确认用例里是否存在同时验证三个点的场景原路返回、订单状态已退款、退款单状态已完成。只验证了“原路返回”但没有验证状态变化的用例覆盖度就不达标。这轮检查还有一个容易漏的地方“不应该发生的事”有没有覆盖。需求里的“不可取消”“不可重复退款”“金额不能超过实付金额”这类否定性规则AI生成的用例经常漏掉。我一般会在核对清单里单独列一栏“否定性规则覆盖”逐条确认。4.3 冗余与冲突扫描AI特别喜欢铺量AI生成用例的一个典型毛病是铺量同一个业务逻辑换几个不同但等价的输入值生成好几条用例看起来数量庞大实际覆盖点完全一样。比如“退款金额1元、2元、3元都退款成功”这种情况在部分退款的边界上只需要保留一条正常用例和一条最小金额边界用例不需要把中间值都穷举。冗余用例的代价不只是评审时间它还会稀释真正重要的用例的曝光度让执行者分不清优先级。我在对话中会在第二段开始前就告诉AI同一个场景下如果多条用例仅因输入值不同而预期结果相同只保留边界最大或最小值一条。冲突扫描相对少见但更致命。AI有时候会在生成“退款申请提交后不可取消”这条用例时又在另一个场景里隐含着用户可以撤销退款申请的逻辑。这种冲突在跨场景用例之间最容易出现因为AI对话有上下文遗忘聊到后面忘了前面确认过的规则。检查时我会把所有带“取消”“关闭”“撤回”这类动作的用例拎出来专门核对业务规则里对应的允许/禁止关系。4.4 从对话记录反查设计思路最后一个指标没法自动化但非常有价值从对话记录中反查设计的合理性。第四段落盘后我会把对话记录从头到尾翻一遍重点看每一轮追问后AI调整了什么。如果追问了“部分退款是否支持多次”之后AI只是在后续用例里改了金额字段而没有增加“多次部分退款累计金额上限”的相关用例说明它没有真正理解这次追问的含义生成的用例质量就要打折扣。这种问题在最终用例里看不出来必须在对话过程里找答案。所以我给团队定了个规矩凡是对话驱动生成的用例集必须能回答“这些用例对应的规则是怎么确认的”这个问题。答案要么来自需求文档原文要么来自对话中与需求方的确认记录。无源之水式的用例一律退回重新生成。5. 我在真实项目里踩过的五个坑含解决办法5.1 对话漂移聊到第10轮AI开始自说自话对话驱动最大的实操问题是上下文漂移。前几轮AI还能严格遵守你确认过的规则聊到后半程尤其是你中间穿插了几个不相关追问之后AI会“默认”一些之前已经否定过的规则。比如第一轮你明确指出“退款申请提交后不可取消”到第八轮你问“审核中的退款单能否编辑金额”AI可能直接回答“可以编辑提交后仍可修改”。它并不是故意改口而是长对话中的注意力权重重新分配把后来出现的模糊信息当成了新规则。我的解决办法是分段式上下文重置。每一段对话开始时不假设AI记得上一段的全部结论而是手动把本段需要的规则摘要贴进去。规则摘要保持在几条以内只放与本段强相关的结论。这样做虽然会多几次粘贴但换来的是规则一致性大幅提升。实测把长对话拆成四段之后漂移导致的错误用例减少了大概七成。5.2 过度设计把等价类和边界值混在一起刷屏另一个高频问题是AI会把“看起来专业”的测试用例全塞进来。比如你让它生成“退款金额异常”的用例它可能一次性输出负数、0、空值、超长数字、带小数、超过实付金额、未知支付渠道、网络超时、重复提交……看起来覆盖很全但这些用例外层其实是“传参异常”内层才是“业务异常”混在一起既增加评审负担又让人抓不住重点。我调整的方式是给AI加一层“用例类型”分类约束规则类用例验证业务规则本身比如退款金额上限。接口类用例验证参数校验与异常返回比如负数、空值。状态类用例验证状态流转与并发冲突比如退款中再次退款。体验类用例验证提示文案交互比如弱网、超时提示。分类之后AI生成的内容不再是一锅炖。评审时可以按类型快速判断哪些是当前迭代必须保留的哪些可以后续再补。实际效果是评审时间压缩了一半以上。5.3 敏感信息进提示词一个必须绕开的雷区这一点虽然不是技术问题但比技术问题更重要。AI对话工具通常会把内容送到外部模型服务这意味着你不能把生产环境的真实数据、用户手机号、支付流水号、身份证号直接贴进提示词。这是数据安全合规的底线。我见过有同事为了省事直接把数据库里的一条真实退款记录拷进对话让AI分析字段。这个动作的风险非常大。正确做法是要么使用模拟数据把手机号改成13800000001这种明确无主的数据要么只贴字段名和类型不贴具体值要么使用本地部署的模型确保数据不出内网。具体到用例生成场景建议建立一条硬规矩给AI的上下文只能包含字段名、字段类型、取值范围、业务规则不能包含生产环境真实数据。这条规矩要写进团队的提示词模板里不能只靠个人自觉。5.4 成本与速度多轮对话到底值不值对话驱动的成本确实比一次性生成高。多轮对话意味着更多的token消耗、更长的等待时间也意味着测试人员要花更多精力在“陪AI聊天”上。值不值我的看法是分场景。当前迭代业务规则复杂、状态多、坑深的时候比如退款流程、权限体系、支付对账对话驱动非常值。这些场景传统人工设计成本本来就要三五天AI对话多消耗一些token完全可以接受。反过来如果只是给一个简单的展示页面、纯静态内容的增删改查生成用例一次性prompt足够没必要走完整四段式流程。我在团队里给了一个简单的判断标准**需求文档中能被找到的“规则描述”数量超过十条或者存在多状态流转就启用对话驱动流程否则走快速生成流程。**这个标准执行了两个迭代提效和成本控制都取得了平衡——快速流程控制低价值用例的生成成本对话驱动流程专攻高价值的复杂业务。5.5 工具链衔接从用例集到自动化脚本的最后一步最后分享一个让对话驱动流程真正闭环的细节用例落盘后如果团队用的是Playwright这类Web自动化框架别急着让AI直接生成脚本而是先让AI按固定格式把用例步骤结构化比如给每一步加上“操作类型”字段navigate、fill、click、assert_text、assert_url。AI生成了这个结构之后再让它基于这个结构生成自动化脚本成功率会明显高于直接从自然语言用例跳脚本。原因是自然语言里大量隐含上下文比如“输入有效金额”这句话不告诉AI填什么数值它就只能随机编。但结构化步骤里预先填充了具体输入值和预期结果AI做脚本翻译就是一个确定性任务。这条链路我实测下来从对话结束到可运行脚本初版大概只要再花十几分钟比手动翻译用例节省的时间非常可观。这个实践最让我有成就感的地方倒不是提效数字而是它把测试设计从“写用例”变成了“定义问题和确认答案”——AI负责把答案铺开人负责判断哪些答案是对的。对话驱动能不能在你们团队落地核心不在于AI能力多强而在于你愿不愿意把需求里那些没说明白的东西一条一条问出来。