企业官网建设流程全解析

医疗影像诊断AI的容错测试，最近几年在软件测试圈子里讨论得越来越多。倒不是因为它时髦，而是因为这类系统一旦在异常输入面前"翻车"，带来的后果往往不是线上告警能兜住的——一张对照度异常的CT、一段被压缩算法破坏的X光序列、一次GPU显存抖动，都可能让模型输出一个与临床事实相悖的结论。作为软件测试从业者，如果我们还用老一套"功能用例+边界值+异常提示"的思路去覆盖这类系统，几乎一定会漏掉真正致命的问题。

这篇文章想分享的，是我们在医疗影像诊断AI项目里积累下来的容错测试实战经验。它不是什么理论框架，而是从数据准备、扰动注入、故障模拟到结果度量的完整测试路径，适合正在或即将接触医疗AI测试的QA工程师、测试开发，以及需要为这类系统设计验证方案的从业者。你不需要懂很深的数据科学，但你需要理解"让模型面对坏输入时不乱说话"这件事，本质上是一个系统工程问题。

1. 医疗影像AI容错测试：先搞清楚它在测什么

1.1 容错测试的边界与定位

容错测试和常规功能测试有个本质区别。功能测试回答的是"系统在正确输入下，功能是否按预期工作"，而容错测试回答的是"系统在非预期、异常、甚至恶意输入下，是否仍然能维持可用性、安全性和可解释性"。

对普通互联网应用，容错测试做到"不崩、不死、能降级、能恢复"就够了。但对医疗影像诊断AI，容错测试的边界必须往前推一大步——它不仅要求系统"不崩溃"，还要求系统在输入异常时，输出的结果仍然在医学上可信、可解释、可审查。这就是医疗场景容错测试最特殊的地方：崩溃不是最坏的结果，最坏的结果是在病态输入下依然煞有介事地给出一个错误诊断结论。

我在实际项目中见过一个典型案例。某个肺结节检测模型，对一张带有强高斯噪声的胸部CT图像输出了一段"自信满满"的检测框和恶性概率评分，置信度高达0.94。后来人工复核才发现，那一刻GPU显存异常导致图像预处理管线在resize阶段静默失败，喂给模型的是一张几乎完全失真的图像。模型没有报错，它只是诚实地做了它最擅长的事——把任何输入映射成一个医学结论。

容错测试在医疗AI里的定位，就是专门针对这类"得体但不正确"的行为做系统性探测。它不替代功能测试，也不替代性能测试，而是在两者之外建立一套专门的防线，覆盖"输入不合法时系统怎么表现""推理环境发生故障时系统怎么表现""模型面对分布外数据时怎么表现"三类核心问题。

1.2 医疗场景的容错为何与众不同

在医疗影像领域，"异常输入"的形态比普通软件丰富得多。普通软件遇到异常输入，通常是格式不对、字段缺失、类型不符、长度超限，这些好排查也好处理。医疗影像AI的输入是医学图像，它的异常形态覆盖了从底层硬件到医学语义的整个光谱：

• DICOM文件本身损坏，或关键Tag缺失（比如窗宽窗位、像素间距、成像模态）。
• 图像来自不同厂商的设备，像素值范围、位深度、体素间距差异极大。
• 患者体型、摆位、扫描协议不同，导致器官位置和形态分布偏移。
• 图像中存在运动伪影、金属植入物伪影、重建算法产生的伪影。
• 图像被传输、转码、压缩后，出现不可见的像素级退化。

这些异常中，有些是系统故障，有些是数据噪声，有些是临床真实世界中每天都在发生的正常变体。真正的挑战在于，测试人员很难在项目早期就枚举出所有这些形态，更难以预判模型会在哪一类异常上给出高危的错误输出。

还有一层医疗AI特殊的约束：诊断结果必须可追溯。普通系统容错测试关注"系统能否恢复"，医疗AI容错测试还关注"异常发生时，系统是否留下了足够的过程日志，让医生或产品团队能判断这个结果可不可信"。很多模型推理框架默认只记录输入输出的缩略信息，一旦出现容错事故，连"当时喂给模型的是什么"都无从查证。这个问题，测试人员在设计容错用例时就必须考虑进去，等上线后再补，代价会大得多。

1.3 三个层次的容错目标

在我们团队的测试实践中，医疗影像AI的容错测试目标被拆成三个层次，每一层都有独立的测试侧重和方法：

