qa-case-review

name	qa-case-review
description	用例评审。由 qalore 调用，不独立触发。 对测试用例执行多层质量检查，输出问题报告。不产生持久化产物，报告仅在对话中呈现。 修复路径由 qa-functional-test 承接。
practices_min_version	2026-06-12-v11

qa-case-review：用例评审

前置说明

变量	来源	fallback
{practices_path}	qalore 注入	自动恢复：读 ~/.claude/qalore-config.json 重建 context
{story_path}	qalore 注入	自动恢复：读 ~/.claude/qalore-config.json 重建 context
{确认项目名}	qalore 注入	临时模式下不强制要求；story 模式下暂停向用户确认

---

核心思考哲学：溯源式质量判断

评审的目标不是找格式问题，而是回答一个问题：这批用例拿去执行，会漏掉什么、卡在哪里？

从三个层次思考：

结构层：用例本身是否可执行？字段是否完整？每个触发性步骤是否有对应预期？每个 → 预期： 是否有对应 → 断言：？ 遵循 {practices_path}/tech-stacks/functional/cases.md「用例格式」「用例质量标准」「断言规则」章节。

覆盖层：该测的场景是否都测了？

• 每个功能点是否覆盖了正向/边界/异常/上下游四个维度
• 有断言基准时（业务逻辑.md / 代码逻辑.md / 交接块），逐条比对：每条断言是否有对应 TC？

归因层：发现问题时，追溯根源在哪一层？

• 用例写法问题 → qa-functional-test 执行层问题
• 断言没被设计进来 → qa-understand 理解层遗漏 遵循 {practices_path}/common/handbook.md「评审规范」章节的严重级别定义。

评审基准优先级：

联动模式（同会话）：context 中的【测试意图已提炼】交接块 → 三层完整比对
独立评审（跨会话）：story 中的业务逻辑.md + 代码逻辑.md → 有什么用什么
临时模式（粘贴内容）：无基准 → 只做结构层和覆盖层（L2a 四维度）

独立评审模式下两个文件都存在时的合并规则：

• 以业务逻辑.md 的断言集合为主基准，逐条核查 TC 覆盖
• 代码逻辑.md 中标注了「代码独立」的断言作为补充基准，也逐条核查 TC 覆盖
• 遇到业务逻辑.md 中标注 ⚠️（文本-代码冲突）的断言：在评审报告中列出冲突并标注「需先与 PM/开发确认后再判断覆盖」，跳过该断言的覆盖检查，不阻断后续评审
• 遇到业务逻辑.md 中标注 ⚠️(代码)（多源代码冲突）的断言：在评审报告中标注「多源代码冲突未解决，需先在 qa-understand 确认以哪个仓库逻辑为准」，跳过该断言的覆盖检查，不阻断后续评审
• 不重新执行 synthesis 合并逻辑，直接使用 story 中已有的置信度标注

---

practices 文件

按需加载规范遵循 {practices_path}/common/handbook.md「context 标记规范」章节。

本 capability 使用的 practices 文件：

• tech-stacks/functional/assertions.md（评审断言覆盖时）
• tech-stacks/functional/cases.md（评审用例格式、质量标准、断言规则时）
• tech-stacks/functional/execution.md（评审断言类型合法性时）

handbook.md 已由网关预加载，直接使用；评审严重级别和结论判定规则见 handbook.md「评审规范」章节。

---

执行前确认

遵循 handbook.md「执行前确认规范」章节。本 capability 的计划摘要格式：

【用例评审执行计划】
项目：{确认项目名}
模块：{模块名}
输入模式：{story 模式 / 临时模式 / 联动模式}
评审用例数：{n} 条
基准：{交接块 / 业务逻辑.md + 代码逻辑.md / 无}
规范版本：{practices version}

---

产出格式

【用例评审报告】
项目：{确认项目名}  模块：{模块名}  评审时间：{YYYY-MM-DD}
评审用例数：{n} 条  规范版本：{practices version}

■ 阻断问题（{n} 条，必须修复）
  [{TC-ID 或 覆盖项}] {问题描述} → 根源：{执行层 / 理解层}

■ 需改进（{n} 条）
  [{TC-ID 或 覆盖项}] {问题描述}

■ 建议优化（{n} 条）
  [{TC-ID 或 覆盖项}] {建议内容}

总结：{n} 条阻断 / {m} 条需改进 / {k} 条建议
结论：{通过 / 需修复后通过 / 不通过}

结论判定规则遵循 {practices_path}/common/handbook.md「评审规范 · 结论判定规则」。

有阻断问题时：

如需修复：执行「修复 {模块名} 以下用例的阻断问题：{TC-ID-001, ...}」

评审是过程验证，不写入 story，不更新 index.json。

评审记录（可选持久化，仅 story 模式和联动模式可用）：

临时模式下无项目路径，跳过此步骤。

story 模式或联动模式时，报告输出完成后询问用户：

是否将本次评审结果写入评审记录？（方便后续跟踪质量趋势）
路径：{story_path}/{项目}/{模块}/{模块名}-功能-评审记录.md

用户同意 → 追加写入，格式见 {practices_path}/tech-stacks/functional/story-formats.md「评审记录文件」章节。

用户拒绝 → 不写入任何文件，流程结束。