我对AI测试现状的一些思考

这段时间一直在参与 AI 应用测试、AI 测试制度建设、评测集设计和自动化测试工具探索。越往前推进，越能感觉到：AI 测试已经不是一个单纯的技术问题，而是一个测试理念、测试方法、测试标准和测试组织方式都需要重新梳理的问题。

过去我们测试传统系统，面对的是相对确定的功能逻辑、交易链路和数据流转。需求说明清楚以后，测试人员可以围绕输入、处理、输出设计用例，判断结果是否符合预期。即使是性能测试、安全测试，也有比较成熟的方法体系和指标体系。

但 AI 应用不太一样。它的输出具有不确定性，质量判断更依赖业务语境，问题表现也更复杂。有时候它不是“不能用”，而是“看起来能用，但不够准”；不是“直接报错”，而是“回答不完整、不稳定、不符合业务口径”；不是“功能失败”，而是“在特定输入、特定上下文、特定风险场景下表现不可控”。

这就使 AI 测试不能简单套用传统测试方法。我们需要在原有测试体系基础上，重新思考 AI 应用到底测什么、怎么测、怎么判断、怎么准出。

一、AI 测试目前最大的难点，是质量判断还没有完全标准化

我认为，当前 AI 测试最核心的问题，不是没有测试方法，而是质量判断标准还不够清楚。

传统系统测试中，很多结果是明确的。比如字段是否正确保存，流程是否按规则流转，接口返回是否符合约定，报表数据是否计算正确。这些都可以通过明确的预期结果来判断。

但 AI 应用的很多结果不是简单的“对”或“错”。比如智能问答场景，模型回答了制度内容，但是否完整？是否准确？是否引用了正确依据？是否遗漏了关键限制条件？是否存在过度解释？是否让用户产生误解？这些都需要进一步判断。

智能写作场景也是一样。模型生成了一篇材料，结构完整、语句通顺，但是否符合业务语境？是否符合单位文风？是否存在事实编造？是否把不确定内容写成了确定结论？这些问题很难只靠简单的断言判断。

所以 AI 测试面临的第一个问题，就是“怎么判”。如果没有清晰的评价标准，测试就会变成主观感受：有人觉得可以，有人觉得不行；业务觉得不准，研发觉得已经回答了；测试发现问题，但问题等级不好定，准出结论也不好写。

因此，我认为 AI 测试必须尽快从“用例执行型测试”向“评价标准驱动型测试”转变。测试用例只是载体，背后真正重要的是评价维度、评价规则和准出标准。

比如对于智能问答，至少要考虑准确性、完整性、依据一致性、拒答合理性、上下文稳定性、敏感内容控制等维度。对于智能问数，要考虑指标理解准确性、SQL 或查询逻辑正确性、权限边界、口径一致性、结果可解释性。对于智能文案，要考虑事实一致性、格式符合性、表达风格、业务适配性和不可编造约束。

只有把这些评价维度拆清楚，AI 测试才不会停留在“问几个问题看看效果”的阶段。

二、AI 测试不能只测模型，要测完整应用链路

现在一提 AI 测试，很多人容易直接想到大模型评测，比如准确率、幻觉率、拒答率、安全性等。这当然重要，但从实际项目测试角度看，只测模型是不够的。

用户真正使用的是 AI 应用，不是裸模型。

一个 AI 应用通常包括前端交互、用户权限、业务流程、知识库或 RAG 工具链、提示词编排、模型服务、插件调用、文件处理、日志审计、内容安全、结果导出等多个环节。任何一个环节出问题，都会影响最终使用效果。

比如智能问答回答不准确，问题不一定出在模型本身。可能是知识库资料缺失，可能是切片策略不合理，可能是召回内容不相关，可能是重排序效果不好，可能是提示词约束不清楚，也可能是业务制度本身版本混乱。

再比如会议纪要功能生成效果不好，可能不是模型能力问题，而是音频转写准确率、多人发言识别、模板解析、上下文长度、导出格式等环节共同影响。

所以 AI 测试不能只盯模型输出，而要看完整链路。测试设计时，要把 AI 应用拆成几个层次：

第一层是基础功能。包括页面操作、文件上传、任务创建、结果展示、导出下载、权限控制等，这部分仍然可以沿用传统功能测试方法。

第二层是模型效果。包括问答准确性、生成质量、上下文理解、拒答能力、安全围栏、稳定性等。

