Menu
用例评审。由 qalore 调用，不独立触发。 对测试用例执行多层质量检查，输出问题报告。不产生持久化产物，报告仅在对话中呈现。 修复路径由 qa-functional-test 承接。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | qa-case-review |
| description | 用例评审。由 qalore 调用，不独立触发。 对测试用例执行多层质量检查，输出问题报告。不产生持久化产物，报告仅在对话中呈现。 修复路径由 qa-functional-test 承接。 |
| practices_min_version | 2026-06-12-v11 |
| 变量 | 来源 | 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「用例格式」「用例质量标准」「断言规则」章节。
覆盖层：该测的场景是否都测了？
归因层：发现问题时，追溯根源在哪一层？
{practices_path}/common/handbook.md「评审规范」章节的严重级别定义。评审基准优先级：
联动模式（同会话）：context 中的【测试意图已提炼】交接块 → 三层完整比对
独立评审（跨会话）：story 中的业务逻辑.md + 代码逻辑.md → 有什么用什么
临时模式（粘贴内容）：无基准 → 只做结构层和覆盖层（L2a 四维度）
独立评审模式下两个文件都存在时的合并规则：
⚠️（文本-代码冲突）的断言：在评审报告中列出冲突并标注「需先与 PM/开发确认后再判断覆盖」，跳过该断言的覆盖检查，不阻断后续评审⚠️(代码)（多源代码冲突）的断言：在评审报告中标注「多源代码冲突未解决，需先在 qa-understand 确认以哪个仓库逻辑为准」，跳过该断言的覆盖检查，不阻断后续评审按需加载规范遵循 {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「评审记录文件」章节。
用户拒绝 → 不写入任何文件，流程结束。
测试用例执行。读取 TC 文件中的断言规则，通过 Playwright MCP + CDP Network MCP 在浏览器中逐条执行，产出执行报告。不修改 TC 文件。
功能测试用例设计与产物输出。由 qalore 调用，不独立触发。 以断言集合为输入，设计覆盖正向/边界/异常/上下游的测试用例，产出 story 和脑图产物。 业务逻辑由 qa-understand 提炼后传入，或已存在于 story 文件中。
测试意图理解与提炼。将任意信息源转化为可测试的理解，写入 story，供 qa-functional-test 和 qa-case-review 使用。 调度层设计：按需加载对应适配器，不预加载所有内容。 内置适配器：文本（PRD/需求/口述）、代码（文件/目录/片段，支持 N 个代码仓库）。 多源时顺序执行各适配器（文本适配器完成后依次执行各代码适配器），完成后加载综合层产出统一交接块。 由 qalore 调用，不独立触发。
全栈测试工程师网关。满足以下任一条件时使用： 1. 收到测试相关任务（生成用例、需求分析、覆盖率检查、用例评审等） 2. 涉及读写 story 的操作——story 是本 skill 管理的结构化测试知识库（路径存于 ~/.claude/qalore-config.json），含业务逻辑/测试用例/代码逻辑/变更日志四类文件， 按项目-模块两级目录组织。用户说「更新story/沉淀/写入story」时必须调用本 skill， 不得自行在其他路径创建文件代替。 已建设能力：测试意图理解、功能测试、用例评审。未建设（Phase 2）：自动化、性能、安全、混沌。 执行前必须先读 ~/.claude/qalore-config.json 获取 practices 和 story 路径， 验证路径有效后继续。路径无效时立即停止，不得使用通用知识代替。
Token 使用统计能力。由 Claude Code Stop Hook 自动触发，不由 qalore 主动调用。 从 transcript JSONL 累加本轮所有 API call 的 usage 数据，以固定格式打印到对话。 仅统计本轮；通过 last_assistant_message 信号词过滤，非 qalore 会话静默退出；无需额外 API 调用。