医疗器械软件确认与回归测试

软件确认与回归测试是软件质量证据链中距离放行最近的两个环节。确认关注在预期使用环境下软件是否满足用户需求与法规要求，回归测试关注修改之后原有功能是否被破坏。二者共同构成软件变更控制的验证基础，也是审评人员核查软件版本一致性与测试充分性的主要抓手。

软件确认的前提与范围

软件确认并非孤立环节，其前提是需求、设计与验证活动已经完成并受控。确认在近似真实的使用环境下进行，使用代表性的输入数据与操作流程，检验软件在预期用途下能否稳定工作。确认范围应覆盖全部用户需求、法规要求与风险控制措施，而非仅重复已有测试。对安全相关功能，确认强度需相应提高。确认方案应事先批准，明确接受准则，避免结果导向后补标准。

• 确认前须完成需求、设计与验证并受控；
• 在近似真实使用环境下开展确认；
• 覆盖用户需求、法规要求与风险控制措施；
• 确认方案预先批准并设定接受准则。

确认测试用例的设计方法

用例设计应综合运用等价类划分、边界值分析、场景法与错误推测等方法，兼顾正常路径与异常路径。高风险功能需增加异常输入、并发操作、资源不足与断电恢复等场景。用例应写明前置条件、操作步骤、预期结果与判定依据，并可被不同测试人员重复执行。对涉及数据计算的功能，应给出数据来源与期望值的推导过程。用例集合需覆盖全部确认范围，不留空白项。

1. 等价类、边界值与场景法组合设计；
2. 覆盖正常路径与异常、并发、断电场景；
3. 写明前置条件、步骤、预期结果与判据；
4. 用例集合覆盖全部确认范围不留空白。

回归测试的触发条件与范围界定

回归测试并非每次修改都需全量执行。触发条件通常包括缺陷修复、需求变更、架构调整、运行环境或第三方组件升级。企业应基于变更影响分析，确定需要重测的模块与接口，形成影响范围清单。对涉及共享组件或核心数据结构的修改，宜扩大回归范围。回归测试应选取优先级高的代表性用例，并保留未受影响模块的验证结论作为未变证据。范围界定依据需记录在案。

• 缺陷修复、需求变更、组件升级触发回归；
• 基于影响分析界定重测模块与接口；
• 共享组件或核心结构变更扩大回归范围；
• 范围界定依据须书面记录并评审。

缺陷分级、修复与复测关闭

缺陷应按严重程度分级，区分影响安全有效的严重缺陷、影响主要功能的一般缺陷与界面文字类轻微缺陷。严重缺陷必须修复并复测通过后方可放行，一般缺陷需评估影响并给出处理结论，轻微缺陷可安排后续版本处理。缺陷修复后需在同一版本上复测，并确认修复未引入新问题。缺陷清单、处理结论与复测记录构成完整闭环，是审评核查的重点内容。

1. 按严重程度分级并明确处理时限；
2. 严重缺陷修复复测通过方可放行；
3. 修复后同版本复测，防止引入新问题；
4. 缺陷清单与复测记录形成闭环。

确认记录与可追溯性管理

确认的最终交付物是完整、可追溯的记录。记录应包含确认方案、用例、原始测试数据、问题记录与确认报告，并标注软件版本号与测试环境。可追溯矩阵把需求、设计、代码、测试用例与缺陷逐层关联，使任一环节的变更都能被快速定位影响范围。记录保存期限应满足法规与质量体系要求，电子记录还需具备权限控制与审计追踪。

• 确认方案、用例、原始数据与报告齐全；
• 记录需标注软件版本与测试环境；
• 建立需求到测试的可追溯矩阵；
• 电子记录具备权限控制与审计追踪。

软件确认与回归测试的本质，是用可复现的证据证明版本变更受控。企业应把影响分析与用例维护纳入日常研发流程，使测试既不过度冗余，也不留下风险盲区，从而让每个发布版本都经得起追溯与复核。

官方来源：国家药监局·医疗器械监管动态