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