qa-test-case-design

当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability.

⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

测试用例设计专项

核心原则

测试用例设计的核心——明确"测什么"，而非"怎么测"。

重要限制：禁止读取代码。测试用例必须基于需求文档，不得读取代码实现。 确保验证"系统应该做什么"，而非"系统如何实现"。

上游未完成就不要开始：没有充分输入（需求解构 / 场景树 / 边界清单）时， 生成的用例一定是泛泛的。先补上游，再做本步。

1. 九列标准格式（本技能是全项目格式定义者）

#	列名	必填	要点
1	用例编号	✅	TC_{模块缩写}_{功能缩写}_{三位序号}，同批不重号
2	测试类型	✅	按所属技能维度：功能/安全/异常/性能/契约/兼容性
3	功能模块	✅	必要时 模块/子功能 两级（子功能并入本列）
4	测试标题	✅	动词开头，点明验证点
5	用例级别	✅	P0/P1/P2/P3，占比见下
6	预置条件	✅	环境+数据+权限+状态，具体到可复现
7	测试步骤	⚠️	协议/规则/计算类必填；UI/业务流程类可留空
8	预期结果	✅	可量化：状态码 / 返回结构 / 数据状态 / 副作用
9	风险等级	✅	高（资损/越权/数据错误/安全）/ 中 / 低

为什么是 9 列：这是 validate_testcase_table.py 与最终 测试用例.csv 的硬约束， 不可增减列。历史上曾有 10 列版本（含"子功能""实际结果"），已废止：

• 「子功能」并入「功能模块」用 模块/子功能 表示，信息不丢
• 「实际结果」是执行阶段字段，由 qa-execution-observation 承载， 放进设计模板会导致执行时回填污染设计产物

编号规则：

text

TC_{模块缩写}_{功能缩写}_{三位序号}
TC_API_LOGIN_001   TC_CART_ADD_007   TC_ORDER_REFUND_003

不使用场景后缀（如 _NORMAL）。场景类别写进「测试类型」与「测试标题」。 旧格式 TC_USER_LOGIN_001_NORMAL 已废止。

级别占比：P0 ≤ 20% / P1 ≤ 40% / P2 ≤ 30% / P3 ≤ 10%

小规模例外：用例总数 < 10 条时配额数学上不成立（20% 不足 1 条）。 加 --no-quota 跳过校验并在报告注明口径。不要为凑比例编造用例或随意改级别。

2. 「测试步骤」留空还是填（历史分歧的裁决）

用例类型	步骤	理由
协议 / 接口类（API、gRPC、WebSocket、Webhook、数据库）	必填，含 method + path + 关键参数	步骤由协议契约决定，不依赖实现，AI 能准确写出
配置 / 规则 / 计算类	必填	同上，规则本身确定
UI / 业务流程类	可留空，标注「由执行人按实际系统补充」	同一"登录"不同系统实现完全不同，AI 强写必然与实际不符

历史版本一刀切要求"留空"，导致 API 类用例丢掉可执行性——而 API 的 method/path 恰恰是规格的一部分、不是实现细节。现按类型区分。

3. 加载时机

需要时才读，不要一上来全读：

什么时候读	读哪个
拿 9 列模板来填	assets/case-table.md（表格 + 展开块两形态 + 逐列填写要求）
查编号规则、级别定义、两处历史格式变更的来龙去脉	references/output-template-full.md（格式唯一真源）
选设计方法（等价类、判定表、正交、状态迁移、错误推测…）	references/design-methods.md
评估覆盖是否够、算覆盖率	references/coverage-and-quality.md
做用例评审	references/review-standards.md

4. 产出

markdown

| 用例编号 | 测试类型 | 功能模块 | 测试标题 | 用例级别 | 预置条件 | 测试步骤 | 预期结果 | 风险等级 |
|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| TC_API_LOGIN_001 | 功能测试 | 认证/登录 | 正确凭证登录成功 | P0 | 账号 u1 已就绪，接口文档已提供 | POST /api/login，body {"user":"u1","pass":"***"} | 返回 200，响应含 token；调 /api/profile 有效；无堆栈泄露 | 高 |
| TC_API_LOGIN_002 | 安全测试 | 认证/登录 | 伪造 Token 被拒 | P0 | 已知合法 token 与签名算法 | 改 1 个字符后请求 /api/profile | 返回 401；响应不含内部信息与用户数据 | 高 |
| TC_API_LOGIN_003 | 异常测试 | 认证/登录 | 写操作超时重试不产生重复副作用 | P1 | 网关可注入延迟；写接口有幂等键 | 令首次请求延迟至超时，按服务端策略重放 2 次 | 重试成功且最终仅 1 次登录成功记录 | 中 |

上面 3 行只展示每列写法，完整模板见 assets/case-table.md。 任何技能产出用例都必须用这套 9 列，有冲突以 references/output-template-full.md 为准。

5. 用例设计原则

DO

• 每个用例只验证一个明确目标
• 预期结果使用"应该/必须/会"等确定性词汇
• 同时包含正向与反向验证
• 标注敏感信息的脱敏处理方式
• 协议类填写具体 method/path/参数

DON'T

• 模糊描述如"检查是否可以正常工作"
• 一个用例混合多个验证点
• 忽略前置条件与环境配置
• 用主观判断代替客观测量
• 忽略异常处理流程
• 强制生成与实际系统不符的 UI 操作步骤

6. 交付前自检

• 9 列齐全，无列错位、无单元格含 |
• 用例编号唯一、3 段式 TC_{模块}_{功能}_{三位序号}、无场景后缀
• 「功能模块」含子功能时用 模块/子功能 表达，未单设列
• 未出现「实际结果」列（属执行阶段）
• 测试步骤：协议/规则/计算类已填写；UI 类已标注"由执行人补充"
• 每条用例只验证一个目标
• 预期结果可客观验证（不是"正确""正常"）
• P0-P3 占比达标；<10 条时已注明实际分布口径
• 风险等级已填，非全高
• 覆盖率已标注口径，无"全覆盖/100%"绝对化表述
• 缺失模块已标"未覆盖 + 原因"

机器校验（列数、编号唯一性、级别/风险取值、占比、覆盖率措辞）：

bash

python scripts/validate_testcase_table.py <用例文件>