test-case-writing

# 测试用例编写 从需求模型（或原始输入源）与代码，产出**人看得懂、能执行**的手动用例文件（markmap），并抽取机器可读的 Test Case Schema 供下游 Skill 消费。 **落盘产物**：`{项目}/测试用例_markmap.md`（唯一人工维护源）+ `{项目}/测试用例.schema.yaml`（由 markmap 单向抽取，规则见 `../core/schema-extraction.md`）。 ## When to Use - **有代码仓库**，需基于实际实现编写用例（代码优先，首选场景） - 给定需求文档/PRD、技术设计方案、API 文档，需要编写测试用例 - 给定 Bug 报告，需要编写回归测试用例 - 需求变更时，增量更新已有测试用例 ## When NOT to Use - 端到端���试整个需求（理解→策略→用例→执行→报告）→ 用 `qa` skill 编排 - 需要系统性需求建模（目标/范围/规则/异常/依赖/不明确项）→ 用 `requirement-analysis` skill；本 skill 只做轻量输入研读 - "这个功能应该怎么测"（范围/类型/深度/优先级的策略决策）→ 用 `test-strategy` skill - **事后独立审查**存量或他人写的用例 → 用 `test-case-review` skill；本 skill 只做写时自审（阶段四） - 编写自动化测试代码 → 用 `automated-e2e-testing`（UI）或 `api-testing`（接口）skill - 代码变更后判断回归范围 → 用 `regression-testing` skill；本 skill 只负责用例文件的增量修改 - 既无代码仓库、也无任何需求/设计文档可参考 → 无从建模与写用例：先走 `exploratory-testing` 探索建立系统理解，或向用户索取输入材料 ## 工作流程 ### 阶段〇：主动索取代码仓库（开工第一件事） 启动测试用例编写前，**主动向用户索要被测项目代码仓库**： - **索取内容**：① 仓库地址（本地路径或远程 URL）；② 被测分支/tag；③ 本次改动范围（PR/MR 链接或 `<base>...<head>` diff 范围，无则默认全量） - **提问模板**： > 🔍 为提升用例准确性，请提供被测项目代码仓库地址与被测分支（若有本次改动的 PR/diff 范围也请给出）。代码将作为功能事实基线，文档作为对照——基于实际实现编写的用例能发现文档与实现的不一致、定位潜在 bug，纯文档模式则无法做到。 - **用户确认无代码 → 降级纯文档模式**：提示「将基于文档编写，准确性受限：无法发现文档与实现的不一致、无法定位潜在 bug、无法核实风险点是否有下游消费」，跳过「代码探索与全面审查」与附录 Cx/Dn 产出。 > 代码模式与文档模式的差异贯穿后续所有阶段，每个阶段都会标注。 ### 阶段一：输入研读 + 范围界定（代码优先） 从输入源中提取所有可测试点，同时识别平台、角色和测试边界。**代码是静态事实的最高来源**（裁决规则见 `../core/evidence.md`）——有代码时以实现为准（测准声明），文档降为对照。 #### 输入源与关注重点 | 输入源 | 重点关注 | |--------|---------| | **代码仓库（最高优先级）** | 实际实现逻辑、数据结构、错误处理、与...