4. 需求分析与可测试性
在硬件产品开发中，需求文档往往写得“正确但不可测”。例如“设备应具备良好的散热能力”“系统应稳定可靠运行”这类描述，在评审时无人反对，但到了测试阶段却无法判定通过与否。需求分析与可测试性工作的核心，就是把产品语言逐层翻译成可观测、可激励、可判定的测试语言，形成从产品需求（PRD）到系统需求（SyRS）再到测试需求（TRD）的可追溯链条。
一、核心原理：需求的三层转化与可测试性判据
需求转化不是简单抄写，而是三次“语义降维”：产品需求回答“为谁解决什么问题”，系统需求回答“用什么指标和架构实现”，测试需求回答“用什么激励、在什么条件下、观测什么量、判定什么结果”。一条需求只有同时具备可观测性（有物理量或状态可测量）、可激励性（能构造输入或环境）、可判定性（有明确阈值与容差）时，才算可测试。
可测试性判据可以归纳为“四问”：测什么量？在什么工况下测？用什么设备测？判定门限是多少？任何一问缺失，该需求就应退回补充，而不是留给测试工程师“自行理解”。
二、方法流程：五步转化法
- 需求拆解：把产品需求拆成功能、性能、接口、环境、可靠性五类条目，每条赋予唯一编号（如 PRD-012）。
- 指标化：为每条需求绑定可量化指标与容差，形成系统需求。例如“充电快”转化为“0→80% 充电时间 ≤ 45min，输入 9V/2A”。
- 可测化：为指标设计激励方式、观测点、测试设备与判定门限，形成测试需求。
- 追溯建链：建立 PRD→SyRS→TRD→测试用例的双向映射，写入需求追溯矩阵（RTM）。
- 评审冻结：由系统、硬件、测试三方评审，确认无“不可测条目”后冻结基线。
三、案例场景：充电性能需求的转化
某便携设备产品需求为“充电速度快，用户体验好”。转化过程如下：
PRD-012 充电速度快，用户体验好
└─ SyRS-045 0→80% 充电时间 ≤ 45min
├─ 条件：25±2℃，电池初始 5% SOC
├─ 激励：9V/2A 适配器，原装线缆
├─ 观测：电池电量计读数 + 电流探头
└─ 门限：T80 ≤ 45min，且峰值温升 ≤ 15K
└─ TRD-045-01 充电时间测试
└─ TRD-045-02 充电温升测试
└─ TRD-045-03 异常适配器降额测试可以看到，一条模糊的产品需求最终被拆成三条可执行、可判定的测试需求，并各自绑定测试点与设备。当 TRD-045-02 失败时，可沿链条回溯到 SyRS-045 的温升约束，而不是停留在“充电慢”的模糊结论上。
四、常见误区与复盘
误区一：把系统需求当测试需求。“功耗≤1.8W”是系统指标，但没说明测试工况、采样方式和判定窗口，直接拿去做测试会导致结果不可复现。
误区二：只做单向追溯。只从需求往下写用例，不做反向覆盖检查，容易遗漏边界与异常场景。
误区三：忽略环境与容差。温度、电压、负载波动未写入需求，测试结果争议不断。
复盘建议：在需求评审时引入“可测试性检查表”，逐条打勾；对无法量化的需求，要求提出方给出替代观测指标，否则标记为“待澄清”，不进入基线。
五、可测试性检查清单
| 检查项 | 合格示例 | 不合格示例 |
|---|---|---|
| 可观测 | 电池电量计读数、电流探头 | “用户体验良好” |
| 可激励 | 9V/2A 适配器、可编程负载 | “正常使用条件下” |
| 可判定 | T80 ≤ 45min，温升 ≤ 15K | “充电应较快” |
| 可追溯 | PRD-012 → SyRS-045 → TRD-045-01 | 需求与用例无编号关联 |
| 边界覆盖 | 低温、低压、异常适配器 | 仅测常温标称工况 |
需求分析与可测试性不是测试团队的独角戏，而是产品、系统、硬件、测试共同完成的“翻译工程”。只有把每条需求都落到可观测、可激励、可判定的测试语言上，验证矩阵才有坚实的输入，后续的测试计划与交付体系才不会建立在模糊描述之上。