做了这么多年测试我越来越觉得写测试用例这件事最耗精力的不是“设计”而是把脑子里的判断翻译成一行行看得见、能执行、不重不漏的表格。尤其是功能测试用例字段一多、分支一多光是把等价类和边界值铺开就能铺一整天。从去年开始我尝试把AI引入这个环节让大模型直接基于PRD、接口文档生成测试用例目前已经在几条产品线上跑顺了。这篇文章是“AI实战”系列的第一篇核心只聊一件事AI生成测试用例这件事到底怎么落地才能不翻车。文章会从最容易被忽略的“输入工程化”讲起然后给出一套可以直接复用的Prompt模板再分别用功能测试和接口测试两个真实案例跑一遍完整流程最后聊一聊AI生成用例之后如何接入自动化测试、代码Review和Harness工程化以及我踩过的那些坑。适合正在做功能测试、接口测试想用AI提效但不知道怎么下手的测试同学也适合测试开发顺手把用例生成纳入流水线的场景。1. 从需求到用例AI真正帮上忙的环节在哪1.1 用例设计流程里哪些工作适合交给AI测试用例的产生路径大致是需求获取、需求分析、测试点提取、用例设计、用例编写、用例评审、后续维护。很多人一听到“AI生成测试用例”第一反应是让AI一口气把最终用例表格吐出来结果往往不尽人意。我的经验是AI在不同环节的“可用度”差异非常大。我一般把环节分成三档高可用测试点提取、正向场景铺开、参数组合计算、边界值批量生成、用例格式规范化。这些工作规则明确、重复度高AI输出质量很稳定。中可用异常流程补全、业务规则到断言的转换、接口参数依赖分析。这些需要一定业务理解AI能做但需要把规则讲清楚或者用示例“喂”一下。低可用隐性需求识别、业务优先级判断、模糊需求的澄清决策。这些靠的是长期业务沉淀AI目前只能帮忙列问题不能替人拍板。所以我的结论很简单AI不是要替代测试设计而是把你“想清楚但没时间铺开”的部分加速完成。设计环节依然由人主导AI负责把设计意图变成成片的用例。1.2 AI不是替代测试设计而是替代“打字”和“查找”我刚入行时用Excel一条条手动写用例后来用思维导图梳理测试点再后来用xmind转用例工具效率一直在涨但瓶颈始终是测试点一旦确定把每个点按“前置条件、步骤、预期结果”的格式展开仍然是纯体力活。真正让我转变的是一次版本迭代一个下单页面的PRD有十几个字段、七八条业务规则按老办法至少要大半天写用例。我用AI先列出了字段级等价类和边界值矩阵再人工补充了运费的叠加规则整个过程不到两小时其中AI生成的部分至少省掉了三个小时。需要很清楚一点AI生成的用例并不一定比老测试手写的更“聪明”。它的优势在于只要规则明确它不会漏写某一个分支不会嫌麻烦也不会因为写了三十条正向用例就开始烦躁。而人的价值则在于判断哪些分支真正重要、哪些异常场景值得投入自动化。把这两者结合起来才是AI生成测试用例最正确的位置。2. 喂给AI的“原料”怎么样才够味输入工程化2.1 PRD、接口文档、历史用例三类输入的整理方法AI生成用例的效果七分靠输入三分靠Prompt。很多团队把PRD直接丢给AI得到的用例自然不忍直视。问题不在于模型不行而在于原始需求文档本身就是一团乱麻。我处理PRD通常分几个步骤先提取纯文本。PDF、Word里的PRD先转成Markdown或文本去掉目录、页眉页脚、营销描述只保留功能相关的章节。再补全字段信息。PRD里最常见的坑是“字段表不完整”比如只写了“手机号必填”没写长度和格式。遇到这种情况我先把原始文档里的零散规则汇总成字段清单再让AI根据常识列出“缺失信息清单”和人确认后再生成用例。最后拆分功能模块。一个大PRD如果包含登录、搜索、下单、支付一次喂给AI大概率后半段内容会被模型忽略。我建议按功能模块拆分每个模块单独生成用例最后再合并去重。接口文档相对好处理一些。如果是Swagger/OpenAPI格式直接导出JSON或Markdown如果是YApi、Apifox也能导出接口列表。关键是要把每个接口的请求参数、必填项、类型、长度限制、枚举值、响应结构、错误码一并保留。接口文档本身就是结构化数据AI从里面提取参数边界准确率比从PRD里提取要高得多。历史用例则是最好的“输出格式样本”。AI有很强的Few-Shot能力你把之前维护良好的用例贴两三条进去它就会照着同样的风格和字段去生成比你在Prompt里反复强调“请按照标准格式输出”有效得多。2.2 把需求“翻译”成AI能懂的结构化描述我曾经让AI直接读一句“用户通过手机号和密码登录密码错误超过5次锁定账号”来生成用例结果它生成的密码规则五花八门有的假设6位以上有的假设必须包含特殊字符还有的假设锁定时间是24小时。原因很简单这条需求本身就是残缺的。后来我把需求整理成结构化描述再喂给AI效果立刻不一样。下面是我常用的一个信息模板信息项说明功能名称用户登录用户角色C端已注册用户、后台管理员前置条件用户已注册服务端账号状态正常主流程输入手机号、密码 - 点击登录 - 登录成功进入首页关键字段规则手机号11位1开头大陆号码密码8-20位必须包含字母和数字业务规则连续失败5次锁定账号锁定时间30分钟锁定期间即使密码正确也不放行异常场景手机号未注册、密码错误、账号被锁定、网络异常、验证码过期输出要求每条用例包含用例ID、标题、前置条件、操作步骤、预期结果、优先级把这个模板发给AI之后我还会额外加一句“如果发现需求描述中缺少必要字段或存在歧义请先列出问题清单不要自己臆测规则。”这一句能挡住AI乱编需求非常重要。整理结构化描述看似多花了几分钟实际是成本最低的一步。因为规则一旦明确AI生成用例的准确率会高出一个量级人工评审的返工量直线下降。这叫“输入工程化”是AI生成测试用例所有技巧里最核心的一条。3. 把测试设计方法写进Prompt等价类、边界值与场景法的落法3.1 一个高复用度的AI测试用例Prompt模板很多测试同学问我要Prompt我给的答案往往是别去抄那些花里胡哨的“角色扮演型”提示词你需要的是把测试设计的约束讲清楚。下面这个模板是我目前在功能测试用例里使用频率最高的几乎可以直接照搬你是一名资深测试工程师擅长功能测试用例设计。请根据下面的需求描述生成测试用例。 需求描述结构化 [这里粘贴整理好的需求说明] 测试设计方法要求 1. 对每个输入字段使用等价类划分法列出有效等价类和无效等价类 2. 对每个有取值范围或长度限制的字段使用边界值分析法覆盖上点、下点、内点 3. 用场景法覆盖主流程、备选流程和异常流程 4. 重点关注业务规则组合不要遗漏条件分支。 输出格式 Markdown表格包含以下列 | 用例ID | 优先级 | 前置条件 | 操作步骤 | 预期结果 | 约束 1. 不要编造需求中未提及的业务规则 2. 如发现需求不完整请先输出“信息缺口清单”等待补充后再生成用例 3. 预期结果必须包含明确的断言页面提示、请求返回码、数据库状态等。这个模板看起来平平无奇但每一句都有用。角色设定让模型切换到测试专家的知识体系“测试设计方法要求”是核心防止AI只写“快乐路径”不会自己去做等价类和边界值计算输出格式限定避免AI自由发挥成小作文最后三条约束则精准打击了AI生成用例最常见的三个毛病。3.2 让AI按判定表或正交法补充组合场景单字段的等价类和边界值AI完成得很好但一旦出现多条件组合AI就会开始偷懒。举个例子商品搜索有四个条件关键词、分类、价格区间、排序方式。如果要求“覆盖所有组合”可能会有上百条用例既不现实也无必要。这时我一般会让AI用判定表法或正交法来缩减。我在Prompt里会增加一句“如果输入条件超过3个请先用判定表列出条件组合再用正交法或业务判断选取代表性组合生成用例不要穷举所有笛卡尔积。”AI通常会给出类似下面的分析条件关键词有/无、分类选中/未选中、价格区间设置/未设置、排序有业务影响/无业务影响在全组合的基础上用正交表或Pairwise思想挑选覆盖单缺陷和双缺陷的代表性组合最终生成用例时标注“本用例覆盖的组合点”如果你用的是支持插件或工具的AI助手也可以直接要求它调用Pairwise工具来生成组合。只要是选对了方法AI生成的组合用例命中率很高能覆盖到最容易漏的“分类选中但价格区间未设置”这类场景。还有一点值得提醒AI对“边界值”的计算通常是可信的但你要明确告诉它边界取几个点。比如密码长度8到20位如果你不强调它可能只写8和20漏掉7和21。我在Prompt里固定写法是“覆盖上点、下点、内点”必要时再加一句“特别注意刚好小于最小值、刚好大于最大值的非法输入”这样AI才会把边界两边的邻值补全。4. 从PRD到功能测试用例跑通第一个真实案例4.1 案例背景商城登录与商品搜索理论讲再多不如动手跑一遍。我拿一个B2C商城的两个功能来做演示手机号密码登录以及商品关键词搜索。第一步我把需求整理成前文说的结构化描述然后直接丢给AI。登录功能的需求描述要点手机号规则11位1开头仅限中国大陆号码输入框内可输入数字禁止粘贴非数字字符密码规则8-20位必须包含字母和数字允许特殊字符账号锁定连续输错5次锁定锁定30分钟期间正确密码也不能登录验证码登录失败累计3次后需要输入图形验证码验证码4位数字有效期2分钟会话登录成功后生成Token有效期24小时多端登录互不挤掉商品搜索的描述要点关键词1-50个字符支持中文、英文、数字不支持特殊符号分类单级分类可不选价格区间最低价与最高价均可不填最低价不得大于最高价价格区间为0-99999排序方式综合、销量、价格升序、价格降序默认为综合这里有一点很关键这些规则不全是PRD字面上写的有一部分是我通读了整份需求文档、和产品确认才拿到的。AI能不能生成好用例完全取决于这步输入做得到不到位。4.2 完整对话过程与生成结果我把上述结构化描述放进3.1的Prompt模板里AI生成的第一版用例节选如下用例ID优先级前置条件操作步骤预期结果TC-LOGIN-001P0用户已注册且状态正常输入正确手机号和密码点击登录按钮登录成功跳转首页响应返回TokenTC-LOGIN-002P0用户已注册输入正确手机号密码错误点击登录提示“密码错误”登录失败TC-LOGIN-003P0同上连续输错5次密码第5次返回“账号已锁定请30分钟后再试”TC-LOGIN-004P1账号处于锁定状态输入正确手机号和正确密码点击登录登录失败提示账号锁定剩余时间可见TC-LOGIN-005P1用户已注册输入11位非1开头的手机号登录失败提示“手机号格式不正确”TC-LOGIN-006P1用户已注册输入长度为7位和21位的密码分别提示密码长度不合法TC-SEARCH-001P0商城有已上架商品输入关键词不选分类和价格区间点搜索返回包含关键词的商品列表TC-SEARCH-002P1商城有分类数据选中某个末级分类不输入关键词返回该分类下所有已上架商品TC-SEARCH-003P1用户已登录价格区间输入最低价100、最高价50提示最低价不能大于最高价不发起请求TC-SEARCH-004P2商城商品数据充足分别按销量、价格升序、价格降序排序列表顺序与所选排序规则一致这版生成结果已经具备基本可用度能覆盖登录和搜索的核心链路。但请注意我没有指望它一次生成就完美而是把重点放在下一步的人工评审上。4.3 用例评审AI生成的用例里哪些要改AI生成的用例拿来就能用不可能。以这个案例为例我评审时至少发现了三处需要修改的问题臆测验证码规则AI在登录异常流程里自动假设“验证码4位数字”。这条规则确实存在但原需求里只写了“验证码为4位”没写“是否区分大小写、是否允许纯数字重复”。我最后和人确认后补全AI原本的用例一旦用错规则测试执行时就会产生误报。缺少并发会话用例AI没有覆盖“同一账号在手机端和PC端同时登录”的场景。这个场景在需求里其实属于“多端登录互不挤掉”但AI没有主动推到这一层。需要我在结构化描述里写清楚或者评审时人工补上。断言不够明确TC-LOGIN-005写的是“提示手机号格式不正确”但没写前端提示的具体文案和后端状态码。如果前端的提示文案改了这条用例的可维护性就很差。我通常会在评审时要求AI把所有预期结果补上“具体提示文案或状态码”。评审AI生成的用例我建议带着一张检查清单去看而不是逐条读。我的清单里固定有几项所有字段规则是否覆盖到边界业务规则分支是否都有正反用例异常场景是否包含了权限、状态、超时等维度预期结果是否可断言用例ID是否规范、能否和需求条目建立追溯关系。把这张表过一遍比逐字阅读AI输出效率高得多。5. 接口测试用例怎么设计AI在参数矩阵上的优势5.1 接口文档转用例的Prompt策略功能测试用例讲完再聊接口测试。AI在接口用例生成上的表现其实比功能用例更稳定因为接口文档是天然的半结构化数据参数名、类型、是否必填、边界条件都清清楚楚。AI最擅长的就是从这种明确规则里批量产出参数矩阵。我在接口场景下用到的Prompt策略和功能测试略有不同。核心是先把接口文档片段粘贴进去然后明确要求AI按参数维度生成用例请根据以下接口文档生成接口测试用例。 接口名称查询商品列表GET /api/v1/products 接口文档 [粘贴OpenAPI或接口文档片段] 要求 1. 对每个请求参数分别生成合法值用例、空值用例、超长/超界用例、类型错误用例、非法枚举用例 2. 参数之间存在依赖关系时生成组合用例例如分类ID存在校验、价格区间大小顺序校验 3. 覆盖鉴权相关场景未携带Token、Token过期、Token权限不足 4. 覆盖业务状态分类不存在、分类下无商品、商品全部下架、价格区间无匹配商品 5. 输出格式用例ID、接口路径、请求参数示例、预期状态码、预期响应关键字段。这个Prompt比功能测试的Prompt多了一项“参数之间存在依赖关系时生成组合用例”这是接口测试区别于功能测试的关键。因为单参数异常基本靠等价类和边界值就能覆盖真正容易漏的是参数之间的逻辑关系比如“分类ID存在但分类被禁用”“价格下限小于0”这类跨字段的异常AI在接口文档驱动下反而更容易列出来。5.2 参数校验、业务规则、异常链路三类用例的生成接口用例我习惯分成三大类让AI分别生成而不是一次性混在一起第一类是参数校验用例。每个参数都要覆盖必填参数不传、传入空字符串、类型传错、长度超上限、长度低于下限、未在枚举范围内等。AI最擅长机械地把每个字段遍历一遍几分钟就能生成几十上百条。第二类是业务规则用例。这里考验的是对业务的理解。比如查询商品列表里categoryId传了一个存在但属于父级分类的ID系统是返回空列表还是返回该分类下所有子类商品priceMin传了负数是直接参数校验失败还是被规整为0这些规则通常不在接口文档里而是埋在后端代码或PRD中。我的处理方式是在Prompt里把已知规则一条条列出来让AI逐条对应生成用例对未知规则则让AI标出“需要产品确认”不要自行假设。第三类是异常链路用例。包括数据库超时、第三方库存服务不可用、返回数据字段缺失等。这类用例很多团队只在手工测试里偶尔想到自动化用例里很少维护。AI生成的价值在于它会按“正常、鉴权、参数、依赖服务、并发”几个维度去罗列不容易漏掉“库存服务超时”这类非功能但容易出问题的场景。5.3 接口用例生成后如何落到Postman或自动化脚本接口用例生成只是第一步真正发挥价值还得落到可执行的工具上。我目前有两种落地方式。一种是把AI生成的用例整理成JSON/CSV导入Postman、Apifox或YApi。AI的Markdown表格输出可以再让它转成符合Postman Collection格式的JSON人工校验后直接导入断言和请求参数一次性建好省掉手动敲接口的功夫。另一种是让AI直接把用例转成自动化脚本。如果团队用的是Python pytest requests我会要求AI输出参数化用例代码例如import pytest import requests BASE_URL https://api.example.com pytest.mark.parametrize( params,expected_status, [ ({keyword: 手机}, 200), ({keyword: }, 400), ({keyword: a * 51}, 400), ({categoryId: 99999, page: 1, size: 10}, 200), ({priceMin: 100, priceMax: 50}, 400), ({page: 0}, 400), ({size: 101}, 400), ] ) def test_search_products(params, expected_status): resp requests.get(f{BASE_URL}/api/v1/products, paramsparams) assert resp.status_code expected_status这里要特别提醒AI生成的自动化脚本只适合作为初稿别直接上流水线。第一个坑是断言太弱比如只判断状态码没判断核心业务字段第二个坑是测试数据依赖比如categoryId99999不一定恒定为不存在需要结合测试环境的数据准备策略第三个坑是没有清理逻辑参数化用例里创建的数据如果不清理反复跑会污染环境。6. AI生成用例只是起点与自动化测试、代码Review和Harness工程化的关系6.1 从用例到自动化脚本的“半自动”路径如果你把AI生成的用例只停留在Excel或Markdown文档层面那其实只发挥了它三成的价值。真正的提效路径是让AI生成的用例直接变成自动化测试的输入。我的做法是两步走第一步AI生成结构化的用例集用JSON保存字段包含接口路径、请求参数、预期状态码、预期核心字段第二步写一个简单的转换脚本把JSON转成pytest的parametrize参数或者转成测试平台可识别的用例描述。这个过程不复杂但它能让“需求变更 - 重新生成用例 - 更新自动化脚本”的反馈周期从几天缩短到几小时。如果你用的是测试平台比如MeterSphere、TestRail这类工具AI生成的用例也可以通过OpenAPI或CSV导入进去配合平台本身的执行、报告能力。关键是不要让AI的输出成为一座孤岛务必在生成时就考虑后续的机器可读性。当前端接口或后端实现发生变化时AI用例生成的“增量更新”能力特别值得用。不要每次重新生成全部用例而是把变更的接口文档片段和原有用例一起喂给AI让它只生成“受影响用例”和“新增用例”再把变更标注出来这样既降低评审成本也避免回归范围失控。6.2 用AI做代码Review时如何把测试用例当验收标准很多团队做代码Review主要靠人肉看代码风格、逻辑漏洞缺少一个明确的需求验收标准。AI生成测试用例之后我建议把测试用例清单直接变成Review的输入之一。具体操作是在Review某个接口的实现时把该接口相关的AI生成用例集合和代码diff一起发给AI让它逐条核对“代码是否满足这条用例对应的预期结果”。这样做有三个好处代码Review从“看代码是否顺眼”变成“看实现是否履约”口径更客观AI能快速定位到“代码没有处理password为空时返回400”这类具体问题而不只是说“这里有逻辑风险”Review产出物和测试用例强相关后续回归时知道该回归哪些点举个例子某次我在Review登录接口时把AI生成的TC-LOGIN-005手机号非1开头和TC-LOGIN-006密码长度7位和21位喂给代码Review的PromptAI立刻发现后端只用正则校验了11位数字但没有校验“1开头”导致非1开头的号码也能通过。这类问题如果只靠人工Review可能需要盯很久才能发现。6.3 Harness工程化为什么用例生成需要纳入流水线最后聊一个偏测试基建的概念Harness工程化。Harness这个词测试领域一般指“测试夹具”或“测试框架的承载层”再往大说就是围绕测试运行的整套工程化能力用例管理、执行引擎、数据准备、结果收集、环境管理。AI生成用例这件事如果不和Harness结合就只是提高了一个环节的效率没办法形成系统性的杠杆。我的设想和落地路径是这样的需求文档合并到指定分支后触发CI流水线流水线里有一个“AI用例生成”任务。这个任务会自动读取变更的PRD或接口文档调用大模型生成增量用例提交到用例管理系统同时打上“AI生成待评审”的标签。测试同学在评审通过后一键转正再自动同步给自动化脚本生成器更新参数化用例触发冒烟测试。这套链路里最值得做的一环是“需求变更跟踪”。很多测试团队最头疼的不是第一次写用例而是需求频繁变更后用例没人同步更新。把AI生成嵌入流水线后至少能在每次变更时自动生成“受影响用例草稿”提醒测试同学去更新。不要指望全自动能达到“变更后半小时内拿到AI初稿”这个状态就已经比大多数团队领先很多了。当然这个工程化改造不是一蹴而就的。如果团队还没有持续集成流水线先从“AI生成用例 人工评审 批量导入用例管理平台”开始也能收到很明显的提效效果。7. AI生成测试用例的翻车现场与应对经验7.1 最常见的四类错误臆造字段、遗漏异常、断言模糊、格式混乱再顺手的工具也有翻车的时候。我在使用过程中AI生成测试用例最容易犯的错集中在四类我列了一个速查表错误类型典型表现原因应对方法臆造字段或规则需求没写验证码规则AI假设“6位数字且2分钟有效”需求描述有缺口AI用常识填补在Prompt里明确“不得编造规则”先用信息缺口清单补需求遗漏异常流程只覆盖登录成功、密码错误漏掉账号锁定、验证码过期、网络超时默认生成“快乐路径”用例缺少异常场景意识在Prompt里强制要求覆盖主流程、备选流、异常流三类场景断言模糊预期结果写“提示错误”或“登录成功”没有具体状态码和文案没有给AI示例模型不明确断言粒度在每条预期结果里要求包含接口状态码、页面文案、数据库状态格式混乱输出大段叙述不用表格或用例ID无规则Prompt里没有限定输出格式和ID规范用3.1节模板固定Markdown表格和用例ID规则这四类问题前两类最要命因为会直接导致漏测和误测。后两类虽然不影响执行但会给后续评审和自动化落地带来很大的麻烦。所以我在每次找AI生成用例时都会先把这四条写成一个“检查项”放在Prompt末尾让AI生成完后自己对照检查。7.2 我的使用建议模型选型、上下文长度、迭代方式模型选型上我日常使用频率最高的是国内可直接使用的几款大模型豆包、DeepSeek、通义千问以及GPT系列。不同模型的风格差异很明显豆包和DeepSeek对中文PRD的理解很稳长文本处理能力也不错适合直接贴需求文档GPT系列在复杂业务规则推理和格式控制上更强适合处理判空、组合爆炸这类逻辑密度高的场景。我的做法是让不同模型打配合第一版用豆包快速生成复杂模块用DeepSeek或GPT做二次精调。上下文长度是另一个容易翻车的地方。大模型的上下文窗口虽然越来越大但你一次性塞入整本PRD后生成质量会明显下降尤其是后段规则经常被模型遗忘。我的经验是单次生成时输入不要超过5000字重要的规则放在Prompt的靠前位置或者拆成多个模块分别生成。对于超过这个体积的文档先做章节切分再按功能模块逐个喂。另外一个关键经验是迭代式生成不要追求一次到位。我先让AI读需求并列出“信息缺口清单”确认完规则后再让它生成用例。生成后如果不满意不是推翻重来而是针对局部给修正指令比如“把TC-LOGIN-005的预期结果补充为具体的状态码和文案”这样AI会在原基础上修改比重新生成稳定得多。7.3 一套可复用的检查清单最后分享我现在每天都会过一遍的检查清单。AI生成的任何一批测试用例在进评审和进自动化之前我都会逐项确认每条用例是否有唯一ID且ID规则稳定能追溯到需求条目是否覆盖所有已知业务规则的正反场景是否包含每类输入字段的有效等价类和无效等价类所有长度、取值范围字段的边界值是否覆盖上点、下点、内点是否覆盖主流程、备选流程、异常流程三大类参数依赖类用例是否覆盖如价格下限大于上限、分类ID不存在鉴权、权限、状态类异常是否覆盖如Token过期、商品下架预期结果里是否有明确断言状态码、页面提示、数据库状态生成格式能否被后续自动化脚本或用例平台直接消费这套清单AI可以在生成时自我对照人工评审时也会再核一遍。双保险下来AI生成的用例已经能达到“可评审”而不是“可观赏”的状态。最后分享一个小技巧不要把AI生成的用例当作最终答案而是把它当成一个“基础完备但缺少轻重缓急”的草稿。AI不知道哪些用例在老板眼里最值钱也不知道哪条用例对应的功能下周就要上线。优先级判断、业务判断、成本判断永远是人来做。把AI能做的铺开把人该做的想清楚这条“AI 测试”的路才算真正走通。