Menú
De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.
Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.
npx skills add https://github.com/zhaoxuya520/AI-Fullstack-Delivery-Workflow --skill test-case-designEl comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.
¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.
设计 API 认证鉴权和权限矩阵时使用。适用于多角色系统、租户隔离、字段级权限。优先使用 OAuth 2.0 / JWT + RBAC + 资源归属检查。
设计具体 API 端点时使用。适用于资源建模后的下一步、列端点清单、HTTP 方法和状态码选择。优先使用 RFC 7231 HTTP 语义 + GitHub REST 命名规范。
设计 API 错误码和错误结构时使用。适用于错误响应规范、调用方错误处理、调试可观测。优先使用 RFC 7807 Problem Details + 业务错误码 + 调用方处理建议。
Basado en la clasificación ocupacional SOC
Mostrando SKILL.md
| name | test-case-design |
| description | 设计测试用例时使用。适用于功能测试、回归测试、UAT 前用例准备。融合等价类、边界值、决策表、状态转换、错误推测五大黑盒方法。 |
参考来源：ISTQB Foundation 黑盒测试技术、Cem Kaner《Lessons Learned in Software Testing》、Glenford Myers《The Art of Software Testing》。
1. 用例 = 前置 + 步骤 + 数据 + 预期 + 后置
缺一项就不是用例
2. 一个用例只测一件事
测多个目的会让失败定位困难
3. 预期必须可验证
"看起来对" 不是预期
4. 用例可独立执行
不依赖前一个用例的副作用
5. 命名要能"读出"测什么
`订单-创建-超出库存上限报错` 优于 `test_001`
原则：同一类输入产生同一类行为，每类选一个代表
示例：年龄字段 [0, 150]
有效等价类：[0, 150] → 取 30
无效等价类：(-∞, -1] → 取 -1
无效等价类：[151, +∞) → 取 200
无效等价类：非数字 → 取 "abc"
→ 4 个用例覆盖所有等价类
原则：边界附近最易出 Bug，必测
示例：长度 [1, 100]
必测：0（下界外）, 1（下界）, 2, 99, 100（上界）, 101（上界外）
常见边界：
- 数值：min-1, min, min+1, max-1, max, max+1
- 长度：0, 1, max, max+1
- 时间：00:00, 23:59, 月末, 闰年, 跨时区
- 数组：空, 1 个, 最大长度, 超出
- 字符串：空, 1 字符, 超长, Unicode, Emoji, RTL
原则：多个条件组合时，列表枚举
示例：折扣规则
条件：会员（是/否）+ 满 100（是/否）+ 优惠券（有/无）
| 会员 | 满 100 | 优惠券 | 折扣 |
|------|-------|-------|------|
| 是 | 是 | 有 | 30% |
| 是 | 是 | 无 | 20% |
| 是 | 否 | 有 | 10% |
| 是 | 否 | 无 | 0% |
| 否 | 是 | 有 | 15% |
| 否 | 是 | 无 | 10% |
| 否 | 否 | 有 | 5% |
| 否 | 否 | 无 | 0% |
→ 8 个用例覆盖所有组合，避免漏测
原则：每个合法转换 + 每个非法转换都测
示例：订单状态机
draft → submitted → paid → shipped → delivered
↓
cancelled
合法转换用例：
- draft → submitted（提交）
- submitted → paid（支付）
- paid → shipped（发货）
- shipped → delivered（确认收货）
- submitted → cancelled（取消）
非法转换用例（必测）：
- delivered → cancelled（已收货不能取消）
- paid → submitted（已支付不能回退）
- draft → paid（未提交不能直接支付）
原则：基于经验、历史 Bug、领域知识推测可能错误处
常见错误推测点：
- SQL 注入：'; DROP TABLE users; --
- XSS：<script>alert(1)</script>
- 路径穿越：../../etc/passwd
- 大小写混淆：Email vs email
- 空值：null, undefined, "", " ", "\n"
- 编码：%20, +, &
- 时区：UTC vs Local, DST 切换
- 货币：999.99, 0.01, -1, 1e10
- 分页：page=0, page=-1, page=999999
- 并发：同时点击两次"提交"
1. 阅读 PRD / API 契约 / UI 流程
↓
2. 提取测试点（输入 / 输出 / 状态 / 规则）
↓
3. 选择方法
- 单字段输入 → 等价类 + 边界值
- 多条件组合 → 决策表
- 状态机 → 状态转换
- 历史问题域 → 错误推测
↓
4. 写正向用例
- 主路径成功
↓
5. 写反向用例
- 校验失败 / 权限失败 / 资源不存在
↓
6. 写边界用例
- 0 / 1 / 最大 / 最大+1
↓
7. 写状态转换用例
- 合法 + 非法
↓
8. 评审
- 同事 review，是否漏点
单字段输入：
- 等价类 3~5 个 + 边界值 4~6 个 ≈ 7~10 用例
多条件组合（N 个布尔条件）：
- 决策表：2^N（避免组合爆炸时用 Pairwise）
状态机：
- 合法转换数 + 非法转换数
API 端点（CRUD）：
- 单端点 ≈ 8~12 用例（成功、空、参数错、认证错、权限错、不存在、冲突、限流）
| 等级 | 含义 | 比例 |
|---|---|---|
| P0 | 阻塞上线，必测必过 | 10%~20% |
| P1 | 主流程，必测应过 | 30%~40% |
| P2 | 次要路径 | 30%~40% |
| P3 | 边缘场景 | 10%~20% |
打分依据：
□ 每个用例都有前置 + 步骤 + 预期
□ 预期是可验证的（不是"看起来对"）
□ 一个用例只测一件事
□ 用例可独立执行
□ 命名能读出测什么
□ 五大方法都用上了（不只是正向）
□ 边界值齐全（min-1, min, max, max+1）
□ 状态机非法转换覆盖
□ 优先级有依据，不是拍脑袋
□ 每个验收标准至少 1 条 P0 用例
templates/test-case-template.md — 单条用例标准模板（前置 + 步骤 + 预期 + 验证点 + 后置）上游：
test-strategy → 测试范围
risk-based-testing → 优先级输入
平行：
exploratory-testing → 探索式补充用例
下游：
api-testing → API 用例细化
acceptance-testing → 验收用例
regression-testing → 入回归套件
bug-reporting → 失败时形成 Bug