把PRD直接变成测试意图：一次真实需求评审到测试用例的落地实战

原创

AI智享空间

发布于 2026-08-18 13:12:36

671

文章被收录于专栏：效能提升效能提升软件测试

图片

一、实验背景：一份真实的PRD，不是示例文档

我们用的PRD，是产品经理小李在一个迭代里实际交付的文档。功能是电商平台的"优惠券领取与使用"模块改版，包含以下几个子功能：

用户在活动页领取优惠券（新增：支持一键领取全部可领券）
优惠券使用规则调整（原来满100减10，新增阶梯满减：满200减30，满500减100）
优惠券叠加规则：满减券和折扣券不可叠加，但可以和运费券叠加
优惠券有效期展示优化：从"2024-12-31到期"改为"还有X天到期"

PRD共11页，包含原型图链接、交互说明、业务规则、边界说明。这是一份"中等质量"的PRD——主干清晰，但细节有若干模糊点，这在现实项目里很正常。

实验目标：记录从这份PRD到测试意图集的完整过程，每个环节标注是AI完成还是人工介入，以及为什么。

二、第一步：把PRD喂给AI——看它能提炼出什么

第一轮，不做任何处理，直接把PRD文本粘贴给Claude，用以下Prompt：

以下是一份产品需求文档，请从测试工程师的角度，
提炼出所有需要被验证的测试意图（Intent）。

测试意图的格式要求：

- 用"用户能够……"或"系统应该……"开头
- 描述业务行为，不描述UI操作
- 每条意图对应一个可验证的业务目标
- 按功能模块分组

PRD内容：[粘贴完整PRD文本]

AI输出的第一版测试意图（节选）：

【优惠券领取模块】
1. 用户能够在活动页看到自己可以领取的所有优惠券列表
2. 用户能够单个领取每一张可领优惠券
3. 用户能够通过"一键领取"按钮同时领取所有可领优惠券
4. 已经领取过的优惠券对用户不可重复领取
5. 活动结束后，领取入口应该关闭，用户无法再领取

【优惠券使用模块】
6. 满200元订单，用户能够使用满200减30的优惠券
7. 满500元订单，用户能够使用满500减100的优惠券
8. 不满足任何满减门槛的订单，优惠券应显示为不可用状态
9. 满减券和折扣券不能同时使用
10. 满减券可以和运费券同时使用
11. 折扣券可以和运费券同时使用

【有效期展示模块】
12. 优惠券应显示"还有X天到期"而非具体日期
13. 当天到期的优惠券应显示"今天到期"或"还有0天到期"

第一轮的结论：AI做得不错，但有明显的空白区。

主干场景覆盖完整，格式规范，语言自然。但有几类场景完全没有出现：

并发领券的场景（多人同时点"一键领取"，库存只剩1张）
阶梯满减的计算准确性（499元能用满200减30吗？这个边界点）
优惠券叠加时的金额计算顺序（先减满减再打折？还是先打折再减满减？）
优惠券已过期但还在购物车里的显示状态

这些空白，不是AI偷懒，是PRD本身没有把这些场景写出来。AI只能从PRD里提炼，PRD里没有的，AI提炼不出来。

三、第二步：让AI主动挖PRD的模糊点

第二轮，换一个角度：不让AI提炼意图，让它找问题。

仔细阅读这份PRD，识别其中存在以下类型的问题：
1. 业务规则描述不完整（只说了正常情况，没说异常情况）
2. 边界条件未定义（金额刚好满足门槛时怎么处理）
3. 并发场景未考虑（多用户同时操作时的一致性）
4. 状态转换未覆盖（对象从一个状态变到另一个状态的所有路径）
5. 与其他功能的交互未说明（这个功能影响哪些已有功能）

对每个问题，给出：问题描述 + 测试中可能产生的风险 + 建议向产品确认的问题

AI输出的模糊点分析（部分）：

