导读测试用例写完以后最怕的不是数量不够而是评审会上被连续追问“这个前置条件是什么” “这里为什么直接跳到下一步” “预期结果怎么算出来的” “边界值有没有覆盖” “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 实现基础版。核心不在于它叫什么名字而在于它把“测试用例评审经验”变成了可复用、可执行、可量化的审核标准。目录为什么测试用例评审总是容易被追问AI 用例审核 Skill 的核心价值是什么5 个维度构建测试用例质量评分模型真实场景618 大促用例到底能审出什么典型问题拆解一条 54 分用例为什么不合格批量审核的价值发现系统性遗漏它适合哪些测试场景它的边界在哪里测试团队如何落地这套审核流程一个可复用的测试用例审核 Prompt写在最后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 分。因为这些场景一旦用例描述不清楚后续带来的问题不是“评审不好看”而是可能直接影响测试结论。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 张验证 步骤商品 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 分别是什么类型优惠券是否满足使用门槛是否存在新人券与品类券互斥关系当前账号是否具备领取和使用这些券的条件这些信息不完整就会导致同一条用例在不同执行人员手里跑出不同结果。问题四金额计算过程缺失优惠类测试最怕只写最终金额不写计算过程。因为金额是否正确不仅取决于最终值还取决于扣减顺序。比如先满减再用券先用券再满减按订单维度扣减按商品维度分摊优惠是否按比例分摊到每个商品这些都会影响最终金额。所以金额类测试用例必须写清楚计算链路而不是只写一个结果。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-80320 元叠加 2 张品类券后金额为 320-30-30260 元订单最终实付 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、T1这样做一段时间后团队用例质量会稳定提升。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 时代最应该补齐的能力。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。