输入数据层容错。目标是不合法、不完整、被污染、超出约定范围的图像输入不会导致系统崩溃、挂死、产生无意义输出。这一层主要用异常样本、扰动注入、变异测试来驱动。典型问题：DICOM损坏时解析器会不会抛异常并被上层捕获？图像尺寸不符时代码会不会直接段错误？像素值全为零的动态范围会不会导致模型输出NaN？

推理过程层容错。目标是模型推理过程中，外部环境波动或资源受限不会引发静默错误。GPU显存不足、CUDA报错、推理超时、并发请求打满显存、模型权重文件被误替换成不匹配版本，都属于这一层的测试范围。核心诉求是"错误要显性化"，不能让异常被吞掉然后继续输出不可信结果。

结果输出层容错。目标是模型面对分布外数据或经过扰动、伪造的输入时，输出结果的置信度、边界框、分割区域仍然保持合理，或者能够明确表达"我无法给出可信结论"。这一层是医疗AI容错测试最有技术难度的部分，因为模型没有一个开关能告诉你"它不确定"，测试人员必须通过置信度校准、OOD检测、对比测试等方式去把"没有自信"的信号挖掘出来。

测试设计时，这三个层次不要混在一起做。它们对用例组织、数据要求、缺陷定级标准的影响都不同，混为一个池子会让测试结果失去可分析性。

2. 测试数据与扰动设计：先学会制造"坏输入"

2.1 DICOM影像基础：容错测试的起点

做医疗影像AI的容错测试，绕不开DICOM格式。DICOM既不是纯图像格式，也不是纯元数据格式，而是把医学图像和结构化元数据封装在一起的标准容器。一张DICOM文件里，像素数据可能只占一半体积，另一半是大量描述采集设备、患者信息、成像参数、序列信息的Tag。

容错测试必须覆盖DICOM的两个组成部分。像素数据方面，测试人员要关注位深度（8位、12位、16位）、PhotometricInterpretation（灰度还是彩色）、存储格式（原生还是JPEG压缩）、像素间距（PixelSpacing）造成的信息差异。元数据方面，要重点关注那些"模型推理间接依赖但不直接显示"的Tag，比如：

• WindowCenter和WindowWidth：影响显示和预处理结果。
• RescaleIntercept和RescaleSlope：把存储值转成真实物理值的关键。
• SeriesInstanceUID、StudyInstanceUID：影响数据溯源和多序列关联。
• ImagePositionPatient、ImageOrientationPatient：影响空间配准和3D重建。

很多容错事故的根本原因不在像素本身，而在这些元数据的缺失或错误。比如某次测试中，肝分割模型对一批新影像的Dice系数骤降，排查到最后发现是上游PACS系统在导出时把RescaleSlope写成了1.0，但实际数据需要乘以8才能还原为真实的HU值。这类问题，容错测试如果不专门针对DICOM元数据设计用例，几乎不可能提前暴露。

2.2 数据集的来源与扩充策略

容错测试的数据集不能直接用模型训练集的一部分来充当。训练集是"好数据"，容错测试需要的是"坏数据"和"边缘数据"。我们实际使用时把容错测试数据分成三类：

第一类是公开数据集中的挑战样本。一些公开的医学影像数据集里自带质量标注或伪影样本，比如带有运动伪影的CT采集、不同剂量水平的重建图像。这些样本的优点是贴近真实临床退化模式，缺点是覆盖面有限。

第二类是脱敏的真实业务数据。如果条件允许，从实际业务链路中抽取那些曾经被医生退回、被质控拦截、被标注人员标记为"难以判读"的影像数据，这些往往是容错测试的宝藏。这类数据严格脱敏后，能真实反映产品上线后会遇到的输入形态。

第三类是人工构造的合成扰动数据。在干净数据基础上，我们主动施加噪声、模糊、压缩、几何变换、异常插值等扰动，覆盖模型可能遇到的各种退化模式。合成数据的最大价值在于可控——你知道原始图像是什么，可以精确评估扰动到什么程度模型开始不可信。

实际项目中，这三类数据的比例通常是公开样本20%、真实脱敏数据30%、合成扰动数据50%。合成扰动数据的占比最大不是因为它最重要，而是因为它最容易参数化、最适合做批量化测试用例。

三类重点补充的扰动类型包括：高斯噪声和斑点噪声（模拟低剂量采集）、高斯模糊和运动模糊（模拟呼吸/心跳运动）、JPEG有损压缩（模拟传输转码退化）、对比度拉伸和窗宽窗位偏移（模拟不同阅片设备的预处理差异）。每类扰动还要设置多个强度档位，不能只测一个"差不多"的强度——容错能力往往是在某些强度档位突然崩溃的。

