2. 医疗嵌入式软件法规与标准
医疗嵌入式软件与普通消费电子软件最大的区别，不在于技术难度，而在于它被一整套法规与标准体系所约束。软件一旦进入医疗器械，其失效可能直接对应患者伤害，因此监管机构要求制造商不仅“把软件做出来”，还要“证明软件是安全的、过程是受控的、证据是可追溯的”。本章围绕 IEC 62304、ISO 14971、FDA 指南与 NMPA 要求，梳理它们对软件测试的具体约束，并说明软件安全分级（A/B/C 级）如何决定测试策略，以及合规性文档需要交付什么。
一、四类约束来源及其分工
理解法规约束，关键是分清它们各自“管什么”。IEC 62304 管的是软件生命周期过程：它把软件开发划分为开发策划、需求分析、架构设计、详细设计、单元实现与集成、系统测试、发布、维护等过程，并要求每个过程都有对应的活动和输出。它对测试的直接约束是：测试必须与安全分级挂钩，且验证活动要覆盖需求、架构与单元。
ISO 14971 管的是风险管理：它要求识别危险（Hazard）、估计风险、评价风险、控制风险，并验证控制措施的有效性。对测试而言，ISO 14971 决定了“测什么最重要”——测试用例应优先覆盖风险控制措施所对应的软件需求，风险控制措施的验证证据是测试报告的核心内容。
FDA 指南（如《Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices》）管的是上市前提交的软件文档内容，它按“关注级别”（Minor/Moderate/Major）规定提交材料，并强调软件描述、风险分析、验证与确认（V&V）证据。NMPA 要求则体现为《医疗器械软件注册审查指导原则》等文件，对软件研究资料、网络安全、算法（含人工智能）等提出中文语境下的申报要求。四者关系可概括为：ISO 14971 定风险，IEC 62304 定过程，FDA/NMPA 定提交证据。
二、软件安全分级 A/B/C 的判定与测试策略对应
IEC 62304 按“软件失效可能导致的伤害严重程度”把软件分为三级：A 级——不可能造成伤害或不合理风险；B 级——可能造成非严重伤害；C 级——可能造成死亡或严重伤害。分级不是按代码规模或复杂度，而是按失效后果。判定时通常先由 ISO 14971 的风险分析给出“软件项失效 → 危险 → 伤害”的链路，再取最严重路径定级。
分级直接决定测试深度。A 级软件只需验证软件需求，不强制单元级测试证据；B 级需要在需求验证之外补充架构验证，单元测试可基于风险抽样；C 级则要求需求、架构、单元三个层级都有验证证据，并且每条风险控制措施都要有对应的测试用例和可追溯记录。实践中常见误区是“整个产品统一按 C 级测”，这会造成大量无效工作量；正确做法是按软件项分别定级，例如某输液泵中“流速控制”为 C 级，而“日志导出”可能仅为 A 级。
下面给出一份可直接参考的分级与测试策略对照表（示例，具体项目需结合风险分析确定）：
| 级别 | 失效后果 | 需求验证 | 架构验证 | 单元验证 | 追溯要求 |
|---|---|---|---|---|---|
| A | 无伤害 | 必须 | 不要求 | 不要求 | 需求↔测试 |
| B | 非严重伤害 | 必须 | 必须 | 抽样 | 需求↔架构↔测试 |
| C | 死亡/严重伤害 | 必须 | 必须 | 全覆盖 | 需求↔架构↔单元↔风险控制↔测试 |
三、合规性文档要求与测试证据链
法规最终落地为文档。IEC 62304 要求每个软件过程都有输出，测试相关的核心文档包括：软件测试计划、软件测试说明（用例）、软件测试报告、软件需求规格说明、软件架构设计说明、软件单元验证记录、可追溯性矩阵、软件问题报告与变更记录。ISO 14971 则要求风险管理计划、风险分析、风险评价、风险控制措施及其验证记录。FDA 与 NMPA 的提交材料本质上是从这些文档中抽取证据。
测试工程师最需要建立的是证据链：一条风险控制措施 → 对应软件需求 → 对应架构/单元 → 对应测试用例 → 对应测试结果 → 对应结论。缺少任何一环，审核时都可能被质疑“验证不充分”。例如某 C 级软件项的风险控制措施是“当传感器读数超限时，软件必须在 200 ms 内停止泵送”，那么需求中要有明确的时限指标，测试用例中要有可测量的判定条件，测试报告中要有时间戳或日志证据，追溯矩阵中要能一键定位到这条链路。
四、把法规要求转化为可执行的测试动作
法规条文本身不直接告诉你怎么写用例，但可以转化为具体动作。第一步，依据 ISO 14971 完成风险分析，输出危险清单与风险控制措施；第二步，依据 IEC 62304 对每个软件项定级，确定验证层级；第三步，把风险控制措施写成可验证的软件需求，并标注级别；第四步，按级别设计测试用例——C 级需求逐条覆盖，B 级需求覆盖并补充接口测试，A 级需求做基本功能验证；第五步，执行测试并保留原始记录；第六步，更新追溯矩阵，确认无遗漏；第七步，将测试报告与风险管理报告一并归档，作为注册申报材料。
这七步不是一次性活动，而是随需求变更、风险更新、软件版本迭代持续进行的。每次变更都要重新评估：是否影响安全级别？是否影响风险控制措施？是否需要补充或回归测试？只有把法规约束嵌入日常测试流程，而不是在申报前临时补文档，才能真正做到既合规又高效。