3. 测试范围与测试策略制定
测试用例管理，说白了就是让测试资产变得有序、可追溯、可复用。很多团队一开始都挺随意的，用例写在 Excel 里，散落在各个成员的电脑上。结果呢？人一走，用例就丢了。版本一迭代，用例就乱了。
我个人习惯把用例管理看作一个「知识库」的建设过程。它不只是一堆步骤和预期结果，更是团队对产品质量理解的沉淀。今天我们就聊聊怎么把这个库建好、管好、用好。
3.1 用例库的建立与维护
建库之前，先想清楚一个问题：你的用例库是给谁用的？
- 给测试人员用： 需要步骤清晰、数据明确、可执行性强。
- 给开发人员用： 需要关联代码模块、覆盖边界、便于自测。
- 给项目经理用： 需要统计覆盖率、执行进度、通过率。
- 给新人用： 需要标注业务背景、前置条件、常见坑点。
我在项目中遇到过一种情况：测试用例写得像天书，只有写的人自己能看懂。后来我们统一了用例模板，强制要求包含「前置条件」「测试数据」「操作步骤」「预期结果」「实际结果」「备注」六个字段。效果立竿见影。
3.1.1 用例库的目录结构
我建议按「业务模块 → 功能子模块 → 测试类型」三层来组织。举个例子：
用例库根目录
├── 用户管理
│ ├── 注册登录
│ │ ├── 功能测试
│ │ ├── 边界测试
│ │ └── 异常测试
│ ├── 权限管理
│ │ ├── 角色分配
│ │ └── 权限校验
│ └── 个人信息
│ ├── 编辑功能
│ └── 数据同步
├── 订单系统
│ ├── 下单流程
│ ├── 支付流程
│ └── 退款流程
└── 数据报表
├── 数据准确性
└── 导出功能
这种结构的好处是：新人上手快，查找用例方便，而且便于后续做覆盖率分析。
3.1.2 用例维护的节奏
用例库不是建完就完事了。它需要持续维护。我一般按这个节奏来：
| 维护类型 | 频率 | 责任人 | 主要工作 |
|---|---|---|---|
| 日常维护 | 每次迭代 | 用例编写人 | 补充新用例、更新预期结果 |
| 定期评审 | 每月一次 | 测试组长 | 检查冗余、过时、重复用例 |
| 季度清理 | 每季度一次 | 测试架构师 | 重构目录、合并相似用例、标记废弃 |
| 年度审计 | 每年一次 | 质量委员会 | 评估用例库健康度、制定改进计划 |
3.2 用例版本管理
版本管理这件事，很多团队都忽略了。你想想看，一个用例今天改了，明天又改回来，后天发现改错了——没有版本记录，你根本不知道发生了什么。
我曾经在一个项目中吃过这个亏。有个核心模块的用例被改了预期结果，结果回归测试没发现一个严重的 bug，直接上线了。后来查原因，发现是有人「优化」了用例，把正确的预期结果改错了。从那以后，我坚持所有用例库必须做版本管理。
3.2.1 版本管理的几种方式
| 方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Git 管理 | 用例以文件形式存储 | 分支管理、diff 对比、回滚方便 | 需要团队会用 Git |
| 工具内置版本 | TestRail、Zephyr 等 | 操作简单、自动记录 | 版本回溯能力有限 |
| 数据库快照 | 自建用例管理系统 | 灵活、可定制 | 开发成本高 |
我个人推荐用 Git 管理。原因很简单：它不只是版本控制，还能做代码审查（Code Review）。每次用例变更都走 MR（Merge Request），让另一个人 review 一下，能避免很多低级错误。
3.2.2 版本号规范
用例版本号我建议跟产品版本号保持一致。比如：
- v2.1.0 表示对应产品 2.1.0 版本的用例集
- v2.1.0-hotfix1 表示紧急修复后的用例更新
- v2.1.0-draft 表示正在编写中的用例草稿
每个用例文件头部，我习惯加一段元信息：
# 用例版本: v2.1.0
# 最后修改人: 张三
# 修改日期: 2024-03-15
# 修改原因: 新增支付超时场景
# 关联需求: REQ-2024-0215
3.3 用例复用策略
复用，是测试用例管理的核心价值之一。你想想看，如果每个项目都从零开始写用例，那得浪费多少时间？
但复用也不是简单的「复制粘贴」。我见过有人把上个项目的用例直接拷过来，改几个字就当新用例用了。结果呢？环境不一样、数据不一样、业务逻辑也不一样，跑起来全是失败。
3.3.1 复用的层次
我一般把复用分成三个层次：
| 层次 | 说明 | 示例 |
|---|---|---|
| L1：步骤复用 | 公共操作步骤提取为模板 | 登录、登出、数据初始化 |
| L2：场景复用 | 完整测试场景跨项目复用 | 支付流程、用户注册流程 |
| L3：数据复用 | 测试数据集跨用例共享 | 身份证号生成规则、邮箱格式 |
3.3.2 复用策略的落地
具体怎么做？我分享几个实战经验：
- 建立公共用例库。 把登录、注册、搜索、分页这些通用功能做成独立用例，打上「公共」标签。其他用例直接引用，不用重复写。
- 参数化设计。 用例里不要写死数据。用变量代替，比如
{{username}}、{{amount}}。执行时传入不同参数，一个用例就能覆盖多种场景。 - 用例模板化。 对于相似的功能（比如各种列表页），做一个模板用例。新功能来了，套模板改参数就行。
- 定期清理无效复用。 有些用例被引用了，但源用例已经改了。这时候要检查引用关系，避免「牵一发而动全身」。
3.4 用例与需求的追溯关系
追溯，说白了就是回答一个问题：「这个需求，测了没有？」
很多团队的需求和用例是两张皮。需求在 Jira 里，用例在 Excel 里，谁也找不到谁。结果呢？上线前才发现某个需求根本没测，或者某个用例找不到对应的需求。
3.4.1 追溯矩阵
我习惯用追溯矩阵来管理这种关系。矩阵的横轴是需求，纵轴是用例，交叉点打勾表示覆盖到了。
| 用例 \ 需求 | REQ-001 | REQ-002 | REQ-003 | REQ-004 |
|---|---|---|---|---|
| TC-001 正常登录 | ✓ | |||
| TC-002 密码错误 | ✓ | |||
| TC-003 找回密码 | ✓ | |||
| TC-004 权限校验 | ✓ | ✓ |
从这个矩阵能一眼看出：REQ-001 有两个用例覆盖，REQ-002 和 REQ-003 各有一个，REQ-004 也有一个。如果某个需求是空的，那就说明漏测了。
3.4.2 追溯的自动化
手工维护追溯矩阵太累了。我建议用工具自动关联。比如：
- 在用例管理工具里，每个用例加一个「关联需求」字段
- 在需求管理工具里，每个需求加一个「关联用例」字段
- 写一个脚本，定期同步两边数据，生成追溯报告
我在项目中写过一个简单的 Python 脚本，每天凌晨跑一次，把 Jira 里的需求和 TestRail 里的用例做关联检查。发现有需求没有关联用例，就自动发邮件提醒。效果很好，漏测率降了不少。
3.5 本章知识体系
下面这张图总结了测试用例管理的核心逻辑，你可以把它当作一个思维导图来理解：
这张图把四个核心模块串在了一起。你可以看到，用例库是基础，版本管理是保障，复用策略是效率，需求追溯是质量。四者缺一不可。