【问题1】阶梯满减的累计规则未明确描述：PRD说"满200减30，满500减100"，但未说明：  订单金额600元，是减30（满200档）还是减100（满500档）？  还是两者都减（200+400=600，减30+100=130）？测试风险：金额计算逻辑有三种可能实现，测试需要知道哪种是正确的建议确认：满减是取"最优档"还是"所有满足档次叠加"？
【问题2】"一键领取"的部分失败未定义描述：用户点击"一键领取"时，如果某些券的库存在点击瞬间耗尽，  系统应该怎么处理？是领取所有可领的券并告知哪些没领到？  还是整体失败？还是静默略过？测试风险：不同处理方式对应完全不同的测试场景建议确认：部分失败时的用户反馈和系统行为
【问题3】优惠券过期的实时性未定义描述：用户在购物车里已经选中了一张优惠券，这张券在他结算前一秒到期，  结算时系统应该怎么处理？测试风险：如果未处理，可能出现用户用过期券完成支付的漏洞建议确认：结算时是否需要实时校验优惠券有效性
【问题4】"还有X天到期"的计算基准未明确描述：X天是按自然日算（今天算一天），还是按剩余小时数算（不足24小时显示今天到期）？  例如：优惠券2024-12-31 23:59到期，2024-12-31的早上显示"还有0天"还是"今天到期"？测试风险：显示逻辑和用户预期可能不符建议确认：X天的计算规则和今天到期的判断逻辑

这一轮的价值，远超第一轮。

AI找出的四个模糊点，每一个在测试中都可能产生真实的问题——如果不在需求阶段问清楚，测试阶段要么猜着写用例，要么上线后发现缺陷。

这份分析，我们在需求评审会的前一天发给了产品经理小李，让她在评审会上针对性地解答。

四、第三步：需求评审会——人工介入的核心环节

带着AI整理的四个问题，进入需求评审会。

这个环节，是整个流程里最需要人工全程参与的部分。

评审会上的三个确认结果：

问题1（阶梯满减）：取"最优档"，不叠加。600元订单只能减100，不能减130。

问题2（一键领取部分失败）：领取所有可领的，库存不足的跳过，结束后展示领取成功的数量和失败的数量，比如"成功领取3张，2张已抢完"。

问题3（过期实时校验）：结算时实时校验，过期券自动移除并弹窗提示，不允许用过期券结算。

问题4（X天计算）：按自然日，不足一天按"今天到期"处理，但同时要加红色警示样式（这是评审会上产品新补充的，原PRD里没有）。

会议上出现了一个原来AI也没有发现的新问题——运费券的叠加顺序。

开发工程师问：满减券+运费券，是先减满减再判断运费？还是先算订单总金额（含运费）再减满减？不同顺序，满减门槛的计算基数不同，可能影响用户是否达到门槛。

这个问题，PRD里没有，AI也没有发现（因为PRD里运费和订单金额的关系描述是分开的），是开发的实现经验触发了这个边界。

评审会结束，小李补充了PRD，我们更新了问题列表。

为什么这个环节必须人来做：

需求评审会的价值，不在于"把PRD读一遍"，而在于不同角色的认知碰撞——开发的实现经验、测试的边界意识、产品的业务意图，三者放在一起，才能发现任何一方单独看不到的问题。AI能提炼单份文档的问题，但触发不了跨角色认知碰撞产生的新问题。

五、第四步：把会议结论回写给AI，生成完整意图集

评审会结束，把以下内容整合给AI：

原始PRD
四个模糊点的确认结论
评审会新发现的运费问题及结论

第二版Prompt：

以下是更新后的需求信息，包括原始PRD和评审会的补充确认结论。
请生成完整的测试意图集，要求：

1. 覆盖所有正常路径（Happy Path）
2. 覆盖所有边界条件（Boundary）
3. 覆盖所有异常路径（Negative）
4. 覆盖并发场景（Concurrency，如有）
5. 每条意图标注类型和优先级（P0/P1/P2）
6. 对于每条意图，给出简短的"验证关注点"说明

[粘贴整合后的需求信息]

AI输出的完整测试意图集（节选关键部分）：

