企业官网建设流程全解析

上个月项目组排期会，领导问我：用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 四段式流程的整体设计

我在项目中把对话驱动用例生成的流程固定成了四段，每一段解决一个明确问题：

这个顺序是刻意设计的：先确认AI“理解了业务”，再让它“发散场景”，然后“钻边界”，最后“格式化输出”。前两步是防幻觉，第三步是体现测试价值，第四步才是真正产出。

我自己的经验是：第一段和第三段最容易出高质量内容，第二段AI容易铺量，第四段则要花心思约束格式，否则AI生成的用例会五花八门。

2.2 第一段：业务认知对齐怎么做

第一段对话不用急着要用例，先让AI复述业务规则。我会这样开场：

请忘掉你是测试工程师。现在你是一名业务分析师。下面这段描述来自需求文档：“用户可以申请订单退款，退款方式为原路返回；支持整单退款与部分退款；退款申请提交后不可取消，但可在审核前由客服关闭。”请基于这段描述列出：1）你理解到的核心业务规则；2）你发现到的规则不明确之处；3）需要我补充确认的问题清单。

这一段有两个作用。第一，AI列出的“规则不明确之处”往往是测试设计的金矿。比如它可能会问“部分退款的金额上限是什么？是否允许退款金额超过实付金额？”这两个问题如果需求里没有答案，你就得去找产品经理确认，确认完直接用结论去驱动后续用例生成。第二，如果AI复述规则时产生了错误理解，比如把“原路返回”理解成“统一退到余额”，这时候纠正成本最低。

实测下来，这一段适合用“角色切换”提示词，因为让AI切换角色不是为了好玩，而是为了让它调用一套不同的思维框架。业务分析师角色更关注规则完整性，直接套测试工程师角色反而会过早跳到“怎么测”。

2.3 第二段：场景枚举与优先级划分

业务对齐后，再让AI基于确认过的规则枚举场景。这轮我会明确要求“按用户操作路径”而不是“按测试类型”来枚举，因为按“正向、反向、异常”这种套路枚举，产出的场景千篇一律；按操作路径枚举，才能真正贴近用户。

实际对话片段大概是：

基于确认后的规则（我会把第一段整理好的规则清单贴进去），请以用户操作路径为维度，枚举退款申请相关的所有业务场景。要求：1）每个场景包含触发条件、操作步骤、预期结果；2）标注优先级P0/P1/P2；3）不要写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的两种方式

上下文不止可以是自然语言描述，还可以是接口定义和页面元素信息。我常用的两种方式：

第一种方式是贴接口文档关键字段。直接把接口路径、请求参数、响应码、业务约束贴进对话。例如对于退款申请接口，可以贴出字段说明：refundAmount（BigDecimal，必填，不超过订单实付金额）、refundReason（String，必填，长度不超过200）、requestId（String，必填，幂等键）。AI看到这些字段后，生成的用例自然会包含“refundAmount超过实付金额”“requestId重复提交”这类接口级用例。

第二种方式是贴页面元素和操作路径。这一步对偏UI的用例有用，可以跟Playwright这类自动化工具衔接。如果你准备让AI输出可直接转成脚本的用例，可以给它看关键页面的元素定位信息，比如“退款申请页包含订单号输入框（id=orderId）、退款金额输入框（id=refundAmount）、提交按钮（id=submitBtn）”。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能力多强，而在于你愿不愿意把需求里那些没说明白的东西，一条一条问出来。