2. 风险管理驱动的测试验证

在医疗器械工程中，测试验证并不是孤立的技术活动，而是风险管理过程的“证据生产环节”。ISO 14971 给出的风险管理流程，本质上是一条从“可能造成伤害的来源”出发，逐步收敛到“可接受风险”的推理链。测试验证的价值，在于把这条推理链中的每一个假设、每一项控制措施、每一个剩余风险判断，转化为可观察、可重复、可追溯的客观证据。理解两者的映射关系，核心是回答一个问题：风险文件中的哪一条结论，需要由哪一类测试来支撑？

一、从危害分析到可测试的风险条目

ISO 14971 的流程通常包括：风险管理计划、危害识别、风险估计、风险评价、风险控制、剩余风险评价、风险管理报告与生产后信息。测试验证真正介入的起点，往往不是“危害识别”本身，而是危害被转化为可测试的风险条目之后。危害是潜在的伤害来源，例如“电击”“过热”“剂量不足”“报警失效”；而风险条目必须包含可判定的条件，例如“在单次故障条件下，患者漏电流超过 100 μA”。前者无法直接设计测试，后者可以。

因此，从危害分析到测试用例设计的第一步，是把危害分析表中的“危害—可预见事件序列—伤害”逐条展开，并标注哪些环节存在可测量的物理量、状态或行为。例如，某输液泵的危害分析给出“流速控制失效导致过量输注”，其可预见事件序列可能包括：驱动机构失步、传感器漂移、软件闭环失效、气泡干扰。对应的可测试对象分别是电机步进精度、流量传感器示值误差、闭环控制响应、气泡检测阈值。只有落到这些对象上，测试用例才有明确的被测项和判据。

二、风险估计参数与测试判据的对应

风险估计通常使用“伤害严重度”和“伤害发生概率”两个维度。严重度往往由临床后果决定，测试无法直接改变；但发生概率与设计、制造、使用中的失效模式相关，正是测试验证可以施加影响的部分。风险估计中常用的参数包括：失效模式的触发条件、暴露时间、可探测性、故障率量级等。这些参数在测试中会转化为具体的试验条件与判据。

例如，某监护仪的风险估计给出“报警失效导致延误治疗”，严重度为“严重”，概率估计为“偶尔”。若设计采用“报警自检 + 看门狗”作为风险控制措施，则测试验证需要覆盖：自检能否在开机时发现报警通道故障、看门狗能否在软件死锁时触发独立报警、报警声压级是否在环境噪声下仍可识别。这里的“偶尔”并不是一个可直接测量的数字，但它提示测试需要覆盖单点故障、间歇性故障和边界条件，而不是只做正常功能确认。

三、风险控制措施与测试类型的映射

ISO 14971 将风险控制措施按优先级排列：固有安全设计、防护措施、安全信息。不同优先级的控制措施，对应的测试类型和证据强度不同。固有安全设计通常需要设计验证与型式试验；防护措施需要功能测试与故障测试；安全信息则需要可用性测试与标签确认。把这一映射关系画清楚，可以避免“所有风险都用同一类测试覆盖”的常见问题。

四、从风险控制到测试用例的展开方法

把风险控制措施展开为测试用例，建议采用“控制措施—失效路径—测试条件—判据”四列结构。以“防护措施：过温保护”为例，控制措施是当温度超过阈值时切断加热；失效路径包括温度传感器失效、比较器失效、继电器粘连；测试条件需要覆盖传感器开路/短路、比较器阈值偏移、继电器触点粘连；判据则是加热回路在设定时间内断开，且表面温度不超过限定值。这样展开后，测试用例不再是“验证过温保护功能正常”，而是具有明确故障注入方式和可测量结果的具体试验。

对于软件相关的风险控制，测试用例还需要覆盖状态机、时序和异常处理。例如，某呼吸机的风险控制措施是“在氧气供应中断时切换至空气并触发报警”。测试用例应包含：氧气压力传感器信号从正常值阶跃下降至零、切换阀动作时间、报警触发延迟、以及切换过程中通气参数是否保持在允许范围内。这些测试条件直接对应风险估计中的“可探测性”和“暴露时间”参数。

五、闭环的关键：可追溯矩阵与变更联动

风险管理与测试验证形成闭环，最终体现在可追溯矩阵上。矩阵的左侧是风险条目编号、危害、控制措施；右侧是对应的测试用例编号、测试类型、判据、测试记录编号和结论。矩阵不是一次性文档，而是随设计变更、测试偏差、生产后信息持续更新的活文件。当某个风险条目的控制措施发生变更时，矩阵应能立即指出哪些测试用例需要重新执行；当某个测试用例出现偏差时，矩阵应能回溯到受影响的风险条目，判断剩余风险是否仍然可接受。

实际项目中，常见的断点有三类：一是风险条目描述过于笼统，无法映射到具体测试；二是测试用例只验证正常功能，未覆盖风险估计中提到的失效路径；三是测试完成后未更新剩余风险评价，导致风险管理报告与测试证据脱节。解决这三类断点，需要在风险管理计划中明确测试验证的介入节点、测试用例的编写规则，以及测试结果回写风险文件的流程。

六、示例：输液泵风险条目与测试用例映射

上表中的参数均为教学示例，用于说明映射方式，不代表任何具体产品的实测结果。实际项目中，判据应来自产品技术要求、风险管理文件和相关标准。通过这样的映射，风险分析不再是测试前的“纸面工作”，测试也不再是脱离风险结论的“功能确认”，两者共同构成从危害识别到剩余风险评价的完整证据链。