夜雨聆风医疗器械软件的验证与确认，是注册申报和体系核查中最高频被质疑的环节。很多企业把测试通过了等同于软件合格了，这在审评老师眼里是远远不够的。今天就把验证、确认、风险、变更这条主线捋清楚。
验证与确认，不是一回事
软件验证回答的是我们把产品做对了吗，确认回答的是我们做的是对的产品吗。验证面向的是过程，比如单元测试、集成测试、静态分析，这些活动的依据是软件需求和设计说明，目标是证明代码实现了设计意图。确认面向的是结果，典型活动是系统测试和用户测试，目标是证明软件在预期使用环境下能满足用户需求和安全目标。
审评最常见的问题是你的测试用例依据是什么。如果测试用例无法追溯到软件需求规格（SRS）和软件风险分析（FMEA/FTA），那么测试报告做得再漂亮，也会被认为是事后补的脚本。需求—设计—编码—测试这条链路要双向可追溯，是 GJB 8000、IEC 62304 都反复强调的点。
风险管理与软件分不开
医疗器械软件的风险来源，不只是硬件失效，更多是软件逻辑缺陷、接口误用、报警遗漏、网络安全事件。软件风险管理必须在系统风险管理框架下展开，识别危险情况后倒推软件缓解措施，再把这些措施落到具体的需求项和测试项。一份空洞的软件风险分析表只罗列了可能崩溃、可能误报，没有可量化的危害场景和缓解验证，是整改通知里的常客。
软件安全性等级（A/B/C）也不是随便定的。一旦定到 B 级以上，意味着异常处理、断电恢复、报警优先级、网络安全等都要有对应的措施和证据。降级要给出充分理由，否则核查老师一句依据何在足以卡住整批资料。
变更分级与回归测试
软件不是一次性写完就完事，真正的考验在维护期。每一次变更，无论是修 Bug、改界面、升级第三方组件，还是适配新操作系统，都要走变更影响分析，判定是重大还是轻微变更。判定依据不是改动行数多少，而是改动是否影响软件安全有效性、是否触及风险控制项、是否改变预期用途。
变更确定后必须做回归测试，回归范围不能凭感觉。原则上受影响的需求项、上下游接口、共用模块、风险缓解措施都要重测，而不是只测改动的那一段。很多企业变更记录里只贴了已修复 XX 问题的截图，没有回归矩阵，没有版本对照，没有缺陷闭环记录，这种材料在体系核查中基本等于零。
常见软件缺陷类型
实战中容易被审评点名的软件缺陷，大致分几类。一是逻辑类，比如报警条件判断错误、剂量计算公式写错、单位换算遗漏；二是接口类，多线程同步、并发访问数据库导致的数据覆盖；三是健壮性类，断电、断网、外设异常时未能进入安全状态；四是网络安全类，未授权访问、明文传输、默认口令未关闭。
这些问题单靠黑盒测试发现不了，需要白盒分析、静态扫描、故障注入、模糊测试等手段配合。把缺陷管理做成缺陷池而非临时清单，按严重度分级追踪闭环，并在注册资料中以问题来源—分析—修复—验证—回归四段式呈现，是最稳妥的应对姿势。
软件的合规，说到底是用证据说话。每一条要求都对应一份可追溯的记录，比任何说辞都有力。把验证与确认当一回事，软件这一关才能稳稳迈过去。