{"slug":"test-case-writing","title":"test-case-writing","summary":"从需求文档、API 文档、Bug 报告或代码仓库产出可执行的手动测试用例（markmap）时使用——代码优先：索取仓库、先代码审查找潜在 bug 再写用例，并抽取机器可读 Schema。不用于：需求建模（requirement-analysis）、测试策略（test-strategy）、独立审查（test-case-review）、自动化脚本（automated-e2e-testing / api-testing）。","platform":"Claude","tags":[],"authorName":"LLM Mart","authorSlug":"llm-mart","score":0,"source":"github","price":null,"verified":false,"createdAt":"2026-09-02T16:13:16.678058Z","repo":{"url":"https://github.com/fishzjp/qa-skills","stars":33,"forks":6,"license":"MIT","updatedAt":"2026-09-08T06:46:25Z"},"bodyHtml":"<hr>\n<h2>name: test-case-writing\nslug: test-case-writing\ndisplayName: 测试用例设计\nversion: 0.7.0\ndescription: 从需求文档、API 文档、Bug 报告或代码仓库产出可执行的手动测试用例（markmap）时使用——代码优先：索取仓库、先代码审查找潜在 bug 再写用例，并抽取机器可读 Schema。不用于：需求建模（requirement-analysis）、测试策略（test-strategy）、独立审查（test-case-review）、自动化脚本（automated-e2e-testing / api-testing）。</h2>\n<h1>测试用例编写</h1>\n<p>从需求模型（或原始输入源）与代码，产出<strong>人看得懂、能执行</strong>的手动用例文件（markmap），并抽取机器可读的 Test Case Schema 供下游 Skill 消费。</p>\n<p><strong>落盘产物</strong>：<code>{项目}/测试用例_markmap.md</code>（唯一人工维护源）+ <code>{项目}/测试用例.schema.yaml</code>（由 markmap 单向抽取，规则见 <code>../core/schema-extraction.md</code>）。</p>\n<h2>When to Use</h2>\n<ul>\n<li><strong>有代码仓库</strong>，需基于实际实现编写用例（代码优先，首选场景）</li>\n<li>给定需求文档/PRD、技术设计方案、API 文档，需要编写测试用例</li>\n<li>给定 Bug 报告，需要编写回归测试用例</li>\n<li>需求变更时，增量更新已有测试用例</li>\n</ul>\n<h2>When NOT to Use</h2>\n<ul>\n<li>端到端测试整个需求（理解→策略→用例→执行→报告）→ 用 <code>qa</code> skill 编排</li>\n<li>需要系统性需求建模（目标/范围/规则/异常/依赖/不明确项）→ 用 <code>requirement-analysis</code> skill；本 skill 只做轻量输入研读</li>\n<li>\"这个功能应该怎么测\"（范围/类型/深度/优先级的策略决策）→ 用 <code>test-strategy</code> skill</li>\n<li><strong>事后独立审查</strong>存量或他人写的用例 → 用 <code>test-case-review</code> skill；本 skill 只做写时自审（阶段四）</li>\n<li>编写自动化测试代码 → 用 <code>automated-e2e-testing</code>（UI）或 <code>api-testing</code>（接口）skill</li>\n<li>代码变更后判断回归范围 → 用 <code>regression-testing</code> skill；本 skill 只负责用例文件的增量修改</li>\n<li>既无代码仓库、也无任何需求/设计文档可参考 → 无法开工</li>\n</ul>\n<h2>工作流程</h2>\n<h3>阶段〇：主动索取代码仓库（开工第一件事）</h3>\n<p>启动测试用例编写前，<strong>主动向用户索要被测项目代码仓库</strong>：</p>\n<ul>\n<li><strong>索取内容</strong>：① 仓库地址（本地路径或远程 URL）；② 被测分支/tag；③ 本次改动范围（PR/MR 链接或 <code>&lt;base&gt;...&lt;head&gt;</code> diff 范围，无则默认全量）</li>\n<li><strong>提问模板</strong>：\n<blockquote>\n<p>\uD83D\uDD0D 为提升用例准确性，请提供被测项目代码仓库地址与被测分支（若有本次改动的 PR/diff 范围也请给出）。代码将作为功能事实基线，文档作为对照——基于实际实现编写的用例能发现文档与实现的不一致、定位潜在 bug，纯文档模式则无法做到。</p>\n</blockquote>\n</li>\n<li><strong>用户确认无代码 → 降级纯文档模式</strong>：提示「将基于文档编写，准确性受限：无法发现文档与实现的不一致、无法定位潜在 bug、无法核实风险点是否有下游消费」，跳过「代码探索与全面审查」与附录 Cx/Dn 产出。</li>\n</ul>\n<blockquote>\n<p>代码模式与文档模式的差异贯穿后续所有阶段，每个阶段都会标注。</p>\n</blockquote>\n<h3>阶段一：输入研读 + 范围界定（代码优先）</h3>\n<p>从输入源中提取所有可测试点，同时识别平台、角色和测试边界。<strong>代码是静态事实的最高来源</strong>（裁决规则见 <code>../core/evidence.md</code>）——有代码时以实现为准（测准声明），文档降为对照。</p>\n<h4>输入源与关注重点</h4>\n<table>\n<thead>\n<tr>\n<th>输入源</th>\n<th>重点关注</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td><strong>代码仓库（最高优先级）</strong></td>\n<td>实际实现逻辑、数据结构、错误处理、与文档偏差、潜在 bug、改动范围（diff）</td>\n</tr>\n<tr>\n<td>需求文档/PRD</td>\n<td>功能点列表、边界说明、用户角色、业务规则</td>\n</tr>\n<tr>\n<td>技术设计方案</td>\n<td>数据模型、接口签名、状态流转、缓存策略、消息格式</td>\n</tr>\n<tr>\n<td>API 文档</td>\n<td>接口参数、必填/选填、返回值、错误码、鉴权方式</td>\n</tr>\n<tr>\n<td>Bug 报告</td>\n<td>复现步骤、根因分析、修复范围（回归用例）</td>\n</tr>\n<tr>\n<td>FAQ/会议纪要</td>\n<td>隐含需求、设计决策、边界限制</td>\n</tr>\n</tbody>\n</table>\n<p><strong>关键提醒</strong>：FAQ 中的每个问答都是潜在的边界用例；\"非目标\"声明中的限制需要对应的验证用例。</p>\n<p><strong>已有上游产物时直接消费</strong>：存在 <code>需求模型.md</code>（requirement-analysis 产出）则以其为结构化输入，澄清记录直接引用，不再重复建模；存在 <code>测试策略.md</code>（test-strategy 产出）则按其范围/深度/优先级要求执行，Risk Map 中的风险编号（R1、R2…）作为 <code>risk_ref</code> 挂到对应用例。存在 type_scope（类型域决策）时按 <code>../core/test-type-matrix.md</code> 第 12 节消费方式映射执行：<strong>用例型</strong>轴（业务安全/可靠/并发/兼容，standard 及以上）产对应类型用例——type 用 security / reliability / concurrency / compatibility，名称行加 <code>[并发]</code> 等标签（i18n/迁移/契约轴用 type: functional + 标签）；<strong>脚本型</strong>轴（性能/视觉，standard 及以上；无障碍任意档位产 axe 扫描任务与违规清单）不产手动用例，导读区标注\"执行物走专项脚本\"并留给执行策略裁决；<strong>审查型</strong>（light 档）发现并入附录 Cx 审查清单；exclude 轴不产出。</p>\n<h4>识别范围</h4>\n<p>在读输入源时同步记录：<strong>平台/端</strong>（管理后台、用户端、后端 API、第三方回调）、<strong>用户角色</strong>（每个角色能看到什么、能做什么、不能做什么）、<strong>测试边界</strong>（本期范围 vs 不测的 vs 依赖项）。</p>\n<h4>受众与执行模型判定（开工必做，决定用例写法）</h4>\n<p>被测功能有无 UI，直接决定用例正文怎么写。开工时先判定，必要时向用户确认一句：</p>\n<ul>\n<li><strong>有 UI 的功能</strong>（网页后台、App、小程序、H5 页面）→ 测试工程师<strong>独立执行</strong>。操作步骤写具体的 UI 动作（进入哪个页面、填哪个字段、点哪个按钮）；预期结果写页面上能观察到的现象。</li>\n<li><strong>无 UI 的后端功能</strong>（数据 stage、API 接口、SDK 迁移、定时任务、消息队列消费）→ 测试工程师<strong>无法独立执行</strong>，写成**「测试-开发协作清单」**：操作步骤标「请开发执行」（给开发具体的数据与触发方式）；预期结果标「请开发反馈」（反馈实际值/截图）；验证方式标「开发查库/查日志反馈」。<strong>开工即问</strong>：向用户确认执行模型（\"测试能否独立执行？后端功能通常需开发代跑 + 查库反馈，对吗？\"）。</li>\n</ul>\n<p>无论哪种模型，<strong>用例正文都必须用业务语言</strong>（格式细则见 <code>../core/case-format.md</code>，阶段三执行）。</p>\n<h4>代码探索与全面审查（代码模式专属，有代码时必做）</h4>\n<p>在文档研读基础上执行 4 步，建立项目地图并发现潜在 bug。这步产出后续用例的「代码依据」与缺陷记录基础。</p>\n<p><strong>步骤 1 — 定位与概览</strong>：确认仓库路径/被测分支/改动范围；读 README、路由表、入口文件、配置文件，建立项目地图。</p>\n<p><strong>步骤 2 — 改动盘点</strong>：<code>git diff &lt;base&gt;...&lt;head&gt; --stat</code> 列改动文件，逐个分类：\uD83C\uDD95 新建（新功能主线，全面覆盖）、✏️ 修改（回归风险源，重点覆盖原行为是否保持 + 新行为）、\uD83D\uDDD1️ 删除（功能下线，验证下线后无残留入口）、\uD83D\uDC80 死代码（未挂载路由/未被引用，标记可忽略）。产出「改动文件 → 影响模块 → 回归用例」映射（记入附录「改动文件映射」）。</p>\n<p><strong>步骤 3 — 全面代码审查（派 Explore 代理矩阵，始终执行）</strong>：</p>\n<blockquote>\n<p>按改动文件数/子系统切分，派 1–3 个只读 Explore 代理并行；每个代理聚焦一类发现。代理 prompt 框架示例：\n「审查 <code>{仓库路径}</code> <code>{分支}</code> 的 {文件/子系统列表}，针对以下清单逐项查找，每条发现附 <code>文件:行</code> 证据并标注确信度：① 潜在 bug；② 文档与实现不一致；③ 死代码/死声明；④ 疑似高风险但可能无下游消费（需核实是否证伪）。只读，不修改。」</p>\n</blockquote>\n<p>审查清单<strong>执行 <code>../core/coverage.md</code> 第 7.1 节「代码审查发现模式清单」全部 13 项</strong>（null/undefined 未兜底、边界未防护、状态死锁、并发竞态、错误静默吞掉等），不是可选参考。</p>\n<p><strong>步骤 4 — 风险分级 + 转化</strong>：</p>\n<ul>\n<li><strong>高风险点 D1-Dn</strong>：按 <code>../core/risk-model.md</code> 评级（Impact × Likelihood → Critical/High/Medium/Low），每条映射一条回归用例</li>\n<li><strong>潜在 bug → 缺陷记录 Cx</strong>：编号 + 现象 + 证据（E0–E4 等级 + <code>文件:行</code>，格式见 <code>../core/evidence.md</code>）+ 处置（主线验证 / 专项验证 / 待实测确认 / 已证伪 / 后端范围）</li>\n<li><strong>文档偏离</strong>：记入附录「文档偏离对照」；<strong>死代码</strong>：标注可忽略，不写用例</li>\n</ul>\n<h4>输入源缺失时的降级策略</h4>\n<ul>\n<li>只有 PRD 无设计文档 → 不检查\"PRD 与技术设计不一致\"，审查阶段跳过\"技术实现细节\"维度</li>\n<li>只有 API 文档 → 以接口参数和错误码为主要输入源，重点覆盖输入校验和错误处理（方法见 <code>../core/methods/data-driven.md</code>）</li>\n<li>只有 Bug 报告 → 聚焦回归测试，围绕 Bug 涉及的功能区域展开</li>\n</ul>\n<h3>阶段二：需求澄清</h3>\n<p>文档研读完成后，<strong>必须先检查是否存在模糊、不完整或矛盾之处</strong>，不得自行假设。</p>\n<p><strong>触发与扫描的单一权威源在 <code>../core/clarify-pattern.md</code>（此时加载）</strong>：基础触发按其「何时必须问」，深度扫描按其「需求歧义九类漏网模式」A–I 逐类过筛（本阶段不再维护独立清单）。</p>\n<p><strong>代码模式特有触发</strong>（文档模式无此项）：<strong>文档与代码不一致</strong>——数据结构、字段是否提交、流程顺序、默认值——默认以代码为准（测准声明），列出两边原文并询问\"偏离是否确认为非缺陷？\"</p>\n<p>提问格式与裁决落盘规则统一按 <code>../core/clarify-pattern.md</code>：逐条独立成卡、给出建议选项、用户答复记入澄清记录。</p>\n<p><strong>输出</strong>：无需澄清 → 一句话确认\"需求已足够清晰\"（并入导读，<strong>不单列澄清章节、不产出仪式性清单</strong>——干净材料上的澄清仪式是纯输出预算开销，实测曾致整体净收益为负），直接进入阶段三；有问题 → 列出问题清单，<strong>等待用户回复后再进入阶段三</strong>；后续编写中发现新问题 → 随时补充提问，不硬写。澄清记录对齐需求模型的 <code>open_questions</code> 字段（用户裁决具有最终裁决力，见 <code>../core/evidence.md</code> 裁决规则）。</p>\n<h3>阶段三：用例编写</h3>\n<p><strong>直接输出最终用例文件，不产出任何中间文件（无 outline、无矩阵表格）。</strong> 使用 markmap 格式（Markdown 标题层级 + 列表）。</p>\n<h4>逐模块推进与交付核对（硬约束）</h4>\n<p>按模块逐个编写：<strong>每个模块标题下有用例后才能进入下一模块</strong>（不要求先产出完整骨架——直接逐模块写）。<strong>交付前对照输入材料逐模块核对</strong>：输入的每个功能模块（含 FAQ、异常处理、权限/角色、定时任务等易漏段落）在产出中都有非空模块且有用例；空模块必须补齐，或在待澄清清单中显式记录阻塞原因后才能定稿。<strong>多模块输入只完成第一个模块就交付 = 最严重的交付缺陷。</strong></p>\n<p><strong>维度核对（逐条，与模块核对同级）</strong>——模块齐全但维度缺失同样拦截定稿：</p>\n<ol>\n<li><strong>主流程不可省</strong>：每个功能的最短正向主路径（创建/提交/发起这类最简单操作）至少 1 条用例——\"太显然\"不是省略理由；</li>\n<li><strong>时间双侧</strong>：每条时间类规则（时限/有效期/超时/自动触发）至少 1 条双侧边界用例（边界前一拍可成功 / 到达后进入另一态）——<strong>时限数值已在材料中给定时同样必须双侧</strong>（如\"30 分钟超时\"→第 29 分 59 秒可支付、第 30 分 00 秒被关闭；\"7 天自动确认\"→满 7×24h 前一秒可手动确认、到达后自动确认）。给定数值不等于已验证，恰在边界时刻的行为是独立用例；</li>\n<li><strong>负向底数</strong>：状态机型输入，非法转换与终态约束各至少 1 条负向用例。</li>\n</ol>\n<blockquote>\n<p>纪律依据：把「完整性」从阶段 4B 的后置审查纪律改为交付前的显式核对项——弱执行环境下后置纪律可能被跳过，逐模块核对拦住「写一个模块就收工」的早停。但模块核对拦住模块坍缩后，弱模型仍会出现<strong>维度坍缩</strong>——模块全而维度空，故核对必须下探到维度。</p>\n</blockquote>\n<h4>输出预算纪律（硬约束）</h4>\n<p>输出预算有限（32K token 级），<strong>仪式与用例争预算——用例优先</strong>：</p>\n<ul>\n<li><strong>用例数封顶</strong>：<code>min(可测点数 × 1.5, 80)</code> 条为上限；超出时按 P0 &gt; P1 &gt; P2 收缩，不稀释单条质量（四段式不省略）去凑数量；</li>\n<li><strong>测试数据守约束</strong>：用例中的测试数据（唯一名、账号、订单号等）须满足材料声明的字段约束（maxLength/枚举/格式）——生成的数据模板总长按约束上限预留余量，不顶格（实测自伤案例：API 任务唯一名模板 22 字符撞契约 maxLength 20，整条用例因 NAME_INVALID 失败）；参数矩阵组合还须满足<strong>跨字段业务规则</strong>（如\"使用门槛不能低于面额\"、\"开始时间早于结束时间\"）——逐参数独立变化时每格组合回检全部规则，违反规则的格子改取合法值或拆为显式负向用例（实测自伤案例：金额顶格 1000 配低于面额的门槛，被业务规则正确拒绝而用例期望成功）；</li>\n<li><strong>附录只在代码模式产出</strong>，纯文档模式不产 Cx/Dn/改动映射/代码证据清单（无代码可引）；</li>\n<li><strong>导读压缩</strong>：四件套每件 ≤3 行；术语表只收正文实际出现的术语；</li>\n<li>单条用例超出四段式框架的内容（背景解释、方法论证）一律删除——细节属于澄清记录或附录，不属于用例。</li>\n</ul>\n<blockquote>\n<p>依据：api-testing 的输出预算纪律（parametrize 收敛/行数上限）是全集唯一实测防截断手段；实测曾发生输出被截断只剩一个 <code>{</code> 的事故，与澄清仪式开销同源——预算意识必须从 api-testing 推广到本 skill。</p>\n</blockquote>\n<h4>设计方法选择（此时加载 <code>../core/testing-principles.md</code>）</h4>\n<p>按功能特征选方法，不强制状态机：明显状态流转 → State Machine；输入输出型 → 等价类+边界值；权限系统 → Role×Action×Resource；API → 参数矩阵；复杂业务流程 → Workflow；数据转换 → Input→Transform→Output；历史 Bug 较多 → 回归聚焦。</p>\n<h4>组织方式与格式（此时执行两项硬约束文件，不是可选参考）</h4>\n<ul>\n<li><strong>组织</strong>：按状态流转和操作生命周期组织模块（方法执行 <code>../core/methods/state-machine.md</code>：提取状态机 → 按状态节点分模块 → 每条边一个用例 + 非法转换/竞态/逆向边 → 横切关注点独立模块）。无状态流转的功能按 <code>../core/methods/boundary.md</code> / <code>../core/methods/data-driven.md</code> / <code>../core/methods/permission.md</code> 对应方法组织，按输入源特征加载。</li>\n<li><strong>格式</strong>：<strong>执行 <code>../core/case-format.md</code> 全部格式硬约束</strong>——文件头部导读四件套、正文零代码内部、TC 编号（<code>TC-{模块号}-{序号}</code>，P0 加 <code>（SMOKE-n）</code>）、四段式/协作五段式、前置去冗余、嵌入具体数据（禁占位符）、页面可达性、异步判定时限、断言范围 ≤ 验证强度、可测试性标注、测准声明（代码模式）、附录区规范（Cx/Dn/代码证据清单/文档偏离/改动文件映射，与正文物理隔离）。拼装起点模板见 <code>templates/markmap_template.md</code>。</li>\n</ul>\n<h4>优先级规则（严格执行）</h4>\n<p>在用例名称行标注 <code>[P0]</code>/<code>[P1]</code>/<code>[P2]</code>，不标注时默认 P1。</p>\n<p><strong>P0（冒烟）</strong>— 满足以下<strong>全部</strong>条件：主流程的核心路径；失败则整个功能不可用；<strong>P0 自检</strong>（逐条执行）：如果这条用例失败，用户能否完成核心操作？答案为\"否\"才是 P0。</p>\n<p><strong>P1（常规）</strong>：正常功能验证 + 常见异常处理。<strong>P2（边界）</strong>：极端输入、低频场景、性能指标、需特殊环境。</p>\n<p>存在 Risk Map 时按 <code>../core/risk-model.md</code> 的映射建议执行（Critical → 必有 P0，High → P0/P1，Medium → P1，Low → P2/按需），偏离需说明理由。</p>\n<h3>阶段四：审查（写时抽查）</h3>\n<blockquote>\n<p>降级依据：全检式 4A/4B 在弱模型×输出预算下是伪执行（实测消耗大量核对预算却不改变产出行为）。\n<strong>覆盖的执行点已迁移到阶段三交付核对（模块核对+维度核对，生成路径内联）</strong>，\n本阶段只做轻量抽查，不回到原文档逐段比对（该指令是 thinking 预算杀手，已废除）。</p>\n</blockquote>\n<h4>4A：模块写完后的抽查（只做两条）</h4>\n<ol>\n<li><strong>抽查主流程</strong>：该模块最短正向主路径的用例是否存在（与维度核对第 1 条同一口径，此处只是复查）</li>\n<li><strong>抽查单一职责</strong>：抽 2-3 条用例确认只测一个点、预期唯一</li>\n</ol>\n<h4>4B：全局抽查（全部模块完成后，只做三条）</h4>\n<ol>\n<li><strong>FAQ/非目标抽查</strong>：FAQ 每条至少 1 条用例（遗漏高发区）</li>\n<li><strong>二阶交叉抽查</strong>（中型以上项目）：<code>../core/testing-principles.md</code> 第 3 节三项中抽 1 项执行（写入路径×校验 / 失败×重试 / 标识×重复）</li>\n<li><strong>跨模块重复检查</strong>：重复用例合并、TC 编号连续</li>\n</ol>\n<blockquote>\n<p><strong>已废除</strong>：逐文档溯源全检、coverage.md 19 维全检、多角色四视角全检——这些维度的<strong>设计知识</strong>\n仍在 <code>../core/coverage.md</code>（按需参考，供强模型/大项目加深），但不再是交付前的强制执行项；\n强制执行项只有阶段三交付核对的模块核对+维度核对。</p>\n</blockquote>\n<h4>审查输出</h4>\n<p><strong>直接在用例文件中补充遗漏和调整</strong>，不产出独立审查报告。只在用例文件末尾（附录之后）按 <code>../core/case-format.md</code> 第 10 节格式追加「审查记录」。</p>\n<h3>阶段五：定稿 + Schema 抽取</h3>\n<ol>\n<li><strong>可读性自检</strong>：<strong>执行 <code>../core/executability.md</code> 全部检查项</strong>（零上下文新人复述、术语表核对、正文零代码自检、执行性确认、判定时限核查），不是可选参考</li>\n<li><strong>Schema 抽取</strong>：从 markmap 单向抽取 <code>测试用例.schema.yaml</code>——字段定义、抽取规则与 YAML 转义纪律统一在 <code>../core/schema-extraction.md</code>（此时加载）；抽取后运行 <code>../core/scripts/validate_schema.py 测试用例_markmap.md 测试用例.schema.yaml --strategy {策略路径}/测试策略.md</code> 校验（YAML 合法性 + TC 编号一致性 + 占位符检查 + <strong>风险覆盖门禁</strong>：Risk Map 中全部 Critical/High 风险须被 ≥1 条用例的 risk_ref 反向覆盖，零覆盖即门禁失败；上游无策略文件则省略该参数。有代码仓库可叠加 <code>--repo-root</code> 抽查 code_refs 指涉真实性）</li>\n<li>文件命名：<code>{项目名}/测试用例_markmap.md</code> + <code>{项目名}/测试用例.schema.yaml</code></li>\n</ol>\n<h2>Schema 双轨原则</h2>\n<p>markmap 是给人的交付物与<strong>唯一人工维护源</strong>；Schema 是机器可读元数据层，由本 skill 从 markmap <strong>单向抽取</strong>，作为 Skill 间流转接口（<code>test-case-review</code> / <code>regression-testing</code> / 执行层消费）。<strong>不要求人维护两份</strong>，Schema 永远可由 markmap 再生；markmap 修改后必须重新抽取。存量 markmap 按同规则抽取即可，不需人工重写。</p>\n<h2>增量更新流程</h2>\n<p>需求变更时增量更新已有用例（而非从零重写）：</p>\n<ol>\n<li><strong>影响分析</strong>：确定变更影响哪些模块、哪些用例（直接用例 + 下游依赖 + 状态流转受影响的边 + 数据模型变更影响的查询/校验）。代码模式：基于 <code>git diff</code> 盘点改动文件，按附录「改动文件映射」分类定位受影响用例</li>\n<li><strong>标记受影响用例</strong>：按 TC 编号列出，标记 <code>[已变更]</code>、<code>[已废弃]</code>、<code>[需新增]</code>（Schema 的 <code>status</code> 同步）</li>\n<li><strong>更新用例</strong>：新增用追加编号，废弃用 <code>~~删除线~~</code> + <code>[已废弃-原因]</code></li>\n<li><strong>局部审查</strong>：对变更模块执行 4A + 涉及变更的跨模块检查</li>\n<li><strong>重新抽取 Schema</strong>（并运行 <code>../core/scripts/validate_schema.py</code> 校验），输出变更报告（格式见 <code>../core/case-format.md</code> 第 10 节）</li>\n</ol>\n<h2>Common Mistakes</h2>\n<table>\n<thead>\n<tr>\n<th>错误</th>\n<th>后果</th>\n<th>正确做法</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td>不做需求澄清直接写用例</td>\n<td>用例基于错误假设，浪费返工</td>\n<td>发现模糊立即提问</td>\n</tr>\n<tr>\n<td>有代码却不读代码，只靠文档</td>\n<td>用例基于错误假设（文档常与实现不符）</td>\n<td>有代码必读代码，以实现为准（测准声明）</td>\n</tr>\n<tr>\n<td>产出不可执行的用例（占位符/虚构入口/无时限异步）</td>\n<td>死用例占空间，执行者无法开工</td>\n<td>执行 <code>../core/executability.md</code> 全部硬标准</td>\n</tr>\n<tr>\n<td>用例正文堆代码内部（<code>文件:行</code>/SDK 符号/错误码常量）</td>\n<td>测试工程师看不懂、无法执行</td>\n<td>正文纯业务语言，代码证据隔离到附录（<code>../core/case-format.md</code>）</td>\n</tr>\n<tr>\n<td>无 UI 后端功能照搬 UI 用例写\"操作步骤\"</td>\n<td>测试无法独立执行，步骤悬空</td>\n<td>开工判执行模型；无 UI 写协作五段式</td>\n</tr>\n<tr>\n<td>缺导读区（术语/环境账号/图例）</td>\n<td>没接触过项目的人第一步就卡住</td>\n<td>导读四件套，未知信息列 TODO 标注找谁拿</td>\n</tr>\n<tr>\n<td>校验用例只挂创建路径</td>\n<td>编辑/重提路径绕过校验的 bug 漏测（高发）</td>\n<td>二阶交叉检查：写入路径 × 校验规则逐格核对</td>\n</tr>\n<tr>\n<td>异步用例无判定时限</td>\n<td>通过/失败由执行者自定</td>\n<td>预期结果写明时限，无依据则列澄清问题</td>\n</tr>\n<tr>\n<td>轻信文档/口头描述，风险点未核实代码</td>\n<td>写入伪用例（如已证伪的\"门控死锁\"）</td>\n<td>每个风险点核实下游消费，评级按 <code>../core/risk-model.md</code> 挂证据</td>\n</tr>\n<tr>\n<td>只测功能不查潜在 bug</td>\n<td>遗漏缺陷验证，bug 上线才暴露</td>\n<td>全面代码审查（<code>../core/coverage.md</code> 7.1 模式清单），潜在 bug 转 Cx</td>\n</tr>\n<tr>\n<td>P0 泛滥或缺失</td>\n<td>冒烟测试失去筛选意义</td>\n<td>逐条执行 P0 自检问题</td>\n</tr>\n<tr>\n<td>忽略 FAQ/非目标声明</td>\n<td>遗漏边界用例</td>\n<td>FAQ 每条至少 1 条用例</td>\n</tr>\n</tbody>\n</table>\n<h2>与其他 skill 配合</h2>\n<ul>\n<li><strong>上游</strong>：<code>qa</code>（端到端编排）→ <code>requirement-analysis</code>（需求模型）→ <code>test-strategy</code>（策略 + Risk Map）→ 本 skill。上游产物存在则直接消费；不存在则内联轻量版本（够用即可）</li>\n<li><strong>下游</strong>：<code>test-case-review</code>（事后独立审查）→ <code>automated-e2e-testing</code> / <code>api-testing</code>（消费用例与 Schema 执行）→ <code>regression-testing</code>（消费 <code>code_refs</code> / <code>risk_ref</code> 做影响面分析）</li>\n<li>共享的方法论与格式标准在 <code>core/</code>（设计方法 <code>core/methods/</code>、覆盖检查表、用例格式、Schema 抽取规则）；本 skill 私有资产仅 <code>templates/markmap_template.md</code>（拼装起点）</li>\n<li>本 skill 产出<strong>手动测试用例 + Schema</strong>；审查发现的<strong>疑似</strong>缺陷记 Cx（待验证），已确认 Bug 的根因分析归 <code>bug-analysis</code></li>\n</ul>\n","files":[{"path":"SKILL.md","sizeBytes":23398,"isText":true},{"path":"templates/markmap_template.md","sizeBytes":13874,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-09-09T18:19:22.410263Z","sha256":"44EEC9CEEC9A220BCA513CA7D8BB209FAAAF170B26635910226436AF91E0D5A6","sizeBytes":17649},"review":null,"source":{"repositoryUrl":"https://github.com/fishzjp/qa-skills","path":"skills/test-case-writing","license":"MIT","commit":"9d93d0410362cceb14c2597b12bc465fc2062bd4","subtreeSha":"82FE871243A7A904F1AE327D5ADAF1DCADC84B250F8AC1FFB2698E6761E38940","lastSyncedAt":"2026-09-19T13:50:33.111608Z"},"reviewedAt":"2026-09-09T18:20:31.030078Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/fishzjp/qa-skills/tree/main/skills/test-case-writing"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install fishzjp-qa-skills@llmmart"},{"target":"git","command":"git clone https://github.com/fishzjp/qa-skills.git"}]}