第三层是工具链能力。特别是 RAG、插件调用、智能问数、文档解析、OCR、语音转写等场景，要验证从输入到检索、处理、生成、展示的全过程。

第四层是工程能力。包括性能、稳定性、并发访问、长文本输入输出、异常恢复、日志追踪、审计留痕、服务降级等。

第五层是管理能力。包括测试准入准出、评测集管理、评价指标、问题分级、风险确认和版本回归机制。

只有这样看，AI 测试才不会被简化成“测模型回答得好不好”。

三、AI 测试要重视场景分类，不同场景不能用一套方法

AI 应用的类型不同，测试重点也不同。现在很多 AI 测试讨论容易把所有场景混在一起说，导致方法看起来全面，但真正落地时不够具体。

比如智能问答、智能问数、智能文案、智能审查、多模态生成、舆情监测，这些场景的风险点完全不同。

智能问答的核心风险是回答是否准确、依据是否可靠、拒答是否合理、制度版本是否一致。

智能问数的核心风险是指标口径是否理解正确、查询逻辑是否正确、权限是否越界、结果是否可解释。

智能文案的核心风险是事实是否编造、表达是否符合业务要求、材料结构是否可用、是否把不确定内容写实。

智能审查的核心风险是规则识别是否完整、风险提示是否准确、审查意见是否可追溯。

多模态内容生成的核心风险是内容合规、图文一致、生成质量、版权和安全边界。

舆情监测的核心风险是数据来源、实时性、召回率、误报率、风险信号识别能力。

这些场景不能用同一套用例模板简单覆盖。AI 测试一定要做场景分类，并在分类基础上设计不同的测试点、评价规则和样本集。

我现在越来越倾向于把 AI 测试看成“场景化评价工程”。也就是说，不能先问“AI 应用怎么测”，而要先问“这个 AI 场景的业务目标是什么、主要风险是什么、输出结果如何影响业务决策”。

不同场景的测试目标不同，准出标准也应该不同。低风险办公辅助场景，可以更关注可用性、体验和效率；高风险业务辅助决策场景，就必须更关注准确性、可解释性、权限边界和人工确认机制。

这也是后续制度建设中需要明确的内容：不同风险等级、不同应用场景，应当采用差异化的验证要求，不能所有场景一刀切。

四、AI 测试要把“评测集”作为核心资产建设

传统测试中，测试用例是核心资产。AI 测试中，评测集会成为更关键的资产。

因为 AI 应用的质量不是靠一次性执行就能完全判断的。模型版本会变，提示词会调，知识库会更新，安全围栏会修改，应用功能也会不断迭代。每次变更后，都需要用稳定的评测集来判断质量是否提升、是否退化、是否引入新的风险。

一个好的 AI 测试评测集，不只是问题列表，而应该包含明确的测试意图、输入样本、适用场景、评价维度、参考答案或判断规则、预期风险、优先级、是否可自动化等信息。

比如智能问答评测集，不能只放一些普通问题，还要覆盖：

制度原文直接问答；

跨章节综合问答；

边界条件问答；

相似概念区分；

过期制度干扰；

无依据问题拒答；

敏感问题拒答；

多轮上下文追问；

长文本输入；

诱导性提问；

业务高频问题；

历史生产或使用中发现的问题。

这些样本积累得越多，AI 应用测试就越有依据。

评测集还要分层管理。基础回归集用于每次版本更新后的快速验证；专项评测集用于某类能力或风险的深入验证；安全对抗集用于测试拒答和内容安全；性能评测集用于控制输入输出长度、并发模型和 token 生成速率；业务黄金集用于验证核心场景的准确性和稳定性。

从测试管理角度看，评测集不是一次性交付物，而是长期资产。它需要持续补充、版本管理、问题回流和自动化执行。否则每次测试都临时找问题，AI 测试就很难形成稳定能力。

五、AI 应用的性能测试不能被忽视

当前谈 AI 测试时，大家更容易关注回答准确性、幻觉、安全合规等问题，但 AI 应用的性能测试同样重要，而且测试方法需要调整。

传统性能测试更多关注 TPS、响应时间、并发用户数、资源使用率、稳定性等指标。AI 应用仍然需要这些指标，但还不够。

对于大模型应用，还要关注首 token 响应时间、token 生成速率、总生成耗时、长文本输入下的响应表现、并发下的排队等待、上下文长度对性能的影响、模型服务稳定性、算力资源利用率、流式输出稳定性等。

