1. 医疗软件回归测试平台工程导论

医疗软件与普通消费软件最大的区别，在于它的失效后果往往直接作用于患者。输液泵的流速计算偏差、影像后处理软件对病灶尺寸的误判、检验结果审核规则被错误放宽，都可能从"一个缺陷"演变为"一次临床风险"。因此，医疗软件的质量要求不是"功能可用"这么简单，而是要在安全性、有效性、可追溯性三条主线上同时成立。安全性要求软件在异常输入、异常状态和异常操作下不产生危害；有效性要求软件在声称的适应范围内确实达到预期临床用途；可追溯性要求从需求、设计、代码、测试到缺陷的每一条链路都能被审计复现。这三条主线共同决定了：医疗软件的每一次修改，都必须回答"改了什么、影响了什么、验证到什么程度"。

回归测试正是回答这个问题的核心手段。它的定义可以概括为：在软件发生变更后，重新执行一组经过选择的测试，以确认原有功能未被破坏、且变更本身达到预期目标的过程。这里有两个关键词容易被忽略——"经过选择"和"原有功能"。回归测试不是把全部用例再跑一遍，而是在有限的时间和算力下，挑选出最可能受变更影响、且风险最高的那部分用例。它的价值也不止于"发现回归缺陷"：在医疗软件中，回归测试同时承担着变更影响分析的验证、法规符合性证据的生成、以及发布决策的支撑三重作用。一次规范的回归，其测试记录本身就是注册申报和体系审核中的客观证据。

然而，当产品线从单一设备扩展到多型号、多版本、多法规区域时，回归测试会迅速遇到瓶颈。典型表现是：用例数量随版本线性增长，而执行时间、环境准备时间和人工判读时间呈超线性增长；同一份用例在不同型号上需要手工改写；测试结果散落在个人电脑和邮件里，无法回答"这个版本到底测了什么、没测什么"。平台工程化的目标，就是把这些重复、易错、依赖个人经验的环节，转化为可配置、可复用、可度量、可审计的工程能力。具体而言，平台需要提供四类能力：用例与需求的关联管理、测试环境的自动化编排、测试执行与结果采集的标准化、以及质量数据的持续可视化。

上图把本节的核心逻辑串成了一条链：左侧是医疗软件的质量约束，中间是平台需要建设的能力，右侧是课程的学习路径，底部则是回归测试从变更触发到发布决策的完整闭环。可以看到，平台工程化并不是简单地"买一套测试管理工具"，而是围绕变更—影响—选择—执行—决策这条主线，把每个环节的输入、输出和判断依据都定义清楚。

以影响分析为例，实际工作中可以这样操作：假设某输液泵软件修改了"流速计算"模块中的舍入逻辑，从四舍五入改为银行家舍入。影响分析需要沿着三条路径展开——第一条是代码调用链，查看哪些函数直接或间接调用了该舍入函数；第二条是需求追溯链，找到与该计算相关的需求条目及其关联用例；第三条是风险链，判断该变更是否触及安全相关等级。三条路径的交集，就是本轮回归必须覆盖的最小用例集。如果平台已经建立了用例与需求的关联关系，这一步可以从"人工翻文档"变成"系统自动列出候选集"，再由测试工程师确认和补充。

再看执行与采集环节。医疗软件的回归测试往往需要同时覆盖多个型号和多个法规区域版本。例如同一套输液泵产品，可能有面向不同市场的固件分支，其差异仅在于报警阈值和单位显示。平台化之后，测试用例可以参数化：把"报警阈值"和"单位制式"抽成配置项，同一份用例脚本在不同配置下自动生成对应的执行实例。执行结果统一采集为结构化记录，包含用例编号、关联需求、执行环境、输入参数、实际输出、判定结果和证据附件。这样，当审核人员问"这个版本的高优先级用例通过率是多少"时，平台可以直接给出答案，而不是靠人工汇总。