把需求文档直接粘给 AI 让它列测试点这个动作我试了不下十次结果每次都能用一句话总结AI 给出的测试点第一眼很全一过评审就散架。要么漏掉状态流转里的关键分支要么干脆给我一个需求里从来没提过的功能还得我一条条回去翻原文核对。这是《AI 测试工程笔记》系列的第三篇想认真聊的是我这几个月在项目里真正跑通的一套流程——先把需求整理成结构化的需求模型再让 AI 在这个模型上做测试设计。它适合的读者很明确被需求文档一句话、测试设计三小时反复折磨的测试工程师以及正在评估 AI 辅助测试到底能不能落地的团队。后面写的全部来自真实操作记录没有理论包装。1. 测试点的质量上限在需求模型里就已经决定了先说结论需求文档是写给人看的不是写给模型推导用的。它按人类阅读习惯组织有背景、有铺垫、有一堆上下文但唯独缺少测试设计最需要的结构化信息——什么条件下允许什么操作、操作之后系统处于什么状态、异常了怎么兜底。大模型在处理这种开放式文本时默认行为是生成最合理的续写而不是从材料里严格推导可验证的事实。所以你把原始需求丢给它它给出的测试点本质上是它猜出来的只是猜得比新手认真。举个例子。需求里写商品数量不能为负AI 会很勤快地补出 -1、0、1 这几个边界值但它不知道这个系统里单笔订单最多 99 件、数量必须是整数、超过库存上限要拦截。这些信息需求文档里没有AI 不知道它只能靠通用经验填一个看起来合理的答案。在测试设计里看起来合理恰恰是最危险的信号——因为测试点的价值不在于好像会发生什么而在于明确验证系统在特定条件下给出正确反应。1.1 为什么模型缺失时AI 必然产生幻觉大模型的本质是一个概率续写器你在提示词里给的信息越少它需要用自己的先验知识去补全的部分就越多幻觉率也就越高。这个现象在测试点生成场景里被放大了因为测试点天然要求穷尽性——你要把所有可能出错的路径都列出来。当需求文档没有给出足够的约束时AI 为了显得专业会主动填充它认为应该有的规则而不是它被明确告知的规则。我见过最夸张的一次AI 给一个仅有用户可取消订单六个字的需求生成了 40 多条测试点里面有一半的需求方根本不知道自己在做这个功能。这里的关键认知是AI 不会告诉你它不知道什么。它只会用流畅的文字把不确定性包装成确定性。所以我们必须先建立一份它能够依赖的、信息完整的模型把猜测空间压缩到最小。模型越完整AI 越没有机会发挥测试点的可信度才越高。1.2 需求模型其实就四张表实体、状态、规则、流程把需求整理成模型之后AI 的工作就从猜变成了在给定空间里枚举。我用的模型只包含四类信息实体、状态、规则、流程。这套四要素不是拍脑袋定的它来自一个朴素的观察绝大多数线上 bug 都能归到四类里——数据错了实体字段、状态乱了状态流转、条件没拦住规则校验、顺序走岔了流程异常。模型把这四类信息补全AI 的搜索空间就跟着完整了。要素回答的问题能推导出来的测试点类型实体系统有哪些业务对象对象上有哪些字段字段校验、必填项、数据完整性状态对象有哪些合法状态哪些转换是允许的状态流转、非法跳转、重复操作规则什么条件下允许什么操作业务规则、边界值、权限控制流程正常路径和异常路径分别怎么走场景流程、异常处理、超时重试四张表之间不是孤立的。规则会引用状态流程会调用规则实体的字段会出现在状态的判断条件里。测试点恰恰就是从这些交叉点上长出来的一个测试点的前置条件来自状态表操作动作来自流程表校验逻辑来自规则表预期结果可以落到某个状态或字段上。模型把这四类信息组织好了AI 的生成质量就有了底座。1.3 建模颗粒度粗了 AI 没依据细了没人维护建模最容易走偏的地方是颗粒度。太粗比如只在模型里写一条订单取消AI 没有更多依据能做的还是靠通用经验猜太细比如把每个接口参数、每个数据库字段的约束都列进去模型本身就成了维护负担需求一变动就是一场灾难。我实践下来的标准是一条业务规则必须能拆成条件 结果两段一个状态必须能写清楚触发动作 目标状态。达到这个程度就停笔。打个比方模型是给 AI 的一堆积木。积木太大AI 只能整块整块地拿搭不出细节积木太小AI 挤在零件堆里反而不知道怎么组合。能让 AI 自由拼出各种场景的最小积木粒度就是规则的条件——结果粒度。我在评审模型时经常问自己一句话如果我要把一个测试点追溯回依据能否在这四张表里找到一个明确的条目找不到就说明建模还不够细找到一堆类似的条目就说明已经过细了。2. 一个能落地的需求模型模板以及它是怎么从需求里抽出来的理论学习到这儿就够用了下面直接上我在项目里用的模板。这份模板没有什么高深之处唯一的设计原则是让所有信息都能被 AI 稳定理解同时让人也能方便维护。2.1 用 Markdown 维护需求模型模板与理由我司实际项目里需求模型直接用 Markdown 文件维护放在需求文档所在的代码仓库里。选 Markdown 有三个理由。第一大模型训练语料里 Markdown 结构出现的频率极高它对这个格式的理解最稳定你给结构化表格它就会按结构化表格来推理第二Markdown 文件可以被 git 跟踪需求评审、模型变更都能留下 diff方便追溯是谁在什么时候改了什么规则第三产品经理和测试都能直接编辑不需要引入额外的建模工具或者学习曲线。# 需求模型{模块名} ## 实体定义 - {对象A}{字段1}、{字段2}、{字段3} - {对象B}{字段1}、{字段2} ## 状态列表 | 当前状态 | 触发动作 | 目标状态 | 允许角色 | ## 业务规则 | 编号 | 条件 | 结果 | ## 流程列表 - F1 正常路径动作A → 校验规则 → 动作B → 结果状态 - F2 异常路径动作A → 校验失败 → 兜底处理模板本身不复杂复杂的是把真实需求填进去的过程。填的时候有一个容易犯的错把需求文档里的句子原样抄进规则表。这不叫建模叫搬运。关键是要把每一句话拆成条件和结果把隐含的边界值显式地写出来把异常的分支单独列成流程。这一步做得好不好直接决定后面 AI 生成测试点的下限。2.2 从一段真实需求到模型的推导过程下面这段是真实需求的原话未支付订单在支付时限内可以随时取消超过支付时限系统自动取消已支付订单在 30 分钟内可以申请取消超过 30 分钟只能走售后流程取消成功后库存自动释放退款原路返回。这段话一百个字不到但直接丢给 AI它大概率会生成取消订单后页面显示取消成功这类正确但没营养的测试点真正的风险点一个都不碰。我的拆分过程是这样先找实体原文里出现的业务对象只有订单一个字段包括订单号、用户ID、商品清单、订单金额、支付状态、取消类型、取消时间。然后是状态表把待支付、已支付、取消中、已取消四个状态和它们之间的转换关系列成表当前状态触发动作目标状态允许角色待支付用户主动取消已取消用户/客服待支付支付时限到期已取消系统定时任务已支付用户发起取消申请取消中用户取消中客服审核通过已取消客服取消中客服审核驳回已支付客服然后是规则表把原文里的支付时限内30 分钟内超过30分钟这些条件显式拆出来编号条件结果R1订单状态为待支付且当前时间在支付时限内用户可取消取消后释放库存R2订单状态为待支付且支付时限已到期系统自动取消释放库存并通知R3订单状态为已支付支付完成时间不超过 30 分钟用户可发起取消申请订单进入取消中R4订单状态为取消中取消申请不可重复提交R5订单状态为已取消不可再次支付、不可申请取消R6客服审核驳回取消申请订单状态从取消中改回已支付库存解冻最后是流程列表把原文里的业务动作串起来F1 主动取消用户点击取消 → 校验 R1 → 释放库存 → 订单置为已取消 → 发送通知F2 超时取消支付时限到期 → 系统定时任务扫描 → 订单置为已取消 → 释放库存 → 发送通知F3 申请取消用户申请 → 校验 R3 → 订单置为取消中 → 客服审核 → 通过则置为已取消并退款驳回则按 R6 处理整个推导过程大约花了二十分钟。拆完以后我自己都觉得惊讶原文里取消成功后库存自动释放退款原路返回这么一句带过的话落到模型里变成了 F1、F3 两个流程的必经节点。这恰恰是人做测试设计时最容易漏的东西——需求是一句话系统是一串状态变换中间横着无数个分支。2.3 模型写完后的三个自查问题模型写完之后我会用三个问题做自查。第一个问题每一个状态是不是都有明确的触发动作和允许角色如果哪个状态只有名字没有来源AI 生成测试点时就会绕着它走。第二个问题每一条规则的条件里是不是包含了可量化的边界值——时限、次数、金额阈值支付时限必须写成15 分钟而不是一段时间。第三个问题异常分支是不是都进了流程列表比如超时、库存释放失败、审核驳回这些在原文里可能只是一句话但在流程里必须是一个完整的路径。这三个问题里只要有一个答不上来我就不会把模型交给 AI。因为模型里留的每一个空白AI 都会用幻觉来填。与其事后花时间审它的幻觉不如事前花五分钟把模型补完整。这个时间投入在产品前期看起来微不足道但到评审阶段会发现它的杠杆效应大得惊人。3. 让 AI 生成测试点的提示词先定框架再谈发挥模型准备好了接下来是提示词。这个部分我迭代了很多版目前的版本已经稳定使用了两三个月核心思路是把测试设计的框架先定死然后才是让 AI 在框架内发挥。3.1 提示词的四个组成部分以及为什么追溯要求最重要提示词由四个部分组成角色定义、任务说明、输入材料、输出与约束要求。角色定义给 AI 一个明确的立场——资深测试工程师任务说明告诉它要做什么——基于需求模型生成测试点输入材料就是我上面整理好的那四张表输出与约束要求是整个提示词的核心也是最容易被忽略的部分。你是一名资深测试工程师请基于给定的需求模型生成测试点。 需求模型 {把上面整理好的模型整体贴进来} 生成要求 1. 按以下类别逐类生成测试点正常流程、异常流程、规则校验、边界值、状态流转、字段校验、并发与一致性。 2. 每个测试点必须能追溯到模型中的具体条目实体字段、状态转换、规则编号、流程编号。追溯依据写在最后一列。 3. 如果某个场景在模型中找不到依据禁止编造单独列进模型缺失待补充清单。 4. 输出为 Markdown 表格列测试点ID、类别、前置条件、操作步骤、预期结果、优先级、追溯依据。 5. 同一条规则下的测试点不要重复枚举相似变体优先覆盖跨规则组合。 6. 每个优先级为 P1 的测试点必须写明风险理由。这六条要求里第 2 条是幻觉控制的关键。它把 AI 的工作模式从凭记忆自由发挥改成了从给定材料里逐个推导相当于给它戴了一个紧箍咒。第 3 条是配套的兜底机制允许 AI 诚实地说模型里没有依据而不是硬编一个测试点出来凑数。实际用下来这两条配合能把幻觉率压到很低但代价是偶尔需要处理一些待补充清单里的条目——这是好事说明 AI 的边界守得住。第 5 条和第 6 条是我在踩了坑之后才补上的具体原因放到后面的坑位部分讲。3.2 把尽量覆盖换成一张覆盖度清单很多人写提示词喜欢用一句尽量覆盖所有场景这句话对 AI 基本无效。它不是不听话是不清楚你的所有指什么。我现在的做法是把覆盖度拆成一张固定清单每次都原样贴进提示词——正常流程、异常流程、规则校验、边界值、状态流转、字段校验、并发与一致性这七类其实就是一个简化版的测试设计方法。对每个类别我会在提示词里补一句如果该类别在本模型中不适用写明不适用的理由防止 AI 为了凑类别硬编。比如一个纯前端展示功能你让它生成并发与一致性场景它可能会强行编一个两个用户同时打开页面的用例这种测试点没有实际意义。明确告诉它可以不生成反而会逼它去理解模型的真实边界。覆盖度清单的另外一个好处是方便后续验收拿清单对着生成的测试点逐类打钩五秒钟就能看出来它漏了哪一类。3.3 输出样例与我的验收标准以订单取消模型为例AI 生成的输出大致长这样。每条测试点都有明确的类别、前置条件和追溯依据评审的时候可以顺着追溯列直接回到模型里去核对。测试点ID类别前置条件操作步骤预期结果优先级追溯依据TP-01正常流程待支付订单未超时用户点击取消订单状态变为已取消库存释放发送取消通知P1F1 / R1TP-02异常流程待支付订单支付时限已过用户点击取消提示订单已超时取消无法操作P1F2 / R2TP-03规则校验已支付订单支付后 29 分钟用户发起取消申请状态进入取消中进入客服审核P1R3 / F3TP-04边界值已支付订单支付后 31 分钟用户发起取消申请提示已超过可取消时限引导走售后流程P1R3 边界TP-05状态流转订单处于取消中用户再次点击取消提示申请处理中按钮置灰P2R4 / 状态表TP-06并发一致性同一订单两个取消请求同时到达并发提交模型无并发约束说明列入模型缺失清单-模型缺失我的验收标准有四条第一每个测试点都能在模型里找到追溯依据找不到的一律不算数第二覆盖度清单里的每个类别至少被勾到一次除非 AI 明确写了不适用的理由第三模型里的每条规则至少被一个测试点引用第四待补充清单里的项要么回需求方确认要么补进模型后重新生成。走完这套验收测试点基本可以直接进入下一环节。4. 从测试点到可执行用例衔接环节最容易漏掉的事AI 生成测试点只是第一步测试点离可执行的测试用例还有一段距离。这个环节经常被工程师跳过结果就是生成的用例要么没法执行要么执行了也发现不了问题。4.1 测试点转用例时必做的四个补全测试点解决的是测什么的问题测试用例解决的是怎么测的问题。转用例时我必做四个补全环境与前置数据、精确的操作步骤、具体化的预期值、清理逻辑。拿前面表格里的 TP-04 举例已支付订单支付后 31 分钟发起取消申请。落成用例时我会补成——前置数据先造一张订单用支付回调把订单置为已支付再用数据库修改支付时间字段让时间往后拨 31 分钟操作步骤进入订单详情页面点击申请取消按钮断言接口返回业务码 XZ3002提示文案为已超过可取消时限订单状态仍为已支付库存不变化清理删除测试订单及相关支付记录。这四个补全里最容易忽略的是清理逻辑。AI 生成的测试点里几乎不会写数据清理但测试数据累积起来会造成环境污染影响下一轮执行结果。我现在的习惯是让 AI 生成的表格里增加一列数据要求其中明确标注该测试点会创建哪些数据、需要哪些前置依赖然后由测试人员在用例脚本里补上对应的清理步骤。4.2 用需求追踪矩阵核对覆盖率测试点从 AI 出来之后我不会直接开始写脚本而是先做一遍覆盖率核对工具就是需求追踪矩阵。做法很简单行放测试点 ID列放模型里的规则编号、状态转换、流程编号每个测试点在它追溯的那几列打个勾。核对规则只有两条任何一列是空的说明对应规则没有测试点兜住任何一行是空的说明这个测试点没有需求依据多半是幻觉。测试点R1R2R3R6F1F2TP-01xxTP-02xxTP-03xTP-04xTP-06人工补x上面这张矩阵里R6 这一列是空的说明客服驳回取消申请这个规则没有测试点覆盖。这种遗漏靠肉眼很难发现因为生成的测试点数量一多视觉上会被看起来很多骗过去。把矩阵拉出来之后空列空行一目了然。用 Excel 的条件格式或者筛选功能几秒钟就能定位比人肉过一遍靠谱得多。4.3 哪些测试点必须人工重写覆盖率核对完之后还有一类测试点我必须人工重写金额、权限、支付等高风险规则的预期结果。AI 生成的预期值通常只到系统报错这个粒度但真正的校验要做的是具体的错误码、提示文案、资金流水的一致性。这些东西 AI 不知道它不是逻辑不行是它没有你系统的接口文档和错误码字典。并发一致性的测试点同理。AI 能想到两个请求同时取消同一订单但它不知道你这套系统的分布式锁策略是悲观锁还是乐观锁也不知道库存服务的扣减接口是不是幂等的。这类用例必须由测试设计和开发一起确认后重写。非功能类测试点性能、安全、兼容性我也基本不用 AI 的产出原因一样它没有当前系统的基线数据给不了有参考价值的阈值。我的原则总结成一句话AI 生成的东西当草稿人工做三件事——删幻觉、补遗漏、改高风险预期值。5. 实测踩坑记录AI 生成测试点的五个典型问题这部分写的是我在实际项目里踩过的坑也是这套流程迭代了三个版本的原因所在。每个坑都有对应的解法不一定通用但至少能给你一个排查方向。5.1 幻觉型测试点测了一个不存在的功能第一个版本跑出来之后我在评审 AI 输出的测试点列表时发现有一条写着已部分退款订单再次申请取消校验剩余金额应重新计算。我愣了一下翻遍整个需求模型里面压根没有部分退款这个概念。这条测试点的追溯依据是空的属于典型的幻觉——AI 把电商行业通用的业务经验混进了我的模型里。解决办法就是上线了前面提到的追溯要求和模型缺失清单凡是没有依据的测试点直接删不要尝试给它找理由同时让 AI 把这种情况单独列进待补充清单留给需求方确认。从此之后这类凭空冒出来的功能测试点基本绝迹了。5.2 边界值看似全面实际经不起业务推敲AI 特别擅长生成 -1、0、最大值加一这类通用边界值但业务系统里真正需要卡住的是领域边界。比如支付时限通用边界是超时前 1 秒和超时后 1 秒但实际业务里更关键的是支付时限剩余 1 秒时用户恰好发起取消和超时取消任务与用户取消请求同时发生这两个并发边界。AI 第一次生成的边界值测试点里完全没有这两个场景。我的解法是把业务边界值显式写进模型在状态表或规则表旁边加一行注释比如支付时限 15 分钟下单时间记录到秒。AI 有了这个参数生成的边界值才有业务含量。5.3 同场景变体过剩跨规则组合反而漏光第二版提示词生成的测试点比例严重失衡正常取消路径下AI 给了七八个几乎一样的变体——待支付订单点击取消成功待支付订单点击取消成功含运费待支付订单点击取消成功积分订单而跨规则的组合场景却一个没有。最典型的遗漏是取消中订单客服审核驳回同时用户再次发起取消申请和取消成功后订单处于已取消状态用户尝试再次支付。解法是提示词里加进第 5 条同一条规则下的测试点不要重复枚举相似变体优先覆盖跨规则组合。这一步之后生成的测试点数量明显下降但有效覆盖反而上来了。5.4 优先级永远是 P1直到你要求它给理由第一版生成的测试点优先级那一列清一色 P1。原因是 AI 对高优先级的理解是这个功能很重要而不会区分这个功能出错会导致资金损失和这个功能出错只是体验略差。后来我在提示词里加了一句每个 P1 必须写明风险理由效果立竿见影——AI 开始主动把一些执行结果温和的场景降到 P2因为它在给理由的过程中被迫进行了风险思考。当然挨个核对它的风险理由还是得人工来但至少不用再面对一张全红的优先级表。5.5 模型一更新测试点就新旧混杂真实项目里需求一定会变。有次产品把可取消时限从 30 分钟改成 15 分钟我改了模型里的 R3然后重新让 AI 生成了一版测试点。结果发现新旧测试点混在一起有些引用了旧规则编号有些新规则下又少了对应场景。现在的做法是把模型放进 git 管理每次模型更新后跑一次完整的重新生成然后对新旧两版测试点做 diff——消失的测试点、变化的预期值、新增的规则引用三块差异恰好就是需求变更的回归测试范围。这一步的意外收益是原来需求变更时我要靠肉眼去猜影响面现在模型 diff 帮我自动划出了边界。6. 人机分工的边界我的实操体会最后说一点人机分工的体会。AI 最适合做的是在明确边界内的高速枚举人适合做的是确定边界和判断业务价值。模型边界定得越清楚AI 的输出越稳边界留的口子越大幻觉越多。我现在的固定动作是AI 出的草稿绝不直接进用例库必须经过一次人工评审但评审时间已经从原来的两小时压缩到二十分钟。省下来的时间主要用来补并发和跨规则组合这两类测试点它们恰恰是 AI 最容易漏、也最能体现测试设计经验的地方。这套方法后续还能扩展。需求模型本身可以当作需求评审的核对单在需求方评审阶段就提前暴露不明确的地方模型的 git diff 可以用来驱动回归测试的范围选择需求改了哪块就重点回归哪块。做测试设计这么多年我越来越觉得 AI 并没有让测试变得简单它只是把我们从写里解放出来让我们把精力放在判断上——而判断的前提是你手里的模型足够好。我在实际项目里验证下来的结论是模型多花二十分钟AI 生成测试点的可用率就能从五成提到八成以上这笔账怎么算都划算。