4、需求分析与评审：需求可测试性分析，需求评审流程，测试用例与需求的追溯矩阵
大家好，我是老张。在自动化测试这个行当里摸爬滚打了十几年，我越来越觉得：测试的成败，其实在写第一行代码之前就决定了。你想想看，如果需求本身就有问题，后面测试用例写得再漂亮，那也是白搭。今天我们就来聊聊需求分析与评审这个关键环节。
4.1 需求可测试性分析
什么叫需求可测试性？说白了就是：拿到一条需求，你能不能设计出明确的通过/不通过标准。我见过太多项目，需求写得像散文诗——「系统响应要快」「界面要友好」「运行要稳定」。嗯，这种需求，你让测试怎么测？
可测试需求的三个基本特征：
- 可量化：有具体的数值或范围
- 可观察：结果能被明确感知或记录
- 可重复：相同条件下结果一致
我在项目中遇到过这样一个案例：客户要求「PLC 控制器在高温环境下能正常工作」。这怎么测？后来我们和客户反复沟通，把需求改成了「PLC 控制器在 55°C ± 2°C 环境下连续运行 72 小时，无故障停机，CPU 占用率不超过 80%」。你看，这样测试方案就清晰了。
给大家一个实用的检查清单，判断需求是否可测试：
| 检查项 | 不可测试的表述 | 可测试的表述 |
|---|---|---|
| 性能 | 系统响应要快 | 从触发信号到输出响应 ≤ 50ms |
| 可靠性 | 系统要稳定 | MTBF ≥ 8760 小时（1年） |
| 精度 | 测量要准确 | 测量误差 ≤ ±0.5% FS |
| 兼容性 | 支持主流协议 | 支持 Modbus RTU、Profinet、EtherCAT |
我的个人习惯：在需求评审前，我会先做一轮「可测试性预审」。把那些模糊的、二义性的、无法验证的需求标记出来，带着问题去参加评审会。这样效率高很多。
4.2 需求评审流程
需求评审不是走过场。我曾经见过一个项目，评审会开了 3 小时，大家喝喝茶聊聊天就结束了。结果开发到一半发现需求有重大遗漏，返工成本直接翻了三倍。所以，评审一定要有流程、有记录、有结论。
我建议的评审流程是这样的：
- 预审阶段（1-2 天）：评审材料提前发给所有参会人员，各自独立审查。我个人习惯用 Excel 列出所有疑问点。
- 正式评审会（2-4 小时）：逐条过需求，重点讨论争议点和模糊点。测试人员要特别关注可测试性。
- 问题跟踪：所有评审意见必须记录在案，明确责任人、解决期限。
- 闭环确认：修改后的需求需要再次确认，确保所有问题都已关闭。
避坑指南：我曾经遇到过一个项目，评审时大家口头说「没问题」，但没人签字确认。结果后期扯皮，测试说需求没写清楚，开发说评审时你们都没意见。从那以后，我坚持所有评审结论必须书面化、签字确认。
评审中测试人员要重点关注什么？我总结了三个核心点：
- 完整性：有没有遗漏的边界条件？异常场景有没有覆盖？
- 一致性：不同模块的需求之间有没有矛盾？比如 A 模块要求响应时间 ≤ 100ms，B 模块依赖 A 模块，那 B 的响应时间不可能比 A 还短。
- 可实现性：以当前的技术条件和资源，这些需求能不能实现？别等到测试阶段才发现根本测不了。
4.3 测试用例与需求的追溯矩阵
追溯矩阵，听起来很高大上，其实就是一个映射表：每条需求对应哪些测试用例，每个测试用例覆盖了哪些需求。为什么要做这个？原因很简单：
- 确保每条需求都被测试覆盖到，没有遗漏
- 当需求变更时，能快速定位受影响的测试用例
- 评审时能直观展示测试覆盖率
我常用的追溯矩阵格式是这样的：
| 需求编号 | 需求描述 | 测试用例编号 | 测试用例名称 | 覆盖状态 |
|---|---|---|---|---|
| REQ-001 | 温度采集精度 ±0.5°C | TC-001 | 常温精度验证 | 已覆盖 |
| REQ-001 | 温度采集精度 ±0.5°C | TC-002 | 高温精度验证 | 已覆盖 |
| REQ-001 | 温度采集精度 ±0.5°C | TC-003 | 低温精度验证 | 已覆盖 |
| REQ-002 | 报警响应时间 ≤ 200ms | TC-004 | 报警响应时间测试 | 已覆盖 |
| REQ-003 | 支持 10 种故障码 | — | — | 未覆盖 |
你看，REQ-003 这一行是空的，说明这条需求还没有对应的测试用例。这就是追溯矩阵的价值——一眼就能看出测试盲区。
我的做法：在项目初期就用 Excel 或 Test Management 工具建立这个矩阵。每写一个测试用例，就关联对应的需求编号。项目结束时，跑一个覆盖率报告，所有未覆盖的需求一目了然。这招在客户验收时特别有用，能直接证明你的测试是完整的。
最后说一句：需求分析做得好，测试工作就成功了一半。别急着写代码、别急着写用例，先把需求吃透、评审透。这个时间花得值。