test-case-writing
SKILL.md
测试用例编写（中文版）
英文版： 见技能 test-case-writing-en。
提示词见本目录 prompts/test-case-writing.md。
何时使用
- 用户提到「测试用例编写」「test case writing」「用例设计」
- 需要根据需求设计测试用例
- 触发示例：「根据以下需求编写测试用例」「设计登录功能的测试用例」
输出格式选项
本技能默认输出为 Markdown（与 Standard-version 模板一致）。若需其他格式，请在需求末尾明确说明：
| 格式 | 说明 | 如何请求（示例） |
|---|---|---|
| Markdown | 默认，便于阅读与版本管理 | 无需额外说明 |
| Excel | 制表符分隔，可粘贴到 Excel | 「请以 Excel 可粘贴的制表符分隔表格输出」 |
| CSV | 逗号分隔，首行为表头 | 「请以 CSV 格式输出」 |
| JSON | 便于程序解析 | 「请以 JSON 形式输出」 |
| TestRail | TestRail 导入格式 | 「请以 TestRail 格式输出」 |
详细说明与示例见本目录 output-formats.md。
如何使用
- 打开本目录
prompts/下对应提示词文件，复制虚线以下内容。 - 附加你的需求与上下文（业务流程、环境、约束、验收标准）。
- 若需非 Markdown 输出，在末尾追加
output-formats.md中的请求句。
参考文件
- prompts/test-case-writing.md — 测试用例编写 Standard-version 提示词
- output-formats.md — Markdown / Excel / CSV / JSON 请求说明
代码示例 | Code Examples
本技能提供以下真实代码示例：
-
测试用例设计模式（计划中） - 完整的测试用例设计示例
- 等价类划分示例（10+ 个）
- 边界值分析示例（8+ 个）
- 决策表测试示例（5+ 个）
- 状态转换测试示例（3+ 个）
- 真实项目用例集（50+ 个）
-
用例生成工具（即将推出）
-
用例质量检查器（即将推出）
更多示例将在后续版本补充。
常见误区 | Common Pitfalls
- ❌ 只测试正常场景 → ✅ 同时覆盖正常、异常、边界场景
- ❌ 用例描述不清晰 → ✅ 使用明确的步骤和预期结果
- ❌ 缺少测试数据 → ✅ 提供具体的测试数据
- ❌ 用例粒度不当 → ✅ 保持适当的粒度，不要太粗或太细
- ❌ 忽略前置条件 → ✅ 明确说明前置条件和环境要求
- ❌ 没有优先级 → ✅ 标记用例优先级（P0/P1/P2/P3）
- ❌ 用例间有依赖 → ✅ 保持用例独立性
最佳实践 | Best Practices
1. 用例结构
标准用例格式：
## TC-001: 用例标题
**优先级**: P0 / P1 / P2 / P3
**类型**: 功能 / 界面 / 性能 / 安全 / 兼容性
**前置条件**:
- 条件1
- 条件2
**测试步骤**:
1. 步骤1
2. 步骤2
3. 步骤3
**测试数据**:
- 数据项1: 值
- 数据项2: 值
**预期结果**:
- 结果1
- 结果2
**实际结果**: [执行时填写]
**状态**: Pass / Fail / Blocked / Skip
**备注**: [可选]
2. 测试设计方法
等价类划分
将输入域划分为若干等价类，从每个等价类中选取代表性数据：
示例：年龄输入（有效范围 18-65）
| 等价类 | 类型 | 测试值 | 预期结果 |
|---|---|---|---|
| < 18 | 无效 | 10, 17 | 拒绝 |
| 18-65 | 有效 | 18, 30, 65 | 接受 |
| > 65 | 无效 | 66, 100 | 拒绝 |
边界值分析
测试边界值和边界值附近的值：
示例：年龄输入（有效范围 18-65）
| 测试值 | 类型 | 预期结果 |
|---|---|---|
| 17 | 下边界-1 | 拒绝 |
| 18 | 下边界 | 接受 |
| 19 | 下边界+1 | 接受 |
| 64 | 上边界-1 | 接受 |
| 65 | 上边界 | 接受 |
| 66 | 上边界+1 | 拒绝 |
决策表
处理多个条件组合的场景：
示例：登录验证
| 条件 | 规则1 | 规则2 | 规则3 | 规则4 |
|---|---|---|---|---|
| 用户名正确 | ✓ | ✓ | ✗ | ✗ |
| 密码正确 | ✓ | ✗ | ✓ | ✗ |
| 结果 | 登录成功 | 密码错误 | 用户名错误 | 都错误 |
状态转换
测试对象在不同状态间的转换：
[未登录] --登录--> [已登录] --登出--> [未登录]
| |
+----登录失败---------+
3. 用例优先级
P0（Critical）：
- 核心业务流程
- 阻塞性问题
- 必须在每次发布前执行
P1（High）：
- 重要功能
- 常用场景
- 应该在每次发布前执行
P2（Medium）：
- 一般功能
- 非核心场景
- 可以选择性执行
P3（Low）：
- 边缘场景
- 不常用功能
- 时间充裕时执行
4. 用例编写原则
SMART 原则：
- Specific（具体）: 步骤和结果明确
- Measurable（可衡量）: 结果可验证
- Achievable（可实现）: 可以实际执行
- Relevant（相关）: 与需求相关
- Time-bound（有时限）: 执行时间合理
3C 原则：
- Clear（清晰）: 任何人都能理解
- Concise（简洁）: 不冗余
- Complete（完整）: 包含所有必要信息
5. 覆盖率目标
- 需求覆盖率: 100%（所有需求都有对应用例）
- 代码覆盖率: 80%+（自动化测试）
- 场景覆盖率: 正常、异常、边界都要覆盖
- 优先级分布: P0(20%) + P1(30%) + P2(30%) + P3(20%)
故障排除 | Troubleshooting
问题1：不知道如何开始编写用例
症状：面对需求文档不知从何下手
解决方案：
使用 5W1H 分析法：
- What（测什么）: 识别功能点
- Who（谁用）: 识别用户角色
- When（何时）: 识别触发条件
- Where（哪里）: 识别使用场景
- Why（为何）: 理解业务目标
- How（如何）: 设计测试步骤
示例：
## 需求：用户登录功能
### 5W1H 分析
**What**:
- 用户名密码验证
- 记住我功能
- 忘记密码链接
**Who**:
- 注册用户
- 未注册用户
- 管理员
**When**:
- 首次访问
- Session 过期后
- 主动登出后
**Where**:
- Web 端
- 移动端
- 不同浏览器
**Why**:
- 保护用户数据
- 个性化体验
- 权限控制
**How**:
- 输入用户名密码
- 点击登录按钮
- 验证并跳转
### 测试用例设计
基于以上分析，设计以下用例：
1. 正常登录（P0）
2. 用户名错误（P1）
3. 密码错误（P1）
4. 记住我功能（P2）
5. 忘记密码流程（P2）
...
问题2：用例覆盖不全面
症状：测试后仍发现很多遗漏的场景
解决方案：
使用测试覆盖检查清单：
## 测试覆盖检查清单
### 功能维度
- [ ] 正常流程
- [ ] 异常流程
- [ ] 边界条件
- [ ] 错误处理
### 数据维度
- [ ] 有效数据
- [ ] 无效数据
- [ ] 空值/null
- [ ] 特殊字符
- [ ] 超长数据
- [ ] 数据类型错误
### 用户维度
- [ ] 不同角色
- [ ] 不同权限
- [ ] 未登录用户
- [ ] 已登录用户
### 环境维度
- [ ] 不同浏览器
- [ ] 不同操作系统
- [ ] 不同屏幕尺寸
- [ ] 不同网络条件
### 状态维度
- [ ] 初始状态
- [ ] 中间状态
- [ ] 最终状态
- [ ] 异常状态
### 时间维度
- [ ] 首次使用
- [ ] 重复使用
- [ ] 超时场景
- [ ] 并发场景
问题3：用例太多，执行不完
症状：用例数量庞大，测试时间不够
解决方案：
-
优先级排序：
- 先执行 P0 和 P1 用例
- P2 和 P3 根据时间选择性执行
-
风险评估：
- 高风险区域增加用例
- 低风险区域减少用例
-
自动化：
- 将重复性用例自动化
- 手工测试专注于探索性测试
-
用例合并：
- 合并相似用例
- 一个用例验证多个检查点
示例：
## 用例优化前（5个用例）
TC-001: 登录成功
TC-002: 登录后显示用户名
TC-003: 登录后显示头像
TC-004: 登录后显示菜单
TC-005: 登录后跳转首页
## 用例优化后（1个用例）
TC-001: 登录成功并验证用户信息
**测试步骤**:
1. 输入正确的用户名和密码
2. 点击登录按钮
**预期结果**:
- ✓ 登录成功
- ✓ 显示用户名
- ✓ 显示用户头像
- ✓ 显示导航菜单
- ✓ 跳转到首页
问题4：用例描述不清晰
症状：其他人执行用例时理解困难
解决方案：
使用 Given-When-Then 格式：
## TC-001: 购物车添加商品
**Given（前置条件）**:
- 用户已登录
- 商品库存充足（> 10 件）
- 购物车为空
**When（操作步骤）**:
1. 访问商品详情页
2. 选择数量：2
3. 点击"加入购物车"按钮
**Then（预期结果）**:
- 显示"添加成功"提示
- 购物车图标显示数字 2
- 商品出现在购物车列表中
- 商品数量显示为 2
- 总价 = 单价 × 2
问题5：测试数据准备困难
症状：每次执行用例都要花很多时间准备数据
解决方案：
- 创建测试数据集：
## 测试数据集
### 用户数据
| 用户名 | 密码 | 角色 | 状态 | 用途 |
|--------|------|------|------|------|
| admin@test.com | Admin123! | 管理员 | 正常 | 管理员功能测试 |
| user1@test.com | User123! | 普通用户 | 正常 | 正常流程测试 |
| user2@test.com | User123! | 普通用户 | 锁定 | 异常状态测试 |
### 商品数据
| 商品ID | 名称 | 价格 | 库存 | 用途 |
|--------|------|------|------|------|
| P001 | 商品A | 100 | 999 | 正常购买测试 |
| P002 | 商品B | 200 | 1 | 库存不足测试 |
| P003 | 商品C | 0 | 100 | 免费商品测试 |
-
使用数据生成工具：
- Faker.js（JavaScript）
- Faker（Python）
- 自定义数据生成脚本
-
数据库快照：
- 保存测试数据库快照
- 每次测试前恢复快照
问题6：用例维护成本高
症状：需求变更后要更新大量用例
解决方案：
- 模块化设计：
## 公共步骤库
### 登录步骤
**步骤ID**: COMMON-LOGIN
**步骤**:
1. 访问登录页面
2. 输入用户名：{username}
3. 输入密码：{password}
4. 点击登录按钮
### 添加商品到购物车
**步骤ID**: COMMON-ADD-TO-CART
**步骤**:
1. 访问商品详情页：{product_id}
2. 选择数量：{quantity}
3. 点击"加入购物车"
## 测试用例
### TC-001: 购买商品流程
**步骤**:
1. 执行 COMMON-LOGIN (username=user1, password=User123!)
2. 执行 COMMON-ADD-TO-CART (product_id=P001, quantity=2)
3. 点击购物车图标
4. 点击"去结算"按钮
...
- 参数化用例：
## TC-001: 登录验证（参数化）
| 用例ID | 用户名 | 密码 | 预期结果 |
|--------|--------|------|---------|
| TC-001-1 | valid@test.com | Valid123! | 登录成功 |
| TC-001-2 | invalid@test.com | Valid123! | 用户名错误 |
| TC-001-3 | valid@test.com | Invalid | 密码错误 |
| TC-001-4 | | Valid123! | 用户名为空 |
| TC-001-5 | valid@test.com | | 密码为空 |
问题7：不知道如何验证复杂的预期结果
症状：预期结果涉及多个系统或复杂计算
解决方案：
分解验证点：
## TC-001: 订单提交
**预期结果**:
### 1. 前端显示
- [ ] 显示"订单提交成功"提示
- [ ] 跳转到订单详情页
- [ ] 订单号格式正确（ORD-YYYYMMDD-XXXXX）
- [ ] 订单状态显示"待支付"
### 2. 数据库验证
- [ ] orders 表新增一条记录
- [ ] order_items 表新增对应商品记录
- [ ] 商品库存减少对应数量
- [ ] 用户积分增加
### 3. 第三方系统
- [ ] 发送订单确认邮件
- [ ] 推送订单通知到手机
- [ ] 同步订单到 ERP 系统
### 4. 日志验证
- [ ] 记录订单创建日志
- [ ] 记录库存变更日志
- [ ] 记录积分变更日志
获取更多帮助
如果问题仍未解决：
- 查看 FAQ.md
- 查看示例的 README.md 文件
- 参考测试用例模板
- 咨询团队的测试负责人
相关技能： requirements-analysis、functional-testing、test-case-reviewer、test-strategy。
目标受众
- 在真实项目中执行该测试域工作的 QA 与开发人员
- 需要结构化、可复用测试交付物的测试负责人
- 需要快速生成可落地测试产出的 AI 使用者
不适用场景
- 无测试范围上下文的纯线上应急处置
- 需要法律/合规最终裁定但缺少专家复核的决策
- 缺少最小输入（范围、环境、期望行为）的请求
关键成功因素
- 先明确范围、环境与验收标准，再生成测试内容
- 生成结果必须结合真实系统约束做二次校验
- 保持产物可追踪（需求 -> 测试点 -> 缺陷 -> 决策）
输出模板与解析脚本
- 模板目录：
output-templates/template-word.md（Word 友好结构）template-excel.tsv（Excel 可直接粘贴）template-xmind.md（XMind 结构化大纲）template-json.jsontemplate-csv.csvtemplate-markdown.md
- 解析脚本目录：
scripts/- 解析通用：
parse_output_formats.py - 解析按格式：
parse_word.py、parse_excel.py、parse_xmind.py、parse_json.py、parse_csv.py、parse_markdown.py - 转换通用：
convert_output_formats.py - 转换按格式：
convert_to_word.py、convert_to_excel.py、convert_to_xmind.py、convert_to_json.py、convert_to_csv.py、convert_to_markdown.py - 批量转换：
batch_convert_templates.py（批量输出到artifacts/）
- 解析通用：
示例：
python3 scripts/parse_json.py output-templates/template-json.json
python3 scripts/parse_markdown.py output-templates/template-markdown.md
python3 scripts/convert_to_json.py output-templates/template-markdown.md
python3 scripts/convert_output_formats.py output-templates/template-json.json --to csv
python3 scripts/batch_convert_templates.py --skip-same
Weekly Installs
16
Repository
naodeng/awesome…a-skillsGitHub Stars
3
First Seen
13 days ago
Security Audits
Installed on
cursor15
gemini-cli14
github-copilot14
codex14
amp14
cline14