软件验证与确认

在软件医疗器械领域，验证（Verification）与确认（Validation）是两个常被混用却内涵不同的概念。前者关注是否按需求正确实现，后者关注是否满足用户的真实使用目的。两者的策划与执行水平，直接决定软件产品的安全有效性证据是否充分。本文梳理软件验证与确认的体系要求与实施要点。

概念区分与相互关系

通俗地说，验证是把事情做对，确认是做对的事情。验证活动针对软件需求与设计，通过评审、静态分析、单元测试、集成测试与系统测试，确认每一条需求都被正确实现；确认活动则回到用户与临床场景，通过可用性评价、临床评价或真实使用测试，确认软件在其预期用途下能够安全有效地达成医疗目的。二者不可互相替代：测试全部通过但临床场景不适用的情况并不罕见。企业应在策划阶段就分别制定验证计划与确认计划，明确各自的范围、方法、责任人与完成准则，并保留计划审批记录。

验证策划：层级、策略与准入准出

有效的验证需要分层设计。单元测试聚焦模块内部逻辑与边界条件，通常由开发人员执行并记录；集成测试验证模块间接口与数据传递，重点覆盖异常处理与外部依赖；系统测试在完整产品层面验证功能、性能、兼容性、安全性与可靠性。策划时应明确每一层的准入与准出准则，例如代码评审通过方可进入测试、严重缺陷清零且用例通过率达到目标方可准出。对于安全级别为C的软件，应提高覆盖率要求并对关键路径实施更严格的独立复核。验证环境应与开发环境分离，并保留环境配置与版本记录。

静态方法与动态方法

验证方法可分为静态与动态两类。静态方法包括代码评审、需求与设计评审、静态代码分析、架构一致性与复杂度分析，其优势是在早期发现缺陷、降低修复成本；动态方法则是实际执行软件，通过等价类划分、边界值分析、错误推测、状态迁移与场景法等设计用例。对于含算法的产品，还需设计数据集层面的验证，覆盖不同人群、不同设备来源与不同质量水平的数据。推荐的组合是：以静态分析保证代码规范与安全，以评审保证需求与设计一致，以分层动态测试保证功能与性能，三者证据相互补充，形成完整的验证证据链。

确认：真实场景与可用性评价

确认应尽可能贴近真实使用环境。对SaMD而言，确认活动通常包括：在目标运行环境（操作系统、浏览器、移动端版本、网络条件）下的完整流程测试；由代表性用户参与的可用性评价，可参考IEC 62366与人因设计相关指导原则开展；以及基于临床数据的临床评价或同品种比对。确认要特别关注使用错误风险，如误读界面信息、误选参数、忽略告警等，并通过界面设计、二次确认步骤与提示语加以控制。确认活动应在产品发布前完成，发生重大更新后应重新评估其必要性与范围。

自动化、回归与缺陷管理

软件迭代频繁，回归测试成本极高，因此自动化是必然选择。企业应搭建持续集成环境，将单元测试、接口测试与静态分析纳入流水线，每次提交自动执行并生成报告。自动化并不免除人工确认，探索性测试与场景测试仍需保留。缺陷管理同样重要：应建立缺陷分级（致命、严重、一般、轻微）、处理时限与关闭准则，缺陷修复后必须回归验证并评估是否引入新风险。缺陷趋势数据可用于评估软件成熟度，也可作为CAPA与管理评审的输入，帮助管理层判断发布节奏与资源投入。

验证与确认是软件医疗器械质量体系中最有技术含量、也最容易流于形式的部分。只有把分层验证、真实场景确认、自动化回归与缺陷闭环有机结合起来，企业才能在快速迭代的同时守住安全有效的底线。