1. 测试设计这件事为什么值得让 AI 掺和一脚测试设计是软件质量保障链条里最考验功力的环节。需求文档扔过来你得在有限时间里把测试点拆全、把边界找齐、把异常路径覆盖到位还得让用例可执行、可维护、可追溯。做过几年测试的人都有体会写用例不难难的是“想全”。人脑天然有盲区尤其是面对复杂业务逻辑、多条件组合、状态流转这类场景漏测几乎是必然的。我所在的团队做的是企业级后台系统一个中等规模的需求迭代测试设计阶段通常要产出 80 到 150 条用例。按照传统方式一个熟练的测试工程师从读需求到用例评审通过大概需要 1.5 到 2 个工作日。这还不算评审时被产品经理和开发怼回来返工的时间。痛点很明确效率瓶颈不在执行在设计。这次我拿了一个真实需求——一个订单状态流转与退款审批的模块——完整地让 AI 陪我走了一遍测试设计全流程。从需求解析、测试点拆解、用例生成、边界补充到最终评审全程复盘。这篇文章不是讲“AI 能替代测试”而是讲“AI 怎么当一个合格的测试设计副手”。如果你也在做测试设计或者正在琢磨怎么把 AI 塞进质量保障流程里这篇复盘应该能给你一些直接能抄的作业。2. 整体思路AI 在测试设计里到底该站什么位置2.1 先想清楚哪些环节交给 AI哪些必须自己扛我见过不少人一上来就让 AI“写测试用例”结果生成一堆看起来像模像样但根本跑不通的东西。问题出在定位错了。测试设计不是单一动作它是一条链需求理解与信息补全AI 擅长快速提取关键信息、识别歧义点测试点拆解与场景枚举AI 擅长穷举组合、补充人容易忽略的异常路径用例结构化编写AI 擅长按模板批量产出但需要人给约束优先级判断与风险取舍这个必须人来AI 不懂你的业务上下文和线上历史评审与最终把关人主导AI 可以辅助检查遗漏我的策略是AI 做“广度覆盖”和“初稿生成”人做“深度判断”和“最终裁剪”。把 AI 当成一个不知疲倦、但需要你给方向的实习生。2.2 为什么选这个需求来做验证我挑的是一个订单退款审批模块核心逻辑不复杂但分支多订单有 5 种状态待支付、已支付、部分退款、全额退款、已关闭退款审批有 3 级自动通过、一级审批、二级审批触发条件涉及金额阈值、用户等级、退款原因、历史退款次数这个需求的特点是状态组合多、条件分支密、边界值明确。正好是 AI 擅长的“组合爆炸”场景也是人容易漏测的重灾区。用它来验证 AI 辅助测试设计的实际效果比较有代表性。2.3 工具选型为什么没上花哨的框架市面上有不少测试用例自动生成工具有基于模型的、有基于代码覆盖率的。我这次没用那些原因很简单需求阶段还没有代码基于代码的工具根本跑不起来。我用的就是通用的对话式 AI 助手配合一套我自己整理的提示词模板。选它的理由零成本接入不需要额外部署自然语言交互需求文档直接贴进去就能用输出格式可以通过提示词约束适配我们团队现有的用例管理模板迭代快发现输出不对随时调整提示词提示不要迷信“专用测试工具”。在需求阶段通用 AI 助手配合好的提示词效果往往比专用工具更灵活。3. 核心细节我是怎么一步步让 AI 干活的3.1 第一步把需求“喂”对比什么都重要很多人用 AI 效果差第一步就错了——直接把需求文档整篇粘贴进去然后说“帮我写测试用例”。这样出来的东西质量极不稳定。我的做法是分三步喂第一遍让 AI 复述需求。我把需求文档贴进去提示词是“请用你自己的话复述这个需求的核心业务逻辑列出所有涉及的状态、角色、条件和动作。如果有任何你觉得描述不清或有歧义的地方单独列出来。”这一步的目的是验证 AI 是否真的理解了。如果它复述出来的东西有偏差后面全白搭。实测下来AI 在这一步能识别出 60% 到 70% 的歧义点比如“退款金额超过 500 元需要二级审批”这句话里500 元是含还是不含需求文档没写清楚AI 会主动问出来。第二遍补充业务上下文。需求文档通常只写“是什么”不写“为什么”。我会额外告诉 AI 一些背景这个模块历史上出过什么线上问题、哪些场景用户投诉最多、开发和产品最担心什么。这些信息 AI 自己猜不到但你给了它它就能在后续拆解时重点覆盖。第三遍明确输出约束。在让 AI 生成用例之前我会先给它一个模板用例编号 | 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 用例类型并且明确告诉它优先级只分 P0/P1/P2用例类型只分功能/边界/异常/权限。约束越明确输出越可用。3.2 第二步测试点拆解让 AI 做“穷举”需求理解到位后我让 AI 做测试点拆解。提示词大意是“基于以上需求列出所有需要测试的功能点、边界点、异常点和权限点。每个点用一句话描述不要写具体步骤。”这一步 AI 的表现超出预期。它把一个看起来简单的退款审批拆出了 47 个测试点其中我人工核对后发现有 8 个是我自己第一遍读需求时没想到的比如退款审批过程中订单状态被其他操作变更时的并发处理同一用户短时间内重复提交退款申请的幂等性审批人离职或权限变更后待审批任务的处理退款金额为 0 或负数时的系统行为这些点不一定都要写成用例但它们提醒了我这个需求的测试范围比表面看起来大。3.3 第三步用例生成关键在“分批”和“给例子”47 个测试点如果一次性让 AI 生成用例输出会很长而且质量会下降。我的做法是分批按功能模块分成 4 批每批 10 到 15 个测试点。每批生成时我会先给 AI 一个“样例用例”告诉它“这是我希望的输出格式和详细程度请参照这个标准生成其余用例。”样例用例是我自己手写的包含完整的步骤和预期结果。这个技巧很关键。AI 对“格式”的理解全靠例子。你给它一个高质量样例它就能模仿你不给它就自由发挥出来的东西千奇百怪。3.4 第四步边界值和异常场景让 AI 专门补一轮正常功能用例生成完后我单独开了一轮对话专门让 AI 补边界和异常。提示词是“针对这个需求列出所有可能的边界值金额、次数、时间、状态数量等和异常场景网络中断、并发冲突、数据不一致、权限不足等每个场景给出具体的测试数据建议。”这一轮 AI 输出了 23 个边界和异常场景我筛选后保留了 15 个纳入用例。其中比较有价值的包括边界/异常场景测试数据建议我的取舍退款金额恰好等于审批阈值500.00 元保留P0退款金额比阈值多 0.01 元500.01 元保留P0用户历史退款次数达到上限第 N 次和第 N1 次保留P1审批过程中订单被关闭并发操作保留P1退款金额为负数-1 元保留P2审批人同时审批两笔退款并发请求保留P1注意AI 生成的边界场景不一定都值得写成用例。有些场景理论上存在但实际业务中几乎不可能发生强行写进去只会增加维护成本。取舍标准是这个场景如果出问题用户会不会感知到会就保留不会就砍掉。4. 实操过程完整走一遍从需求到用例的全流程4.1 需求解析阶段的实操记录我拿到的需求文档大概 1200 字描述了一个退款审批流程。我第一遍读完后自己先列了一个粗略的测试点清单大概 20 个点。然后我把需求文档贴给 AI让它做同样的拆解。AI 的输出比我多了 27 个点。我逐一核对发现它多出来的点主要集中在三类状态组合我习惯按主流程想AI 会把所有状态两两组合都列出来权限矩阵不同角色对不同状态的订单能做什么操作AI 列了一个完整的矩阵时间边界审批超时、退款到账时间、申请有效期这些和时间相关的点这三类恰好是人脑容易偷懒的地方。人倾向于想“正常情况”AI 倾向于想“所有情况”。这就是互补。4.2 用例生成阶段的参数与约束设置在让 AI 生成用例时我设置了几个关键约束约束一步骤必须可执行。我明确要求“操作步骤必须具体到点击哪个按钮、输入什么数据、选择什么选项”不接受“进行退款操作”这种模糊描述。约束二预期结果必须可验证。要求“预期结果必须包含具体的页面提示文案、数据状态变化、数据库字段值”不接受“退款成功”这种笼统描述。约束三前置条件必须完整。要求“前置条件必须包含用户登录状态、订单当前状态、审批人配置、系统参数设置”确保用例可以独立执行。约束四优先级判断标准。我给了 AI 一个简单的判断规则P0主流程、资金相关、权限相关P1分支流程、边界值、异常恢复P2UI 细节、提示文案、非核心路径有了这些约束AI 生成的用例可用率从第一轮的 40% 提升到了第三轮的 85% 左右。4.3 用例评审阶段的 AI 辅助检查用例写完后我没有直接拿去评审而是先让 AI 做了一轮“自查”。提示词是“请检查以下用例列表找出1重复或高度相似的用例2步骤不完整或预期结果不明确的用例3可能遗漏的场景。”AI 找出了 6 条重复用例、4 条步骤不完整的用例以及 3 个我确实漏掉的场景。其中最有价值的一个遗漏是退款审批通过后如果订单在退款到账前被用户主动关闭系统应该怎么处理。这个场景我在写用例时完全没想到但线上确实有可能发生。4.4 最终产出与效率对比整个流程走下来我统计了一下环节传统方式耗时AI 辅助耗时产出质量对比需求解析2 小时40 分钟AI 多识别 8 个歧义点测试点拆解3 小时1 小时AI 多覆盖 27 个点用例编写8 小时3 小时可用率 85%需人工润色边界异常补充2 小时40 分钟AI 补充 15 个有效场景评审前自查1 小时20 分钟AI 发现 13 个问题合计16 小时5 小时 40 分钟覆盖率提升约 30%效率提升大概 65%但更重要的是覆盖率的提升。传统方式下我大概能覆盖 70% 到 75% 的场景AI 辅助后提升到了 90% 以上。漏测风险显著降低。5. 踩过的坑和常见问题排查5.1 AI 生成用例的典型问题与修正方法问题一步骤太笼统。AI 经常写“用户发起退款申请”但不写具体怎么发起。修正方法是给样例明确要求“步骤必须写到操作级别”。问题二预期结果不可验证。AI 写“系统提示退款成功”但实际页面提示可能是“您的退款申请已提交预计 1-3 个工作日到账”。修正方法是把系统的实际提示文案提供给 AI让它参照。问题三前置条件缺失。AI 默认所有用例都从“用户已登录、订单已支付”开始但实际测试中很多用例需要特定的审批人配置。修正方法是在提示词中明确列出所有可能的前置条件维度。问题四优先级判断不准。AI 倾向于把所有用例都标成 P0。修正方法是给出明确的优先级判断规则并要求它解释每条 P0 的理由。问题五重复用例。不同批次生成的用例之间可能有重复。修正方法是最后统一做一轮去重检查。5.2 提示词迭代的实操心得我前后调整了 5 版提示词总结下来最有效的几个技巧给角色“你是一个有 5 年经验的测试工程师”——这句话能让 AI 的输出更专业给样例一个高质量样例胜过十句描述给约束明确告诉它“不要做什么”和“必须做什么”同样重要分批处理一次处理 10 到 15 个测试点质量最稳定要求解释让 AI 解释它的判断依据方便你发现它的逻辑偏差5.3 哪些场景不适合让 AI 主导不是所有测试设计都适合 AI 辅助。以下几种情况我建议人主导业务规则极其复杂且文档缺失AI 没有上下文生成的东西会偏离实际涉及安全合规的测试需要人的专业判断AI 容易遗漏关键检查点探索性测试设计需要人的直觉和经验AI 不擅长“灵光一现”性能测试场景设计需要结合系统架构和容量规划AI 缺乏系统级视角提示AI 辅助测试设计的边界是“广度”和“初稿”不是“深度”和“终稿”。把 AI 当副手别当替身。6. 我个人的一些实操体会这套流程我跑了三个需求之后最大的感受是AI 不会让你变懒但会让你变快。它帮你把那些机械的、穷举的、容易漏的活干了你的精力可以集中在真正需要判断力的地方——哪些场景风险最高、哪些用例值得自动化、哪些边界需要和开发确认。另外一点体会是提示词的质量直接决定输出质量。我见过有人抱怨 AI 写的用例没法用一看他的提示词就一句话“帮我写测试用例”。这就像你跟一个新来的实习生说“你去测一下”然后怪他测不全。给 AI 的指令越具体、约束越清晰、样例越标准它的输出就越接近可用。最后分享一个小技巧我会把每次 AI 生成的用例中特别好的几条收藏起来作为下次生成时的“样例库”。积累多了之后AI 的输出质量会肉眼可见地提升。这个正反馈循环一旦建立起来测试设计这件事就从“苦力活”变成了“指挥活”。