1. 课程导入
硬件产品从样机到量产，失败往往不是因为“没测”，而是因为“测得不系统”。研发阶段发现的问题越晚，修复成本越高：原理图阶段改一根走线只需几小时，模具开好后改结构可能意味着数周延期与数十万元损失。本课程要解决的核心问题，就是如何用一套可执行、可追溯、可交付的测试体系，把风险在正确的时间点暴露出来。
整套体系由三块相互咬合的拼图构成：测试计划回答“测什么、什么时候测、谁来测、测到什么程度算通过”；验证矩阵回答“每一条需求由哪个测试项覆盖、覆盖到什么深度、证据在哪里”；交付体系回答“测试结果如何沉淀为可评审、可审计、可复用的资产”。三者不是文档堆叠，而是一条从需求到证据的闭环链路。
核心原理：测试是风险的分时暴露机制
硬件开发的不确定性集中在四类风险：功能风险（做出来能不能用）、性能风险（指标是否达标）、环境风险（温湿度、振动、跌落、EMC 下是否稳定）、制造风险（批量一致性是否可控）。测试计划的本质，是把这四类风险按“暴露成本最低”的顺序分配到 EVT、DVT、PVT、MP 四个阶段。
验证矩阵则是把风险落到可执行颗粒度的工具。它通常以需求条目为行、以测试用例为列，交叉点标注覆盖状态与证据编号。一个健康的矩阵应满足两条硬性规则：每条需求至少被一个用例覆盖，每个用例都能追溯到至少一条需求。任何“孤儿需求”或“无源用例”都是体系漏洞。
方法流程：从需求到交付的六步链路
- 需求拆解：把产品规格书拆成可验证条目，赋予唯一 ID，例如 REQ-PWR-003 表示电源纹波要求。
- 风险分级：按失效影响与发生概率打分，高风险项优先安排早期验证与更严苛裕量。
- 用例设计：为每条需求设计正常、边界、异常三类用例，明确输入条件、测量点与判据。
- 矩阵建立：将需求 ID 与用例 ID 交叉映射，统计覆盖率，识别空白区。
- 执行与记录：按阶段执行，记录样机编号、固件版本、环境条件、原始数据。
- 评审与归档：输出测试报告，问题单闭环，用例与矩阵随版本迭代更新。
案例场景：一次电源纹波验证的完整链路
某工业网关项目在 DVT 阶段发现 5V 电源纹波在满载时达到 120mV，超出规格 80mV。若在 PVT 才发现，可能已批量备料。该项目的处理链路如下：
需求: REQ-PWR-003 5V输出纹波 ≤ 80mV @ 满载, 25℃
用例: TC-PWR-011 满载纹波测试
条件: 输入24V, 负载2A, 示波器20MHz带宽限制, 探头接地弹簧
实测: 118mV ~ 122mV (3台样机一致)
判据: FAIL, 裕量不足
措施: 输出电容由22uF改为47uF, 增加LC滤波
复测: 62mV ~ 68mV, PASS
证据: 波形截图 + 样机SN + 固件v0.9.3
这个案例说明：判据必须量化到具体条件，否则“纹波有点大”无法驱动决策；证据必须绑定样机与版本，否则复测无法复现；问题必须回写矩阵，否则同类风险会在下一个项目重演。
常见误区与复盘要点
| 误区 | 典型表现 | 纠正做法 |
|---|---|---|
| 计划即排期 | 只有时间表，没有范围与判据 | 计划必须包含需求映射与通过标准 |
| 矩阵形式化 | 全部打勾，无证据编号 | 每个勾必须关联可查证据 |
| 只测正常态 | 边界与异常场景缺失 | 强制设计边界、异常、组合用例 |
| 证据不留版本 | 截图无样机号与固件版本 | 证据命名含 SN、版本、日期 |
| 问题不闭环 | 改完不复测、不回写矩阵 | 问题单必须复测并更新覆盖状态 |
接下来的章节将依次展开测试计划的编写要素、验证矩阵的构建与覆盖率计算、各阶段测试项设计、证据管理与交付评审，最终形成一套可直接落地的硬件测试体系。