1. 为什么我放弃了“让AI直接列测试点”这个偷懒方案先说个结论如果你只是把需求文档扔给ChatGPT让它“生成测试点”十分钟后你确实能拿到一版看似工整的清单但它大概率长这样——“验证手机号为空时提示”“验证密码错误时提示”——全是废话和你自己对着需求文档划重点没什么区别甚至更啰嗦。我真正开始把AI测试点生成跑进日常流程是在我摸索出一套前置动作之后先把需求转成结构化模型用模型去约束AI的输出边界。这个思路改变的不只是产出质量而是整个测试设计的工作方式。我的核心用法是需求模型扮演“知识底座”AI负责“在底座之上做枚举和扩展”。没有底座AI就是在裸奔有了底座AI的每个输出都能追溯回需求本身评审的时候你可以问它“这条是哪条规则推出来的”它答得上来你才敢用。这篇文章是“AI测试工程笔记”的第三篇前两篇我聊了AI在用例生成和缺陷分析里的应用这次重点拆解从需求模型到测试点的完整链路。内容会偏实操会给出提示词模板、模型结构和运行记录也会把踩过的坑原样摆出来。适用对象很明确正在做功能测试、测试设计手里有AI工具但总觉得“生成的东西用不上”的测试工程师。如果你是测试开发或者对提示词工程有一定基础这篇文章里的思路可以直接平移到你自己的自动化测试设计场景里。2. 需求模型不是流程图是可被AI消费的结构化素材2.1 需求模型到底长什么样很多测试同学一听到“需求模型”四个字第一反应是画用例图、时序图、状态图。这些UML产物当然有用但它们更多是给人看的用来交流、评审、归档。而AI最擅长消费的是清晰、分域、带规则的文本结构。所以我在实践中把需求模型简化成三个互相独立又互相关联的模块信息结构系统里都有哪些核心数据对象它们的属性、格式、约束是什么。比如“用户”有手机号、密码、昵称“订单”有订单号、金额、状态。操作流程用户完成某个目标需要经过哪些步骤每一步的入口、动作、出口是什么。流程不必画图用编号列表描述清楚即可。业务规则系统在特定条件下必须遵守的约束包括必填项、长度限制、格式校验、状态流转条件、唯一性约束、权限限制等。这三块拆完需求模型就有了。它不需要多复杂关键在于“完整性”和“确定性”——每一条信息都能回溯到原始需求文档而不是你脑补出来的。2.2 为什么模型必须前置直接让AI读需求文档不行吗你可以把需求文档理解成一篇散文把AI理解成一个擅长揣测的学生。你让一个擅长揣测的学生读散文然后写总结他可能写得很好也可能跑题跑到天上——因为散文的语义太模糊每个人理解不同AI的“理解”只是概率预测它会在你最意外的方向上给你惊喜。而模型的作用是把“散文”翻译成“应试大纲”。大纲里每一条都是明确的、原子的、无歧义的。AI拿到大纲之后做的不是“理解”而是“排列组合”。它基于大纲里的规则去枚举可能的场景、条件、异常准确性会大幅提升。我实测过两组对照同一份支付需求直接投喂原始需求文本AI生成40条测试点其中有效可用的约50%大量内容集中在“正常支付成功”和“余额不足”这种表面场景。先建模再投喂AI生成36条测试点可用率超过85%而且边界、异常、状态冲突这些靠人肉容易漏掉的场景覆盖明显更全。这组数据我没法给你做出严格的实验报告但对比样本跑了十几次趋势始终一致模型前置之后AI生成的稳定性显著变好。2.3 建模时最常见的三个误区第一把流程画得过于复杂。流程的目的是让AI知道“操作顺序”不是让你炫技。一个登录流程用三步描述清楚“输入-校验-跳转”比画一张十个节点的流程图有效得多。第二规则和流程混着写。AI分不清“步骤”和“约束”时生成的测试点容易错位比如把“密码长度6-20位”这种规则当成一个独立操作步骤输出。建议在模型里用明确的标签区分两者。第三遗漏隐性规则。需求文档里只写“校验手机号格式”但没写格式具体是什么。如果你建模时不补上“11位、以1开头”AI生成的边界测试点就会凭空捏造规则。建模的过程本质上是需求澄清的过程你在建模型时发现的所有不确定项就是后续要拉产品经理确认的清单。3. 手把手教你把需求文本拆成AI可用的需求模型3.1 从一个最简单的登录需求开始我用登录模块来演示因为大家都熟悉容易跟上思路。假设原始需求是这样的用户输入手机号和密码点击“登录”按钮系统校验通过后进入首页。手机号需为11位数字密码长度6-20位。连续输错5次密码账号锁定30分钟。这段话信息量不大但真扔给AI让它生成测试点它往往会生成二三十条“手机号为空”“密码为空”“手机号格式错误”这种很表面的内容。你现在跟我一起把这段需求拆成三块模型信息结构手机号必填11位数字以1开头这里“以1开头”是常识补全需求没写但所有国内手机号校验都这么干我就写进模型里了写进去AI才能生成“以0开头的11位数字”这种边界用例密码必填字符串长度6-20位账号状态正常、锁定锁定时长30分钟操作流程用户进入登录页输入手机号、密码点击“登录”按钮系统校验输入格式系统校验账号密码是否匹配匹配成功 → 进入首页匹配失败 → 返回错误提示业务规则手机号必须是11位数字且以1开头密码长度必须在6-20位之间密码连续输错5次账号锁定30分钟锁定状态下即使密码正确也不能登录锁定时间到达后自动解锁3.2 信息结构怎么提炼四个字对象、属性信息结构不是让你把页面上所有字段抄一遍而是提炼出“系统里真正承载业务的对象”以及它们的“关键属性”。判断标准很简单这个属性会不会影响业务流程分支如果不会就不写。登录例子里的“记住我”勾选框就不会影响登录成功与否我不会写进去手机号和密码会影响必须写。实际操作中我习惯用“名词提取法”通读一遍需求把所有名词圈出来再逐个判断“这个词是不是一个独立业务对象”。订单、商品、用户、优惠券是系统、页面、按钮这些技术名词不算。再强调一次信息结构里每个属性都要带上约束。约束通常有这些类型——必填性、长度、格式、取值范围、唯一性、时效性。你在建模型时把这些约束显式列出来AI生成测试点的时候才会围绕约束做边界枚举。3.3 操作流程怎么拆关键在“步骤粒度”粒度太粗AI不知道在哪一步插入异常粒度太细模型又变成一堆啰嗦的“点击、输入、滑动”描述分散AI的注意力。我的经验是一个操作流程控制在4-8步每一步都是一个完整动作。比如支付流程我通常拆成用户提交订单进入支付页用户选择支付方式余额/银行卡/第三方用户点击“确认支付”系统创建支付单并扣款系统回调更新订单状态用户看到支付结果页面第4步里“扣款失败”怎么处理那是异常分支是业务规则要解释的不要在流程里展开成十几个分支。流程保持主路径清晰分支交给规则区。支撑我这么做的直觉是AI在流程里擅长识别“顺序关系”而所有对立关系成功/失败、条件关系如果…则…交给规则区处理它的枚举能力才能发挥出来。混在一起AI输出的结构会混乱你评审的成本反而更高。3.4 业务规则的设计每个规则都要能独立成为测试点业务规则区是整个模型的精华也是AI生成高价值测试点的核心素材。我写规则时遵循两条标准一条规则只表达一个约束每个约束都能被翻译成“如果违反会怎样”以登录需求为例规则“密码连续输错5次账号锁定30分钟”翻译成测试点就是输入4次错误密码后第5次输入正确密码能否正常登录输入5次错误后是否提示锁定锁定期间尝试登录是否被拒绝锁定29分钟后尝试登录是否仍被拒绝锁定满30分钟后是否自动解锁。这一条规则就能推演出5-6个测试点而你建模型的时候只是写了一句规则。AI之所以在模型前置后生成质量高靠的就是这种“规则-场景”的推演能力。我还建议你在规则区把“尚未定义的规则”也列出来用“待确认”标记。比如手机号已注册但未验证能不能登录这个需求没写。你把它列进模型的“待确认规则”里AI会在生成测试点时把这部分作为风险点标出或者你也可以在提示词里要求它“对未定义的规则输出风险说明”。这等于用AI帮你做了需求查漏。4. AI生成测试点的提示词模板与运行实例4.1 提示词结构五个要素缺一不可模型建好了接下来是把它“投喂”给AI。我用的提示词不是一个简单的“帮我生成测试点”而是一套固定结构包含五个部分角色设定告诉AI它是谁专业背景是什么任务描述清晰说明要做什么输出什么形态的结果输入素材把需求模型完整贴进来输出格式规定分类方式、字段结构约束与边界明确禁止做什么避免生成废话把五个要素串起来我常用的模板长这样# 角色 你是一名有10年经验的测试工程师擅长功能测试设计熟悉边界值分析、等价类划分、错误推测法。 # 任务 基于以下需求模型为[功能模块名称]设计测试点。 # 需求模型 【信息结构】 - 用户手机号必填11位数字以1开头、密码必填字符串长度6-20位、账号状态正常/锁定锁定时长30分钟 【操作流程】 1. 用户打开登录页输入手机号和密码 2. 点击“登录”按钮 3. 系统校验输入格式 4. 系统校验账号密码是否匹配 5. 匹配成功则进入首页失败则返回错误提示 【业务规则】 - 手机号必须是11位数字且以1开头 - 密码长度必须为6-20位 - 连续输错5次密码账号锁定30分钟 - 锁定期间即使密码正确也不允许登录 - 锁定30分钟后自动解锁 # 输出要求 1. 将测试点按以下分类输出功能测试、界面测试、异常场景、边界测试、安全测试、兼容性测试 2. 每个测试点包含编号、测试点名称、前置条件、操作步骤、预期结果 3. 对需求模型中“待确认”的规则单独输出一条风险提示 4. 不要输出与需求模型无关的测试点 5. 不要输出类似“验证系统正常运行”这种无实际操作的通用描述模板的关键在“输出要求”的后两条。很多AI生成的测试点让人想摔键盘就是因为AI喜欢补各种“合理但不属于当前需求”的场景。你在输出要求里明确“不要输出无关测试点”效果立竿见影。4.2 实测同一个模型三种提示词效果的直观对比我拿上面的登录模型跑了三次三种提示词策略结果差异很大策略A直接要求“生成登录模块测试点”输出30条全部集中在功能正常路径和常见错误类似“验证正确手机号密码可以登录”“验证错误密码提示失败”。没有一条涉及锁定状态或边界格式通用性极强可用性很差。策略B贴模型但没写约束输出42条覆盖了锁定、边界格式等模型里的规则但有大约10条是“验证密码包含特殊字符”“验证手机号包含中文”这种需求根本没定义的情况。这些加进来不能说错但会把用例库撑得很虚。策略C贴模型完整约束输出36条功能11条、异常9条、边界8条、安全5条、兼容3条。每条都能从模型里找到依据没有多余内容。所以说提示词的成本不在于“写得长”而在于“想清楚边界”。约束写到位你的评审工作量能少一半。4.3 让AI“先建模再出测试点”二段式提示词结构对于稍微复杂的模块直接给一个完整建模的大提示词AI有时候会“顾此失彼”——模型没建透就开始出测试点。这时候我把流程拆成两步第一步让AI基于需求文本自己建模你是资深测试工程师。请阅读以下需求文本输出该功能的需求模型模型需包含信息结构、操作流程、业务规则并标出需求中未定义但你认为是关键风险的点。 需求文本 [粘贴原始需求]第二步把AI生成的模型人工校对后再作为输入跑一遍测试点生成的提示词。这个做法多了一次人机交互但好处是能看到AI的“理解过程”把模型错误扼杀在源头。我在处理新项目、业务规则密集的模块时都用两步法熟悉的模块、规则清晰的场景直接一步到位。5. AI生成测试点的质量不高问题往往出在提示词外5.1 AI容易漏掉“状态冲突”和“时序相关”的测试点测试设计里有一类场景靠“规则枚举”推不出来它需要“组合状态”的想象力比如订单已支付但回调失败或者用户已注销但缓存里还有登录态。这类状态冲突测试点AI经常漏。原因是需求模型的规则区是静态的AI在静态规则基础上做枚举本来就缺少“动态变化”的维度。你需要主动在建模阶段补一张“状态流转表”把对象的每个状态以及触发迁移的事件列出来再让AI基于状态表做测试点生成。实操建议建模时增加“状态流转”小节不要只依赖信息结构。信息结构管“字段”状态流转管“对象生命周期”两者组合起来AI才能覆盖到“从已支付到已取消”这种跨状态的测试点。5.2 权重分配AI适合枚举人工负责判断哪些值得测AI的另一个问题是“平均用力”。它生成的测试点里有10分重要的核心流程也有1分重要的边缘场景。如果你照单全收测试用例库会变得臃肿、冗余执行成本直线上升。我现在的做法是把AI生成的测试点当成“测试点子池”最后一定要人工做一轮优先级标注P0核心流程、主路径、涉及资金/安全的关键规则P1主要异常路径、边界值、状态切换P2体验类、兼容类、低频场景这一步没法完全自动化至少目前我还没找到可靠的让AI自动判优先级的方法。但AI帮你把池子扩大了你筛选的空间就大了这本身已经价值很大——以前你可能因为时间紧只测了P0有了AI的完整清单你会发现很多原本没时间想到的P1场景。5.3 提示词之外的护栏建立“测试点验收清单”我在团队里推行一套简单的验收标准每一条AI生成的测试点都要过这四关才能进用例库验收项判断标准可追溯性能否从该测试点找到对应的需求模型条目可执行性操作步骤是否具体到一个人按步骤能独立执行结果可判定预期结果是否明确是否包含提示信息或页面状态无重复性与已有测试点是否存在语义重复模糊词不算重复这套验收清单AI也可以辅助执行比如让AI“自查”一遍但最终保留判断权在测试工程师手里。AI是扩展你的视野上限不是替代你的判断能力。6. 新一代AI Agent 在测试点生成上的实战玩法老读者知道我一直在测各种AI Agent工具而“测试点生成”这个场景恰好特别适合Agent化——固定的角色、固定的输入结构、固定的输出要求就是一套标准化流程。我把这些模板打包成Agent后产物已经不再是“提示词文本”而是一个“测试点生成工作台”。6.1 把模板固化进Agent一次配置长期复用我现在的做法是把上面的提示词模板嵌入到支持的Agent工具里像Codex、Claude Projects、自建的Prompt工作流都能干这件事。配置一次之后后续每次拿到新需求只需要把“需求文本”替换进去Agent会自动完成“建模→提示词执行→输出格式化”这一套流程。这里要提醒一句Agent环境里跑测试点生成一个重要差别是“上下文长度”。测试点生成吃的上下文不大一般几千字完全够所以不用太担心Agent的窗口限制。但如果你把整个需求文档不加整理直接塞进去Agent可能在你没注意的地方把上下文费用烧得很高。我建议只投喂整理后的需求模型中相关章节不要“喂全文档”。6.2 用AI Agent自动做“测试点去重”和“相似测试点聚类”AI生成的测试点几乎必然有重复例如“手机号格式错误提示”可能同时出现在功能、异常、边界、安全四个分类里。人工去重等于重复劳动这类工作交给Agent处理正合适。我踩过的坑是用传统的字符串匹配做去重遇到“输入11位数字但第一位不是1”和“输入12位数字”这种语义相关但文本不同的测试点它分不出来。Agent的优势在于能结合上下文语义判断“这些测试点是否覆盖同一个规则”我实测下来对一个36条的测试点池做去重聚类Agent能合并掉6~8条重复项准确率稳定维持在“肉眼复核基本无错”的水平。具体的Agent提示词模板可以复用上面的结构只需在“输出要求”里增加一条“对相似测试点进行聚类合并输出合并原因。”这里不再重复贴模板因为本质上是对已验证模板的组合应用。6.3 从测试点到测试用例的延伸测试点生成完之后下一步自然就是转成可执行的测试用例。我在实际流程里也是用Agent做这个转换让AI把每个测试点展开为标准用例字段——用例编号、优先级、前置条件、测试数据、步骤、预期结果。转换之后再加一层“从测试点反查需求模型”的追踪矩阵追踪覆盖率。这个做法能顺手解决“测试点覆盖了但用例漏了”这种低级问题。追踪矩阵以前手工维护很痛苦现在Agent生成初稿人工复核效率提升明显。更细节的内容我计划在下一篇笔记里专门讲测试用例自动生成与覆盖率追踪这里先不展开。7. 常见问题与排查技巧实录7.1 AI生成的测试点重复率太高怎么办重复率高主要有三个原因分类边界不清晰、业务规则粒度太粗、AI在多个分类里都试图“覆盖全面”。排查路径先检查模型的业务规则是不是一条规则包含了多个约束比如“手机号必须是11位数字且以1开头”其实是两条独立约束拆开写之后AI在边界测试和安全测试里的输出自然就不重叠了。7.2 生成的测试点太“通用”放到哪个项目都能用这是“需求模型信息密度不足”的信号。你的模型里只有“手机号、密码、登录”这种通用信息AI就只能给出通用结果。解决方法是把项目特有的规则写进模型比如“连续输错5次锁定30分钟”这种项目专属逻辑。模型越具体输出越有项目特色。我见过有人把需求模型揉成一句话就丢给AI那和直接丢需求文档没区别效果自然好不了。7.3 AI漏掉了产品经理口头说的需求该怎么防这是最危险的一类问题需求文档本身没写但产品经理在评审时口头补充了一条规则你忘了更新到模型里AI当然也不会知道。我的防范办法是每次评审会结束立刻把口头补充的需求写进模型的“业务规则”区标注来源是“评审会议”。有一段时间我偷懒周五评审会的内容拖到周一才更新模型结果周五下午老板让我出一版登录功能的测试点给开发看AI生成的结果完全没覆盖评审会刚确认的“同一手机号30天内只能注册3次”规则我拿出去的方案当场被开发怼了。那次之后我养成了“会议结束当天更新模型”的习惯也建议你在团队里把这个流程固化下来。7.4 生成结果太长一个登录功能给了60条测试点数量多不一定是好事用例库膨胀会直接增加执行和维护成本。我在提示词里加了一个“测试点数量范围”的约束比如“控制在25~35条之间如果超出按优先级排序并删除最低优先级的内容”。生成稳定之后我再做一轮人工筛选效果比我逐条删轻松得多。7.5 常见问题速查表现象根因解决方案测试点重复率高分类边界模糊/规则粒度太粗拆分规则让分类标准更清晰测试点太通用需求模型信息密度不足补充项目专属规则到模型中遗漏关键业务规则建模不完整/口头需求未入模型评审会后立即更新模型输出过长或过短缺少数量约束在提示词中显式设置范围边界场景缺失缺少边界值/等价类的显式要求在提示词中增加“输出边界值”要求嵌套需求没识别AI没理解父子关系在模型里用编号显式体现层级8. 当前这套流程能解决什么问题边界在哪里我现在跑这套“模型→AI→测试点”的流程跑了大半年稳定应用在Web端和App端的日常迭代里。它的真实价值在于把测试设计从“经验驱动”慢慢转变成“模型驱动AI枚举人工裁决”对于新功能、需求频繁变更的项目效果尤其明显——模型一旦建好需求改一条规则AI重新生成一次的成本几乎为零。但也要说清楚它的边界。第一完全陌生的业务领域你建模时如果缺乏行业常识AI生成的点也会跟着跑偏这时候需要领域专家补位。第二AI生成的是“测试点”不是“测试策略”它不会告诉你“这个模块应该重点做探索性测试”还是“这个功能应该上全量回归”这种策略判断还得测试负责人来做。第三依赖AI生成测试点之后如果团队没有维护模型和用例库的习惯三个月后模型过时了AI的输出质量会像断供的煤气灶一样——火越来越小。所以我现在的态度很明确AI在测试设计里扮演的角色是高效率的参谋而不是替代你的决策。把模型建好把提示词配好把验收关把好剩下的大量重复枚举工作交给AI你才有时间做真正体现测试价值的事情——理解业务、判断风险、设计策略。如果你已经在用AI生成测试点不妨试一下先把需求文档转成“信息结构操作流程业务规则”三件套再投喂给AI。我自己是在跨过这一步之后才感觉AI生成的东西真正“能打”了。