医疗器械软件更新了，测试报告还能接着用吗

先别急着改报告上的版本号

不妨假设一个图像查看软件，原来只能按时间排序，现在增加按检查类型筛选。研发说，没有改图像处理算法，只是多了一个筛选入口。

这个描述有帮助，但还不够。筛选后会不会打开另一份检查？原来的排序逻辑有没有被共用代码影响？列表为空、记录缺失时，界面怎样提醒？如果新入口还调用了旧模块，影响就未必停在一个按钮上。

这里不是说加按钮一定危险，而是想提醒你：变化的大小，不能只按改了几行代码来算。

我会请研发把“改了什么”说成别人能核对的内容：需求哪一项变了，涉及什么模块和接口，哪些配置跟着调整，原有功能为什么认为不受影响。无需写成厚材料，但不能只有一句“功能优化”。

旧测试报告上的版本、环境和日期，先保留原样。那是当时发生过的工作。把封面改成新版本，并不会让新软件自动经历那次测试，反而把原本有用的历史证据弄模糊了。

不妨给旧证据分三个去向

第一种，是准备继续引用的证据。比如某项功能没有变化，关联接口、运行条件和判定依据也没有变化，团队经过评估，认为原有结果仍能支持这部分判断。

注意，这里关键的不是“没改”，而是“为什么没有受到影响”。我会把引用哪份报告、适用到哪里、评估依据是什么一起留下，让下一个接手的人不用重新猜。

第二种，是需要补测的证据。变化本身要验证，受到牵连的旧功能也可能需要再看一遍。回归测试说得直白些，就是把原来正常的相关功能再跑一遍，看看修改有没有带来意料之外的变化。

第三种，是只能保留作历史记录的证据。测试环境已经不同，原先的需求已经撤销，或者找不到当时实际测试的安装包，再把它当作当前结论的直接依据，就很勉强了。

这三个去向是我的整理建议，不是法规规定的三种报告类型。它的用处，是让大家不再围着“整份能不能用”争论，而是逐项讨论证据的适用范围。

还有一种情况先别硬分：信息不够。比如外购组件升级了，却拿不到变更说明。这时可以写“待确认”，明确找谁补资料；不要因为项目赶时间，就把不知道填成没有影响。

看指导文件时，也要看清它管什么

美国 FDA 的器械软件功能上市前提交资料指导文件，在测试资料部分建议说明被测版本、变更及补充测试，并通过回归分析判断是否需要回归测试、需要运行哪些测试。版本历史还应说明测试版本与发布版本的差异及其潜在影响。

这给咱们一个很实在的提醒：测试结果需要和具体版本连在一起，变更也需要有说得通的评估。

但这份文件针对美国 FDA 上市前申报，属于指导性建议，不能直接当作中国注册要求，更不是一张“旧报告通用许可证”。国内项目仍要回到适用的中国要求和产品实际情况判断。本文谈的是证据怎么整理，不替具体产品决定申报路径。

如果项目确实面向美国，也别只下载旧文件就往下做。FDA 当前官网的这份文件前面已加上提示：应结合现行 QMSR 核对质量管理要求。这里引用的是测试资料与版本记录建议，不是把旧质量体系条文搬来当现行依据。

下一次版本评审，可以这样谈：把新旧版本和相关报告同时摆到桌面上，先选一处具体变化谈透。

请研发说明改动和可能牵连的地方；请测试同事说明哪些用例能覆盖、哪些环境与实际发布不一致；请质量和注册同事把证据要求、产品风险以及申报资料的对应关系补进来。

会议不必承诺“今天把所有问题解决”。至少留下四件明确的事：这次变化是什么，影响判断的依据在哪里，哪些测试要补，完成后由谁核对发布版本与证据。

如果软件仍在快速迭代，我还会单独约定一个准备交付的版本。它不是永远不能改，而是后续每次变化都要能看见。否则测试追着研发跑，报告追着测试跑，最后大家手里都有文件，却不是同一个产品状态。

补测之后也别只收一个“通过”。看看失败项怎么处理、重新测试对应哪个版本、还有哪些异常未解决。把结论落在真实记录上，比给文件名加一个“最终版”更让人踏实。

对于准备不再重复的测试，也值得留一句完整理由。不是写“以前测过”，而是说明原来验证的要求仍然成立、相关条件如何保持一致。理由写不出来时，先补充调查，往往比仓促选择全测或者不测更有帮助。

至于旧报告，保留好原件，再用清楚的引用把它放回证据链中。哪些继续支持判断，哪些已被新结果替代，哪些只供查历史，读者应当一眼找得到。

软件更新后，珍惜已经做过的测试没有错。咱们要省的，是没有理由的重复劳动；但该补上的依据，也值得认真补上。

这样再回答“报告还能不能用”，就不用靠胆子大不大，而是能说明：这部分为什么能用，那部分还差什么。