熬了两天，交付了 100 多条测试用例。
产品翻了两页：「步骤呢？」
开发凑过来看了一眼：「第三步跳到第五步，中间缺了一步。」
测试组长放下手里的文档：「边界值呢？超卖场景呢？这个用例的预期结果，怎么只有一个数字？」
这不是个例。测试用例评审中，追问的深度往往取决于在场人的经验值——不是用例本身有多差，而是缺少一套系统性的检查标准。
今天介绍的这个 Skill，提供的就是这样一套标准：5 维度、100 分制、60 分及格线，用数据替代主观判断。
1
评审维度：5 个维度，每个维度有明确的打分规则
这不是一套评分模板，而是一套有输出标准的评审体系。
输入方式： Excel 文件（.xlsx）、Markdown 文档、PRD 截图（支持直接读图）
输出方式： 每条用例逐条评分 + 扣分原因 + 改进建议，Markdown 表格一键导出
2
3 个实战场景：它能审出什么？
很多人关心的是：这个工具在复杂业务场景下是否有效？
以下三个场景均来自真实审核案例。
场景一：PRD 写了 10 条联动规则，用例漏了一半
背景： 618 大促 PRD 规定了这样一段复杂联动规则：
满减（满100减10）与品类优惠券叠加，先满减、再品类券；同一订单最多用 2 张券；超卖容限 ±3%；支付超时 30 分钟自动关闭，延长支付最多 1 次/15 分钟；新人专享券与品类券互斥，不可叠加。
测试工程师编写了 45 条用例，覆盖范围看似完整。
Skill 审核后，发现了以下问题：
整体数据：45 条用例，通过率 97.8%，平均分 78.2——但 Skill 识别出了 4 类评审会上会被追问的问题。
场景二：TC045 评分 54 分，典型问题在哪里？
原始用例：
TC045：优惠券叠加使用3张验证
- 步骤3：商品A价格100元，商品B价格100元……
- 步骤4：叠加使用优惠券A（满200减30）、优惠券B（满200减30）、优惠券C（满200减30）
- 预期结果：商品A剩余70元
Skill 逐维度评审：
逻辑完整性（12/25）： 步骤3中商品A为100元，商品B为100元，合计200元，恰好满足满减门槛。但步骤4同时叠加了3张优惠券——而 PRD 明确规定同一订单最多使用2张。步骤与规则存在直接矛盾。
预期结果明确性（10/20）： 预期结果描述为「商品A剩余70元」。但「剩余70元」的定义不明确：是商品原价？是待支付金额？是100-30=70？还是100-30-30=40？语义模糊，执行人员无法判断对错。
前置条件完备性（8/15）： 用例未说明商品A、B、C是否为实物商品（PRD 规定虚拟商品不参与活动），未说明各优惠券是否为同类型，也未说明商品是否均满足各优惠券的使用门槛。前置条件与测试步骤的信息不对等。
综合评分：54 分，不及格。
对应的改进方案：
- 步骤修正：
「商品A（实物）100元，商品B（实物）100元，商品C（实物）200元」 - 计算过程补充：
「步骤1：满减后 400-80=320；步骤2：叠加品类券A（满200减30）和品类券B（满200减30），第3张优惠券C超出使用限制，系统自动取消」 - 预期结果明确：
「商品A最终实付=100-40-30=30元；商品B最终实付=100-40-30=30元；商品C最终实付=200-40-30=130元；订单合计=30+30+130=190元」
修复后评分预期：80 分以上。
场景三：12 条用例犯了同一个错误——系统性遗漏
这是审核中发现的典型问题模式：错误本身不复杂，但重复次数多，影响范围广。
618 活动 PRD 明确规定：「本活动仅限实物商品参与，虚拟商品（话费充值、游戏点卡等）不参与满减及优惠券。」
然而，TC004 至 TC045 中，步骤描述一律为「商品A」「商品B」——未有一条用例明确标注商品类型为实物或虚拟。
这带来的风险是：测试执行人员若未自行核对 PRD，很可能在虚拟商品上执行用例，导致测试结果与 PRD 预期完全不符，整批用例需要返工。
Skill 识别并批量标注：步骤中未明确商品类型，建议统一为「商品A（实物）价格100元」或「商品C（虚拟）价格50元」。
12 条用例的系统性遗漏，一次性输出。
3
完整审核结果：45 条用例，真实质量画像
对一批 618 大促真实测试用例进行完整审核，结果如下：
表面数据：97.8% 通过率，78.2 平均分，结论是「质量尚可」。
深入分析：问题被及格线掩盖了。
问题一：TC045 逻辑矛盾，执行可行性存疑
步骤与 PRD 规则直接冲突，预期结果语义模糊。该用例若不修正，测试执行人员无法正常执行。
问题二：12 条用例系统性遗漏商品类型
PRD 明确规定了活动适用范围，但用例中未体现。每次执行都存在误用虚拟商品的风险，错误会在评审或验收阶段暴露。
问题三：优惠计算过程普遍缺失
TC020 预期结果仅写「最终实付160元」，未说明 200-30-10=160 的计算过程。执行人员无法独立判断 160 元是否正确。
值得肯定的地方
- 模块划分合理：
6 大模块（活动时间/适用范围/满减规则/优惠券/库存/支付）覆盖了活动核心功能点 - 边界值意识较强：
满减三档的刚好门槛（100/200/500）、超出门槛（101/201/501）、不足门槛（99/199）均已覆盖 - 互斥场景完整：
叠加与互斥场景的覆盖基本到位 - 超卖框架建立：
TC026/TC027 已对 ±3% 超卖容限建立了基本覆盖
整体评价：底子扎实，细节有待完善——而这些细节，往往是评审会上被追问的高频区。
4
客观评估：这个 Skill 的能力边界在哪里？
任何工具都有其适用边界，客观说清楚，既是专业，也是信任。
它能做到的事
1. 把主观评审变成量化指标
传统评审中，「这条用例写得不清楚」这句话，不同人有不同的理解。Skill 给出的是：「逻辑完整性 12/25，扣分原因：步骤与 PRD 规则矛盾」。有数字、有原因、有改进建议，评审结论可追溯、可复现。
2. 批量发现系统性遗漏
人工评审时，容易逐条检查，难以发现「12 条用例犯了同一个错误」这类模式性问题。Skill 对全量用例进行扫描，能够识别出高重复性的共性缺陷，一次审核，批量暴露同类问题。
3. PRD 截图直接解析
PRD 通常以截图或 PDF 形式存在，人工阅读后需要自行提炼规则再对照用例。Skill 可以直接读取 PRD 截图，提取规则后逐条对照用例覆盖情况，减少人工理解 PRD 和对照用例之间的信息损耗。
4. 多格式批量处理
支持 Excel（.xlsx）、Markdown（.md）和 PRD 截图，批量上传后统一输出报告。对于大型用例库的批量初筛，无需逐条手动检查。
它做不到的事
1. 无法判断业务规则本身是否正确
Skill 审核的是：用例描述是否与 PRD 一致、用例逻辑是否自洽、用例步骤是否清晰。它不会判断 PRD 本身的规则是否合理——PRD 有 bug，Skill 不会发现。
例如：PRD 规定「同一订单最多使用 2 张优惠券」，Skill 会检查你的用例是否遵守这个规则，但它不会质疑「为什么是 2 张而不是 3 张」。
2. 无法验证执行结果的正确性
Skill 审核的是用例文档本身，不是用例执行后的实际结果。如果一条用例写得很规范，但测试人员执行时操作错误，Skill 不会知道。
换句话说：它保证的是「用例写得对不对」，不是「测试做得好不好」。
3. 复杂嵌套场景的判断力有限
对于涉及多系统联动、外部依赖或状态机复杂度极高的场景，Skill 能够识别出前置条件缺失、边界覆盖不足等结构性问题，但对于「这个场景在真实环境中会不会出现」的业务判断，仍需人工经验介入。
4. 输出质量依赖 PRD 的清晰程度
如果 PRD 本身描述模糊（例如「优惠计算逻辑与财务系统保持一致」这类表述），Skill 对应的评审深度也会受限。PRD 质量是用例质量的天花板，这条规律对 AI 同样适用。
结论
两者不是替代关系，而是互补关系。 Skill 负责把「格式不对、逻辑不通、覆盖不全」的问题筛出来，人工负责判断「这个业务逻辑本身对不对、PRD 的规则合不合理」。
5
适用场景
核心逻辑不变：无论业务复杂度如何，测试用例的本质都是对「输入→规则→输出→异常」的完整描述。Skill 审核的不是业务本身，而是——这些是否都说清楚了。
6
使用方式
Step 1： 在 WorkBuddy 中找到「testcase-reviewer」Skill（触发词：审核测试用例 / 给用例打分 / review 测试用例）
Step 2： 上传测试用例文件（.xlsx / .md）和 PRD 截图，支持多文件同时上传
Step 3： 设置及格线（默认 60 分，可按团队要求自定义），等待 1-3 分钟，获取完整审核报告
共审核测试用例45条，通过率97.8%，平均分78.2分，整体质量达到可执行标准。
从覆盖面来看，6大核心模块（活动时间、适用范围、满减规则、优惠券、库存扣减、支付时效）均已建立完整用例框架，边界值意识较强，满减三档临界点、超卖容限、支付超时节点等关键场景覆盖基本到位，互斥规则几乎无遗漏，整体框架质量扎实。
需要关注三类问题：TC045存在步骤逻辑矛盾（选了违反PRD的叠加方案）、12条以上用例未标注商品类型（实物/虚拟）、多条金额计算用例缺少扣减说明。45条用例3分钟审核完毕，精准锁定全部问题，人工复查同等工作量需要1小时以上。
总结
测试用例评审的痛点，不在于「有没有写」，而在于「评审标准是否一致」。
当评审结论从「我觉得这里有问题」变成「这条用例 54 分，问题在这里」，讨论的维度就变了。
