1. 医疗软件测试体系总览
医疗软件测试与通用软件测试最大的区别，不在于测试方法本身，而在于被测对象所处的监管语境与失效后果。同样是"点击按钮返回错误结果"，在电商系统里可能只是体验问题，在放疗计划系统里可能直接导致剂量计算偏差，危及患者安全。因此，建设医疗软件测试体系的第一步，是先把"被测对象"看清楚：它是什么、属于哪一类、以什么形态存在、受哪些法规约束，然后才能决定测试体系如何分层、如何落地。
一、医疗软件的定义与判定边界
从监管视角看，医疗软件并不是"医院里用的所有软件"。以我国《医疗器械分类目录》和 IMDRF（国际医疗器械监管机构论坛）的共识为参照，医疗软件的核心判定标准是：其预期用途是否用于疾病的诊断、预防、监护、治疗、缓解或损伤的补偿。若软件仅用于医院财务结算、人事排班、一般办公协同，通常不纳入医疗器械管理；而一旦软件输出的信息被用于临床决策，例如影像重建、心电自动分析、胰岛素剂量推荐，就进入了医疗器械范畴。
这个边界对测试的直接含义是：测试证据必须能支撑"安全有效"的结论。也就是说，测试不仅要证明功能正确，还要证明风险已被识别并控制到可接受水平。这决定了医疗软件测试体系天然是"风险驱动"的，而不是"需求驱动"的简单延伸。
二、典型形态：SaMD、SiMD 与 HIT 系统
医疗软件按与硬件的关系和运行形态，通常分为三类，它们的测试重点差异明显：
- SaMD（Software as a Medical Device，独立医疗软件）：软件本身就是医疗器械，不依附于特定硬件。例如 AI 肺结节辅助诊断软件、糖尿病视网膜病变筛查软件。测试重点是算法性能（灵敏度、特异度、AUC）、数据集偏倚、版本迭代后的再验证，以及人机交互中的"医生是否会被误导"。
- SiMD（Software in a Medical Device，医疗器械中的软件）：软件嵌入在硬件设备中，是设备功能的组成部分。例如输液泵的控速固件、CT 机的图像重建模块、起搏器的参数管理软件。测试重点是软硬件接口、实时性、失效安全（fail-safe）行为，以及嵌入式环境下的资源约束。
- HIT（Health Information Technology，健康信息技术系统）：用于医疗业务管理、数据流转与临床辅助的信息系统，如 HIS、LIS、PACS、EMR。测试重点是数据完整性、接口互操作（HL7/FHIR/DICOM）、权限与审计、可用性与并发性能，以及临床工作流中的"信息是否被正确传递"。
需要强调的是，这三类并非互斥。一个 AI 辅助诊断模块（SaMD）往往需要嵌入 PACS（HIT）中调用，其输出又可能回写到 EMR。测试体系必须能覆盖这种跨形态的组合链路，否则单点测试通过、集成后仍可能出错。
三、测试体系全景：从风险到证据的闭环
医疗软件测试体系可以理解为一条"风险—需求—测试—证据—放行"的闭环链路。它的核心不是堆测试用例，而是保证每一条风险都有对应的验证活动，每一个验证活动都留下可追溯的证据。下图给出这一体系的全景结构，左侧是输入与约束，中部是测试活动分层，右侧是输出与放行判断。
这张图的关键在于右侧的"放行评审"不是终点，而是与左侧"风险管理"形成反馈回路。医疗软件的测试体系必须支持全生命周期：上市后收集到的不良事件、临床反馈、算法漂移，都要能回溯到风险清单，触发再验证。
四、建设路线：从"能测"到"测得可信"
对于多数团队，医疗软件测试体系的建设不是一步到位，而应分阶段推进。以下路线可作为参考：
- 第一阶段：建立可追溯性。把需求、风险、测试用例三者用唯一编号关联起来。哪怕一开始用表格维护，也要保证"每条风险至少有一个测试用例覆盖，每个用例能追溯到需求或风险"。这是后续所有工作的地基。
- 第二阶段：补齐分层测试能力。在单元、集成、系统三层中，至少先把接口测试和系统测试做扎实。医疗软件大量问题出在接口层：HL7 消息字段缺失、DICOM 标签错误、设备通信超时。建议为每个接口建立"正常+异常+边界"三类用例。
- 第三阶段：引入风险驱动的测试设计。根据软件安全分级（A/B/C）决定测试强度。C 级软件（可能导致死亡或严重伤害）必须做完整的单元覆盖、集成验证和系统测试；A 级可适当简化，但不可省略追溯。
- 第四阶段：建立变更控制与回归机制。任何代码变更都要做影响分析，明确回归范围。建议维护一份"变更—影响模块—回归用例"的映射表，避免每次发版都全量回归导致资源浪费，也避免漏测。
- 第五阶段：接入临床与真实世界证据。对于 SaMD 类产品，实验室测试通过不等于临床可用。需要引入回顾性数据集验证、临床场景模拟，甚至前瞻性试验，作为放行的补充证据。
五、一个具体的追溯示例
假设某输液泵软件（SiMD）中有一条风险："因流速计算错误导致输液过量"。对应的需求是"流速计算误差不超过 ±5%"，测试用例设计如下：
| 风险编号 | 需求编号 | 测试用例 | 输入条件 | 预期结果 | 判定依据 |
|---|---|---|---|---|---|
| R-012 | REQ-045 | TC-101 | 设定流速 10 mL/h，药液粘度标准 | 实测流速 9.5～10.5 mL/h | 误差 ≤ ±5% |
| R-012 | REQ-045 | TC-102 | 设定流速 10 mL/h，药液粘度偏高 | 实测流速 9.5～10.5 mL/h 或触发报警 | 误差 ≤ ±5% 或安全报警 |
| R-012 | REQ-045 | TC-103 | 电池电压降至 3.3 V（低电量边界） | 流速仍达标或进入安全停机 | 失效安全行为 |
这个例子说明：医疗软件测试用例的判定依据不能只写"功能正常"，而要写可量化的接受标准或明确的安全行为。这也是医疗软件测试与普通软件测试在用例设计层面最直观的差异。
总结来看，医疗软件测试体系的建设，本质上是把"风险—需求—测试—证据—放行"这条链路打通并持续运转。理解 SaMD、SiMD、HIT 三类形态的差异，是为了在测试设计时抓住各自的要害；理解全景图，是为了知道自己在哪个环节、缺什么证据；理解建设路线，是为了避免一开始就追求大而全，而是从追溯性这个最小内核开始，逐步长出完整的测试能力。