2.3 扰动注入参数的确定方法

扰动参数怎么定，是容错测试实操中最需要经验和判断力的环节。定得太轻，测试过了但实际风险没暴露；定得太重，模型全员崩溃，对评估没有任何指导意义。

我们的做法是把扰动强度锚定在原始数据的可识别性上，而不是随便选一个数学参数。以高斯噪声为例，不同噪声强度在图像上造成的退化感知差异很大，同样的标准差在软组织窗和骨窗上看起来完全不同。一种可靠的方法是"视觉锚定法"：让两名以上有医学影像读图经验的人员对扰动后的图像进行可判读性评分，找到"人类仍然能判断大致结构"和"人类已经无法确认关键结构"的中间强度档位，以这个区间作为主要测试档位，再向两边扩展1-2档。

对于窗宽窗位类扰动，参数的确定逻辑要更贴近临床。医生阅片是有固定习惯的，肺窗、纵隔窗、骨窗有明确的窗宽窗位范围。容错测试时不能只测"非常规范围"，还要测"常规范围内但偏离模型训练分布"的情况，选一个宽泛的映射：比如把窗宽设为标准值的80%、120%、150%，窗位同样做偏移，观察模型对同一图像在不同显示参数下的结果一致性。

具体参数上，可直接参考的几种扰动配置如下：

扰动注入不是一次性的。我们在测试周期内会对同一批扰动样本做多次注入，每次随机种子不同，以覆盖"同参数不同实例"的随机性。这能有效避免一个常见陷阱：某些模型对特定一幅图的噪声特别敏感，换个实例就恢复稳定——如果只测一次，你会被单样本的偶然性愚弄。

3. 核心容错场景与实操用例

3.1 图像格式与元数据异常测试

格式与元数据异常测试的核心目标是确保系统对"不规范的输入"有明确的处理路径，而不是让异常在系统深处静默蔓延。

这类测试首先要做的是DICOM文件损坏模拟。我们会在测试目录里准备一整套"坏文件库"，每个文件都是通过程序化方式破坏的：截断文件尾部、清空像素数据区、篡改DICOM头长度字段、把压缩标志位改成未压缩但数据体仍是压缩数据。对每一类破坏方式，分别验证三层行为：文件解析层是否正确抛出错误、服务层是否正确捕获并转为业务错误、调用方是否收到清晰可理解的错误响应而不是一个空结果或500。

元数据缺失测试同样重要。用pydicom读取一个正常DICOM文件后，你可以删除特定Tag再保存为新文件。需要覆盖的删除项包括：PixelSpacing、RescaleSlope/Intercept、WindowCenter/WindowWidth、SOPInstanceUID、Modality。其中Modality的缺失特别容易被忽略——很多模型在预处理阶段区分CT和MR，如果Modality缺失而代码用了get(key, "CT")这类默认值，会导致一系列下游处理步骤在错误的前提假设下工作。

还有一类比较容易踩坑的情况是像素数据与元数据声明不一致。比如声明是8位灰度但实际像素数据里混杂了非预期值，声明是单帧却混入了多帧数据。这类不一致往往不会被解析器拦截，而是会直接导致后续处理阶段出现难以定位的数值异常。

针对格式和元数据异常，测试用例的组织建议按"异常注入位置"和"系统故障层"做矩阵，在报告中明确每个用例对应的系统路径。这会让开发团队定位问题快很多，容错测试组成员也不必在开发追问"这用例到底触发在哪一层"时含糊其词。

3.2 图像退化扰动测试：噪声、模糊与压缩

图像退化扰动测试是容错测试里最容易批量化、也最能量化的部分。这类测试回答一个问题：随着图像质量逐步下降，模型输出的准确性和可信度以什么趋势衰减？

我们团队的实践经验是，这类测试必须先建基线，再拉曲线。没有基线的退化测试是无效的。基线的含义是：在干净的原始数据集上跑一遍模型，记录每个样本的检测结果、分类概率或分割指标。随后对同一批样本做不同强度和类型的扰动，再跑一遍模型，计算与基线之间的差异。

关键观测指标有几个维度。第一是硬标签翻转率——即扰动后模型的最终诊断结论发生翻转的样本比例。第二是置信度退缩率——模型输出概率值在扰动前后的变化幅度。第三是几何稳定性——同一病灶在轻微扰动下，检测框的中心点、尺寸、分割边界是否发生剧烈漂移。

