测试用例评审加强版：跨需求、用例与证据追踪高风险缺口
需求要求退款可恢复，风险清单把重复扣款列为 P0，现有用例却只覆盖了成功退款。多份材料同时参与评审时，真正难的不是再找一个问题，而是判断它和哪一份事实冲突、会影响哪条高风险链路。
测试用例评审加强版 Skill 为跨材料评审保留来源、优先级与差异。它把需求、风险和现有用例逐项对照，让发现带上依据与严重度；材料说法不一致时，结论会标记冲突，而不是默认选择看起来更合理的一方。
本文用订单覆盖评审演示这一过程：怎样对齐来源、定位高风险缺口、记录冲突，并让后续修订可以回查到原始材料。
Awesome QA Skills 按语言和测试阶段组织 Skill。项目结构与通用安装方式已经在系列总览说明，这里只讲 测试用例评审加强版。
先看源 Skill
主 Prompt 把工作拆到 相对基础版（test-case-reviewer）的差异、严重级别定义（默认）、质量要求、常见误区（Gotchas）、交付前自检。这些标题只是导航，真正使用时还要回到项目材料。
源目录现有 10 份示例、8 个脚本入口。可以先看 分析结果示例。
评审结果要能定位
结合需求、风险清单和现有用例评审订单覆盖，并记录冲突来源
“内容不够好”没法行动。下面这种写法更有用。
| 严重度 | 位置 | 发现 | 修复建议 |
|---|---|---|---|
| P1 | 输入契约 | 没写事实源优先级 | 增加冲突处理与降级规则 |
| P2 | 输出模板 | 结论没有证据字段 | 增加 source、status、owner |
每条发现都要指向具体位置。没有位置、影响和修法的意见，先别塞进评审报告。
看一处修改前后
以 结合需求、风险清单和现有用例评审订单覆盖，并记录冲突来源 为例，评审前的写法常常只有一句宽泛要求。
修改前：检查输出质量，确保结果准确完整。
修改后：每条结论必须包含 source、status 和 owner。
找不到来源时标记 assumption；没有运行记录时 status 不得写 passed。第二版能测，也能在失败时指出具体字段。围绕 相对基础版（test-case-reviewer）的差异、严重级别定义（默认） 做评审时，我会再查三件事。触发条件有没有误伤相邻任务，输入缺失时是否降级，示例是否偷偷承诺了工具没有执行的事情。
修完以后怎么复核
| 复核对象 | 方法 | 通过信号 |
|---|---|---|
| 触发 | 用相邻请求做正反例 | 该触发的触发，不该触发的保持安静 |
| 契约 | 用缺字段输入试跑 | 输出明确列出缺口 |
| 示例 | 逐条追踪来源 | 没有伪造文件、命令或结果 |
| 改动范围 | 查看 diff | 没顺手改掉无关语气和规则 |
一段可以直接改的调用词
把下面的方括号换成项目内容。材料越具体，Skill 越少猜。
请使用 test-case-reviewer-plus Skill。
任务：结合需求、风险清单和现有用例评审订单覆盖，并记录冲突来源
版本与环境：[需求版本 / 构建号 / 环境]
输入材料：[文件路径或链接]
范围：[本次包含与排除的业务链路]
限制：[账号、数据、时间、合规要求]
逐条给出位置、严重度、影响和修改建议。区分契约缺失、事实错误和个人偏好，修改后附复核方法。
最后列出待确认问题，不要补写材料里没有的事实。第一次调用先看结构和缺口。补齐材料后再生成正式产物，能省掉不少来回修改。
进阶使用，从一次调用走到持续流程
把典型问题变成回归样例。每次修改 测试用例评审加强版 后，同时跑应通过、应拒绝和缺失输入三组检查，评审结论才不会只停在文字层。
三段式 Skill 链
testcase-writer-plus → test-case-reviewer-plus → test-reporting
| 交接 | 传递内容 | 接收方检查 |
|---|---|---|
| 上游到 test-case-reviewer-plus | 来源版本、范围、风险和未决问题 | 测试用例评审加强版 输入是否过期，冲突是否标记 |
| test-case-reviewer-plus 到下游 | 主产物、证据索引、未完成项 | 测试用例评审加强版 产物能否继续执行，Owner 是否明确 |
| 下游回写 test-case-reviewer-plus | 运行结果、缺陷和新风险 | 是否更新 测试用例评审加强版 基线与回归范围 |
不要把三次输出复制进一个大 Prompt。测试用例评审加强版 只接收结构化摘要和可访问的原始材料，能减少上下文浪费，也方便追错。
放进团队流程的门禁
| 门禁 | 建议检查 | 失败动作 |
|---|---|---|
| test-case-reviewer-plus 输入门禁 | 版本、环境、Owner、来源可访问 | 停止 测试用例评审加强版 并列出缺口 |
| test-case-reviewer-plus 产物门禁 | 关键结论带依据和状态 | 退回 测试用例评审加强版 补证据 |
| test-case-reviewer-plus 执行门禁 | 命令、退出码、报告可复现 | 标记基础设施或测试问题 |
| test-case-reviewer-plus 决策门禁 | 残余风险有接受人和日期 | 不进入下一阶段 |
团队可以每个 Sprint 看一次 测试用例评审加强版 的采用率、人工修改率、无依据结论数和失败定位时间。数字的目标由团队自己定，先连续记录几轮再谈阈值。
评审时保留原文和证据
先引用位置，再写问题。区分契约缺失、表达问题和个人偏好。相对基础版（test-case-reviewer）的差异 相关的问题应说明会导致什么行为漂移。修完以后重新检查，不要只把措辞改得更顺。
安装与调用
安装单个 Skill 就够了。项目总览里的安装说明不再在每篇重复。
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/test-case-reviewer-plus -g调用时直接写“请使用 test-case-reviewer-plus Skill”，然后附上真实材料。
两个实际问题
评审发现一定要全部修改吗？
不需要。先看严重度和契约影响。纯偏好问题可以不改，但要记录选择。
文案变短就代表更好吗？
不代表。触发条件、输入、输出和风险边界不能被一起删掉。
什么时候需要人工复核？
涉及范围取舍、风险接受、发布决定或材料冲突时必须由负责人确认。
输出怎么留档？
保存输入版本、Skill 输出、人工修改和最终证据。只留最后一份文档，很难解释结论怎么来的。
先拿一份真实材料跑 测试用例评审加强版，保留输入、输出和复核意见。文章里的片段只能帮你搭起结构，项目证据还得在项目里产生。
参考
- Awesome QA Skills 项目主页:https://github.com/naodeng/awesome-qa-skills
- Awesome QA Skills 系列总览:https://inaodeng.com/zh-cn/blog/ai-testing/introduction_of_awesome_qa_skills/
- 分析结果示例:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/test-case-reviewer-plus/examples/analysis-sample.md
- Awesome QA Skills：测试用例评审增强版 Skill 源文件:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/test-case-reviewer-plus
- 测试用例评审加强版 Skill 详情页:https://inaodeng.com/zh-cn/qaskills/test-case-reviewer-plus/