2. 医疗软件法规与标准对回归测试的约束

医疗软件的回归测试不是普通软件“改完再跑一遍”的自选动作，而是被法规和标准层层约束的合规活动。IEC 62304、FDA 指南、NMPA 要求、ISO 13485 以及可追溯性要求，共同决定了回归测试“为什么做、做到什么程度、留下什么证据”。理解这些约束的差异与叠加关系，是设计回归测试平台的前提。

各法规标准的约束定位

IEC 62304 是医疗器械软件生命周期过程标准，它把软件按 A、B、C 三个安全分级管理。回归测试在其中的核心约束是：软件变更后必须进行影响分析，并基于分析结果确定回归范围。标准并不要求“全量重测”，但要求你能证明“未测的部分确实不受影响”。安全级别越高，对变更影响分析和验证充分性的要求越严。

FDA 的指南（如《General Principles of Software Validation》及 510(k) 相关软件文档指南）强调验证活动应覆盖需求、风险与测试之间的对应关系。对于回归测试，FDA 关注的是：变更是否引入了新的风险、原有风险控制措施是否仍然有效、测试证据是否可审查。FDA 不规定具体测试工具，但要求证据链完整、可复现。

NMPA 的要求体现在《医疗器械软件注册审查指导原则》等文件中，强调软件研究资料应包含版本变更、验证与确认记录。对境内注册产品，回归测试记录需要能支撑“变更后软件仍满足安全有效要求”的结论，且中文记录、签批流程、版本标识需符合国内质量体系习惯。

ISO 13485 是质量管理体系标准，它不直接规定测试技术，而是要求组织对设计变更实施控制，确保变更经过评审、验证和确认，并保留记录。回归测试在 ISO 13485 视角下是“设计变更控制”的一个执行环节，必须纳入受控流程。

可追溯性与证据留存：约束的落地形式

上述标准最终都收敛到两个可操作要求：可追溯性和测试证据留存。可追溯性要求建立“需求—风险—测试用例—测试结果—变更”之间的双向链接。当一次变更发生时，平台应能沿链接快速定位受影响的需求和风险，进而确定回归测试集。证据留存则要求测试执行记录、环境信息、版本信息、执行人、时间戳、结果判定都可归档、可检索、可重现。

在实际平台设计中，这意味着回归测试不能只保存“通过/失败”，还要保存：被测软件版本、测试用例版本、测试环境快照、输入数据、预期结果、实际结果、执行日志。对于安全级别 B、C 的软件，还应保留评审与批准记录。

回归范围如何被约束决定

法规标准并不直接给出“测哪些用例”，而是通过影响分析间接约束回归范围。一个可操作的判断逻辑是：变更点 → 受影响的需求 → 关联的风险控制措施 → 覆盖这些需求的测试用例 → 回归测试集。如果变更涉及安全级别 C 的软件项，或涉及风险控制措施的实现，回归范围应覆盖到该风险控制措施的全部验证用例，而不能只测变更点本身。

举例说明（以下为教学示例，非实测数据）：某输液泵软件将“阻塞报警阈值”从 80 kPa 调整为 70 kPa。影响分析发现：该变更关联需求 REQ-ALM-012（阻塞报警触发），关联风险 RISK-003（阻塞未及时报警导致伤害），覆盖该需求的测试用例为 TC-045 至 TC-052。按 IEC 62304 对 B 级软件的要求，回归集至少应包含 TC-045 至 TC-052，并补充边界值用例 TC-053（阈值 69/70/71 kPa）。若该变更还改动了报警声音文件，则需追加音频输出相关用例。

证据留存的实际字段设计

为了让证据在 FDA 或 NMPA 审查时可被接受，回归测试平台的一条执行记录通常应包含以下字段。这些字段不是凭空设计，而是从“可重现”和“可追溯”两个要求反推出来的：

不同标准对回归测试的约束差异

IEC 62304 更偏“过程合规”，关注你是否按安全级别执行了影响分析和验证；FDA 更偏“证据充分性”，关注你能否证明变更后风险仍受控；NMPA 更偏“注册资料一致性”，关注变更是否在注册申报范围内、记录是否符合国内体系；ISO 13485 更偏“变更控制流程”，关注变更是否经过评审、批准和验证。四者叠加后，回归测试平台需要同时满足：过程可审计、证据可重现、记录可签批、变更可追溯。

落到平台实现上，建议把“变更单”作为回归测试的触发入口：变更单中记录变更描述、影响分析结论、关联需求与风险、确定的回归用例集；平台据此生成回归任务，执行后自动回写结果并生成归档包。这样，法规约束就不再是外部检查项，而是内嵌到回归测试流程中的数据结构和状态流转。