在具体操作上，一个强烈建议的做法是按扰动强度绘制模型性能退化曲线。比如在5个噪声强度档位上分别计算模型AUC或F1分数，可以得到一条曲线。曲线平缓下降，说明模型容错能力强；曲线在某档位出现断崖式掉落，说明模型对该类扰动存在临界脆弱点，这个点就是测试报告中最有价值的信息。

压缩扰动测试要特别注意和传输链路结合。很多医疗影像在院内传输时会经过网关转换或压缩，像素域已经发生变化。我们实际测试中发现，某些模型对JPEG质量因子为70的压缩不敏感，但质量因子降到50时，细小的钙化灶检出率直接掉了一半。这种非线性退化如果不在测试中主动暴露，上线后会以真实病例的形式暴露，那就不是性能问题了。

3.3 几何变换与空间一致性测试

医学影像对空间信息极其敏感。与自然图像不同，CT和MR图像中的解剖结构位置、方向、尺度都具有严格的临床意义。几何变换容错测试的目的，是验证模型在图像发生平移、旋转、翻转、重塑时，输出结果是否依然在物理空间中保持一致。

我们团队常用的三组测试分别是：镜像翻转一致性、小角度旋转稳定性、尺度缩放鲁棒性。

镜像翻转测试的做法比较直接——将图像进行左右翻转，等于模拟了体位或采集方向的左右互换。对于很多分类模型，输出标签本来就不应该因翻转而改变；对于分割和检测模型，输出结果则必须进行相应的空间映射后再比较。这两类模型的一致性判定规则不同，测试用例的断言必须分别实现。

小角度旋转稳定性的实操细节在于旋转后引入的边缘填充会改变图像统计分布。如果用零填充，旋转后图像的四个角落变成黑色区域，模型可能会学习到"黑角=某种信号"的虚假关联。更合理的做法是使用反射填充或边缘值填充，并在用例中记录填充方式，以便复现。

尺度缩放测试有个容易忽略的点——医学图像的原生像素间距差异。同一台设备采集的CT图像，若重建时的像素间距不同，肝脏尺寸的实际物理大小就会有差异。模型如果对这类缩放敏感，跨设备的泛化能力就会出问题。我们在实测中发现一个分割模型在像素间距从0.7mm改成1.4mm后（图像尺寸通过resize保持一致），分割结果偏移严重，直到测试报告出来后大家才意识到问题不在模型结构，而在预处理插值方式上。

3.4 分布外数据与置信度校准测试

分布外数据（Out-of-Distribution，简称OOD）测试，在医疗影像AI的容错测试里地位特殊。通俗地说，就是拿"模型训练时从没见过的类型的影像"去喂它，看它是否知道"自己不知道"。

我在项目中一直强调一个观点：分布外数据测试测试的不是模型性能，而是模型的"自我认知"。对于诊断AI来说，一个能力平庸但知道自己局限的模型，远比一个能力不错但无限自信的模型安全得多。

实操中，OOD样本比很多人想象的要容易获取。你把CT训练好的模型拿去跑一批MR数据，或者把肺部影像训练的模型拿去跑一组乳腺钼靶影像，这些跨模态数据就是最典型的分布外样本。还有更隐蔽的分布外类型——比如训练集全部来自西门子设备，你拿一批GE设备的正常肺部CT做测试，虽然医学模态相同，设备风格差异也可能让模型产生严重的分布偏移。

分布外测试的重点不是标题中"模型对分布外数据输出什么"，而是"模型是否以某种方式表达不确定性"。衡量这种不确定性的方法有两种。第一种是置信度校准度——模型给出的概率值是否真实反映实际正确率。理论校准曲线如果严重偏离对角线，通常意味着模型根本不知道自己在说什么。第二种是低置信度样本的覆盖密度——分布外输入是否会导致置信度分布整体下移，还是模型依然给出高置信度输出。后一种情况如果出现，就是典型的"盲目自信"，需要列为高优先级缺陷。

在测试设计中，我们会在OOD数据集上额外统计一个指标：非诊断决策率。这里需要产品侧定义一个策略——当模型拒绝给出结论时，系统应该返回"无法分析"并触发人工复核流程。容错测试的目的就是确认这个策略在异常输入下能被正确触发，而不是让模型在分布外数据上还硬要给一个诊断倾向。

3.5 对抗样本与极端输入的容错

