什么是测试用例
测试用例是一组条件和步骤，用于验证软件的特定功能或特性是否正常工作。每个测试用例定义了测试什么、如何测试，以及期望的结果是什么。
可以把测试用例看作是 QA 流程的构建块。编写良好的测试用例是可重复的、无歧义的，并且覆盖正常路径和边界情况——这样任何测试人员都能拿起它们并一致地执行。
本文提供了一个实用的测试用例模板，然后基于最常见的登录与注册场景进行完整的实战案例编写。这些测试用例覆盖了正常路径和关键边界情况，可直接复制到你的测试管理工具中使用。
测试用例模板
以下是一个标准的测试用例模板，你可以复制到测试管理工具、电子表格或文档中。
测试用例编号： TC-[模块]-[编号]
所属模块： [例如：登录、注册]
测试标题： [简短、描述性的名称]
优先级： [严重 / 高 / 中 / 低]
前置条件： [测试前必须满足的条件]
测试数据： [测试中使用的具体数据]
测试步骤：
1. [步骤 1]
2. [步骤 2]
3. [步骤 3]
期望结果：
[正确执行步骤后应该发生什么]
实际结果：
[实际发生了什么——测试执行时填写]
状态： [通过 / 失败 / 阻塞 / 未执行]
Bug 编号： [BUG-XXX（如适用）]
测试人员： [姓名]
测试日期： [YYYY-MM-DD]
测试用例字段说明
编写测试用例前，先理解每个字段的含义：
| 字段 | 说明 | 示例 |
|---|---|---|
| 测试用例编号 | 唯一标识，格式：TC-[模块]-[编号] |
TC-REG-001 |
| 所属模块 | 该用例属于哪个功能模块 | 注册、登录、密码重置 |
| 测试标题 | 一句话描述测试场景，清晰可辨 | 使用有效邮箱和密码成功注册 |
| 优先级 | 重要程度：严重 > 高 > 中 > 低 | 严重：核心流程故障；高：主要功能异常；中：边界问题；低：体验优化 |
| 前置条件 | 测试开始前必须满足的状态 | 用户已登录、该邮箱尚未注册 |
| 测试数据 | 测试中使用的具体值，精确到字符串 | email = "<user@example.com>" |
| 测试步骤 | 编号的操作步骤，每步一个动作 | 1. 访问 URL；2. 输入值；3. 点击按钮 |
| 预期结果 | 正确执行后应发生什么，须可验证 | 账户创建成功，页面跳转至仪表盘 |
| 实际结果 | 执行时实际发生的情况（执行时填写） | 同预期结果 / 报错："邮箱已存在" |
| 状态 | 通过 / 失败 / 阻塞 / 未执行 | 执行时填写 |
| Bug 编号 | 关联的 Bug 跟踪编号（如适用） | BUG-0042 |
| 备注 | 补充信息：临时方案、关联工单等 | 仅 Firefox 复现 |
完整示例
下面是一个完整的测试用例示例，展示模板如何填充：
测试用例编号： TC-REG-001
所属模块： 用户注册
测试标题： 使用有效邮箱和密码成功注册
优先级： 严重
前置条件： 用户在注册页面，该邮箱尚未注册
测试数据： email = "newuser@example.com", password = "SecurePass123!", name = "张三"
测试步骤：
1. 访问 https://app.example.com/register
2. 在"全名"字段输入"张三"
3. 在"邮箱"字段输入"newuser@example.com"
4. 在"密码"字段输入"SecurePass123!"
5. 在"确认密码"字段输入"SecurePass123!"
6. 勾选"我同意服务条款"复选框
7. 点击"创建账户"按钮
期望结果：
- 账户创建成功
- 用户被重定向到"验证您的邮箱"页面
- 30 秒内向 newuser@example.com 发送确认邮件
- 用户邮箱验证后可使用注册凭据登录
测试用例模板表（可复制）
以下表格可直接复制到 Excel / Google Sheets 中，作为测试用例管理表。前 5 列已填充示例数据，后面列留空供你填写实际执行结果。
| 编号 | 模块 | 测试标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 实际结果 | 是否通过 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| TC-REG-001 | 注册 | 使用有效邮箱和密码成功注册 | 严重 | 正常路径 | 用户在注册页面，该邮箱尚未注册 | 1. 访问 /register 2. 输入姓名、邮箱、密码 3. 勾选条款 4. 点击创建 | email="<newuser@example.com>", password="SecurePass123!" | 账户创建成功，跳转至验证邮箱页面，30秒内收到确认邮件 | |||
| TC-LOGIN-001 | 登录 | 使用正确的邮箱和密码成功登录 | 严重 | 正常路径 | 用户有已验证账户 <user@example.com> | 1. 访问 /login 2. 输入邮箱 3. 输入密码 4. 点击登录 | email="<user@example.com>", password="CorrectPass123!" | 认证成功，跳转至仪表盘，会话令牌设置正确 |
空白模板表（可复制）
以下是空白模板表头，复制后可自行添加行填入你自己的测试用例数据：
| 编号 | 模块 | 测试标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 实际结果 | 是否通过 | 备注 |
|---|
如何编写好的测试用例：最佳实践
1. 每个测试用例独立
一个测试用例应验证一个特定的行为。如果测试失败，你应确切知道哪里出了问题。不要将多个场景合并到一个测试用例中。
2. 测试数据要具体
"输入有效邮箱"太模糊。"输入 <user@example.com>"很精确。具体的测试数据使测试用例可复现。
3. 覆盖正常路径和边界情况
正常路径（用有效数据成功登录）很重要，但边界情况能发现真正的 Bug：
- 空字段
- 无效格式
- 边界值
- 过期令牌
- 并发会话
4. 编写前置条件
前置条件设置测试环境。没有前置条件，测试人员可能从错误的状态开始，得出错误的通过/失败结论。
5. 使用清晰的编号步骤
每个步骤应是一个单一操作。"填写表单并提交"太模糊。要分解为逐个字段输入。
6. 详细描述期望结果
"登录成功"不够。要指定用户看到什么、重定向到哪里、发送什么邮件、数据库中发生什么。
BugCapturer 如何帮助测试用例执行
在执行测试用例时，测试人员需要快速记录结果。BugCapturer 是一款免费的 Chrome 扩展，用于 Bug 报告和视觉反馈，能让这部分变得毫无摩擦：
- 标注截图：测试用例失败时，捕获页面当前状态，用箭头和文字高亮问题——无需用语言描述。
- 屏幕录制：对于复杂场景（如涉及时序问题的多步骤登录流程），录制完整测试执行的短视频（WebM 格式）。
- 自动技术元数据：URL、浏览器、操作系统、屏幕分辨率和视口尺寸自动捕获——对于复现环境相关的 Bug 至关重要。
- 诊断数据：控制台错误和失败的网络请求（HTTP 状态码 ≥ 400）随视觉证据一起捕获。网络 URL 自动脱敏敏感参数。
- Excel/TSV 导出：一键复制结构化 Bug 报告行到剪贴板。直接粘贴到测试管理工具或团队电子表格中。
这意味着测试人员花更少的时间写 Bug 报告，花更多的时间执行测试用例。
下载：测试用例模板
将上面的模板和示例复制到你偏好的格式中：
- TestRail / Zephyr / Xray——使用标准字段创建测试用例
- Excel / Google Sheets——作为电子表格使用，每个字段一列
- Notion / Confluence——创建一个数据库，每个测试用例一条记录
- Markdown——保存在代码仓库中进行版本控制
本文中的模板和示例可直接使用。根据你的具体应用定制登录/注册场景，添加你自己的模块，构建一个完整的测试套件，让你的 QA 团队可以自信地执行。