test-case-writing

测试用例编写（中文版）

英文版：见技能 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

用例结构

标准用例格式：

TC-001: 用例标题

优先级: P0 / P1 / P2 / P3 类型: 功能 / 界面 / 性能 / 安全 / 兼容性 前置条件:

条件1
条件2

测试步骤:

步骤1
步骤2
步骤3

测试数据:

数据项1: 值
数据项2: 值

预期结果:

结果1
结果2

实际结果: [执行时填写] 状态: Pass / Fail / Blocked / Skip 备注: [可选]

测试设计方法

等价类划分

将输入域划分为若干等价类，从每个等价类中选取代表性数据：

示例：年龄输入（有效范围 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

用户名正确 ✓ ✓ ✗ ✗

密码正确 ✓ ✗ ✓ ✗

结果登录成功密码错误用户名错误都错误

状态转换

测试对象在不同状态间的转换：

[未登录] --登录--> [已登录] --登出--> [未登录] | | +----登录失败---------+

用例优先级

P0（Critical）：

核心业务流程
阻塞性问题
必须在每次发布前执行

P1（High）：

重要功能
常用场景
应该在每次发布前执行

P2（Medium）：

一般功能
非核心场景
可以选择性执行

P3（Low）：

边缘场景
不常用功能
时间充裕时执行

用例编写原则

SMART 原则：

Specific（具体）: 步骤和结果明确
Measurable（可衡量）: 结果可验证
Achievable（可实现）: 可以实际执行
Relevant（相关）: 与需求相关
Time-bound（有时限）: 执行时间合理

3C 原则：

Clear（清晰）: 任何人都能理解
Concise（简洁）: 不冗余
Complete（完整）: 包含所有必要信息

覆盖率目标

需求覆盖率: 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:

输入用户名密码
点击登录按钮
验证并跳转

测试用例设计

基于以上分析，设计以下用例：

正常登录（P0）
用户名错误（P1）
密码错误（P1）
记住我功能（P2）
忘记密码流程（P2） ...

问题2：用例覆盖不全面

症状：测试后仍发现很多遗漏的场景

解决方案：

使用测试覆盖检查清单：

测试覆盖检查清单

功能维度

正常流程
异常流程
边界条件
错误处理

数据维度

用户维度

不同角色
不同权限
未登录用户
已登录用户

环境维度

不同浏览器
不同操作系统
不同屏幕尺寸
不同网络条件

状态维度

初始状态
中间状态
最终状态
异常状态

时间维度

首次使用
重复使用
超时场景
并发场景

问题3：用例太多，执行不完

症状：用例数量庞大，测试时间不够

解决方案：

优先级排序：

先执行 P0 和 P1 用例
P2 和 P3 根据时间选择性执行

风险评估：

高风险区域增加用例
低风险区域减少用例

自动化：

将重复性用例自动化
手工测试专注于探索性测试

用例合并：

合并相似用例
一个用例验证多个检查点

示例：

用例优化前（5个用例）

TC-001: 登录成功 TC-002: 登录后显示用户名 TC-003: 登录后显示头像 TC-004: 登录后显示菜单 TC-005: 登录后跳转首页

用例优化后（1个用例）

TC-001: 登录成功并验证用户信息

测试步骤:

输入正确的用户名和密码
点击登录按钮

预期结果:

✓ 登录成功
✓ 显示用户名
✓ 显示用户头像
✓ 显示导航菜单
✓ 跳转到首页

问题4：用例描述不清晰

症状：其他人执行用例时理解困难

解决方案：

使用 Given-When-Then 格式：

TC-001: 购物车添加商品

Given（前置条件）:

用户已登录
商品库存充足（> 10 件）
购物车为空

When（操作步骤）:

访问商品详情页
选择数量：2
点击"加入购物车"按钮

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 步骤:

访问登录页面
输入用户名：{username}
输入密码：{password}
点击登录按钮

添加商品到购物车

步骤ID: COMMON-ADD-TO-CART 步骤:

访问商品详情页：{product_id}
选择数量：{quantity}
点击"加入购物车"

测试用例

TC-001: 购买商品流程

步骤:

执行 COMMON-LOGIN (username=user1, password=User123!)
执行 COMMON-ADD-TO-CART (product_id=P001, quantity=2)
点击购物车图标
点击"去结算"按钮 ...

参数化用例：

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.json
template-csv.csv
template-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