对抗样本测试是容错测试中技术含量最高、也最容易被轻视的部分。很多人觉得对抗攻击是纯学术界的概念，在实际医疗AI系统里不会出现。但在我们的测试经验里，即使是无关攻击的普通扰动，只要刻意让像素值发生微小而定向的变化，同样能使模型在个别样本上产生完全错误的结论。这类"手滑级的对抗扰动"在医疗影像链路上出现的概率并不低——图像传输中的单点比特翻转、压缩解码时像素值的轻微偏移，在数学上与低强度对抗扰动非常相似。

考虑到医疗场景的特殊性，我们没有直接要求模型对强对抗攻击全面免疫——这是不现实的。我们设计了一套渐进式的对抗容错测试策略：

第一档是对比度扰动和模糊扰动，已有公开攻击算法可以直接使用，用随机梯度方向的低强度扰动来验证模型是否对微小像素变化过度敏感。第二档是带约束的定向扰动，扰动强度限制在最差情况下人眼不易察觉的范围内，评估在这样微小的扰动下模型的决策边界是否被破坏。第三档是边界检测攻击，用它定位模型的"决策不连续区域"——哪些图像在极小扰动下会产生剧烈输出变化，这些区域往往是容错设计的薄弱点。

值得强调的是，对抗样本测试的结果不一定直接要求开发团队修模型。更多时候，它帮助产品团队认识到需要在推理链路前增加输入质量检测、对抗预处理和输出一致性校验，从系统层面对抗这类风险。这类系统层的防御往往比单纯提升模型鲁棒性更有效、更可控。

3.6 系统级故障注入与资源容错

模型层面的容错测试之外，系统级容错测试绝不能省略。AI服务是一个完整的软件链路，图像输入的点火、预处理、推理、后处理、结果持久化，任何一环故障都会影响最终诊断结果。系统级故障注入测试的目标是回答：中间环节出问题后，错误是显性地暴露，还是被系统吞掉形成隐性错误？

我们在实际项目中重点做了四类系统级故障注入：

GPU显存不足模拟。通过并发请求把显存打满，观察推理进程是报CUDA OOM错误并重试，还是静默降级到某种状态继续输出不可信结果。这类测试特别能发现"异常吞掉"问题——有些推理框架在显存不足时无法抛出明确错误，而是产生一个"全零输出"或"旧结果复用"。

模型加载与版本替换故障。测试过程中替换模型文件为错误版本、不完整版本、shape不匹配版本，验证推理服务是否会加载失败并回退到上一版本，或至少在告警中明确提示。这里特别关注的是"热加载"逻辑，很多AI服务支持模型热更新，替换过程中的任何不完整加载都不应该产生一次性错误结果。

预处理管线故障注入。在图像解码、resize、归一化、窗宽窗位映射的每个环节注入延迟或错误，观察错误是会被捕获并重试，还是成为下游模型的"脏输入"。这一层最容易出现问题，也是普通测试人员最容易忽略的。

推理超时与重复请求。模拟单次推理耗时超过预设阈值时，服务是否做了超时控制，是否对重复请求做了幂等处理，是否会因为并发重复请求导致同一影像被重复诊断而产生费用和资源浪费。

系统级故障注入测试要特别注意清理测试痕迹。最稳妥的实践是在独立的测试环境做，并确保故障注入后系统能恢复到基线状态，别把测试环境搞脏导致后续测试结果失真。

4. 工具链与代码实践：一套可复用的测试脚手架

4.1 测试框架选型与项目结构

容错测试的工程化水平，直接决定它能不能在项目里持续迭代。医疗影像AI容错测试依赖pytest作为基础测试框架，配合pydicom做DICOM处理、OpenCV和NumPy做图像扰动、TorchMetrics做模型指标计算，再辅以一套自研的服务探针工具做系统级故障注入。整套脚手架的结构可以按下面的方式组织：

medical_ai_fault_test/ ├── data/ │ ├── baseline/ # 基线数据集（干净样本） │ ├── dict_anomaly/ # DICOM元数据损坏样本 │ ├── degraded/ # 图像退化样本 │ └── ood/ # 分布外数据样本 ├── injectors/ # 扰动注入模块 │ ├── noise_injector.py │ ├── blur_injector.py │ ├── compression_injector.py │ └── geometry_injector.py ├── checks/ # 结果断言与指标计算 │ ├── stability_check.py │ ├── confidence_check.py │ └── spatial_check.py ├── infra_fault/ # 系统级故障注入探针 │ └── gpu_normal_mode.py ├── tests/ │ ├── test_dicom_anomaly.py │ ├── test_image_degradation.py │ ├── test_geometry_stability.py │ ├── test_ood_confidence.py │ └── test_system_fault.py └── reports/ # 输出报告与退化曲线