比如一个智能问答应用，如果普通短问题响应还可以，但输入较长制度文本后响应明显变慢；或者并发上来后首 token 时间变长；或者生成过程中偶发中断；或者 token 生成速率达不到用户体验要求，这些都会直接影响应用可用性。

AI 应用性能测试还要注意输入输出规模。不能只用短问题测试，也要设计固定输入长度、固定输出长度、长文本输入、长文本生成、复杂上下文、多轮会话等场景。否则测出来的数据容易偏乐观。

我认为，AI 应用性能测试至少要覆盖几类场景：

一是单业务基准测试，了解不同模型、不同场景下的基础响应能力。

二是并发递增测试，观察并发提升后响应时间、错误率和资源变化。

三是混合业务场景，模拟多个 AI 功能同时使用时的整体表现。

四是长文本和边界场景，验证上下文长度、文件解析、长输出对性能的影响。

五是稳定性测试，观察长时间运行下模型服务、应用服务、网关和依赖组件是否稳定。

六是异常场景测试，比如模型服务不可用、知识库检索异常、第三方插件超时等情况下应用如何处理。

AI 应用如果未来要进入真实业务场景，仅有“能回答”是不够的，还要能稳定、及时、可持续地回答。

六、AI 测试自动化要做，但不能只做接口调用

AI 测试自动化是必然方向。人工逐条提问、人工看答案、人工整理结果，短期可以支撑试点，长期一定不可持续。

但 AI 测试自动化也不能简单理解为“批量调用接口”。如果只是把问题批量发给模型，再把回答保存到 Excel，这只是最基础的一步。

真正有价值的 AI 测试自动化，应该包括几个能力：

一是用例集管理。支持不同场景、不同标签、不同优先级、不同风险等级的样本管理。

二是批量执行。支持接口调用、并发控制、失败重试、超时处理、结果保存。

三是结果评价。支持规则判断、人工评价、AI 辅助评价以及多维度评分。

四是对比分析。支持不同模型版本、不同提示词版本、不同知识库版本之间的效果对比。

五是问题沉淀。把失败样本、低分样本、高风险样本回流到评测集。

六是报告输出。自动汇总准确率、拒答率、稳定性、主要问题类型和风险建议。

尤其是评价环节，不能完全依赖模型自己评自己。AI 辅助判定可以提高效率，但关键样本、争议样本、高风险样本仍然需要人工复核。比较合理的方式是“自动化执行 + AI 辅助初评 + 人工抽检/复核 + 结果沉淀”。

从工具建设角度看，AI 测试自动化不能只做成一个脚本，而应该逐步形成平台化能力。哪怕一开始很轻量，也要在设计上考虑用例管理、执行记录、评价结果、版本对比和问题回流。否则脚本越写越多，最终也会变成新的维护负担。

七、AI 测试制度建设必须跟上，否则测试容易失去边界

AI 应用测试还有一个现实问题：如果制度和流程不清楚，测试很容易变成无限责任。

AI 应用本身不确定性较高，业务期望也容易变化。如果没有明确的准入、测试范围、评价标准和准出要求，测试人员很容易陷入被动：业务觉得不好用就让测试继续测，研发调了提示词就让测试重新测，知识库换了资料也要测，模型版本变了还要测，但每次测到什么程度算完成并不清楚。

所以 AI 测试必须有制度化支撑。

我认为至少要明确几件事：

第一，AI 应用提测前要满足哪些准入条件。比如需求场景是否明确、知识库资料是否确认、模型或智能体配置是否稳定、接口是否可用、权限边界是否说明、评价标准是否初步确定。

第二，不同类型 AI 场景分别要测哪些内容。不能所有场景都只用一套笼统测试方案。

第三，测试结论如何形成。哪些问题属于功能问题，哪些属于效果问题，哪些属于安全问题，哪些属于性能问题，哪些属于体验问题，要有基本分类。

第四，准出标准如何制定。不同风险等级、不同使用范围、不同业务影响程度的 AI 应用，准出要求应该不同。

第五，变更后如何回归。模型、提示词、知识库、业务规则、插件工具、应用代码发生变化后，分别触发什么范围的回归测试。

第六，人工确认机制如何保留。对高风险场景，AI 输出不能直接作为最终业务结论，必须明确人工确认或复核要求。

这些制度不是为了给测试自己加枷锁，而是为了让 AI 应用建设各方对质量要求形成共同理解。制度越清楚，测试边界越清楚，协同效率也越高。

