SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场test-cases

test-cases

测试与质量

查看项目

更新于 10-15 12:38

技能介绍

用途

test-cases 依据 keel 需求设计可追溯的 UT/IT/E2E 用例文档，视角为 QA 分析师——关注边界覆盖与路径完备性，追求可测性而非实现细节。它基于需求文档设计测试用例，建立验收标准与测试用例的追溯关系。

主要能力

  • 从需求文档提取功能点 (F-XXX)、用户故事 (US-XXX)、验收标准 (AC-XXX)，为每个验收标准选择测试类型并设计用例。
  • 测试类型包括：单元测试 (UT-XXX) 验证内部逻辑，集成测试 (IT-XXX) 验证组件协作，E2E 测试 (E2E-XXX) 验证单 US 用户场景，用户旅程 (Journey-XXX) 验证跨 US 业务闭环。
  • 生成追溯矩阵，展示需求与测试、代码的完整关联，是核心产出。
  • 测试用例从需求推导，不是从代码推导；每个验收标准至少有一个测试用例覆盖；测试类型根据验收标准的性质选择。

使用方式

  • 最常见用法：/test-cases（自动检测初始/增量）。
  • 标准模式：/test-cases（逐步确认）。
  • 规范升级回扫：/test-cases --realign[=scope]，详见 references/realign.md；推荐 /pipeline realign。
  • 快速档（ceremony: fast）：跳过测试类型选择的逐步确认，自动根据 AC 性质选择最佳测试类型，仅保留最终写入前的 1 次确认。档位由编排层下传的 ceremony 决定，不得自行解读用户原话来判档。

前置条件

  • 需求文档：docs/devdocs/01-requirements.md
  • 系统设计文档：docs/devdocs/02-system-design.md（设计 UT/IT 时需要了解接口签名和模块划分）
  • 如不存在，建议先运行前置阶段。

工作流程

读取需求文档 → 提取功能点、用户故事、验收标准 → 为每个验收标准选择测试类型 → 按功能点分批设计测试用例 → 汇总用户旅程 → 生成追溯矩阵（含 Journey）→ 用户确认。

按功能点 (F-XXX) 分批设计，每批完成一个功能点的全部测试用例（UT + IT + E2E）。首个功能点的用例作为质量锚点，每个新功能点开始前回顾首批用例的详细程度。

输出文件

主文件：docs/devdocs/03-test-cases.md。默认拆分为主文件 + 子文件结构：

docs/devdocs/
├── 03-test-cases.md           # 大纲：策略、覆盖率、追溯矩阵、用例索引
├── 03-test-unit.md            # UT 详情
├── 03-test-integration.md     # IT 详情
└── 03-test-e2e.md             # E2E 详情

小型项目例外：测试用例 ≤ 15 个且文档 ≤ 200 行时，可合并为单一文件 03-test-cases.md。

适用场景

  • 用户已完成需求文档，要求设计测试用例。
  • 用户需要测试覆盖策略。
  • 新功能测试（/feature 调用）、Bug 回归测试（/bugfix 调用）、改进测试（/insights 调用）。
  • 后续可配合 /dev-tasks 进行开发任务拆分，完成后建议运行 /dev-tasks；文档变更较大时建议运行 /agent-memory 同步记忆文件。

限制与约束

  • 阶段边界约束（最高优先级）：文档阶段不得产出实现代码或测试代码文件（恢复方式：使用 /dev-workflow 执行编码）；生成/更新文档未在顶部写入 generated_by / spec_version / generated_at 三字段 YAML frontmatter 时禁止继续。
  • 追溯约束：每个验收标准至少有 1 个测试用例覆盖；必须生成追溯矩阵。
  • 用例设计约束：每个用例必须有明确的预期结果；优先级必须标注 (P0/P1/P2)；后批次用例详细程度不低于首批次。
  • 覆盖约束：P0 验收标准必须 100% 测试覆盖；单元测试覆盖率目标按 /testing-guide 核心阈值表执行。
  • 行/分支覆盖率数值以 /testing-guide 核心阈值表为权威，本节不镜像。
  • 断言质量判据（测试命名 / 禁弱断言 / Mock 边界）以 /testing-guide 为权威。
  • 不适合跑测试（用 /test-run）与开发指导（用 /dev-workflow）。
  • 语言规则：支持中英文提问，统一中文回复，使用中文生成文档。

协作

需求输入 /requirements、新功能测试 /feature、Bug 回归测试 /bugfix、改进测试 /insights、追溯更新 /sync、测试质量 /testing-guide、任务拆分 /dev-tasks。

状态说明

  • ✅ 完整覆盖：有测试用例 + 变更来源 + 测试通过
  • ⏳ 进行中：有测试用例，代码/测试部分完成
  • ⚠️ 部分覆盖：有变更来源但缺测试，或有测试但无变更来源
  • ❌ 未覆盖：无测试用例或无代码实现

变更来源为变更事件锚点，不是当前实现定位符；hash 失效时（squash / rebase / 上游 force-push）警告并回到当前代码事实重建。