这个结构的核心设计思路是：注入器只负责制造坏输入，检查器只负责判定结果好坏，测试用例只负责编排两者的关系。这样分层之后，新增一种扰动类型不需要大改测试逻辑，新增一种判定规则也不需要动注入器。

pytest本身原生支持参数化，非常适合做"多个样本X多个扰动档位"的批量测试。配合pytest-xdist做并行执行，容错测试的批量耗时可以压缩到一个可接受的区间。

4.2 关键测试用例代码实现

第一类核心用例是DICOM元数据异常测试。用pydicom读取正常文件，删除关键Tag后保存为异常文件，再调用待测系统处理接口，断言返回的错误类型或降级行为。关键代码如下：

import pydicom import pytest from pathlib import Path def make_tag_missing_dicom(src_path: Path, dst_path: Path, tag: str): ds = pydicom.dcmread(str(src_path)) if tag in ds: del ds[tag] ds.save_as(str(dst_path)) @pytest.mark.parametrize("tag", [ "PixelSpacing", "RescaleSlope", "WindowCenter", "Modality", "SOPInstanceUID", ]) def test_dicom_missing_tag(tag, baseline_ct_path, tmp_path, inference_client): bad_file = tmp_path / f"missing_{tag}.dcm" make_tag_missing_dicom(baseline_ct_path, bad_file, tag) resp = inference_client.predict(str(bad_file)) assert resp.http_status == 200 assert resp.business_code == "INVALID_INPUT_META" assert resp.process_logs is not None

这里断言的重点不是"系统必须拒绝输入"，而是"系统返回了结构化、明确、可追踪的业务错误"。允许业务上走降级或默认值逻辑，但必须有日志和标识。

第二类核心用例是图像退化参数化测试。我们在注入器中封装了AddNoise、AddBlur等操作，便于多档位批量执行。

import numpy as np from injectors.noise_injector import gaussian_noise def test_noise_degradation_trend(baseline_ct_image, model_client): clean_probs = model_client.predict(baseline_ct_image) results = [] for sigma in [0.02, 0.05, 0.08, 0.12]: noisy = gaussian_noise(baseline_ct_image, sigma=sigma) probs = model_client.predict(noisy) results.append({ "sigma": sigma, "label_flipped": int(np.argmax(clean_probs) != np.argmax(probs)), "confidence_change": float(clean_probs.max() - probs.max()), "bbox_shift_px": model_client.get_bbox_shift(), }) # 记录趋势，供报告生成 return results

第三类核心用例是系统级故障注入。GPU显存打满后请求推理服务的核心代码如下：

import torch import threading import pytest def allocate_gpu_memory(fraction: float): dummy = torch.empty( int(torch.cuda.mem_get_info()[1] * fraction), dtype=torch.uint8, device="cuda" ) return dummy def test_gpu_oom_fault_injection(baseline_ct_image, inference_service): blocker = allocate_gpu_memory(0.85) try: resp = inference_service.predict(baseline_ct_image) # 容错要求：OOM时必须显式报错，不能返回空结果 assert resp.http_status in (429, 503) assert resp.error_category == "RESOURCE_EXHAUSTED" finally: del blocker torch.cuda.empty_cache()

这个用例的核心目的，是逼着系统在资源耗尽时走显式的告警分支，而不是静默产生错误结果。

实际执行时，故障注入会破坏服务状态，所以整个用例必须用独立的子进程或容器隔离运行，测试结束要自动重启服务并确认恢复到正常状态。否则会把整套测试环境带入不稳定状态。

4.3 批量执行与报告生成

容错测试用例量级通常在数百到上千条，批量执行时不能只看通过率。我们会在每条用例中记录详细的"观测值"而不是简单的"通过/失败"，这样报告能提供真正的分析价值。

以下是一个简化的执行与结果采集流程：

pytest tests/test_image_degradation.py \ --durations=20 \ --json-report \ --json-report-file=reports/degradation_run.json

报告生成阶段会做两类分析。第一类是趋势分析——把不同扰动档位的指标序列化，生成"噪声强度-置信度"、"噪声强度-标签翻转率"这类对应关系，直接输出版本对比图。第二类是缺陷聚类——按"扰动类型+模型模块"组合统计失败用例数量，找出最容易让模型崩溃的组合，供开发团队去定位根因。

报告的核心不是追求一条数据完美，而是把"模型在什么输入形态下开始不可信"这个问题的答案量化出来。这比单条用例的通过或失败有价值得多。

