Day 5 —— 测试用例的管理与评审
前面几天学的是"怎么设计用例"，今天讲"怎么写规范、怎么管起来、怎么评审、怎么维护"。这块最能体现一个测试人员是否专业。
一、一份规范用例长什么样
以"登录失败-密码错误"为例，完整字段如下：
| 字段 | 内容 |
|---|---|
| 用例编号 | TC-LOGIN-003 |
| 所属模块 | 用户登录 |
| 用例标题 | 输入正确用户名和错误密码，登录失败并提示 |
| 优先级 | P1 |
| 前置条件 | 已打开登录页，账号 admin 已注册 |
| 测试步骤 | 1. 输入用户名 admin 2. 输入密码 000000 3. 点击登录 |
| 测试数据 | admin / 000000 |
| 预期结果 | 提示"用户名或密码错误"，停留在登录页 |
| 备注 | — |
规范要点：
- 标题：模块 + 动作 + 预期，一眼看懂
- 步骤：可操作，别人照着能跑
- 预期：可验证，不写"正常显示"这种模糊词
- 一条用例只验证一个点，别把"登录成功 + 记住密码 + 跳转首页"塞进一条
口诀：标题能看懂，步骤能照做，预期能验证，一条只测一个点。
二、用例的组织方式
当用例多到几百条，必须结构化。常见两种组织法：
按模块组织（推荐入门）：
用例库
├── 用户模块（登录/注册/找回密码/个人信息）
├── 商品模块（列表/搜索/详情）
├── 购物车模块
├── 订单模块（下单/支付/取消/售后）
└── 后台模块
按用例类型组织（适合进阶）：
用例库
├── 功能用例
├── 接口用例
├── 性能用例
├── 兼容性用例
└── 安全用例
实际项目一般先按模块、再按类型打标签，用 Excel 或测试管理工具（禅道、TestLink、Jira）管理。
三、用例库管理工具对比
| 工具 | 特点 | 适合 |
|---|---|---|
| Excel | 简单灵活、上手快 | 小团队、初期 |
| 禅道 | 国产、用例+缺陷一体 | 国内中小团队 |
| TestLink | 开源、经典用例管理 | 传统团队 |
| Jira + Zephyr | 和敏捷开发打通 | 用 Jira 的团队 |
| XMind | 思维导图写用例，快速梳理 | 需求梳理、初稿 |
XMind 写用例是高效技巧：一棵树 = "模块 → 功能 → 场景 → 具体用例"，评审时汇报也直观。
四、用例评审：什么时候开、怎么开
1. 为什么必须评审
用例是一个人写的，理解偏差、遗漏、重复几乎必然有。评审就是把问题堵在执行之前——改用例的成本远低于改线上 Bug。
2. 评审的三种形式
| 形式 | 做法 | 场景 |
|---|---|---|
| 交叉评审 | 测试组内互看 | 日常推荐 |
| 正式评审会 | 拉产品、开发、测试一起过 | 大需求、核心模块 |
| 走查（Walkthrough） | 作者讲、大家听 | 快速过一遍 |
3. 评审看什么（评审清单）
- 覆盖是否完整：需求每条都对应上用例了吗？
- 有无遗漏：异常、边界、性能、安全考虑了吗？
- 有无冗余：重复用例删掉
- 优先级是否合理：核心功能有没有标 P0
- 预期结果是否明确：能不能判定通过失败
- 前置条件是否充分：需要什么数据、什么环境
口诀：覆盖全、无遗漏、去冗余、优先级、预期明、前置足。
五、用例的维护与更新
用例不是写完就锁进柜子，它会"腐烂"：
| 场景 | 怎么处理 |
|---|---|
| 需求变更 | 同步修改用例，留版本记录 |
| 功能下线 | 用例归档，不直接删除（保留痕迹） |
| 迭代新增 | 新增用例，同步更新回归用例集 |
| 发现线上 Bug | 补一条对应用例，防止再犯 |
| 用例重复跑了很多次无效 | 按"杀虫剂悖论"更新或改造，提高发现新 Bug 的能力 |
核心原则：用例库是"活文档"，跟代码一样要维护。线上每出一个 Bug，就应该多一条用例——这叫"缺陷反哺用例"。
六、回归测试的用例集怎么选
不可能每次迭代都全量跑 320 条，要分层：
| 用例集 | 包含什么 | 什么时候跑 |
|---|---|---|
| 冒烟用例集 | P0 核心流程，几十条 | 每次提测先跑，过不了直接打回 |
| 全量回归集 | 全部 P0+P1 | 版本发布前 |
| 影响范围集 | 本次改动 + 关联模块 | 每次改动的快速验证 |
| 线上巡检集 | 核心链路 | 上线后定时跑 |
口诀：提测先冒烟，发布跑全量，改动看影响，上线常巡检。
七、写用例的常见扣分项
- ❌ 预期结果写"显示正常""无异常"——无法判定通过失败
- ❌ 步骤写成"输入测试数据"——不具体，别人没法照做
- ❌ 一条用例塞多个验证点——失败了不知道哪一步的问题
- ❌ 只写正向用例，没有异常用例——覆盖不全
- ❌ 优先级全标 P0——等于没有优先级
- ❌ 用例和需求对不上号——评审时说不清覆盖了哪条需求
加分项：在用例库里标注"对应需求条目编号"，做到需求-用例可双向追溯，这是专业度的体现。
📋 小结表（Day 5）
| 主题 | 核心要点 |
|---|---|
| 规范用例 | 标题清、步骤可做、预期可验、一条一点 |
| 组织方式 | 先按模块、再按类型，打标签管理 |
| 管理工具 | Excel / 禅道 / TestLink / Jira+Zephyr / XMind |
| 评审形式 | 交叉评审、正式评审会、走查 |
| 评审清单 | 覆盖全、无遗漏、去冗余、优先级、预期明、前置足 |
| 用例维护 | 随需求更新、缺陷反哺、归档不删 |
| 回归策略 | 冒烟→全量→影响范围→巡检 |
🔑 口诀
标题清步骤细，预期要能验；一条一个点，需求对得上；评审看六项，覆盖漏冗有；用例要常新，线上 Bug 补一条；冒烟全量影响集，回归分层不白跑。
一句话记：用例写得可执行，评审堵在执行前，维护跟着需求走。
✍️ 练习题（Day 5）
- 一份规范的测试用例至少要包含哪些字段？请列全。
- 判断题：用例评审是测试组内部的事，不需要产品、开发参与。（对/错？为什么）
- 用例评审时重点看哪 6 个方面？
- 简答：什么叫"缺陷反哺用例"？为什么要这么做？
- 项目里 320 条用例，每次提测都全量跑太慢，请设计一套分层回归策略（说明每次跑哪些）。
浙公网安备 33010602011771号