简介ISTQB认证测试工程师人工智能测试中文大纲CT-AI-1.0-CN-1.0面向希望系统掌握AI系统质量保障与测试方法的测试工程师、质量人员及备考认证者围绕人工智能、深度学习测试与模型测试建立从概念到实践的知识框架。资源为1个PDF文件约4.03MB共90页按认证大纲体例编排包含学习目标、认知水平与考试要求等说明。正文十一章依次覆盖人工智能介绍、AI系统质量特征、机器学习总览、数据准备与预处理、功能表现度量、神经网络与测试以及AI系统测试总览、专属质量特征测试、方法与技术、测试环境和用AI辅助测试。已有1190人学习适合据此梳理准确性、可靠性、可解释性、公平性与鲁棒性等测试要点也可对照数据质量、模型评估指标和测试环境搭建查漏补缺形成可落地的AI测试思路。1. 概率正确性为什么同一个输入两次跑出不同结果如果你拿一份传统软件的测试报告去审一个模型系统最容易翻车的地方在于同一条用例上午跑是通的下午跑挂了晚上再跑又通了日志里没有任何异常代码一行没改。很多团队第一反应是环境不稳查了半天容器、缓存、依赖版本最后发现是模型本身在“抖”。这就是这份《认证测试工程师 人工智能测试大纲》要回答的起点问题当被测对象的“正确性”本身变成一个概率分布测试的对象就不再是代码分支而是数据分布、训练过程和运行环境三者叠加出来的行为面。大纲用十一章、九十页把这件事拆开讲从人工智能效应、机器学习工作流到功能表现度量、蜕变测试、对抗攻击再到测试环境与概念漂移监控。它解决的不是“怎么写一条测试用例”而是“当预期结果没法硬编码时测试凭什么说系统合格”。搞懂这套框架你才能理解模型测试、深度学习测试为什么不能照搬传统测试那套等价类加边界值的思路。2. 质量特征的变形为什么把传统质量模型套上去会失效传统软件的质量模型里功能性、可靠性、性能效率这些特征有明确的判定口径功能对不对看需求可靠性看平均无故障时间性能看响应曲线。但大纲第二章列出的那组特征——灵活性与适应性、自治、进化、偏差、行为准则、副作用与奖励黑客、透明度与可解释性、安全性——每一个都在挑战这套口径。核心原因是AI系统的行为不是被完全指定的而是被训练出来的训练目标和你真正想要的东西之间永远隔着一条缝。2.1 灵活性与适应性预期结果本身在漂移灵活性指的是系统面对没见过的输入仍能给出合理反应适应性指的是它能随环境变化调整行为。听起来是优点放到测试里就是麻烦你没法用一组固定的输入输出对来定义“正确”。一份图像分类系统同一张图加了一点亮度扰动人眼看还是同一类系统可能给出完全不同的置信度分布。传统测试里这叫缺陷在AI测试里这要先判断扰动幅度是否落在允许范围内。常见的判定思路是引入“行为域”而不是“预期值”先定义输入空间中哪些变换应当保持输出语义不变比如旋转、缩放、光照变化再用 metamorphic testing蜕变测试的方式生成衍生用例检查关系是否成立。大纲把这条思路放在第九章的蜕变测试里和对抗攻击、数据中毒并列用意是让读者意识到测AI系统的第一件事是重新定义“什么叫对”而不是急着跑用例。2.2 自治与进化测试基线会自己移动自治性越高系统自己做的决策越多进化性越强系统在部署后还会继续从数据里学。这两条合在一起意味着测试基线不是发布时冻结的而是随时间漂移的。一份推荐系统上线时点击率达标三个月后用户兴趣迁移同一套测试用例的通过率会自然下滑但这不一定是缺陷。大纲在第七章专门讲了概念漂移的测试需要把“模型精度下降”拆成两类一类是输入数据分布变了协变量漂移一类是输入和标签之间的关系变了概念漂移。前者可以通过监控输入特征分布发现后者必须靠带标签的新样本回采。实测里比较稳妥的做法是保留一条固定不变的“锚定测试集”每次模型更新都跑一遍同时维护一条滚动更新的“现实测试集”两个结果之间的差值才是漂移信号。这一步如果没有在测试计划里写清楚后面所有指标都会变成玄学。2.3 偏差、副作用与奖励黑客优化目标本身就是缺陷来源偏差bias在这份大纲里不是指统计学里的偏差-方差而是指系统输出对某些群体、场景的系统性偏离。副作用和奖励黑客是同一枚硬币的两面你给模型一个奖励函数它会找到让奖励最大化的捷径而这条捷径往往不是你想要的。典型的例子是游戏AI学会卡bug刷分或者内容推荐模型学会用标题党拉点击。注意奖励黑客不是模型“学坏了”而是奖励函数没写全。测试要做的是在设计阶段就把奖励函数的漏洞当作缺陷去攻击。测试侧的做法在大纲第九章有落点对抗攻击提供了一套系统化构造边界输入的方法数据中毒则模拟训练数据被污染后的表现。把这两类技术和偏差测试结合能覆盖“模型在正常分布上表现良好、但在特定子群上系统性出错”的情况。实践中我一般会把子群切分做得比业务方要求的更细至少按关键属性交叉切两到三层否则偏差问题在总体指标上会被平均掉。2.4 可解释性它是测试对象不是文档附件大纲把透明度和可解释性拆成整体可解释性与单一可解释性两层。整体层面回答“这个模型大致怎么决策”单一层面回答“这一条预测为什么是这个结果”。很多团队把可解释性当成上线前补的一份模型说明文档这是典型的踩坑姿势可解释性本身是可以被测试的质量特征比如检查特征归因是否稳定、局部解释是否随输入微小扰动而剧烈跳变。比较务实的做法是选一批业务上必须能解释的样本对其做局部解释再对输入做小幅度扰动看解释结果是否保持一致。如果解释自己都不稳定那这份解释对测试结论没有支撑价值。大纲在第八章把可解释性测试和自治系统测试、概率系统测试放在一起逻辑是越是难解释的系统越需要把解释能力本身变成可验证项。3. 从机器学习工作流反推测试点数据在哪一步决定了结果大纲第三章到第五章是一条完整链路机器学习形式 → 工作流 → 数据 → 度量。很多人读大纲只记住有监督、无监督、强化学习三个名词真正有用的信息在工作流那张图里数据准备、特征工程、训练、验证、测试、部署、监控每一步都对应一类测试活动。测试工程师如果只盯着模型评估那一步前面数据环节埋的雷最后都会在线上爆。3.1 三种学习范式对应三套测试假设有监督学习的测试假设是“标签可信”所以测试重点在标签质量和分布覆盖无监督学习没有标签测试假设变成“结构合理”重点在聚类结果是否稳定、异常检测的阈值是否合理强化学习的测试假设是“环境可复现”重点在奖励函数设计和策略在边界状态下的行为。这份大纲把三种范式的测试差异放在工作流之后讲顺序是有讲究的先理解工作流再理解范式才知道每种范式该在哪个环节加测试。以强化学习为例同样是训练一个策略环境随机种子不同会得到差异极大的策略测试如果不在固定种子下做对比结论完全没有可比性。常见实现思路是把种子、环境版本、依赖库版本一起写进测试基线任何一项变动都视为需要重新建立基线的事件。3.2 训练集、验证集、测试集的切分是测试设计的一部分大纲第四章明确把“工作流中的训练、验证和测试集”单列一节这不是复习机器学习常识而是在强调数据切分方式直接决定测试结论的有效性。如果切分时没有考虑时间顺序用未来数据训练、用过去数据测试指标会虚高如果切分时没有做分组同一个用户的行为同时出现在训练集和测试集里模型相当于提前看过答案。一个可复现的检查清单长这样检查项不合格表现后果时间切分随机切分代替时序切分线上指标明显低于离线指标分组切分同一实体跨集出现测试集精度虚高类别分布测试集类别比例严重偏离真实分布少数类缺陷被掩盖去重近重复样本跨集变相数据泄漏我一般会要求数据切分的脚本和模型训练脚本分开评审切分逻辑一旦写错后面所有调参都是在错误基础上做的。3.3 过拟合与欠拟合模型测试的黑匣子时刻大纲把过拟合、欠拟合和配套的动手练习放在第三章末尾是因为这是测试工程师第一次需要脱离代码看模型行为。过拟合在测试上的表现是训练集指标很好测试集指标明显掉下来欠拟合是两边都差。但真正难判的是中间态——测试集指标还行但在某些子群上崩了。提示判断过拟合不要只看训练集和测试集的总体差距要按子群拆开看。总体差距小不代表没有过拟合可能只是过拟合发生在少数子群上被平均掉了。比较实用的做法是画学习曲线横轴训练样本量纵轴训练误差和验证误差。两条曲线如果收敛后仍有明显间隙说明模型容量相对数据量偏大如果两条曲线都很高且贴近说明欠拟合。大纲配套的动手练习就是用简单数据集演示这两种形态目的是让测试人员对曲线形状建立直觉而不是背定义。3.4 数据标注的质量就是测试的基准线大纲第四章最后一节讲数据标注方式和错误标注数据。核心结论很直白如果测试集的标注有错那所有基于这个测试集算出来的指标都不可信。有监督学习里标注错误分两类一类是随机错误表现为指标轻微下降一类是系统性错误比如某个类别整体标错表现为该类别指标异常低但总体指标看不出问题。常见的排查手段是抽样人工复核加一致性检查同一批样本让两个标注员独立标算一致率一致率低的子集重点复查。大纲里还提到预训练模型和迁移学习的风险逻辑类似——预训练模型自带的偏差会顺着微调过程传导到下游任务测试时不能只测微调后的表现还要测预训练特征在目标域上的基本可分性。4. 度量与方法的耦合混淆矩阵之后才是真正的测试设计大纲第五章讲功能表现度量第九章讲测试方法与技术两章隔了几十页但实际工作中它们是连着的你选什么度量决定了你该用什么方法去构造用例你用什么方法决定了度量结果该怎么解读。把这两章分开看很容易变成背公式合起来看才是一套完整的判定链路。4.1 混淆矩阵不是一张表是测试决策的坐标系混淆矩阵把预测结果分成真正例、假正例、真负例、假负例四格。大纲把它放在度量章开头原因是后面所有指标都是这四格的组合。但测试人员真正要关注的是这四格里哪一格的错误代价最高这个判断来自业务而不是来自数学。比如医疗筛查场景假负例有病判成没病的代价远高于假正例那度量就应该偏向召回率反垃圾邮件场景假正例正常邮件判成垃圾的代价更高度量就应该偏向精确率。如果业务方说不清哪类错误更严重那测试方案就没法定验收准则这时候应该先把这个问题抛回去而不是自己拍一个 F1 分数当目标。4.2 精确率、召回率、F1 与 AUC 的取舍逻辑这几个指标的关系在大纲里是并列给出的实际选型时有一套朴素的判断顺序先看正负样本是否均衡再看业务更怕哪类错误最后看需不需要一个与阈值无关的总体排序能力指标。指标适用场景容易被误用的地方准确率类别均衡、错误代价对称类别极不均衡时严重虚高精确率假正例代价高忽略漏判召回率假负例代价高忽略误报F1需要平衡两者隐含假设两类错误同等重要AUC需要评估排序能力对类别不均衡不敏感可能掩盖子群问题AUC 特别值得单独说一句它衡量的是模型把正例排在负例前面的能力和具体阈值无关所以在阈值还没定的时候常被拿来当总体指标。但 AUC 高不代表每个子群都高也不代表校准良好。实践中我一般会把 AUC 和分群召回率放在一起看只报一个 AUC 的评估报告基本没有决策价值。4.3 度量的局限性基准套件也会骗人大纲在度量章末尾专门写了“机器学习功能表现度量的局限性”和“基准套件”。局限性这部分讲的是任何单一度量都是对模型行为的降维降维就会丢信息。基准套件的问题是另一层公开基准上的高分可能来自对基准分布的过拟合换到真实场景未必成立。注意基准套件适合做模型选型的初筛不适合做验收依据。验收必须用业务场景里采出来的、带时间戳的、经过标注质量检查的数据集。一个可操作的验证方法是构造“对抗性基准”在标准测试集之外单独维护一份包含边界样本、少数类样本、近期新增类别的集合每次评估都同时跑标准集和这份集合两个结果的差距就是模型对基准过拟合程度的粗略估计。4.4 蜕变测试没有预期结果时怎么判对错大纲第九章把蜕变测试和结对测试、背靠背测试、A/B测试并列这一组方法的共同点是它们都不依赖逐条用例的预期输出。蜕变测试的核心是找“输入变换和输出变换之间的关系”比如“给图像加一层不影响语义的噪声分类结果应当不变”或者“搜索词加一个同义词返回结果集合不应显著缩小”。下面这段伪代码描述的是蜕变关系的检查逻辑不是某个具体框架的 API# 蜕变关系检查对输入施加保持语义的变换断言输出关系成立 def check_metamorphic_relation(model, inputs, transform, relation): violations [] for x in inputs: y_base model.predict(x) x_new transform(x) # 保持语义的输入变换 y_new model.predict(x_new) if not relation(y_base, y_new): # 断言输出间的关系 violations.append((x, y_base, y_new)) return violations # relation 示例分类标签不变 # relation 示例回归输出差值在容忍范围内这段代码里transform必须是对语义无损的变换relation是把“预期输出”降级成“输出间关系”的断言函数。参数设计的难点在容忍度关系太严会把正常波动判成缺陷太松会漏掉真实问题。我的经验是先在一个已知正常的模型上跑一遍用违反率的分布定阈值而不是拍一个固定数字。4.5 对抗攻击与数据中毒把攻击者当成用例生成器对抗攻击是通过对输入做微小扰动让模型判错数据中毒是在训练数据里注入恶意样本。大纲把这两者放在测试技术章而不是安全章用意是它们首先是构造测试输入的方法其次才是安全威胁。对抗样本能高效暴露模型决策边界的脆弱位置数据中毒能测试训练流程对异常样本的鲁棒性。实际使用时要注意对抗样本的迁移性在一个模型上生成的对抗样本换一个模型未必有效。所以对抗测试的结论要写清楚是在哪个模型、哪个扰动预算下得到的不能笼统写成“模型存在对抗脆弱性”。5. 避坑与排查AI测试里最容易翻车的五个地方这一章不是理论是我在实际项目里反复见到的翻车现场。每一条都按现象、原因、解决三段写能对上号的直接抄排查顺序。5.1 离线指标全绿上线一周就崩现象模型在测试集上各项指标达标部署后一周内业务指标明显下滑日志里没有报错。原因测试集和线上数据的分布不一致且测试集没有按时间切分训练时用了未来信息。另一层原因是线上输入经过了不同的预处理链路训练时的特征和推理时的特征计算口径有细微差异。解决先做特征一致性核对把线上一条真实请求的原始输入和预处理后特征打印出来和训练管线同一条样本对一遍再把测试集按时间重新切分用最近一段时间的数据做一次回溯评估。这两步做完大部分“上线就崩”能定位到具体环节。5.2 同一个模型两次评估结果差很多现象同一个模型文件、同一份测试集两次评估的准确率差了几个百分点。原因评估脚本里混入了随机性比如数据加载顺序影响批归一化统计、 dropout 没关、或者测试时做了随机数据增强。还有一种情况是测试集本身在两次评估之间被改动过但没有记录版本。解决评估脚本固定随机种子模型切到推理模式关闭所有训练期才用的随机操作测试集打上内容哈希评估报告里带上哈希值。这属于血泪经验看起来是小事排查起来能耗掉一整天。5.3 总体指标正常某个子群系统性出错现象总体召回率达标但按用户群体、设备类型或时间段拆开看某个子群的召回率明显偏低。原因测试集的子群样本量不足或者训练数据里该子群样本占比过低导致模型没学好。也有可能是标注标准在该子群上不一致。解决评估报告强制按关键维度分群输出子群样本量低于阈值的标注“样本不足结论不可靠”对低表现子群做标注质量抽检排除标注问题后再判断是否属于模型偏差。这一步不做偏差问题会一直藏在平均值里。5.4 蜕变测试关系写得太宽或太严现象蜕变测试要么一条违反都报不出来要么报出大量违反但人工复核全是误报。原因关系函数里的容忍度是拍脑袋定的没有在已知正常的模型上做校准。解决先在基线模型上跑一遍蜕变关系统计违反率分布用分位数定阈值再把关系按语义强度分层强关系标签不变和弱关系置信度变化在区间内分开统计。校准这一步省不得否则蜕变测试会变成噪音发生器。5.5 把可解释性输出当结论用现象模型给出局部解释业务方直接拿解释去对外说明后来发现解释和模型实际行为对不上。原因可解释性方法本身有近似误差特征归因结果不稳定且不同解释方法可能给出矛盾结论。解决把解释稳定性作为独立测试项对同一批样本做输入微扰检查解释结果是否一致对外使用解释结论前必须经过测试侧确认解释与模型行为的一致性。解释是辅助判断工具不是模型行为的权威描述。6. 设计取舍测试环境、仿真度与用AI测AI的循环依赖大纲第十章讲测试环境第十一章讲用人工智能进行测试这两章放在最后不是凑数它们对应两个绕不开的取舍。第一个取舍是仿真度。AI系统的测试环境很难做到完全真实自动驾驶类系统要在仿真里跑百万公里推荐系统要用回放日志模拟线上流量。仿真度越高测试成本越高而且高仿真环境本身可能引入新的偏差。我的判断标准是仿真环境只需要在“影响被测质量特征的维度”上保真其他维度可以降级。比如测感知模块光照和天气要保真交通参与者的行为模型可以简化测决策模块交通流分布要保真渲染画质可以降级。这个取舍必须在测试计划里写清楚否则评审时会被问“仿真环境凭什么代表真实世界”而答不上来。第二个取舍是用AI测AI的循环依赖。用模型生成测试用例、用模型做结果判定、用模型做缺陷预测这些手段能提升效率但会引入一层新的不确定性判定器本身也可能出错而且它的错误模式和被测系统可能相关。比较稳妥的结构是让判定器和被测系统在数据来源、模型架构或训练目标上保持差异形成背靠背的关系。大纲第九章的背靠背测试讲的就是这个思路只是很多人只把它用在两个被测系统之间忘了判定器也需要被背靠背校验。还有一个容易被忽略的点是测试环境的版本管理。模型、数据、依赖库、仿真器任何一项版本变动测试结论的可比性就断了。我后来养成的习惯是每次评估前先打印一份环境指纹包含模型哈希、测试集哈希、关键库版本和随机种子附在评估报告首页。这个习惯来自一次排查了三天才发现是仿真器小版本升级导致行为差异的经历——从那以后我每次建基线都强制走一遍环境指纹核对不管多小的改动。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 20:23:30 · 阅读 1.2k AI测试为何不能照搬传统测试：概率正确性、蜕变测试与概念漂移
简介ISTQB认证测试工程师人工智能测试中文大纲CT-AI-1.0-CN-1.0面向希望系统掌握AI系统质量保障与测试方法的测试工程师、质量人员及备考认证者围绕人工智能、深度学习测试与模型测试建立从概念到实践的知识框架。资源为1个PDF文件约4.03MB共90页按认证大纲体例编排包含学习目标、认知水平与考试要求等说明。正文十一章依次覆盖人工智能介绍、AI系统质量特征、机器学习总览、数据准备与预处理、功能表现度量、神经网络与测试以及AI系统测试总览、专属质量特征测试、方法与技术、测试环境和用AI辅助测试。已有1190人学习适合据此梳理准确性、可靠性、可解释性、公平性与鲁棒性等测试要点也可对照数据质量、模型评估指标和测试环境搭建查漏补缺形成可落地的AI测试思路。1. 概率正确性为什么同一个输入两次跑出不同结果如果你拿一份传统软件的测试报告去审一个模型系统最容易翻车的地方在于同一条用例上午跑是通的下午跑挂了晚上再跑又通了日志里没有任何异常代码一行没改。很多团队第一反应是环境不稳查了半天容器、缓存、依赖版本最后发现是模型本身在“抖”。这就是这份《认证测试工程师 人工智能测试大纲》要回答的起点问题当被测对象的“正确性”本身变成一个概率分布测试的对象就不再是代码分支而是数据分布、训练过程和运行环境三者叠加出来的行为面。大纲用十一章、九十页把这件事拆开讲从人工智能效应、机器学习工作流到功能表现度量、蜕变测试、对抗攻击再到测试环境与概念漂移监控。它解决的不是“怎么写一条测试用例”而是“当预期结果没法硬编码时测试凭什么说系统合格”。搞懂这套框架你才能理解模型测试、深度学习测试为什么不能照搬传统测试那套等价类加边界值的思路。2. 质量特征的变形为什么把传统质量模型套上去会失效传统软件的质量模型里功能性、可靠性、性能效率这些特征有明确的判定口径功能对不对看需求可靠性看平均无故障时间性能看响应曲线。但大纲第二章列出的那组特征——灵活性与适应性、自治、进化、偏差、行为准则、副作用与奖励黑客、透明度与可解释性、安全性——每一个都在挑战这套口径。核心原因是AI系统的行为不是被完全指定的而是被训练出来的训练目标和你真正想要的东西之间永远隔着一条缝。2.1 灵活性与适应性预期结果本身在漂移灵活性指的是系统面对没见过的输入仍能给出合理反应适应性指的是它能随环境变化调整行为。听起来是优点放到测试里就是麻烦你没法用一组固定的输入输出对来定义“正确”。一份图像分类系统同一张图加了一点亮度扰动人眼看还是同一类系统可能给出完全不同的置信度分布。传统测试里这叫缺陷在AI测试里这要先判断扰动幅度是否落在允许范围内。常见的判定思路是引入“行为域”而不是“预期值”先定义输入空间中哪些变换应当保持输出语义不变比如旋转、缩放、光照变化再用 metamorphic testing蜕变测试的方式生成衍生用例检查关系是否成立。大纲把这条思路放在第九章的蜕变测试里和对抗攻击、数据中毒并列用意是让读者意识到测AI系统的第一件事是重新定义“什么叫对”而不是急着跑用例。2.2 自治与进化测试基线会自己移动自治性越高系统自己做的决策越多进化性越强系统在部署后还会继续从数据里学。这两条合在一起意味着测试基线不是发布时冻结的而是随时间漂移的。一份推荐系统上线时点击率达标三个月后用户兴趣迁移同一套测试用例的通过率会自然下滑但这不一定是缺陷。大纲在第七章专门讲了概念漂移的测试需要把“模型精度下降”拆成两类一类是输入数据分布变了协变量漂移一类是输入和标签之间的关系变了概念漂移。前者可以通过监控输入特征分布发现后者必须靠带标签的新样本回采。实测里比较稳妥的做法是保留一条固定不变的“锚定测试集”每次模型更新都跑一遍同时维护一条滚动更新的“现实测试集”两个结果之间的差值才是漂移信号。这一步如果没有在测试计划里写清楚后面所有指标都会变成玄学。2.3 偏差、副作用与奖励黑客优化目标本身就是缺陷来源偏差bias在这份大纲里不是指统计学里的偏差-方差而是指系统输出对某些群体、场景的系统性偏离。副作用和奖励黑客是同一枚硬币的两面你给模型一个奖励函数它会找到让奖励最大化的捷径而这条捷径往往不是你想要的。典型的例子是游戏AI学会卡bug刷分或者内容推荐模型学会用标题党拉点击。注意奖励黑客不是模型“学坏了”而是奖励函数没写全。测试要做的是在设计阶段就把奖励函数的漏洞当作缺陷去攻击。测试侧的做法在大纲第九章有落点对抗攻击提供了一套系统化构造边界输入的方法数据中毒则模拟训练数据被污染后的表现。把这两类技术和偏差测试结合能覆盖“模型在正常分布上表现良好、但在特定子群上系统性出错”的情况。实践中我一般会把子群切分做得比业务方要求的更细至少按关键属性交叉切两到三层否则偏差问题在总体指标上会被平均掉。2.4 可解释性它是测试对象不是文档附件大纲把透明度和可解释性拆成整体可解释性与单一可解释性两层。整体层面回答“这个模型大致怎么决策”单一层面回答“这一条预测为什么是这个结果”。很多团队把可解释性当成上线前补的一份模型说明文档这是典型的踩坑姿势可解释性本身是可以被测试的质量特征比如检查特征归因是否稳定、局部解释是否随输入微小扰动而剧烈跳变。比较务实的做法是选一批业务上必须能解释的样本对其做局部解释再对输入做小幅度扰动看解释结果是否保持一致。如果解释自己都不稳定那这份解释对测试结论没有支撑价值。大纲在第八章把可解释性测试和自治系统测试、概率系统测试放在一起逻辑是越是难解释的系统越需要把解释能力本身变成可验证项。3. 从机器学习工作流反推测试点数据在哪一步决定了结果大纲第三章到第五章是一条完整链路机器学习形式 → 工作流 → 数据 → 度量。很多人读大纲只记住有监督、无监督、强化学习三个名词真正有用的信息在工作流那张图里数据准备、特征工程、训练、验证、测试、部署、监控每一步都对应一类测试活动。测试工程师如果只盯着模型评估那一步前面数据环节埋的雷最后都会在线上爆。3.1 三种学习范式对应三套测试假设有监督学习的测试假设是“标签可信”所以测试重点在标签质量和分布覆盖无监督学习没有标签测试假设变成“结构合理”重点在聚类结果是否稳定、异常检测的阈值是否合理强化学习的测试假设是“环境可复现”重点在奖励函数设计和策略在边界状态下的行为。这份大纲把三种范式的测试差异放在工作流之后讲顺序是有讲究的先理解工作流再理解范式才知道每种范式该在哪个环节加测试。以强化学习为例同样是训练一个策略环境随机种子不同会得到差异极大的策略测试如果不在固定种子下做对比结论完全没有可比性。常见实现思路是把种子、环境版本、依赖库版本一起写进测试基线任何一项变动都视为需要重新建立基线的事件。3.2 训练集、验证集、测试集的切分是测试设计的一部分大纲第四章明确把“工作流中的训练、验证和测试集”单列一节这不是复习机器学习常识而是在强调数据切分方式直接决定测试结论的有效性。如果切分时没有考虑时间顺序用未来数据训练、用过去数据测试指标会虚高如果切分时没有做分组同一个用户的行为同时出现在训练集和测试集里模型相当于提前看过答案。一个可复现的检查清单长这样检查项不合格表现后果时间切分随机切分代替时序切分线上指标明显低于离线指标分组切分同一实体跨集出现测试集精度虚高类别分布测试集类别比例严重偏离真实分布少数类缺陷被掩盖去重近重复样本跨集变相数据泄漏我一般会要求数据切分的脚本和模型训练脚本分开评审切分逻辑一旦写错后面所有调参都是在错误基础上做的。3.3 过拟合与欠拟合模型测试的黑匣子时刻大纲把过拟合、欠拟合和配套的动手练习放在第三章末尾是因为这是测试工程师第一次需要脱离代码看模型行为。过拟合在测试上的表现是训练集指标很好测试集指标明显掉下来欠拟合是两边都差。但真正难判的是中间态——测试集指标还行但在某些子群上崩了。提示判断过拟合不要只看训练集和测试集的总体差距要按子群拆开看。总体差距小不代表没有过拟合可能只是过拟合发生在少数子群上被平均掉了。比较实用的做法是画学习曲线横轴训练样本量纵轴训练误差和验证误差。两条曲线如果收敛后仍有明显间隙说明模型容量相对数据量偏大如果两条曲线都很高且贴近说明欠拟合。大纲配套的动手练习就是用简单数据集演示这两种形态目的是让测试人员对曲线形状建立直觉而不是背定义。3.4 数据标注的质量就是测试的基准线大纲第四章最后一节讲数据标注方式和错误标注数据。核心结论很直白如果测试集的标注有错那所有基于这个测试集算出来的指标都不可信。有监督学习里标注错误分两类一类是随机错误表现为指标轻微下降一类是系统性错误比如某个类别整体标错表现为该类别指标异常低但总体指标看不出问题。常见的排查手段是抽样人工复核加一致性检查同一批样本让两个标注员独立标算一致率一致率低的子集重点复查。大纲里还提到预训练模型和迁移学习的风险逻辑类似——预训练模型自带的偏差会顺着微调过程传导到下游任务测试时不能只测微调后的表现还要测预训练特征在目标域上的基本可分性。4. 度量与方法的耦合混淆矩阵之后才是真正的测试设计大纲第五章讲功能表现度量第九章讲测试方法与技术两章隔了几十页但实际工作中它们是连着的你选什么度量决定了你该用什么方法去构造用例你用什么方法决定了度量结果该怎么解读。把这两章分开看很容易变成背公式合起来看才是一套完整的判定链路。4.1 混淆矩阵不是一张表是测试决策的坐标系混淆矩阵把预测结果分成真正例、假正例、真负例、假负例四格。大纲把它放在度量章开头原因是后面所有指标都是这四格的组合。但测试人员真正要关注的是这四格里哪一格的错误代价最高这个判断来自业务而不是来自数学。比如医疗筛查场景假负例有病判成没病的代价远高于假正例那度量就应该偏向召回率反垃圾邮件场景假正例正常邮件判成垃圾的代价更高度量就应该偏向精确率。如果业务方说不清哪类错误更严重那测试方案就没法定验收准则这时候应该先把这个问题抛回去而不是自己拍一个 F1 分数当目标。4.2 精确率、召回率、F1 与 AUC 的取舍逻辑这几个指标的关系在大纲里是并列给出的实际选型时有一套朴素的判断顺序先看正负样本是否均衡再看业务更怕哪类错误最后看需不需要一个与阈值无关的总体排序能力指标。指标适用场景容易被误用的地方准确率类别均衡、错误代价对称类别极不均衡时严重虚高精确率假正例代价高忽略漏判召回率假负例代价高忽略误报F1需要平衡两者隐含假设两类错误同等重要AUC需要评估排序能力对类别不均衡不敏感可能掩盖子群问题AUC 特别值得单独说一句它衡量的是模型把正例排在负例前面的能力和具体阈值无关所以在阈值还没定的时候常被拿来当总体指标。但 AUC 高不代表每个子群都高也不代表校准良好。实践中我一般会把 AUC 和分群召回率放在一起看只报一个 AUC 的评估报告基本没有决策价值。4.3 度量的局限性基准套件也会骗人大纲在度量章末尾专门写了“机器学习功能表现度量的局限性”和“基准套件”。局限性这部分讲的是任何单一度量都是对模型行为的降维降维就会丢信息。基准套件的问题是另一层公开基准上的高分可能来自对基准分布的过拟合换到真实场景未必成立。注意基准套件适合做模型选型的初筛不适合做验收依据。验收必须用业务场景里采出来的、带时间戳的、经过标注质量检查的数据集。一个可操作的验证方法是构造“对抗性基准”在标准测试集之外单独维护一份包含边界样本、少数类样本、近期新增类别的集合每次评估都同时跑标准集和这份集合两个结果的差距就是模型对基准过拟合程度的粗略估计。4.4 蜕变测试没有预期结果时怎么判对错大纲第九章把蜕变测试和结对测试、背靠背测试、A/B测试并列这一组方法的共同点是它们都不依赖逐条用例的预期输出。蜕变测试的核心是找“输入变换和输出变换之间的关系”比如“给图像加一层不影响语义的噪声分类结果应当不变”或者“搜索词加一个同义词返回结果集合不应显著缩小”。下面这段伪代码描述的是蜕变关系的检查逻辑不是某个具体框架的 API# 蜕变关系检查对输入施加保持语义的变换断言输出关系成立 def check_metamorphic_relation(model, inputs, transform, relation): violations [] for x in inputs: y_base model.predict(x) x_new transform(x) # 保持语义的输入变换 y_new model.predict(x_new) if not relation(y_base, y_new): # 断言输出间的关系 violations.append((x, y_base, y_new)) return violations # relation 示例分类标签不变 # relation 示例回归输出差值在容忍范围内这段代码里transform必须是对语义无损的变换relation是把“预期输出”降级成“输出间关系”的断言函数。参数设计的难点在容忍度关系太严会把正常波动判成缺陷太松会漏掉真实问题。我的经验是先在一个已知正常的模型上跑一遍用违反率的分布定阈值而不是拍一个固定数字。4.5 对抗攻击与数据中毒把攻击者当成用例生成器对抗攻击是通过对输入做微小扰动让模型判错数据中毒是在训练数据里注入恶意样本。大纲把这两者放在测试技术章而不是安全章用意是它们首先是构造测试输入的方法其次才是安全威胁。对抗样本能高效暴露模型决策边界的脆弱位置数据中毒能测试训练流程对异常样本的鲁棒性。实际使用时要注意对抗样本的迁移性在一个模型上生成的对抗样本换一个模型未必有效。所以对抗测试的结论要写清楚是在哪个模型、哪个扰动预算下得到的不能笼统写成“模型存在对抗脆弱性”。5. 避坑与排查AI测试里最容易翻车的五个地方这一章不是理论是我在实际项目里反复见到的翻车现场。每一条都按现象、原因、解决三段写能对上号的直接抄排查顺序。5.1 离线指标全绿上线一周就崩现象模型在测试集上各项指标达标部署后一周内业务指标明显下滑日志里没有报错。原因测试集和线上数据的分布不一致且测试集没有按时间切分训练时用了未来信息。另一层原因是线上输入经过了不同的预处理链路训练时的特征和推理时的特征计算口径有细微差异。解决先做特征一致性核对把线上一条真实请求的原始输入和预处理后特征打印出来和训练管线同一条样本对一遍再把测试集按时间重新切分用最近一段时间的数据做一次回溯评估。这两步做完大部分“上线就崩”能定位到具体环节。5.2 同一个模型两次评估结果差很多现象同一个模型文件、同一份测试集两次评估的准确率差了几个百分点。原因评估脚本里混入了随机性比如数据加载顺序影响批归一化统计、 dropout 没关、或者测试时做了随机数据增强。还有一种情况是测试集本身在两次评估之间被改动过但没有记录版本。解决评估脚本固定随机种子模型切到推理模式关闭所有训练期才用的随机操作测试集打上内容哈希评估报告里带上哈希值。这属于血泪经验看起来是小事排查起来能耗掉一整天。5.3 总体指标正常某个子群系统性出错现象总体召回率达标但按用户群体、设备类型或时间段拆开看某个子群的召回率明显偏低。原因测试集的子群样本量不足或者训练数据里该子群样本占比过低导致模型没学好。也有可能是标注标准在该子群上不一致。解决评估报告强制按关键维度分群输出子群样本量低于阈值的标注“样本不足结论不可靠”对低表现子群做标注质量抽检排除标注问题后再判断是否属于模型偏差。这一步不做偏差问题会一直藏在平均值里。5.4 蜕变测试关系写得太宽或太严现象蜕变测试要么一条违反都报不出来要么报出大量违反但人工复核全是误报。原因关系函数里的容忍度是拍脑袋定的没有在已知正常的模型上做校准。解决先在基线模型上跑一遍蜕变关系统计违反率分布用分位数定阈值再把关系按语义强度分层强关系标签不变和弱关系置信度变化在区间内分开统计。校准这一步省不得否则蜕变测试会变成噪音发生器。5.5 把可解释性输出当结论用现象模型给出局部解释业务方直接拿解释去对外说明后来发现解释和模型实际行为对不上。原因可解释性方法本身有近似误差特征归因结果不稳定且不同解释方法可能给出矛盾结论。解决把解释稳定性作为独立测试项对同一批样本做输入微扰检查解释结果是否一致对外使用解释结论前必须经过测试侧确认解释与模型行为的一致性。解释是辅助判断工具不是模型行为的权威描述。6. 设计取舍测试环境、仿真度与用AI测AI的循环依赖大纲第十章讲测试环境第十一章讲用人工智能进行测试这两章放在最后不是凑数它们对应两个绕不开的取舍。第一个取舍是仿真度。AI系统的测试环境很难做到完全真实自动驾驶类系统要在仿真里跑百万公里推荐系统要用回放日志模拟线上流量。仿真度越高测试成本越高而且高仿真环境本身可能引入新的偏差。我的判断标准是仿真环境只需要在“影响被测质量特征的维度”上保真其他维度可以降级。比如测感知模块光照和天气要保真交通参与者的行为模型可以简化测决策模块交通流分布要保真渲染画质可以降级。这个取舍必须在测试计划里写清楚否则评审时会被问“仿真环境凭什么代表真实世界”而答不上来。第二个取舍是用AI测AI的循环依赖。用模型生成测试用例、用模型做结果判定、用模型做缺陷预测这些手段能提升效率但会引入一层新的不确定性判定器本身也可能出错而且它的错误模式和被测系统可能相关。比较稳妥的结构是让判定器和被测系统在数据来源、模型架构或训练目标上保持差异形成背靠背的关系。大纲第九章的背靠背测试讲的就是这个思路只是很多人只把它用在两个被测系统之间忘了判定器也需要被背靠背校验。还有一个容易被忽略的点是测试环境的版本管理。模型、数据、依赖库、仿真器任何一项版本变动测试结论的可比性就断了。我后来养成的习惯是每次评估前先打印一份环境指纹包含模型哈希、测试集哈希、关键库版本和随机种子附在评估报告首页。这个习惯来自一次排查了三天才发现是仿真器小版本升级导致行为差异的经历——从那以后我每次建基线都强制走一遍环境指纹核对不管多小的改动。希望帮到你。本文还有配套的精品资源点击获取