5. 结果度量、缺陷定级与报告输出

5.1 量化容错能力的核心指标

容错测试要形成结论，必须建立可量化的度量体系。我们在实践过程中沉淀了一套适合医疗影像AI的指标集，每个指标回答一类具体问题。

硬标签翻转率是衡量扰动影响最直观的指标，公式为：

• 对同一组样本，在干净输入上得到的诊断类别或检测结论定义为基线结论；
• 在扰动输入上得到的结论与基线不一致的比例即为翻转率。
• 对分类模型是类别改变，对检测模型可以拆成"检出目标消失"、"新增目标"、"目标类别改变"三类分别统计。
• 临床上翻转率超过10%一般就需要关注，超过20%基本意味着模型在该扰动类型上没有可用性。

置信度退缩曲线关注的是模型在扰动下的"自信程度"。绘制扰动强度与平均置信度的关系曲线，如果曲线平缓说明模型对扰动感知平稳，如果置信度在某个档位上突然飙升或暴跌，说明模型对该类扰动存在异常响应。

几何稳定性指标包含检测框漂移量和分割Dice系数波动。对同一病灶，在不同扰动强度下输出的检测框中心点位移和尺寸变化需要被严格约束，分割Dice系数波动超过一定阈值就视为稳定性缺陷。

OOD拒绝率衡量模型面对分布外数据时的不确定性表达能力。定义一个拒绝阈值（比如置信度低于0.5时拒绝出结论），统计模型在OOD数据集上触发拒绝的样本比例。拒绝率过低说明模型"盲目自信"，拒绝率过高说明模型过于保守，正常区间需要结合产品策略和临床场景一起确定。

这些指标在每次容错测试后都要归档，形成可对比的历史基线。没有历史基线的容错测试是孤立的，只有通过版本迭代前后的指标对比，才能验证容错能力的提升效果。

5.2 缺陷分级与报告模板

医疗AI容错测试的缺陷定级必须与临床风险挂钩，不能按普通软件的"I/O错误必现"逻辑来分级。我们在实践中的分级规则如下：

P0级（致命容错缺陷）：模型在分布外或严重退化输入下，不仅没有表达不确定性，还输出高置信度且与临床事实相悖的诊断结论。这类缺陷直接埋下误诊风险，必须修复后才能继续推进。

P1级（严重容错缺陷）：DICOM元数据异常或预处理管线故障导致模型产出不可信结果且系统没有错误提示，或者系统链路在资源故障下静默降级，产生无意义的空结果或重复请求。这类缺陷需要通过系统改造解决。

P2级（中等容错缺陷）：扰动达到中等强度后模型性能出现非线性断崖，但系统仍能给出结果供人工复核；检测框在轻微扰动下发生明显漂移，但尚未产生错误标签。这类缺陷建议在发布前修复，或至少纳入已知风险清单。

P3级（轻微容错缺陷）：单样本偶发的不稳定输出，以及后续的日志记录和可追溯性不足等问题。这类缺陷可以纳入后续迭代修复，但要记录在案避免遗忘。

这套分级和普通软件测试的Severity分级最大的差异在于：它把"错误输出造成临床误导"放在最高优先级，而不是把"系统崩溃"放在最高优先级。审查时这两类问题的优先级要清楚地在报告中明确，避免开发团队把精力花在低风险的崩溃修复上，而忽略了高风险的高置信度误判。

报告模板通常包含五个模块：测试范围说明、异常输入矩阵与用例覆盖统计、各指标退化趋势图、缺陷清单与分级、复测建议与置信度结论。结构化报告的价值在跨团队沟通时非常明显——质量保障部和算法研究部即使语言体系不同，也能基于同一份数据共同判断这一版本是否可以进入临床试点。

6. 实测中的常见问题与排查实录

6.1 DICOM解析崩溃的根因分析

我们最早遇到的"疑难杂症"来自DICOM解析环节。某个待测系统对一批真实脱敏数据中的约3%样本返回解析失败，报错信息是通用的"Invalid DICOM file"。

进一步深挖发现，这些样本并非真正的损坏文件，而是在文件头部包含了一些不符合标准但仍在被部分PACS设备接受的扩展字段。底层医学影像解析库在严格模式下直接拒绝了解析，而业务代码为了节省错误码空间，把所有解析异常统一转成了同一个错误码。测试结论从"数据损坏"变成"解析策略过于严格导致可用数据被拒收"，这就是容错测试的真正价值——把开放性扩展到"系统对边缘合法输入的容忍度"上。