八、AI 测试对测试人员提出了更高要求

AI 测试不是降低测试人员要求，而是提高了要求。

过去测试人员更多关注功能逻辑、流程规则、数据正确性和缺陷管理。现在 AI 测试要求测试人员同时具备业务理解、质量判断、数据意识、评价设计、工具使用和一定的模型理解能力。

测试人员至少要能回答几个问题：

这个 AI 场景解决的业务问题是什么？

用户会在什么情况下使用它？

输出结果如果不准确，会造成什么影响？

哪些问题需要模型回答，哪些问题应该拒答？

哪些样本能代表核心业务风险？

评价结果应该怎么量化？

自动化执行结果如何判断可信？

版本变化后应该回归哪些能力？

这些问题都不是简单写用例能解决的。

未来 AI 测试人员的竞争力，不只是会不会测 AI 工具，而是能不能建立一套适合具体业务场景的评价方法。能不能把业务风险转化成评测样本，把质量要求转化成评分规则，把测试问题转化成可改进的研发输入，把一次测试经验转化成后续可复用的评测资产。

这对测试经理也提出了要求。不能只安排大家执行任务，还要带着团队建设方法、建设资产、建设工具、建设标准。否则 AI 测试会一直停留在试点式、临时性、人工密集型状态。

九、我对当前 AI 测试阶段的基本判断

总体看，我认为当前 AI 测试还处在从“经验探索”向“工程化治理”过渡的阶段。

前一阶段，大家更多是在试：拿一些问题去问，看看回答准不准；做一些安全对抗，看看能不能拒答；跑一些接口，看看性能怎么样。这是必要的，但不够。

下一阶段，AI 测试必须逐步走向工程化。工程化至少包括几个方面：

测试对象要分层。区分模型、智能体、工具链、应用功能、业务场景。

测试方法要分类。不同 AI 场景采用不同测试策略。

评价标准要明确。不能只靠主观感受判断效果。

评测集要资产化。样本、规则、结果、问题要持续沉淀。

执行过程要自动化。减少人工重复执行，提高回归效率。

测试结论要可追溯。说明依据、数据、问题和风险。

管理流程要制度化。明确准入、准出、变更、回归和人工确认要求。

从这个角度看，AI 测试不是传统测试的一次小扩展，而是测试体系的一次重构。它既需要继承传统测试中成熟的流程、缺陷、性能、安全、自动化方法，也需要补上评价标准、评测集、模型效果分析、内容安全和业务语义判断这些新能力。

十、结语：AI 测试最终要回到质量保障本身

我对 AI 测试现状的一个基本看法是：现在大家都知道 AI 应用需要测试，但很多时候还没有真正想清楚 AI 测试的目标。

AI 测试不是为了证明模型很强，也不是为了简单发现几个回答不准的问题，更不是为了生成一堆测试材料。它的目标仍然是质量保障：在 AI 应用进入真实业务场景前，尽可能识别风险、明确边界、推动改进，并给出可信的测试结论。

只是这个“质量”的含义变得更复杂了。它不仅包括功能可用，还包括回答准确、依据可靠、输出安全、性能稳定、权限可控、结果可解释、风险可管理。

因此，AI 测试不能只靠临时经验，也不能只靠单点工具。它需要制度、方法、评测集、自动化工具和团队能力共同支撑。

对我来说，后续推进 AI 测试工作，有几件事会比较关键：

一是把不同 AI 场景的测试关注点拆清楚，不能笼统谈 AI 测试。

二是把评价标准和评测集建设起来，让测试结论有依据。

三是把性能、安全、功能、效果评测放到完整应用链路中看。

四是把自动化工具做起来，减少人工重复执行，提高回归效率。

五是把制度和流程补齐，明确准入、准出、变更和责任边界。

六是让团队成员在具体项目中逐步形成 AI 测试判断力。

AI 测试现在还没有完全成熟的方法模板，但正因为如此，测试团队才更应该主动参与。谁能更早把业务理解、质量判断、测试方法和工程化工具结合起来，谁就能在 AI 应用快速发展的过程中掌握更多主动权。

我认为，AI 测试未来真正的价值，不是简单回答“这个模型好不好”，而是帮助组织回答一个更重要的问题：这个 AI 应用，在我们的业务场景中，是否足够可靠、足够安全、足够可控，能不能承担它被赋予的业务任务。