原创内容未获授权禁止转载、转发、抄袭。很多测试同学拿到 PRD 后会直接把需求丢给 AI然后让它“生成测试用例”。这样做看起来省事但结果往往不稳定格式很完整内容却很虚维度很多真正能落地的测试点不多。AI 更适合做需求拆解而不是一上来就替你写用例。正确的用法是先让 AI 提取业务规则、状态流转、异常分支和风险点再由测试人员评审、补充和收敛。一、不要直接让 AI 写测试用例不推荐这样问根据下面 PRD帮我生成测试用例。这种问法很容易得到模板化内容比如功能测试、异常测试、兼容性测试、安全测试看起来很全但实际评审时会发现很多内容都不够具体。更推荐这样问你先不要写测试用例。请阅读下面 PRD帮我提取 1. 核心业务流程 2. 关键业务规则 3. 用户角色和权限 4. 状态流转 5. 测试需要重点关注的风险点 要求 - PRD 没写清楚的地方标记为「需确认」 - 不要自行补充业务规则 - 不要输出空泛描述先拆需求再写测试点质量会高很多。二、先把 PRD 拆成业务规则PRD 里很多规则不是集中写在一起的而是散落在说明、备注、异常处理里。测试人员可以先让 AI 把需求整理成结构化规则。示例 PRD用户提交订单后30 分钟内未支付系统自动取消订单。 已支付订单不允许取消。 用户主动取消订单后优惠券需要退回库存需要释放。 部分商品不支持取消。可以这样问 AI请基于这段 PRD按「规则、触发条件、系统处理、测试关注点」整理成表格。整理结果示例规则触发条件系统处理测试关注点超时取消订单创建后 30 分钟未支付系统自动取消订单定时任务是否准时执行已支付不可取消订单状态为已支付拒绝取消前端入口和后端接口是否都限制取消退券用户主动取消订单优惠券恢复可用过期券、失效券是否退回需确认库存释放订单取消成功库存回补是否会重复释放库存商品限制商品不支持取消不允许取消商品维度规则是否生效这一步的价值是把“描述型需求”变成“可测试规则”。如果规则拆不清楚后面生成再多用例也容易跑偏。三、再让 AI 拆测试点业务规则明确后再让 AI 拆测试点而不是直接写完整用例。推荐提示词基于上面的业务规则请从以下维度拆测试点 1. 正常流程 2. 异常流程 3. 状态流转 4. 数据一致性 5. 权限与入口限制 6. 定时任务和并发场景 要求 - 不要写完整测试用例 - 每条测试点必须具体、可执行 - 不要输出“验证功能正常”这类空话 - PRD 未明确说明的规则标记为「需确认」输出示例模块测试点订单取消未支付订单可以主动取消取消后状态变为已取消订单取消已支付订单页面不展示取消入口接口校验已支付订单直接调用取消接口时后端返回失败优惠券使用优惠券的订单取消后优惠券恢复为可用库存订单取消成功后商品库存正确回补定时任务未支付订单超过 30 分钟后自动取消并发处理用户手动取消和系统自动取消同时触发时只能成功一次商品规则不支持取消的商品前端不展示入口后端也要拦截测试点先出来再转测试用例会比一开始就生成用例更稳。订单、支付、审批、权限、库存这类强规则场景都适合先用这种方式拆一遍。四、测试人员重点补这 4 类风险AI 可以补覆盖面但真实项目里的风险还需要测试人员自己判断。尤其下面 4 类不能只依赖 AI 输出。1. 接口绕过页面不展示按钮不代表后端一定安全。比如“已支付订单不允许取消”不能只看页面是否置灰还要直接调用取消接口验证后端是否拦截。2. 状态并发用户手动取消、系统自动取消、支付回调可能在接近时间触发。如果状态控制不严很容易出现重复取消、库存重复释放、订单状态被覆盖等问题。3. 数据一致性订单取消后不能只看订单状态还要检查优惠券、库存、支付单、操作记录是否同步处理。测试时要关注主数据和关联数据是否一致。4. 历史兼容新规则上线后历史订单、历史优惠券、老版本客户端是否会受影响PRD 里经常不会写清楚但测试评审时必须追问。五、把 AI 输出变成评审清单AI 拆出来的测试点不建议直接复制到用例平台。更好的方式是先整理成评审清单让产品、开发、测试一起确认。测试范围测试点状态备注订单状态未支付订单可主动取消已确认取消后状态为已取消订单状态已支付订单不可取消已确认前后端都需要限制优惠券取消订单后优惠券退回待确认需确认过期券是否退回库存取消订单后库存释放已确认注意并发取消定时任务30 分钟未支付自动取消待确认需确认任务执行频率这一步很关键。测试人员真正要做的不是盲目接受 AI 结果而是通过 AI 输出反向发现 PRD 中没有说清楚的地方。六、推荐工作流实际项目中可以按下面流程使用 AIPRD 原文 ↓ AI 提取业务规则 ↓ AI 拆核心流程和状态流转 ↓ AI 生成测试点 ↓ 测试人员补充风险场景 ↓ 产品、开发、测试一起评审 ↓ 整理成正式测试用例直接让 AI 写测试用例看似快后面很容易返工。先拆需求、提规则、找风险反而更容易发现问题也更适合在需求评审阶段使用。七、通用提示词模板你是一名有经验的测试工程师。请阅读下面 PRD不要直接生成测试用例先帮我完成需求拆解。 请输出以下内容 1. 核心业务流程 2. 关键业务规则 3. 状态流转 4. 用户角色和权限 5. 正常场景测试点 6. 异常场景测试点 7. 数据一致性测试点 8. 需要向产品确认的问题 要求 - 测试点必须具体、可执行 - 不要输出空泛描述 - PRD 未说明的地方标记为「需确认」 - 不要自行假设业务规则 - 输出内容适合用于测试评审总结AI 不是用来替测试人员一键写用例的而是用来帮我们更快发现 PRD 里没写清楚的地方。真正有价值的用法是让 AI 先把需求拆透再由测试人员补风险、查边界、推评审最终形成可执行、可评审、可追溯的测试方案。