说到AI辅助测试用例生成我一开始是抗拒的。做了七八年测试Excel里几万条用例都是我一条条敲出来的你告诉我一个对话框就能生成但后来项目紧急一个模块需要在一周内补出覆盖登录、权限、支付三个场景的用例我只能硬着头皮试试。结果第一版生成结果确实不靠谱全是“输入正确的用户名和密码”这种废话。但当我花了半小时把需求、边界、格式约束都写清楚之后生成结果的质量完全不一样了。这篇文章就是我把这次实践完整拆解后的教程适合测试、测开、以及想用AI提升用例编写效率的开发同学。我会从工具选型、提示词设计、实操流程、问题排查四个部分讲争取让你能直接照着做。1. AI辅助测试用例生成的整体设计1.1 传统用例编写的三个痛点你现在回想一下手写测试用例的场景。第一费时。动辄几十条起步登录这种看似简单的功能写完正常、错误、锁定、找回密码、验证码轻松上百条一天就没了。如果是复杂订单流程、支付状态机用例写个三四百条很正常而且越到后期越容易敷衍。第二边界遗漏。很多人写用例习惯“顺着需求写”只测“正确路径”。边界值、异常值、数据库异常、并发操作这些容易被忽略。比如用户名字段要求6到16位手工写的时候大概率只写“6位和16位”但7、15、5、17位甚至空值、全角字符、SQL注入字符这些往往会漏掉。而这些恰恰是线上最容易出问题的地方。第三严重依赖个人经验。老测试能写出深层case新手就只能写“页面能正常打开”这种。同样一份需求文档有人能拆出100条用例有人只能写20条。这种差距不是看几篇文档就能补上的。这三个痛点是AI切入的基础它能不能帮我们减少重复劳动、补全边界、缩小经验差距我的答案是能但前提是你会用。1.2 为什么AI能解决这些问题AI不是魔法。测试用例生成这件事本质是“从自然语言需求中提取规则然后列举正常、异常、边界组合”。大模型在海量公开代码和文档中训练过对这种“提取规则-枚举场景”的模式非常擅长。它可以从一段需求里提取出隐藏规则。比如你告诉它“用户名长度6-16位”它能自动想到5位、6位、16位、17位空值、特殊字符、前后空格、大小写混合等等。你告诉它“错误密码5次锁定”它能自动推理出第4次、第5次、第6次、锁定期间、解锁后、跨天重置这些场景。它还擅长把自然语言转成结构化文本。测试用例本身就是一种结构化产物编号、标题、前置条件、步骤、预期结果、优先级。大模型生成表格、JSON、XML都不在话下。但要注意它并不是真正理解你的系统实现它只是用概率补全最可能的答案。所以它的输出只能作为高质量初稿不能直接上线必须有人工校验这一环。1.3 我推荐的协作闭环我推荐的做法是AI生成初稿 人工校验 回归沉淀。不是让AI全自动而是把AI当“实习生”负责产出初稿你来审核和修改。具体流程是需求清洗 - 提示词生成 - AI产出 - 用例评审 - 补充回填 - 沉淀到用例库。这个闭环的好处有两个一是快用例初稿从原来的一天压缩到两小时二是全AI能覆盖更多边界组合减少人为遗漏。我实践中一个中等模块的初稿节省出的时间基本都用在评审和补充上而不是打字。方式耗时边界覆盖可维护性适合场景纯手工1-2天依赖人员经验高核心业务逻辑纯自动脚本生成秒级依赖预设规则中接口级自动化AI生成 人工校验2-3小时较高高绝大多数日常迭代这套闭环跑熟之后你会发现测试设计能力不仅没有退化反而因为你开始看更多边界和异常能提出更多让开发和产品都意外的问题。2. 工具选型与准备2.1 我用过的AI工具和选型建议工具选择决定了后续效果。我实际用过的国内平台有DeepSeek、通义千问、Kimi、智谱清言等。直接Web聊天也可以但更推荐调用API因为可以批量处理问题也能和内部测试平台集成。如果项目对数据敏感还可以用开源模型本地部署比如Qwen2.5系列通过Ollama跑数据不出内网。不同工具的能力差异不大但推理细节有差别。生成测试用例这种任务需要的是提炼规则和枚举场景的能力所以优先选择推理能力强的模型而不是单纯“聊天顺畅”的模型。我用下来的感觉是DeepSeek和通义千问的系列模型在复杂约束下表现比较稳Kimi更擅长长文本总结智谱清言的JSON输出稳定度也不错。工具类型代表优点注意大模型API国产主流平台便宜、速度快、不用部署需求描述要准确注意脱敏本地开源模型Qwen2.5 7B/14B数据不出内网显存要求高效果稍弱选型建议个人先用Web工具体验团队落地用API敏感项目用本地模型。别一开始就追求效果最强的模型而是先跑通流程再逐步优化。2.2 环境准备与API接入如果你选择API准备三步就够了。第一步注册平台账号并实名充值少量额度第二步在控制台创建API Key保存好不要泄露到代码仓库第三步写一个最小调用脚本。下面是我用Python调用兼容OpenAI格式接口的示例模型用了国产大模型平台的接口。import requests API_KEY 在这里填你的Key API_URL https://api.deepseek.com/chat/completions payload { model: deepseek-chat, messages: [ {role: system, content: 你是一名资深测试工程师擅长编写高质量测试用例。}, {role: user, content: 请为登录功能生成测试用例。} ], temperature: 0.3, top_p: 0.9, max_tokens: 2048 } resp requests.post(API_URL, jsonpayload, headers{Authorization: fBearer {API_KEY}}) data resp.json() print(data[choices][0][message][content])这里参数为什么要这么设置temperature设为0.3是为了让输出更稳定减少模型自由发挥top_p设为0.9是控制候选词范围max_tokens设2048避免用例多时被截断。运行脚本后你就能拿到第一版结果。注意不要把公司敏感信息直接发给外部模型建议先用脱敏工具对字段名、手机号、用户名做替换。2.3 设计一套顺手的提示词模板很多人拿AI生成用例效果差问题出在提示词太随便。测试用例生成不是“帮我生成用例”这么简单你得告诉AI四样东西角色是什么、被测对象是什么、需求规则是什么、输出格式是什么。我把基础模板总结成下面五段角色资深测试工程师 任务根据需求生成测试用例 需求{粘贴需求内容} 约束 - 覆盖正常、异常、边界、安全和性能场景 - 每条用例包含编号、标题、前置条件、步骤、预期结果、优先级 - 用Markdown表格输出 - 不确定的地方标注“待确认”这个模板看起来很基础但实际效果比一句话提示词好很多。当你把需求内容补上约束之后AI会更清楚自己不是闲聊而是在做一个结构化任务。后面实操中我还会在这个模板基础上继续加Few-shot示例和JSON schema。3. 实操从需求到测试用例的全流程3.1 把需求整理成AI能读懂的资料先拿一个最常见的登录功能举例。需求文档可能是这样写的“用户通过手机号和密码登录密码长度8-20位必须包含字母和数字。输入错误密码5次后账号锁定30分钟支持短信验证码登录验证码有效期5分钟同一手机号每天最多发送10次。”这段可以直接扔给AI吗可以但效果一般。因为里面还有大量隐含规则没有写出来手机号格式需要校验已锁定账号再次尝试会提示验证码接口需要限流密码是否支持特殊字符连续错误5次是否包含第5次成功的情况锁定期间能不能走验证码登录。所以第一步是把需求拆成“规则清单”。我的做法是把需求拆成正常流程、异常流程、边界规则、安全要求四类。把模糊描述改成可验证的表述。比如“密码错误5次”要明确为“连续失败5次”。把关联规则写在一起方便AI做组合场景。整理后的输入模板如下功能名称用户登录 接口地址POST /api/v1/auth/login 字段 phone: 手机号11位中国大陆手机号格式 password: 密码8-20位必须包含字母和数字 code: 短信验证码6位数字有效期5分钟 业务规则 1. 手机号、密码和验证码三选二密码登录或验证码登录 2. 密码连续错误5次锁定30分钟 3. 验证码每天最多10次 4. 锁定期间禁止登录但可申请重置密码把这个喂给AI比直接粘需求文档要好得多。因为AI不需要自己从一大段自然语言里猜“哪些字段是核心”你直接把规则摆到它面前它接下来要做的事情是枚举场景而不是理解需求。3.2 第一轮生成直接提问的效果与问题为了做对比我先用最简短的提示词试了一轮。提示词就一句“请为登录功能生成测试用例。”AI输出大概是这样的编号标题步骤预期结果TC01正确登录输入正确手机号和密码登录成功TC02密码错误输入错误密码提示密码错误TC03验证码登录输入正确验证码登录成功问题很明显缺少边界值密码长度为7、8、20、21位没有覆盖缺少异常组合比如手机号错误密码正确、手机号正确密码空没有覆盖锁定策略和验证码过期没有优先级和前置条件。这说明如果不给规则和约束AI只会从常识层面“泛泛而谈”。但这轮不是白跑。它能帮你快速列出一个模块的主体框架。很多时候团队连“正确路径”用例都不齐全用这一轮输出做主导航是够用的。关键别直接把它当最终交付物。3.3 优化提示词后生成的结果把前面整理好的规则和基础模板拼在一起完整提示词长这样你是一名资深测试工程师请为以下登录功能设计一份完整的测试用例集。 需求规则 这里粘贴上面整理好的规则 输出要求 1. 覆盖正常、异常、边界、安全和与验证码相关的场景。 2. 每条用例包含编号、用例标题、前置条件、测试步骤、预期结果、优先级。 3. 使用Markdown表格输出。 4. 如果规则中有不明确或缺少的信息在用例表下方用“待确认”列出来。我实际跑出来大概是35条用例。这里摘几条展示编号用例标题前置条件测试步骤预期结果优先级TC01正确手机号正确密码登录用户已注册输入合法手机号、正确密码点击登录登录成功跳转首页P0TC02密码长度边界-7位用户已注册输入合法手机号、7位符合格式密码提示密码长度必须在8-20位P1TC03密码长度边界-20位用户已注册输入合法手机号、20位符合格式密码登录成功P1TC04连续错误5次锁定用户连续输入错误密码4次第5次输入错误密码提示账号已锁定30分钟后重试P0TC05锁定期间正确密码登录账号处于锁定状态输入正确手机号和密码登录失败提示账号锁定P0TC06验证码有效期5分钟已发送验证码等待超过5分钟输入过期验证码提示验证码过期重新获取P1这一轮明显覆盖了边界、锁定、验证码有效期已经非常接近可以评审的初稿了。把AI生成的内容复制到Excel或Xmind里再补充备注和关联需求编号就能直接进入评审环节。3.4 审核、去重与验收拿到AI用例后我按下面的清单逐条过需求可追溯每条用例能不能对应到一条业务规则对应不上的先标记。边界值完整长度、次数、时间、数量四类边界是否都覆盖。异常组合不同字段同时出错时是否覆盖了高优先级组合。步骤可执行前置条件是否描述清楚。比如“连续输错4次”这个前置如果没有说明执行人很难复现。预期结果明确不要写“登录失败”这种含糊表达要写“提示××错误停留在登录页”。举个例子AI生成的TC01写的是“点击登录”但没有说明是密码登录还是验证码登录。虽然上下文能看出来是密码登录但为了严谨我会改成“输入合法手机号、正确密码点击【登录】按钮”。这种小的修正能极大减少执行阶段的疑问。去重时我用Excel的“删除重复项”配合人工看标题。那些看起来一样但前置条件不同的需要手动判断保留哪个。验收标准很简单把用例交给一个不了解需求的实习生看ta能不能照着执行。能就算合格。4. 进阶让AI生成更稳定可控4.1 用Few-shot范例约束输出格式AI对格式的理解需要样例。如果你只说“输出表格”它可能偶尔给你变成列表。一个更好方式是在提示词里给一条目标格式示例作为“格式参考”。比如参考下面这条用例的字段格式 | TC01 | 正确登录 | 用户已注册 | 输入合法手机号、正确密码 | 登录成功 | P0 |把示例放在需求后面、输出要求之前。这样模型会自动模仿格式。这个技巧对输出为JSON时尤其重要。如果想把用例直接导入测试管理系统可以让它输出JSON数组比如{ id: TC01, title: 正确手机号正确密码登录, precondition: 用户已注册, steps: [输入合法手机号, 输入正确密码, 点击登录], expected: 登录成功跳转首页, priority: P0 }在提示词里指定“输出一个JSON数组字段为id,title,precondition,steps,expected,priority”再加上一个JSON示例基本不会出错。之后用Python脚本一解析就能自动导入Jira、禅道或者其他测试用例管理系统效率提升非常明显。4.2 多轮追问挖掘隐藏场景第一轮生成后不要急着收工。用追问把细节抠出来。我最常用的追问句有这些“上面用例里如果用户是已锁定状态同时验证码正确预期应该是什么”“并发登录怎么处理比如同一账号在两台设备同时登录。”“如果用户输入的是海外手机号或者带国际区号的号码规则怎么走”“验证码达到每天10次上限后用户还能不能通过密码登录”这类追问能逼着AI补出更深层的场景。实测中多问三到四轮用例数量能增加30%而且很多是团队原先想不到的异常分支。这不是AI聪明而是它见过的同类系统多能把常见的坑列出来。你只需要负责从这些建议里判断“是否符合产品逻辑”和“是否值得保留”。4.3 结合接口文档生成接口测试用例如果测试对象是接口给AI喂接口文档比喂业务需求更有用。你可以把Swagger/OpenAPI片段复制到提示词里比如paths: /api/v1/auth/login: post: parameters: - name: phone in: body required: true schema: { type: string } - name: password in: body required: true schema: { type: string }然后问“请基于这个接口定义生成接口测试用例包含参数校验、鉴权、业务流程、异常和性能场景。”AI会自动考虑参数类型、必填、格式、鉴权。如果你有接口的curl命令也可以放进去。对接口用例我还会让AI同时生成请求示例Python或curl这样联调时不用再另查文档。4.4 从用例到自动化脚本AI生成用例只是第一步。更高效的是让AI直接帮你生成自动化脚本。比如把登录用例转成pytest代码import pytest import requests BASE_URL https://example.com def login(phone, password): r requests.post(f{BASE_URL}/api/v1/auth/login, json{phone: phone, password: password}) return r def test_login_success(): r login(13800138000, abc12345) assert r.status_code 200 assert r.json()[code] 0 def test_login_wrong_password(): r login(13800138000, wrong123) assert r.status_code 200 assert r.json()[code] 1001做法是给AI一段指令“把上面的用例表转化为pytest测试函数函数名为test_开头断言要包含状态码和业务码。”注意自动生成的脚本只能作为基线版本需要人工跑通后补断言、补清理逻辑、补测试数据构造。脚本生成的意义在于帮你跳过了写框架步骤而不是完全托管测试。5. 常见问题与踩坑记录5.1 AI一本正经地胡说八道AI会在你没提供规则时自己脑补。比如它会默认密码错误提示“用户名或密码错误”但你的产品可能提示“密码错误”或者为防止撞库故意模糊提示。处理办法把所有从需求文档提取到的规则逐条写进提示词同时在“待确认”部分明确声明“未提供的规则不要假设”。另外可以把temperature调到0.2以下减少模型自由发挥的程度。但也不建议过低否则输出会太重复。我一般用0.3介于稳定和灵活之间。遇到“胡说八道”严重的情况就回退到让它“严格基于需求规则逐条生成不要额外补充产品规则”。5.2 用例重复度过高AI生成的大量用例表面看不同其实都是同一路径的变体。比如“正确手机号正确密码不同记住我选项”可能生成了3条但需求里根本没有“记住我”功能。解决方法是提示词里增加“不要生成需求之外的场景”再加一句“合并同类项同一个功能分支只保留一条高优先级用例”。如果生成结果仍然重复就靠人工去重。做一次之后把去重后的用例反馈到提示词示例中下一次效果就会好很多。我习惯把团队常用的几十条典型用例整理成一个“范例文件”每次生成前贴进去相当于让AI参照你们的用例风格工作。5.3 输出格式不统一表格时好时坏Web端和API端的模型对“Markdown表格”的遵从程度不一样。如果你要稳定格式最好的办法是要求输出JSON然后自己转表格。或者定义一个模板让它“严格按照模板填空”。还有一个坑max_tokens设置太短输出被截断表格只剩一半。遇到这种情况调大max_tokens并加上“如果用例太多请分批输出不要省略”。分批输出后可以用脚本合并。5.4 团队落地的三个建议最后说点团队层面的经验。第一别一上来就要求所有人使用容易翻车。先选一个模块由一两个人跑通流程总结出团队自己的提示词模板。第二建立用例评审机制。AI生成的内容必须经过评审才能进入基线用例库。可以在每次迭代评审时单独拿AI用例和手工用例做对比看覆盖率和缺陷发现率用数据说服观望中的同事。第三把好的提示词、历史用例整理成企业内部的范例库。我个人的体验是当我把团队三年沉淀的用例格式作为Few-shot示例喂进去之后生成结果几乎可以直接用这个投入回报非常高。我自己跑了两个多月之后最明显的变化不是“用例写得快”而是我终于有时间去做那些一直被推迟的探索性测试和线上日志分析了。AI辅助测试用例生成这件事核心不是让AI替代测试工程师而是把重复劳动压缩掉把人的精力留给判断和决策。最后再分享一个小技巧每次生成后把AI输出的“待确认”问题都整理给产品或开发这常常能意外发现需求文档本身存在的问题。比如规则里没说验证码每天上限是10次还是5次AI问出来之后产品和开发才会去对齐。这大概是这个工作流最有价值的副产品之一。
AI辅助测试用例生成实战：从提示词设计到自动化落地
说到AI辅助测试用例生成我一开始是抗拒的。做了七八年测试Excel里几万条用例都是我一条条敲出来的你告诉我一个对话框就能生成但后来项目紧急一个模块需要在一周内补出覆盖登录、权限、支付三个场景的用例我只能硬着头皮试试。结果第一版生成结果确实不靠谱全是“输入正确的用户名和密码”这种废话。但当我花了半小时把需求、边界、格式约束都写清楚之后生成结果的质量完全不一样了。这篇文章就是我把这次实践完整拆解后的教程适合测试、测开、以及想用AI提升用例编写效率的开发同学。我会从工具选型、提示词设计、实操流程、问题排查四个部分讲争取让你能直接照着做。1. AI辅助测试用例生成的整体设计1.1 传统用例编写的三个痛点你现在回想一下手写测试用例的场景。第一费时。动辄几十条起步登录这种看似简单的功能写完正常、错误、锁定、找回密码、验证码轻松上百条一天就没了。如果是复杂订单流程、支付状态机用例写个三四百条很正常而且越到后期越容易敷衍。第二边界遗漏。很多人写用例习惯“顺着需求写”只测“正确路径”。边界值、异常值、数据库异常、并发操作这些容易被忽略。比如用户名字段要求6到16位手工写的时候大概率只写“6位和16位”但7、15、5、17位甚至空值、全角字符、SQL注入字符这些往往会漏掉。而这些恰恰是线上最容易出问题的地方。第三严重依赖个人经验。老测试能写出深层case新手就只能写“页面能正常打开”这种。同样一份需求文档有人能拆出100条用例有人只能写20条。这种差距不是看几篇文档就能补上的。这三个痛点是AI切入的基础它能不能帮我们减少重复劳动、补全边界、缩小经验差距我的答案是能但前提是你会用。1.2 为什么AI能解决这些问题AI不是魔法。测试用例生成这件事本质是“从自然语言需求中提取规则然后列举正常、异常、边界组合”。大模型在海量公开代码和文档中训练过对这种“提取规则-枚举场景”的模式非常擅长。它可以从一段需求里提取出隐藏规则。比如你告诉它“用户名长度6-16位”它能自动想到5位、6位、16位、17位空值、特殊字符、前后空格、大小写混合等等。你告诉它“错误密码5次锁定”它能自动推理出第4次、第5次、第6次、锁定期间、解锁后、跨天重置这些场景。它还擅长把自然语言转成结构化文本。测试用例本身就是一种结构化产物编号、标题、前置条件、步骤、预期结果、优先级。大模型生成表格、JSON、XML都不在话下。但要注意它并不是真正理解你的系统实现它只是用概率补全最可能的答案。所以它的输出只能作为高质量初稿不能直接上线必须有人工校验这一环。1.3 我推荐的协作闭环我推荐的做法是AI生成初稿 人工校验 回归沉淀。不是让AI全自动而是把AI当“实习生”负责产出初稿你来审核和修改。具体流程是需求清洗 - 提示词生成 - AI产出 - 用例评审 - 补充回填 - 沉淀到用例库。这个闭环的好处有两个一是快用例初稿从原来的一天压缩到两小时二是全AI能覆盖更多边界组合减少人为遗漏。我实践中一个中等模块的初稿节省出的时间基本都用在评审和补充上而不是打字。方式耗时边界覆盖可维护性适合场景纯手工1-2天依赖人员经验高核心业务逻辑纯自动脚本生成秒级依赖预设规则中接口级自动化AI生成 人工校验2-3小时较高高绝大多数日常迭代这套闭环跑熟之后你会发现测试设计能力不仅没有退化反而因为你开始看更多边界和异常能提出更多让开发和产品都意外的问题。2. 工具选型与准备2.1 我用过的AI工具和选型建议工具选择决定了后续效果。我实际用过的国内平台有DeepSeek、通义千问、Kimi、智谱清言等。直接Web聊天也可以但更推荐调用API因为可以批量处理问题也能和内部测试平台集成。如果项目对数据敏感还可以用开源模型本地部署比如Qwen2.5系列通过Ollama跑数据不出内网。不同工具的能力差异不大但推理细节有差别。生成测试用例这种任务需要的是提炼规则和枚举场景的能力所以优先选择推理能力强的模型而不是单纯“聊天顺畅”的模型。我用下来的感觉是DeepSeek和通义千问的系列模型在复杂约束下表现比较稳Kimi更擅长长文本总结智谱清言的JSON输出稳定度也不错。工具类型代表优点注意大模型API国产主流平台便宜、速度快、不用部署需求描述要准确注意脱敏本地开源模型Qwen2.5 7B/14B数据不出内网显存要求高效果稍弱选型建议个人先用Web工具体验团队落地用API敏感项目用本地模型。别一开始就追求效果最强的模型而是先跑通流程再逐步优化。2.2 环境准备与API接入如果你选择API准备三步就够了。第一步注册平台账号并实名充值少量额度第二步在控制台创建API Key保存好不要泄露到代码仓库第三步写一个最小调用脚本。下面是我用Python调用兼容OpenAI格式接口的示例模型用了国产大模型平台的接口。import requests API_KEY 在这里填你的Key API_URL https://api.deepseek.com/chat/completions payload { model: deepseek-chat, messages: [ {role: system, content: 你是一名资深测试工程师擅长编写高质量测试用例。}, {role: user, content: 请为登录功能生成测试用例。} ], temperature: 0.3, top_p: 0.9, max_tokens: 2048 } resp requests.post(API_URL, jsonpayload, headers{Authorization: fBearer {API_KEY}}) data resp.json() print(data[choices][0][message][content])这里参数为什么要这么设置temperature设为0.3是为了让输出更稳定减少模型自由发挥top_p设为0.9是控制候选词范围max_tokens设2048避免用例多时被截断。运行脚本后你就能拿到第一版结果。注意不要把公司敏感信息直接发给外部模型建议先用脱敏工具对字段名、手机号、用户名做替换。2.3 设计一套顺手的提示词模板很多人拿AI生成用例效果差问题出在提示词太随便。测试用例生成不是“帮我生成用例”这么简单你得告诉AI四样东西角色是什么、被测对象是什么、需求规则是什么、输出格式是什么。我把基础模板总结成下面五段角色资深测试工程师 任务根据需求生成测试用例 需求{粘贴需求内容} 约束 - 覆盖正常、异常、边界、安全和性能场景 - 每条用例包含编号、标题、前置条件、步骤、预期结果、优先级 - 用Markdown表格输出 - 不确定的地方标注“待确认”这个模板看起来很基础但实际效果比一句话提示词好很多。当你把需求内容补上约束之后AI会更清楚自己不是闲聊而是在做一个结构化任务。后面实操中我还会在这个模板基础上继续加Few-shot示例和JSON schema。3. 实操从需求到测试用例的全流程3.1 把需求整理成AI能读懂的资料先拿一个最常见的登录功能举例。需求文档可能是这样写的“用户通过手机号和密码登录密码长度8-20位必须包含字母和数字。输入错误密码5次后账号锁定30分钟支持短信验证码登录验证码有效期5分钟同一手机号每天最多发送10次。”这段可以直接扔给AI吗可以但效果一般。因为里面还有大量隐含规则没有写出来手机号格式需要校验已锁定账号再次尝试会提示验证码接口需要限流密码是否支持特殊字符连续错误5次是否包含第5次成功的情况锁定期间能不能走验证码登录。所以第一步是把需求拆成“规则清单”。我的做法是把需求拆成正常流程、异常流程、边界规则、安全要求四类。把模糊描述改成可验证的表述。比如“密码错误5次”要明确为“连续失败5次”。把关联规则写在一起方便AI做组合场景。整理后的输入模板如下功能名称用户登录 接口地址POST /api/v1/auth/login 字段 phone: 手机号11位中国大陆手机号格式 password: 密码8-20位必须包含字母和数字 code: 短信验证码6位数字有效期5分钟 业务规则 1. 手机号、密码和验证码三选二密码登录或验证码登录 2. 密码连续错误5次锁定30分钟 3. 验证码每天最多10次 4. 锁定期间禁止登录但可申请重置密码把这个喂给AI比直接粘需求文档要好得多。因为AI不需要自己从一大段自然语言里猜“哪些字段是核心”你直接把规则摆到它面前它接下来要做的事情是枚举场景而不是理解需求。3.2 第一轮生成直接提问的效果与问题为了做对比我先用最简短的提示词试了一轮。提示词就一句“请为登录功能生成测试用例。”AI输出大概是这样的编号标题步骤预期结果TC01正确登录输入正确手机号和密码登录成功TC02密码错误输入错误密码提示密码错误TC03验证码登录输入正确验证码登录成功问题很明显缺少边界值密码长度为7、8、20、21位没有覆盖缺少异常组合比如手机号错误密码正确、手机号正确密码空没有覆盖锁定策略和验证码过期没有优先级和前置条件。这说明如果不给规则和约束AI只会从常识层面“泛泛而谈”。但这轮不是白跑。它能帮你快速列出一个模块的主体框架。很多时候团队连“正确路径”用例都不齐全用这一轮输出做主导航是够用的。关键别直接把它当最终交付物。3.3 优化提示词后生成的结果把前面整理好的规则和基础模板拼在一起完整提示词长这样你是一名资深测试工程师请为以下登录功能设计一份完整的测试用例集。 需求规则 这里粘贴上面整理好的规则 输出要求 1. 覆盖正常、异常、边界、安全和与验证码相关的场景。 2. 每条用例包含编号、用例标题、前置条件、测试步骤、预期结果、优先级。 3. 使用Markdown表格输出。 4. 如果规则中有不明确或缺少的信息在用例表下方用“待确认”列出来。我实际跑出来大概是35条用例。这里摘几条展示编号用例标题前置条件测试步骤预期结果优先级TC01正确手机号正确密码登录用户已注册输入合法手机号、正确密码点击登录登录成功跳转首页P0TC02密码长度边界-7位用户已注册输入合法手机号、7位符合格式密码提示密码长度必须在8-20位P1TC03密码长度边界-20位用户已注册输入合法手机号、20位符合格式密码登录成功P1TC04连续错误5次锁定用户连续输入错误密码4次第5次输入错误密码提示账号已锁定30分钟后重试P0TC05锁定期间正确密码登录账号处于锁定状态输入正确手机号和密码登录失败提示账号锁定P0TC06验证码有效期5分钟已发送验证码等待超过5分钟输入过期验证码提示验证码过期重新获取P1这一轮明显覆盖了边界、锁定、验证码有效期已经非常接近可以评审的初稿了。把AI生成的内容复制到Excel或Xmind里再补充备注和关联需求编号就能直接进入评审环节。3.4 审核、去重与验收拿到AI用例后我按下面的清单逐条过需求可追溯每条用例能不能对应到一条业务规则对应不上的先标记。边界值完整长度、次数、时间、数量四类边界是否都覆盖。异常组合不同字段同时出错时是否覆盖了高优先级组合。步骤可执行前置条件是否描述清楚。比如“连续输错4次”这个前置如果没有说明执行人很难复现。预期结果明确不要写“登录失败”这种含糊表达要写“提示××错误停留在登录页”。举个例子AI生成的TC01写的是“点击登录”但没有说明是密码登录还是验证码登录。虽然上下文能看出来是密码登录但为了严谨我会改成“输入合法手机号、正确密码点击【登录】按钮”。这种小的修正能极大减少执行阶段的疑问。去重时我用Excel的“删除重复项”配合人工看标题。那些看起来一样但前置条件不同的需要手动判断保留哪个。验收标准很简单把用例交给一个不了解需求的实习生看ta能不能照着执行。能就算合格。4. 进阶让AI生成更稳定可控4.1 用Few-shot范例约束输出格式AI对格式的理解需要样例。如果你只说“输出表格”它可能偶尔给你变成列表。一个更好方式是在提示词里给一条目标格式示例作为“格式参考”。比如参考下面这条用例的字段格式 | TC01 | 正确登录 | 用户已注册 | 输入合法手机号、正确密码 | 登录成功 | P0 |把示例放在需求后面、输出要求之前。这样模型会自动模仿格式。这个技巧对输出为JSON时尤其重要。如果想把用例直接导入测试管理系统可以让它输出JSON数组比如{ id: TC01, title: 正确手机号正确密码登录, precondition: 用户已注册, steps: [输入合法手机号, 输入正确密码, 点击登录], expected: 登录成功跳转首页, priority: P0 }在提示词里指定“输出一个JSON数组字段为id,title,precondition,steps,expected,priority”再加上一个JSON示例基本不会出错。之后用Python脚本一解析就能自动导入Jira、禅道或者其他测试用例管理系统效率提升非常明显。4.2 多轮追问挖掘隐藏场景第一轮生成后不要急着收工。用追问把细节抠出来。我最常用的追问句有这些“上面用例里如果用户是已锁定状态同时验证码正确预期应该是什么”“并发登录怎么处理比如同一账号在两台设备同时登录。”“如果用户输入的是海外手机号或者带国际区号的号码规则怎么走”“验证码达到每天10次上限后用户还能不能通过密码登录”这类追问能逼着AI补出更深层的场景。实测中多问三到四轮用例数量能增加30%而且很多是团队原先想不到的异常分支。这不是AI聪明而是它见过的同类系统多能把常见的坑列出来。你只需要负责从这些建议里判断“是否符合产品逻辑”和“是否值得保留”。4.3 结合接口文档生成接口测试用例如果测试对象是接口给AI喂接口文档比喂业务需求更有用。你可以把Swagger/OpenAPI片段复制到提示词里比如paths: /api/v1/auth/login: post: parameters: - name: phone in: body required: true schema: { type: string } - name: password in: body required: true schema: { type: string }然后问“请基于这个接口定义生成接口测试用例包含参数校验、鉴权、业务流程、异常和性能场景。”AI会自动考虑参数类型、必填、格式、鉴权。如果你有接口的curl命令也可以放进去。对接口用例我还会让AI同时生成请求示例Python或curl这样联调时不用再另查文档。4.4 从用例到自动化脚本AI生成用例只是第一步。更高效的是让AI直接帮你生成自动化脚本。比如把登录用例转成pytest代码import pytest import requests BASE_URL https://example.com def login(phone, password): r requests.post(f{BASE_URL}/api/v1/auth/login, json{phone: phone, password: password}) return r def test_login_success(): r login(13800138000, abc12345) assert r.status_code 200 assert r.json()[code] 0 def test_login_wrong_password(): r login(13800138000, wrong123) assert r.status_code 200 assert r.json()[code] 1001做法是给AI一段指令“把上面的用例表转化为pytest测试函数函数名为test_开头断言要包含状态码和业务码。”注意自动生成的脚本只能作为基线版本需要人工跑通后补断言、补清理逻辑、补测试数据构造。脚本生成的意义在于帮你跳过了写框架步骤而不是完全托管测试。5. 常见问题与踩坑记录5.1 AI一本正经地胡说八道AI会在你没提供规则时自己脑补。比如它会默认密码错误提示“用户名或密码错误”但你的产品可能提示“密码错误”或者为防止撞库故意模糊提示。处理办法把所有从需求文档提取到的规则逐条写进提示词同时在“待确认”部分明确声明“未提供的规则不要假设”。另外可以把temperature调到0.2以下减少模型自由发挥的程度。但也不建议过低否则输出会太重复。我一般用0.3介于稳定和灵活之间。遇到“胡说八道”严重的情况就回退到让它“严格基于需求规则逐条生成不要额外补充产品规则”。5.2 用例重复度过高AI生成的大量用例表面看不同其实都是同一路径的变体。比如“正确手机号正确密码不同记住我选项”可能生成了3条但需求里根本没有“记住我”功能。解决方法是提示词里增加“不要生成需求之外的场景”再加一句“合并同类项同一个功能分支只保留一条高优先级用例”。如果生成结果仍然重复就靠人工去重。做一次之后把去重后的用例反馈到提示词示例中下一次效果就会好很多。我习惯把团队常用的几十条典型用例整理成一个“范例文件”每次生成前贴进去相当于让AI参照你们的用例风格工作。5.3 输出格式不统一表格时好时坏Web端和API端的模型对“Markdown表格”的遵从程度不一样。如果你要稳定格式最好的办法是要求输出JSON然后自己转表格。或者定义一个模板让它“严格按照模板填空”。还有一个坑max_tokens设置太短输出被截断表格只剩一半。遇到这种情况调大max_tokens并加上“如果用例太多请分批输出不要省略”。分批输出后可以用脚本合并。5.4 团队落地的三个建议最后说点团队层面的经验。第一别一上来就要求所有人使用容易翻车。先选一个模块由一两个人跑通流程总结出团队自己的提示词模板。第二建立用例评审机制。AI生成的内容必须经过评审才能进入基线用例库。可以在每次迭代评审时单独拿AI用例和手工用例做对比看覆盖率和缺陷发现率用数据说服观望中的同事。第三把好的提示词、历史用例整理成企业内部的范例库。我个人的体验是当我把团队三年沉淀的用例格式作为Few-shot示例喂进去之后生成结果几乎可以直接用这个投入回报非常高。我自己跑了两个多月之后最明显的变化不是“用例写得快”而是我终于有时间去做那些一直被推迟的探索性测试和线上日志分析了。AI辅助测试用例生成这件事核心不是让AI替代测试工程师而是把重复劳动压缩掉把人的精力留给判断和决策。最后再分享一个小技巧每次生成后把AI输出的“待确认”问题都整理给产品或开发这常常能意外发现需求文档本身存在的问题。比如规则里没说验证码每天上限是10次还是5次AI问出来之后产品和开发才会去对齐。这大概是这个工作流最有价值的副产品之一。
