先说说我自己的经历吧。我在测试这行干了快八年前五年一直在手写测试用例写得越多越觉得不对劲——每次PRD一改用例就要跟着翻一遍团队每周光维护用例就要耗掉大半天。后来我换了个思路把手写用例的活儿交给LLM让大模型直接解析PRD自动生成测试用例配合人工评审兜底一个月跑下来需求覆盖率从原来的基线直接提升了45%。这数字不是拍脑袋算的下文我会把统计口径和对比方法都摊开来讲。这篇博文就是把我这套从PRD到测试用例的LLM工作流完整拆给你看包括提示词怎么设计、模型参数怎么调、覆盖率怎么算、哪些坑我替你踩过了适合正在做测试设计、测试开发或者被用例评审逼到头大的朋友。1. 为什么手写测试用例越来越跟不上节奏1.1 需求变更引发的“用例雪崩”我在上一家公司维护过一套电商中台系统业务高峰期一周能收到十几条需求变更。PRD从v2.3改到v2.4看起来只是加了个“优惠券可与满减叠加”的规则但涉及的下游用例少说二十条——购物车计算、订单金额校验、结算页展示、异常提示全要跟着动。手工维护需求追踪矩阵的时候光靠脑子记“哪条用例对应哪个需求点”漏掉一两个太正常了。这就是手写用例的第一个硬伤它把“需求变化”这种高频事件硬生生变成了“用例维护”这种低频但高成本的事件一改就全盘联动。1.2 手动设计用例的“视野盲区”第二个硬伤在于手写用例特别吃个人经验。老测试能想到空值、越界、并发、权限不足这些边界场景新同学往往照着PRD的“正向流程”写一遍就交差了。我统计过团队里新老员工写的同一模块用例老手能覆盖到异常分支和组合条件新手写的基本都是主路径的“Happy Path”。换句话说覆盖率高低直接跟“写用例的人今天状态怎么样”挂钩这本身就不科学。LLM的好处是它训练数据里有海量测试设计模式你只要在提示词里点一句“需要覆盖边界、异常、权限、数据组合”它能批量把这些“人容易忘掉的场景”补出来。1.3 用例数量不等于覆盖质量还有一点我特别想强调用例条数多不代表真的覆盖到位了。以前评审用例经常出现这种情况——一个登录功能写了四十条用例仔细一看十五条是等价类重复十条是换了个测试数据但步骤完全一样真正覆盖不同逻辑分支的可能就五条。这种“虚假繁荣”会让你误以为质量有保障实际上回归测试跑完该漏还是漏。所以后面我做LLM用例生成方案的时候第一原则就是“先定覆盖密度再谈用例数量”把用例和需求点、业务规则一一映射让覆盖率这个指标变得可度量、可追踪。2. LLM解析PRD的核心逻辑与关键选型2.1 大模型为什么能读懂PRD很多人第一次听到“让LLM解析PRD”第一反应是“PRD那么乱它怎么读得懂”。其实这里的关键不是模型多聪明而是PRD本身有结构。大多数PRD包含四样东西背景说明、功能描述、业务规则、验收标准。LLM擅长的是从这些自然语言里抽取“主语、动作、约束条件”比如“用户只有在登录状态下才能领取优惠券且每人限领一张”它能拆成两个需求点登录态校验、每人限领一张。所以你要做的不是让模型凭空想象而是帮它把PRD的结构优势发挥出来。我一般会先把PDF或飞书文档转成Markdown再用提示词明确告诉模型“请按功能模块拆分需求点不要跳行”。模型对结构良好的文本理解精度会高很多。2.2 模型选型和参数调优的实战配置选模型这件事我走过不少弯路。最开始图省事直接调通用模型默认参数结果输出一会是JSON、一会是散文解析脚本得写三套。后来定了一套固定配置用起来才顺手配置项推荐值原因模型类型通用大模型API上下文窗口≥32KPRD动辄几万字窗口太小会截断后半部分需求温度0.2生成用例要稳定温度越高越容易“编造”top_p0.1进一步限制采样空间保证输出可预期输出格式JSON Schema / 结构化输出便于后续自动解析和去重统计最大Token4096以上一个模块的用例往往超过一千条留足余量尤其是温度这项我专门做过对比实验温度设为0.7时同一份PRD跑三次能产出三套完全不同的用例集合人工评审根本没法定调到0.2之后三套结果的重合度能到95%以上评审成本直接降了一个量级。如果你的平台支持结构化输出务必打开这比你在提示词里写一百遍“请输出JSON”都管用。2.3 把幻觉控制在可接受范围内LLM有个绕不开的问题幻觉。PRD里没提到的规则它可能基于训练数据推断出来看着合理实际是错的。我的处理原则是“允许它多给但必须标注来源”。具体做法是在提示词里要求每个测试场景后都跟着一个依据字段写清楚这条用例是从PRD哪一段提炼的是“原文规则”还是“推断场景”。评审的时候只看那些“推断场景”是否合理就行。另外生成完的用例集我会过一道“LLM as Judge”的自动初筛让第二个模型实例扮演资深测试专家把明显无效的、重复的、跟PRD冲突的用例先标记出来人工只处理争议项。这套组合拳下来幻觉用例的比例能从纯自动生成的20%左右压到5%以内。3. 实操流程从PRD到测试用例的四步法3.1 第一步把PRD拆成结构化需求单元整个流程的起点不是“生成用例”而是“拆需求”。我会让LLM先把PRD转成一张需求单元表每条包含需求ID、所属模块、需求描述、业务规则、优先级、依赖关系。这一步相当于建好了后面所有用例的地基。提示词我放在下面你可以直接抄你是一名资深产品经理。请阅读以下PRD文档按功能模块拆分为需求单元列表。 每个需求单元必须包含 - req_id唯一编号格式为MODULE-序号 - module所属功能模块 - summary一句话需求描述 - rules从PRD中提炼的业务规则用列表列出必须在PRD中有原文依据 - priorityP0/P1/P2P0为核心主流程P1为重要分支P2为次要优化 - dependency该需求依赖的其他需求ID没有则填无 要求 1. 不要合并语义不同的规则 2. 不要臆造PRD中不存在的规则 3. 输出为JSON数组格式严格按以下示例结构 [{req_id: ORDER-001, module: 订单, summary: 用户可提交订单, rules: [登录用户可提交订单, 订单金额大于0], priority: P0, dependency: USER-001}]这一步看着简单但直接影响后续质量。我踩过一个坑一开始没让模型标注dependency结果后面生成用例时系统自动把“依赖条件”漏掉了比如只测了“优惠券可叠加”的正向没测“先满足满减再计算优惠券”的顺序逻辑。所以我的建议是拆需求单元时宁可拆得碎一点也不能图快合并。3.2 第二步按需求单元批量生成测试场景需求单元拆完以后把它们分批喂给LLM让它输出测试场景。测试场景是“从测试视角描述要验证什么”比用例高一层级相当于中间产物方便评审时快速判断有没有遗漏。比如对于ORDER-001LLM会生成这些场景正向场景登录用户提交合法订单系统创建订单成功边界场景订单金额为0.01元时能否提交异常场景未登录用户调用提交接口返回401权限场景普通用户尝试查看他人订单返回无权限组合场景同时使用优惠券和满减系统按优先级计算我通常会在这一步把场景类型打成标签正向、反向、边界、异常、权限、性能、兼容这样后续计算覆盖率时可以按维度统计比单纯数用例条数有意义得多。提示词里要注意强调“每个需求单元至少生成五个场景必须包含两类反向场景”否则LLM容易偷懒只给正向。3.3 第三步套用测试用例模板生成可执行用例有了场景再到用例就简单了。这一步我用的是固定的用例模板字段包括用例ID、关联需求ID、用例标题、前置条件、测试步骤、测试数据、预期结果、优先级、自动化标识。换成JSON示例就是这样{ case_id: TC-ORDER-001-01, req_id: ORDER-001, title: 未登录用户提交订单返回401, precondition: 浏览器未登录订单接口可用, steps: [打开创建订单页面, 填写商品ID1001数量1, 点击提交订单], test_data: {product_id: 1001, quantity: 1, token: null}, expected: 接口返回401提示用户登录, priority: P1, automation_ready: true }注意一个细节我会在提示词里给模型看三四个这种完整示例也就是Few-shot。别指望它看一遍字段定义就能稳定输出给足示例比你把要求说十遍都管用。另外LLM生成用例时经常把多个步骤挤在一行里我在后处理脚本里会强制按分号和“然后”进行二次切分把步骤拆成数组保证用例进测试平台后被自动化框架正确识别。3.4 第四步建立需求追踪矩阵并计算覆盖率所有用例生成完我拿需求单元表和用例表做一次关联生成需求追踪矩阵RTM。这个矩阵的核心作用就是回答一个问题每个需求点到底有没有对应的测试用例没有的话就是覆盖缺口。我会让脚本自动统计“无用例关联的需求ID”再交给LLM补生成直到覆盖率达到目标线。这里给个小技巧矩阵里不光要填“有无覆盖”还要填“覆盖类型”——是正向覆盖还是异常覆盖。只有正向覆盖的P0需求在我的统计口径里算“半覆盖”因为它很可能漏掉了真正的风险。4. 覆盖率提升45%是怎么算出来的4.1 先定义清楚这里说的是什么覆盖率谈覆盖率之前一定要先明确口径否则就是耍流氓。我们日常说的覆盖率通常有好几种功能覆盖率、需求覆盖率、代码覆盖率语句/分支/条件。标题里说的45%指的是需求功能覆盖率——即PRD中所有可测需求点被有效用例覆盖的比例。它跟代码覆盖率不是一回事代码覆盖率要等用例跑起来之后用工具去统计而需求覆盖率是在用例设计阶段就能算出来的。如果你想提升的是代码结构覆盖率那光靠生成用例不够还得靠用例执行和插桩分析别把两个概念混了。4.2 对比实验的基线怎么定为了验证LLM方案的提升效果我做了个对照实验。拿同一个项目的PRD先让两位组内资深测试工程师按老办法手工设计用例统计出基线覆盖率再把同一份PRD喂给LLM生成用例后经过人工筛选统计新覆盖率。两组用的需求单元表完全一样以避免“需求拆分粒度的不同”干扰比较结果。这个对照设计很关键不然你说提升了45%评审会质疑“是不是你手工组本来就漏得太多”。4.3 45%的具体数字拆解把计算过程摆给大家看。这份PRD里一共梳理出120个可测需求点。手工组合计有效覆盖了40个需求点其中完整覆盖正向异常边界24个部分覆盖只有正向16个LLM组合计有效覆盖58个需求点其中完整覆盖41个部分覆盖17个。怎么算的45%呢基线覆盖数是40个新增有效覆盖的需求点数是58减40等于18个18除以40等于45%。所以不是“所有需求里多了45%”而是“在原有人工覆盖的基础上多覆盖了45%的需求点”。正因为有了需求追踪矩阵每一步都不靠猜这数字才能拿去跟老板汇报。4.4 怎么防止覆盖率虚高用LLM生成用例最容易出现的情况是看起来覆盖了58个需求点实际一执行发现一堆用例根本跑不通。为什么会虚高三种原因。第一用例步骤描述模糊自动化脚本无从下手第二预期结果写得太宽泛比如“系统处理成功”压根没验证关键字段第三用例之间大量重复换个数据就又是一条新用例。我应对的方式是三道过滤第一道格式校验脚本检查用例字段是否齐全、预期结果里是否含明确断言第二道LLM as Judge做语义去重把步骤相似度高于一定阈值的用例聚成一簇人工选代表第三道人工抽检每周抽10%的用例放到真实环境上跑跑不通过的直接打回重新生成。这样筛完剩下的用例才敢算进覆盖率口径里。5. 常见问题与排查技巧实录5.1 PRD质量太差大模型也救不了最扎心的情况是PRD写得跟产品经理的随手记一样全是“大概”“可能”“用户能正常下单”没有精确的规则描述。LLM不是神仙它最多能从“正常下单”这种话里推断出一个正向场景边界规则全靠猜。我的解决办法是加一个前置预处理步骤先把PRD里所有“形容词”和“模糊词”列出来让LLM标记出哪些需求点缺少明确规则再人工补充约束。简单说LLM负责“把能拆的都拆出来”人负责“把该补的规则补清楚”这条流程跑通之前别指望直接生成用例。5.2 输出格式飘了解析脚本全崩用API做生成的老实说再规范的提示词偶尔也会碰到一次输出里混入散文或者多个JSON块。尤其是模型上下文太长之后更容易出现“头尾正常、中间乱写”的情况。我现在的做法是不追求一次性生成几百条用例而是按模块分批调用每批最多50条同时在代码里做JSON解析的容错抽取所有json代码块再合并。输出失败或解析失败的任务自动降低温度重试一次。重试还失败就进人工队列。这套兜底机制上线后因为格式问题重跑的次数从每天十几次降到了两三次。5.3 “幻觉用例”看着合理实际执行必挂这是大家问得最多的问题。举个例子PRD里只写了“优惠券有效期至2025年12月31日”LLM在生成用例时推断出“过期优惠券不能使用且前端置灰提示”这个推断本身是合理——但问题在于需要确认代码是否真的实现了这个逻辑如果没实现这条用例执行必挂。它不是“错误用例”但它是“超出PRD范围的用例”。我的经验是要把这类推断场景和PRD原文场景分开管理。原文场景直接进入用例库推断场景先打上“待确认”标签产品和技术评审通过后再转正。这么做的另一个好处是你还可以顺手发现“PRD没写但实际应该有的规则”反向推动PRD完善。5.4 用例重复和粒度不统一怎么破用例一多重复问题就暴露了。同一份PRD不同的需求单元里可能都会提到“登录状态校验”LLM会在每个模块下都生成一条登录校验用例单看没问题合到一起就冗余了。我做了一个简单的归一化规则在结果汇总阶段按“接口或页面对象 操作动作”生成一个哈希指纹指纹相同的用例自动归并只保留优先级最高的那条。至于粒度不统一是因为LLM对“一个步骤”的理解不稳定。解决方法是把步骤拆到“可用一个接口请求或一个页面操作完成”的最小粒度并在后处理时用标点符号做强制拆分实在拆不开的再丢回LLM重写。5.5 常见问题速查表问题现象根本原因排查方法解决方案生成的用例多是正向主流程提示词未强调反向场景统计场景类型标签分布提示词明确要求异常/边界/权限场景数量频繁输出非JSON格式模型上下文过长导致漂移检查输出日志中的截断位置分批调用每批控制50条以内用例步骤无法自动化步骤粒度太粗或含模糊描述人工抽查自动化标识强制按“操作对象动作数据”拆分覆盖率高但执行大量失败预期结果没有具体断言筛选预期结果含否定的用例要求预期结果包含明确状态码或字段值越到文档后面覆盖越低长文档注意力衰减检查PMD后半部分生成的用例数将PRD按模块切分后独立调用6. 工程化落地的几点经验6.1 提示词和模板要版本化很多团队用LLM生成用例都是各自写各自的提示词成果留在个人笔记本里换个人就一切重来。我建议把提示词和输出模板当作代码一样管理放进Git仓库每次改动走评审。为什么因为提示词对生成质量的影响可能比你换一个模型都大。我前前后后迭代了十几个版本的“需求拆分提示词”每次改动都记录了样例输出的对比结果后来团队新同学接手直接照着模板用半天就能上手。模板化还有一个好处就是不同业务线的PRD虽然内容不同但产出的用例结构统一后面做统计和自动化都很方便。6.2 人机分工LLM负责“广撒网”人工负责“定生死”我始终不主张“完全让LLM自动生成、自动入库”那样早晚出事故。更现实的模式是LLM批量产出用例草稿自动完成格式清洗和重复归并然后推给测试人员进行分级评审评审不是逐条读而是按“需求单元”批量看重点看推断场景和P0用例。节省下来的时间你可以去做真正有价值的事——设计复杂的业务规则校验、梳理跨模块的数据流、优化自动化脚本的稳定性。说白了LLM把“从无到有”的空白填上了人把“从有到对”的质量关守住两边配合才是效率最高的配方。6.3 与自动化测试链路打通生成出来的用例不能停在Excel里一定要往执行侧推进。我们目前的做法是用例入库时给每个用例打上automation_ready标记脚本框架能识别这个字段凡是标记为true的用例自动映射到Playwright对应的页面对象和接口调用参数。这样新需求上线时LLM生成用例后自动化团队只需要补齐脚本实现用例结构已经提前规范好了不用再手工重写一遍。如果你用的是pytest、TestNG之类的框架原理也一样——关键是让用例模板的字段设计从一开始就跟自动化框架的数据模型对齐不然后续转换要写一堆胶水代码。6.4 长期保持覆盖率不下滑最后分享一个维护上的小心得。用例库是会“腐烂”的三个月不维护覆盖率数字就会悄悄下降。我的做法是每个迭代都跑一遍“增量覆盖检查”新PRD进来只让LLM生成增量需求相关的用例同时标记出哪些旧用例因为需求变更而失效。这样用例库不会无限膨胀覆盖率也能维持在稳定水平。这套流程上线半年后我们不光把需求覆盖率提上来了还顺手把用例评审会议的时长缩短了一半——因为会前大家看的是LLM整理好的覆盖差异报告而不是现场翻几百条用例。说点实在的体会LLM批量生成测试用例这件事本质上是把“测试设计”从纯手工活变成了“人机协作的流水线”。它不会替代测试人员的判断力但能把你的精力从重复劳动里释放出来你的价值也就体现在筛选、判断、补规则这些更高层的地方。这套方案不一定适合所有项目但对PRD结构相对完整、需求迭代频繁的团队来说确实是我近几年试过最值得投入的提效方向之一。