导读
测试用例写完以后，最怕的不是数量不够，而是评审会上被连续追问：
“这个前置条件是什么？” “这里为什么直接跳到下一步？” “预期结果怎么算出来的？” “边界值有没有覆盖？” “PRD 里这个互斥规则，用例体现了吗？”
很多测试工程师都有类似经历：辛辛苦苦写了几十条、上百条用例，结果到了评审阶段，被产品、开发、测试负责人一轮追问，发现问题并不在“不会写用例”，而在于缺少一套稳定、可复用、可量化的用例审核标准。
这篇文章想聊的，不是简单让 AI 帮你“看看用例有没有问题”，而是一个更适合测试开发落地的能力：
把测试用例评审经验，封装成一个 AI 测试用例审核 Skill。
它可以在正式评审前，对测试用例进行批量检查、逐条评分、指出扣分原因，并给出修改建议。
从测试团队的角度看，它的价值不是替代测试负责人，而是先把那些低级问题、逻辑矛盾、覆盖遗漏和系统性缺陷提前筛出来。
先说清楚：这个 Skill 到底是什么？
这里说的 测试用例审核 Skill，不是一个单独的软件，也不是某个平台里的固定按钮。
你可以把它理解成：
把资深测试负责人评审测试用例时的检查标准，封装成一个 AI 可执行的能力包。
它通常由三部分组成。
所以，它不是简单问 AI 一句：
帮我看看这些测试用例有没有问题。
而是让 AI 按一套固定标准执行用例评审。
例如，你可以把 PRD、测试用例 Excel、Markdown 文档或截图上传给 AI，然后触发这个 Skill，让它完成下面这些工作：
逐条检查测试用例是否可执行
判断步骤和 PRD 规则是否冲突
检查预期结果是否明确
发现前置条件是否缺失
对照 PRD 判断核心规则是否覆盖
找出边界值、异常流、互斥规则是否遗漏
给每条用例打分
输出扣分原因和修改建议
汇总批量重复问题
从测试开发角度看，它更像是一个 AI 用例评审器。
输入是 PRD 和测试用例，输出是用例质量评分报告。
如果团队已经有 WorkBuddy、Dify、Coze、OpenWebUI、企业内部 Agent 平台，或者自研测试平台，都可以把这套能力做成一个 Skill、Agent 或工作流。
如果暂时没有平台，也可以先用一段结构化 Prompt 实现基础版。
核心不在于它叫什么名字，而在于它把“测试用例评审经验”变成了可复用、可执行、可量化的审核标准。
目录
为什么测试用例评审总是容易被追问
AI 用例审核 Skill 的核心价值是什么
5 个维度，构建测试用例质量评分模型
真实场景：618 大促用例到底能审出什么
典型问题拆解：一条 54 分用例为什么不合格
批量审核的价值：发现系统性遗漏
它适合哪些测试场景
它的边界在哪里
测试团队如何落地这套审核流程
一个可复用的测试用例审核 Prompt
写在最后：AI 不是替你评审，而是帮你建立标准
- 为什么测试用例评审总是容易被追问
测试用例评审中，很多问题并不是因为测试同学不认真，而是因为用例质量本身缺少统一标准。
同一条用例，有的人觉得“能执行就行”，有的人会追问“预期结果是否可验证”，还有人会继续追问“边界值、异常流、互斥规则是否覆盖”。
这就导致一个现象：
测试用例质量高度依赖评审人的经验。
经验丰富的测试负责人，能一眼看出这条用例少了前置条件、那条用例预期结果不清楚、某个业务规则没有覆盖。
但如果团队没有沉淀统一标准，换一个人评审，结论可能完全不同。
常见问题包括：
所以，用例评审真正需要解决的问题，不是简单判断“这条用例好不好”，而是要回答：
它为什么好？为什么不好？差在哪里？怎么改？
这就是 AI 测试用例审核 Skill 的价值所在。
- AI 用例审核 Skill 的核心价值是什么
很多团队已经开始尝试用 AI 写测试用例，但“写用例”只是第一步。
真正进入团队协作后，更关键的问题是：
这些用例能不能通过评审？能不能执行？能不能沉淀为长期可复用的团队资产？
AI 用例审核 Skill 解决的不是“生成更多用例”，而是“检查已有用例的质量”。
它可以把测试负责人日常评审中的经验动作，拆成一套标准流程：
看步骤是否完整
看前置条件是否清楚
看预期结果是否可验证
看是否覆盖 PRD 核心规则
看边界值、异常流、互斥场景是否遗漏
看多条用例中是否存在重复性的系统问题
过去，这些判断依赖人工经验。
现在，可以先交给 Skill 做一次初筛。
这样做的好处是：
第一，评审前先发现问题。 正式评审时，不再把时间浪费在格式不规范、步骤跳跃、预期不清楚这些基础问题上。
第二，评审标准更稳定。 不同测试人员、不同项目、不同模块，都可以按照同一套规则进行自检。
第三，新人更容易成长。 Skill 不只是告诉你“错了”，还会告诉你为什么扣分、应该怎么改。
第四，历史用例库可以批量治理。 很多团队历史用例库越积越多，但质量参差不齐。AI 审核可以帮助快速摸清用例资产的真实质量。
- 5 个维度，构建测试用例质量评分模型
从测试开发的角度看，一条测试用例是否合格，至少要看 5 个维度。
总分 100 分，默认 60 分作为及格线。
但这里要注意，60 分并不代表用例质量高，只代表这条用例基本可读、可执行。
如果要进入正式评审，建议至少达到 75 分以上。
如果是支付、金融、订单、库存、权限、风控这类高风险业务，建议及格线可以设得更高，比如 80 分。
因为这些场景一旦用例描述不清楚，后续带来的问题不是“评审不好看”，而是可能直接影响测试结论。
- 真实场景：618 大促用例到底能审出什么
以一个典型的 618 大促活动为例。
PRD 中包含如下规则：
满减规则：满 100 减 10，满 200 减 30，满 500 减 80
优惠券规则：满减后再使用品类优惠券
叠加限制：同一订单最多使用 2 张优惠券
互斥规则：新人专享券与品类券不可叠加
商品限制：仅实物商品参与活动，虚拟商品不参与
库存规则：允许超卖，容限为 ±3%
支付规则：支付超时 30 分钟自动关闭，最多可延长支付 1 次，每次 15 分钟
测试同学根据 PRD 编写了 45 条测试用例，看起来覆盖了活动时间、满减、优惠券、库存、支付等核心模块。
如果只看数量和模块划分，这批用例似乎没有明显问题。
但用审核 Skill 批量评审后，会发现一些在人工评审会上高频被追问的问题。
这类问题有一个共同点：
单独看不一定明显，但一旦进入正式评审，很容易被产品、开发、测试负责人追问。
也就是说，Skill 审核出来的不是“文档格式小问题”，而是评审会上真正会影响结论的问题。
- 典型问题拆解：一条 54 分用例为什么不合格
来看一个典型问题用例。
原始用例描述：
TC045：优惠券叠加使用 3 张验证 步骤：
商品 A 价格 100 元，商品 B 价格 100 元
选择优惠券 A、优惠券 B、优惠券 C
提交订单 预期结果：商品 A 剩余 70 元
这条用例表面上是在验证优惠券叠加，但从专业评审角度看，至少有 4 个问题。
问题一：步骤与 PRD 规则冲突
PRD 明确规定：
同一订单最多使用 2 张优惠券。
但用例中直接选择了 3 张优惠券。
如果这条用例的目标是验证“超出优惠券数量限制”，那预期结果应该写成系统禁止选择第 3 张，或者提交时提示超限。
如果这条用例的目标是验证“正常叠加优惠”，那步骤就不能写 3 张券。
这就是典型的逻辑冲突。
问题二：预期结果不可验证
“商品 A 剩余 70 元”这个描述不够清楚。
它到底表示：
商品 A 原价 100 元，减 30 后为 70？
商品 A 分摊优惠后实付 70？
整个订单减完后，商品 A 的展示金额为 70？
还是商品 A 库存剩余 70 件？
测试用例里的预期结果，不能依赖执行人员猜测。
一个合格的预期结果，应该能让执行人员直接判断：
实际结果是否符合预期。
问题三：前置条件缺失
这条用例没有说明：
商品 A、商品 B 是否为实物商品
优惠券 A、B、C 分别是什么类型
优惠券是否满足使用门槛
是否存在新人券与品类券互斥关系
当前账号是否具备领取和使用这些券的条件
这些信息不完整，就会导致同一条用例在不同执行人员手里跑出不同结果。
问题四：金额计算过程缺失
优惠类测试最怕只写最终金额，不写计算过程。
因为金额是否正确，不仅取决于最终值，还取决于扣减顺序。
比如：
先满减，再用券
先用券，再满减
按订单维度扣减
按商品维度分摊
优惠是否按比例分摊到每个商品
这些都会影响最终金额。
所以，金额类测试用例必须写清楚计算链路，而不是只写一个结果。
- 修复后，一条合格用例应该怎么写
可以将 TC045 改成两类用例。
用例 A：验证最多只能使用 2 张优惠券
用例 B：验证满减后再叠加 2 张品类券
这样改完以后，用例的目标、前置条件、步骤、预期结果都更加清晰，执行人员也不需要猜测业务逻辑。
这也是 AI 用例审核 Skill 最适合发挥作用的地方：
它不只是告诉你这条用例不合格，而是指出不合格的具体原因，并给出可操作的修改方向。
- 批量审核的价值：发现系统性遗漏
人工评审有一个天然问题：
容易盯着单条用例看，却不容易发现一批用例里的共性缺陷。
比如在 618 活动 PRD 中，有一条规则非常关键：
本活动仅限实物商品参与，虚拟商品不参与满减和优惠券活动。
但在 45 条测试用例中，很多用例都只写了“商品 A”“商品 B”，没有明确标注商品类型。
单看某一条，也许觉得问题不大。
但如果 12 条、20 条用例都这样写，就会变成一个系统性风险：
执行人员可能拿虚拟商品执行满减用例
自动化脚本可能选错商品池
回归测试时结果不稳定
评审时需要批量返工
后续沉淀到用例库后，长期影响团队质量
AI 用例审核 Skill 的优势，就在于可以批量扫描，识别这种重复出现的问题模式。
它不是只告诉你“某条用例有问题”，而是可以进一步发现：
这类问题在整批用例中出现了多少次。
这对测试负责人非常有价值。
因为团队真正需要改进的，往往不是某一条用例，而是一类写作习惯。
- 一批用例的真实质量画像，应该怎么看
假设某批 618 活动用例审核结果如下：
只看表面数据，很容易得出结论：
这批用例质量不错，基本可以进入评审。
但测试负责人更应该关注隐藏问题。
第一，最低分用例是否存在严重逻辑矛盾
如果最低分用例只是格式不规范，问题不大。
但如果它是步骤与 PRD 规则直接冲突，就必须优先修正。因为这种用例一旦进入执行阶段，会直接影响测试结果可信度。
第二，是否存在批量重复问题
比如 12 条用例都没有标注商品类型，这说明不是某个测试人员漏写，而是团队在用例模板中没有强制要求这个字段。
这类问题应该通过模板解决，而不是逐条提醒。
第三，核心业务链路是否有计算过程
尤其是电商、支付、金融、计费、库存类业务。
只写“最终金额正确”“库存扣减成功”是不够的。用例必须把计算公式、扣减顺序、状态变化写清楚。
否则评审时一定会被追问。
所以，AI 审核报告不能只看平均分。
真正要看的，是低分用例、重复问题和高风险链路。
- 它适合哪些测试场景
测试用例审核 Skill 并不只适合电商大促场景。
只要业务中存在规则、状态、边界、异常和流程联动，它都可以发挥价值。
尤其适合这几类团队：
用例数量多，人工评审成本高
多人协作，评审标准不统一
新人较多，用例质量波动大
经常做复杂活动、支付、权限、状态流转测试
希望沉淀团队级用例模板和评审规范
- 它的边界在哪里
作为测试开发从业者，我们不能神化任何 AI 工具。
测试用例审核 Skill 很有价值，但它也有明确边界。
- 它不能判断 PRD 本身是否合理
它能检查用例是否符合 PRD，但不能替代产品和业务专家判断 PRD 规则是否正确。
比如 PRD 写：
同一订单最多使用 2 张优惠券。
Skill 会检查你的用例是否遵守这条规则。
但它不会主动判断：
为什么是 2 张？ 是否应该按活动类型区分？ 是否和会员权益冲突？ 是否会影响财务结算？
这些问题仍然需要产品、测试负责人和业务专家共同判断。
- 它不能替代真实执行
用例审核解决的是“用例写得是否清楚、完整、可执行”。
但它不能证明系统真实行为一定正确。
一条用例文档写得再规范，也需要通过手工测试、自动化测试、接口测试、数据校验、日志分析等方式去验证系统实现。
所以，它不是测试执行工具，而是用例质量检查工具。
- 它依赖 PRD 的质量
如果 PRD 本身写得非常模糊，比如：
优惠计算逻辑与财务系统保持一致。
这种描述对人和 AI 都不友好。
Skill 可以提醒“规则不清晰”，但无法凭空推导出准确的业务规则。
PRD 的清晰度，仍然决定了测试用例审核的上限。
- 复杂业务判断仍需要人工经验
对于多系统联动、异步消息、复杂状态机、风控策略、资损风险等场景，AI 可以帮助识别结构性问题，但最终是否合理，仍需要测试负责人结合业务经验判断。
因此更准确的定位是：
Skill 做初筛和标准化检查，测试专家做业务判断和风险兜底。
- 测试团队如何落地这套审核流程
如果团队想真正用起来，不建议只是临时让 AI 帮忙“看一下用例”。
更推荐把它变成一个标准流程。
第一步：统一用例模板
至少包含这些字段：
用例编号
用例标题
所属模块
前置条件
测试数据
操作步骤
预期结果
关联 PRD 条款
优先级
备注说明
尤其是复杂业务，一定要有“关联 PRD 条款”字段。
否则用例和需求之间无法追溯，后续评审很难判断覆盖是否完整。
第二步：设置评分标准
建议采用 100 分制：
不同团队可以按业务要求调整及格线。
比如金融、支付、风控类业务，建议把及格线提高到 75 分以上。
第三步：评审前先自检
在正式评审前，由测试人员先上传用例和 PRD，让 Skill 输出问题清单。
重点看三类问题：
低分用例
批量重复问题
PRD 覆盖缺口
这样正式评审时，会议重点就不会停留在格式问题上，而是可以聚焦业务风险。
第四步：沉淀团队问题库
每次审核后，把高频问题沉淀下来。
这样做一段时间后，团队用例质量会稳定提升。
- 从测试开发角度看，它真正改变了什么
测试用例审核 Skill 的意义，不只是节省时间。
它更大的价值在于，让测试用例评审从“经验驱动”逐步走向“标准驱动”。
过去评审用例，很多时候靠测试负责人经验：
“这里不完整。” “这个场景少了。” “这个预期不清楚。” “这个边界没覆盖。”
现在可以变成：
“这条用例逻辑完整性 12/25，原因是步骤与 PRD 规则冲突。” “前置条件 8/15，原因是缺少商品类型、账号权限和优惠券门槛。” “边界异常覆盖 6/15，原因是只覆盖正常路径，缺少临界值和超限场景。”
这就是工程化的变化。
它让评审结论更稳定，也让新人更容易知道自己到底差在哪里。
对测试开发来说，AI 用例审核 Skill 不是一个“玩具能力”，而是可以嵌入测试流程的工程能力：
这个流程的重点不是“用 AI 替代人”，而是把评审标准前置，让问题在正式评审前先暴露。
- 一个推荐的使用流程
可以按照下面这套流程使用。
Step 1：准备输入材料
包括：
测试用例文件：Excel、Markdown、飞书表格导出文件等
PRD 文档：Word、PDF、Markdown、截图均可
业务规则补充说明：如果 PRD 中有口头约定，建议单独补充
Step 2：设置审核要求
比如：
按 100 分制评分
60 分为最低及格线
输出每条用例的问题原因
标注高风险用例
汇总批量重复问题
给出修改建议
输出 Markdown 表格，便于复制到评审文档
Step 3：先看整体质量
关注：
平均分
不及格用例数量
低分用例集中在哪些模块
哪些问题重复出现
是否存在 PRD 规则遗漏
Step 4：再处理重点用例
优先修复：
逻辑矛盾用例
金额计算用例
权限控制用例
状态流转用例
支付、库存、订单等高风险链路用例
Step 5：最后沉淀模板
把审核中反复出现的问题，反向固化到团队用例模板中。
这一步很关键。
否则每次只是让 AI 帮忙改几条用例，团队能力不会沉淀。
真正成熟的做法，是让 AI 审核结果反哺团队规范。
- 一个可复用的测试用例审核 Prompt
如果团队暂时没有现成 Skill，也可以先用下面这段 Prompt 做基础版本。
你是一名资深测试开发专家，请根据我提供的 PRD 和测试用例，对测试用例进行专业审核。
请按照以下 5 个维度评分，总分 100 分：
- 逻辑完整性，25 分
- 检查步骤是否完整、是否存在跳步、是否与业务规则矛盾、是否可执行。
- 预期结果明确性，20 分
- 检查每一步是否有明确、可验证的预期结果。
- 金额、状态、提示、数据变化是否描述清楚。
- 前置条件完备性，15 分
- 检查环境、账号、权限、测试数据、商品类型、配置开关等是否完整。
- PRD 覆盖度，25 分
- 检查是否覆盖 PRD 中的核心功能点、限制条件、联动规则、互斥规则。
- 边界异常覆盖，15 分
- 检查是否覆盖边界值、异常流、并发、超时、错误处理等场景。
请输出以下内容：
- 总体审核结论
- 每条用例评分表
- 每条用例扣分原因
- 每条用例修改建议
- 低于 60 分的高风险用例清单
- 批量重复问题汇总
- PRD 覆盖缺口分析
- 建议补充的测试场景
输出格式请使用 Markdown 表格。
评价要专业、具体、可执行，不要只给笼统建议。
这个 Prompt 只是基础版。
如果要在团队里长期使用，建议进一步结合业务类型做定制。
比如电商、支付、权限、订单、活动、风控、数据同步等场景，都应该有自己的审核规则。
如果要做成真正的 Skill，还需要补充什么？
Prompt 可以解决基础审核，但如果想做成团队级 Skill，建议继续补充 4 类能力。业务场景规则库
不同业务的审核重点不一样。
电商看优惠、库存、支付； 权限看角色、数据范围、审批流； 金融看金额、状态、风控、对账； 订单看状态机、逆向流程、异常恢复。
所以真正可复用的 Skill，应该内置不同业务场景的审核规则。
- 用例模板适配能力
团队里的用例格式可能不一样。
有的用 Excel，有的用飞书表格，有的用 Markdown，有的直接从测试管理平台导出。
Skill 要能识别常见字段，比如：
用例标题
前置条件
操作步骤
预期结果
测试数据
关联需求
优先级
如果字段不完整，也要能提示模板缺陷。
- PRD 规则提取能力
只审核用例是不够的。
更关键的是先从 PRD 中提取规则，再对照用例检查覆盖情况。
例如：
PRD 规则：
同一订单最多使用 2 张优惠券。
新人券与品类券不可叠加。
虚拟商品不参与满减活动。
支付超时 30 分钟自动关闭。
然后再判断测试用例是否覆盖这些规则。
这一步决定了审核深度。
- 报告导出能力
团队落地时，最好能输出固定格式报告：
总体质量概览
高风险用例清单
每条用例评分
PRD 覆盖矩阵
批量重复问题
修改建议
适合补充的用例场景
这样才能真正进入评审流程，而不是停留在聊天窗口里。
- 写在最后：AI 不是替你评审，而是帮你建立标准
测试用例评审，过去很依赖人的经验。
经验丰富的人能看出问题，经验不足的人只能照着模板写。
团队一旦人员变化，用例质量就容易波动。
AI 测试用例审核 Skill 真正有价值的地方，不是让 AI 替代测试负责人，而是把测试负责人脑子里的评审经验，变成一套稳定、可复用、可批量执行的标准。
它适合做三件事：
第一，评审前自查。 先把低级问题、格式问题、明显遗漏提前修掉。
第二，批量扫描历史用例。 快速发现历史用例库中的共性缺陷。
第三，训练新人用例设计能力。 通过评分和扣分原因，让新人知道什么才是高质量用例。
但它不能做所有事。
PRD 是否合理，业务规则是否正确，风险优先级如何判断，复杂系统是否存在真实线上风险，这些仍然需要测试专家来判断。
所以更合理的关系是：
AI 负责标准化检查，测试专家负责业务风险判断。
真正优秀的测试团队，不会只追求“写更多用例”，而是会持续追求：
用例是否覆盖关键业务规则
用例是否具备可执行性
预期结果是否可验证
边界异常是否充分
用例是否能沉淀为团队资产
当测试用例评审从“凭经验拍脑袋”变成“按标准可量化”，测试质量才会真正进入工程化阶段。
而这，才是测试开发在 AI 时代最应该补齐的能力。