排查这类问题最有效的办法是直接打印异常堆栈并对比正常样本的DICOM头字段差异。但这个经验在大型项目里经常被忽略，因为团队习惯了从上层接口的错误提示直接猜根因。

6.2 模型"盲目自信"的置信度陷阱

置信度陷阱是我们在一期容错测试中最典型的发现。对正常CT图像，某个肺炎识别模型的平均置信度在0.85以上。我们对这批正常图像注入高斯噪声后，置信度不降反升——部分语义信息已被破坏的图像，置信度反而增长到0.93以上。

这个现象乍看违反直觉，实际原因是模型的输出概率由最后归一化层强制映射到和为1的分布上，只要倒数第二层的特征向量在某些维度上被噪声"恰好激活"，softmax就会输出一个高概率值。模型并没有一个机制区分"高置信度来自真实特征"和"低置信度来自熵增"。

教学模式是这样的：如果你在容错测试里只在正常数据上画置信度分布，这类问题永远不会暴露。正确做法是同时绘制干净数据和各类扰动数据的置信度分布，看两者是否有显著重叠以及对高置信度区域的贡献差异——也就是上面提到的"置信度校准图"。

这类发现推动了我们的产品团队在推理链路中增加了"输入质量评分"模块，对质量分过低的图像直接拒绝输出诊断结论，走人工复核流程。这是典型的从测试发现问题到推动产品改造的完整通路。

6.3 显存泄漏与并发资源问题

一台8卡GPU服务器上跑诊断AI服务，某次容错测试中我们连续跑完300轮并发推理后，服务响应时间明显变长，且时延曲线出现周期性尖峰。我们需要判断是网络抖动、GPU资源竞争还是服务内部状态异常。

排查过程分了三步。第一步确认基本环境，其它服务占用情况正常。第二步直接监控显存占用和CUDA context数量，发现显存占用曲线在每一轮推理后没有回到基线，而是缓慢上涨最终逼近显存上限。第三步定位到服务端的报告说明推理框架在处理动态batch时反复创建新的CUDA context且未释放。这个问题如果不用故障注入长时间压测，在功能测试里几乎发现不了。

针对这类问题，我们的经验是：容错测试的并发压力组不要只测"请求能不能返回"，要同时监控显存曲线、CUDA context数、显存碎片率等资源维度的指标。否则高并发请求通过后，资源泄漏问题仍然逃逸到生产环境。

6.4 多模型对比测试的环境一致性

一个典型的容错测试需求是"新旧版本模型对比"，测试人员分别对两个模型做同样扰动注入，看新版模型的容错能力是否提升。看起来很简单，但我们在实操中踩过环境不一致的坑——因为两个模型在不同的服务配置下测试，GPU型号不同，推理框架版本不同，导致结论完全不可比。

这个问题要求容错测试必须建立严格的环境基线：同一台物理机、同一个推理服务版本、同一个输入样本集、同一个随机种子。测试中途如果要升级依赖库或切换GPU型号，必须记录变更并把影响评估闭环。环境一致性对AI容错测试的重要性，比功能测试高得多——模型输出的微小数值波动就可能被误判为容错能力问题，而真正的容错问题反而可能被环境噪声掩盖。

7. 一点实战体会

做医疗影像AI容错测试，最难的不是技术，而是认知上的转变。我一开始在项目里还是带着"测功能、找Bug"的思路，结果发现方向偏了——大多数功能层面的Bug再严重，也不会直接产生一个"自信地错误"的诊断结论。而容错测试真正要防的，恰恰是系统在异常面前依然表现得体、甚至过于得体。

几轮测试跑下来，我自己最深的感受是：容错测试的产出，不是一份"发现了几个Bug"的报告，而是帮助团队回答"这套系统在真实世界的混乱输入面前，边界到底在哪里"。医疗影像的输入永远不可能像训练集那样干净，设备差异、传输损耗、操作偏差、患者体态差异都是常态。与其期望模型在下游把所有异常一并解决，不如在测试阶段就把"异常发生时系统必须显性且安全地失败"当作一条强制约束反复验证。

如果你正在准备启动医疗影像AI项目的容错测试，一个小建议：先别急着铺测试用例，花一到两周把异常输入的样本库做扎实。反正最后能发现多少有效问题，很大程度取决于你能深挖多少种异常形态。样本库到位了，后面的框架、用例、报告都是顺势而为的事。医疗AI的上限由算法决定，下限却由测试兜底，容错测试恰是那个兜底的关键一环。