4. 风险驱动的测试策略设计

医疗软件测试与普通商业软件测试最大的区别在于：测试资源永远不足以覆盖全部路径，而漏测的后果可能是患者伤害。因此测试策略不能由“功能清单”驱动，而应由“风险”驱动。ISO 14971 为医疗器械风险管理提供了统一框架，它要求制造商在器械全生命周期内识别危害、估计风险、实施控制措施并验证其有效性。测试活动正是风险控制措施验证的核心手段，也是风险可接受性论证的证据来源。

一、从危害到测试项：ISO 14971 的风险分析链路

ISO 14971 的风险分析不是一次性文档工作，而是一条可追溯的推理链：危害（Hazard）→ 可预见的事件序列（Sequence of Events）→ 危险情况（Hazardous Situation）→ 伤害（Harm）→ 风险估计。测试策略设计的第一步，就是把这条链上的每个节点转化为可验证的测试对象。

以输液泵软件为例：危害是“过量输注”；可预见事件序列可能是“护士设置流速时误输入 999 mL/h，软件未做上限校验”；危险情况是“泵以远超处方速度运行”；伤害是“患者循环超负荷”。由此可直接导出测试项：流速上限边界校验、异常输入拒绝、报警触发与阻断输出。可以看到，风险分析输出的不是抽象风险等级，而是具体的失效模式与触发条件，这正是测试用例设计的输入。

风险估计通常采用 S×P 二维模型：S 为伤害严重度（1～5），P 为伤害发生概率（1～5），风险值 R = S × P。ISO 14971 不规定具体数值，但要求组织在风险管理计划中预先定义可接受准则。例如某企业定义：R ≤ 4 为可接受，5 ≤ R ≤ 9 为 ALARP（合理可行最低），R ≥ 10 为不可接受。这个阈值直接决定了后续测试的深度与优先级。

二、软件安全等级划分：把风险映射为测试强度

风险值本身不能直接指导测试，需要映射为软件安全等级（Software Safety Class）。IEC 62304 将软件按“可能造成的伤害”分为 A、B、C 三级：A 级为不可能造成伤害；B 级为可能造成非严重伤害；C 级为可能造成死亡或严重伤害。等级越高，要求的软件架构、单元验证、集成测试与文档追溯越严格。

划分时不能只看最终伤害，还要看软件失效对风险控制措施的影响。若某软件模块本身不直接控制治疗输出，但它是报警链的一环，其失效会削弱风险控制措施的有效性，则该模块应被提升等级。常见做法是：先按伤害严重度初判，再检查该模块是否参与风险控制，若是则上调一级。这个“就高不就低”的原则，是医疗软件安全分级中最容易被忽视、也最容易在审核中被挑战的点。

三、风险控制措施验证：测试用例从哪里来

ISO 14971 要求风险控制措施必须验证两项内容：措施已实施（implementation）和措施有效（effectiveness）。前者是“代码里有没有做”，后者是“做了之后风险是否真的降下来”。测试用例必须同时覆盖这两层。

以“流速上限校验”为例。实施验证：输入 999 mL/h，观察软件是否拒绝并提示。有效性验证：构造边界值 500 mL/h（上限）、501 mL/h（超限）、499 mL/h（正常），确认拒绝逻辑在边界处不出现漏判或误判。更进一步，还要验证当校验模块本身失效时，是否有独立的第二道防线（如硬件限速或独立报警），这就是“冗余控制措施”的验证思路。

风险控制措施按优先级分为：①设计固有安全（如物理限位）；②防护措施（如软件校验、报警）；③安全信息（如说明书警告）。测试策略应优先验证前两类，因为安全信息不能降低风险发生概率，只能提示。若某风险仅靠说明书警告控制，测试上应将其视为“控制强度不足”，在测试报告中明确标注残余风险。

四、测试优先级排序：把风险值转化为执行顺序

优先级排序不是简单按风险值从大到小排，而要综合考虑三个因子：风险值 R、失效可探测性 D、变更影响范围 C。可探测性越低（越难在测试中发现），优先级越高；变更影响范围越大，回归优先级越高。

一个可操作的排序规则是：P0 = R ≥ 10 或（R ≥ 5 且 D 低）；P1 = 5 ≤ R ≤ 9 且 D 中；P2 = R ≤ 4。发布门禁上，P0 用例必须 100% 通过，P1 允许有明确风险评估的例外，P2 可延后。这样，测试资源始终优先投向“高伤害、难发现”的失效模式。

五、一个可落地的风险驱动测试策略片段

假设某输液泵软件版本迭代，变更了流速计算模块。按上述方法，测试策略可组织为：

表中数据为教学示例，实际项目中 S、P 取值应来自风险管理文件，并由临床、研发、测试三方共同评审确认。测试执行时，P0 用例优先在每日构建中自动运行，P1 在版本候选阶段集中执行，P2 在回归末期抽样执行。这样，风险驱动的测试策略就从一份文档变成了可执行的工程节奏。