【优惠券领取 - 正常路径】INT-001 [P0] 用户能够查看活动页上所有自己可领取的优惠券  验证关注点：展示数量、券面信息准确性
INT-002 [P0] 用户能够单张领取任意一张可领优惠券并领取成功  验证关注点：领取成功后券的状态变为"已领取"，库存相应减少
INT-003 [P0] 用户能够通过"一键领取"同时领取所有可领优惠券  验证关注点：全部成功时展示"成功领取N张"
INT-004 [P1] 一键领取时部分券库存耗尽，系统正确提示领取数量和失败原因  验证关注点：成功数和失败数显示准确，成功领取的券出现在用户券包里
【优惠券领取 - 边界条件】INT-005 [P1] 用户尝试重复领取同一张优惠券，系统拒绝并给出合理提示  验证关注点：第二次领取被拦截，用户已有这张券的状态不受影响
INT-006 [P1] 活动最后一张优惠券被领取后，入口正确关闭  验证关注点：库存归零后领取按钮变为不可用状态
INT-007 [P2] 活动结束时刻（到期时间点）领取请求的处理  验证关注点：活动到期后的请求被拒绝，不影响已领取的券
【优惠券使用 - 满减计算】INT-008 [P0] 订单金额满500元，系统正确应用满500减100优惠券（取最优档）  验证关注点：优惠金额为100元，不是30+100=130元
INT-009 [P0] 订单金额恰好等于200元，满200减30优惠券可以使用  验证关注点：边界值200元刚好满足门槛，不是201元才算
INT-010 [P1] 订单金额199元，满200减30优惠券显示不可用  验证关注点：199元不满足门槛，券变灰且给出"差X元可用"提示
INT-011 [P1] 订单金额499元，满500减100不可用，但满200减30可用  验证关注点：只应用满足门槛的最高档，不是最贵档
【优惠券叠加规则】INT-012 [P0] 用户尝试同时使用满减券和折扣券，系统阻止并给出说明  验证关注点：选第二张时，与第一张冲突的券变为不可选状态
INT-013 [P0] 满减券和运费券可以同时使用，金额计算正确  验证关注点：先以订单商品金额计算满减门槛（不含运费），  再用运费券抵扣运费，验证每步金额正确
INT-014 [P1] 折扣券和运费券可以同时使用，折扣基数为商品金额  验证关注点：折扣应用于商品金额，运费单独处理，合计金额正确
【有效期展示】INT-015 [P1] 距到期超过1天的优惠券显示"还有X天到期"（X按自然日计算）  验证关注点：明天到期的券今天显示"还有1天到期"
INT-016 [P1] 当天到期的优惠券显示"今天到期"并有红色警示样式  验证关注点：今天23:59到期的券，今天早上就应显示"今天到期"+红色
【并发场景】INT-017 [P1] 多用户同时领取同一张限量优惠券时，库存不超发  验证关注点：并发100次请求，最终领取成功数不超过实际库存数
INT-018 [P2] 结算时已选优惠券在支付前到期，系统实时校验并阻止使用  验证关注点：过期券被自动移除，弹窗提示，用户需重新确认订单

这一版，比第一轮多了11条意图，覆盖了所有评审会确认的边界条件和并发场景。

六、第五步：人工校验补全——AI提不出的那些东西

拿到AI生成的意图集之后，测试工程师做了一轮人工review，补充了4条AI没有生成的意图：

补充1：历史数据兼容

INT-019 [P1] 用户的历史优惠券（改版前领取的满100减10券）
    在新系统里仍然可以正常使用和显示
    验证关注点：新旧规则并存期间，旧券不受新规则影响

AI不知道系统有历史数据，PRD里也没有写数据兼容这件事。但测试工程师知道：这个系统已经运行了一年，有大量历史优惠券数据，改版后的兼容性是一个真实风险。

补充2：极端金额的精度问题

INT-020 [P2] 折扣券（如九折）应用于含小数的商品金额时，结果精度正确
   验证关注点：商品199.9元打九折=179.91元，不是179.9或180元，
   精度处理和进位规则符合业务定义

这个场景，PRD里没有，AI也想不到。是测试工程师从之前系统里处理过浮点数精度问题的经验里补充的。

补充3：多设备状态同步

INT-021 [P2] 用户在手机上领取优惠券后，在PC端的券包里即时可见
   验证关注点：多端数据同步的实时性

补充4：优惠券的退款联动

INT-022 [P1] 使用优惠券下单后申请退款，退款金额的计算规则符合预期
   验证关注点：优惠券是否退还？退还金额是优惠后实付还是原价？
  （这需要再次确认产品策略）

补充4还带出了一个新问题——退款时优惠券的处理策略，PRD里没有。这条意图被标记为"待确认"，发回给产品经理。

七、整个流程的分工总结

把全程的人机分工整理成一张清单：

环节                    谁来做          原因

从PRD提炼主干意图        AI              信息完全在文档里，AI提炼效率高
识别PRD的模糊点          AI              模式识别，AI擅长
需求评审会讨论           人工（必须）    跨角色认知碰撞，触发新问题
把会议结论回写给AI       人工（必须）    人判断什么信息值得回写
生成完整意图集           AI              结构化输出，AI擅长
识别历史数据兼容风险     人工（必须）    需要系统运行经验，文档里没有
识别精度/浮点等技术风险  人工（必须）    需要实现层经验，文档里没有
多端同步等架构级场景     人工（必须）    需要了解系统架构，AI不知道
识别和其他功能的联动     人工（必须）    需要产品知识积累，PRD无法覆盖
最终质量判断             人工（必须）    测试意图集是否完整，人负责