AI时代，谁来做AI的“质检员”？
发表日期：2026-10-01被浏览： 13次返回

AI系统正在从实验走向生产。从图像识别、视频识别到生成式AI，越来越多由数据驱动、以概率方式给出结果的系统，进入了真实业务场景。“能不能用”之后，“是否可靠、是否可信”成了更关键的问题。谁来为AI系统把住质量关？

 

9月23日，ISTQB®人工智能测试（简称CT-AI）v2.0机构＆讲师交流会顺利举办。本次交流会聚焦这一新模块的模块定位、大纲内容与认证价值，围绕“为什么要做AI测试”“模块讲什么、怎么考”“企业如何把AI质量落到流程里”三个问题展开深度研讨。CSTQB®授权培训机构代表、注册讲师与本地化专家相聚线上，共同探讨AI测试的人才培养与行业应用路径。

 

会上，ISTQB®资深专家刘海英、汽车企业AI实践者王静先后作主题分享：刘老师系统解读CT-AI v2.0大纲，王老师则作为企业AI实践者，与大家探讨交流AI在企业中的落地问题与解法。两位老师专业扎实、贴合落地，与会代表讨论热烈。

 

1.行业之变

AI系统需要一张新的“质量答卷”

 

为什么要在传统软件测试之外，单独为AI设立测试模块？

刘老师在讲到产业趋势时提到，AI已成为全球竞相投入的重点方向，产业规模持续扩大，中国更是全球AI市场的重要一极；AI正在从“单点工具”渗透到全链路业务，企业纷纷把AI纳入核心战略，AI人才与AI质量人才都变得抢手。

 

与机会并存的是代价。

AI系统的质量问题带来的损失是实实在在的：安全泄露、系统故障、模型幻觉与深度伪造滥用等问题一旦发生，往往直接冲击业务连续性、客户信任与企业声誉，甚至造成可观的经营损失。AI 系统的质量问题，正在变成真金白银的经营风险。

 

▲ 基于AI的系统（刘海英 PPT）

 

更关键的是，AI系统与传统软件存在天然差异。传统软件是显性编程、结果确定；AI系统由数据驱动，输出具有概率性——同样的输入，未必得到完全相同的输出，这决定了验收方式也要变。不能再用“和期望值逐字比对”的思路，而要借助准确率、召回率、红队评测等手段，为AI系统划出容差、阈值与“带宽”。

这些系统的安全与质量，直接影响人们的生产与生活。

 

2.模块定位

补上“如何测试AI系统”这块拼图

 

很多人容易把AI测试与生成式AI测试混为一谈。刘老师特别澄清了两件事。

第一，AI系统不只是大语言模型（LLM）。在CT-AI大纲中，AI系统既包含基于生成式AI的系统，也包含基于机器学习的系统——图像识别、视频识别、特定领域训练出来的模型，都被统称为AI系统。

第二，AI测试与生成式AI测试（简称CT-GenAI）是两个互补的模块。CT-GenAI是“如何用生成式AI帮助我们把测试做得更好”；而CT-AI解决的是“如何测试这些基于AI的系统本身”。一个是用AI做测试，一个是测试AI，方向恰好相反、互为补充。

 

延伸阅读

ISTQB®权威解读：AI测试与生成式AI测试的核心区别

 

从大纲结构看，CT-AI的内容层层递进：

 

3.认证价值

从“验证者”到“守门人”

面对“值不值得考”的问题，刘老师给出的判断是：这张证书的价值正在从“可选”变成“必选”。

原因是合规。

 

全球范围内，针对人工智能的安全评估与质量法规陆续落地——当合规成为AI系统的硬约束，“如何证明它合规”的答案就只有一个：测试。回到测试的本质，这正是CT-AI的用武之地。

 

与此同时，测试人的角色也在升级。

刘老师用一句话概括：从“验证者”到“守门人”——测试人员不再只是验证功能是否正确，而要成为AI系统的最后一道关口，评估其“行为是否可信”。随着多轮交互、记忆复用等新技术出现，Agent的测试难度显著上升，而大语言模型（LLM）的迭代速度已经从“一两个月”加快到“一两个星期”，没有专业的知识体系，很难跟上节奏。

 

▲ 新挑战与新角色——从“验证者”到“守门人”（刘海英 PPT）

 

4.企业实践

当AI开始写代码，质量关怎么守

如果说刘老师回答了“为什么要有这个模块”，王老师则与大家探讨了“企业在真实项目里到底怎么测AI”。

 

过去，AI在研发流程里更像一位“辅助者”——补全代码、检索资料、生成文档；如今，它正在成为真正的“代码生产者”。

 

在汽车研发这样安全等级要求极高的领域，AI Agent已经进入V模型全链路：从需求分析、架构设计、详细设计，到单元测试、集成测试、系统测试，每一个环节都可能由对应的Agent承接。也就是说，每一个环节都是一个小小的AI系统，它的产出会直接流入下一环节，验证这条链路上每个Agent的输出是否可靠，就成了质量团队的新任务。

 

AI写代码带来的挑战，第一个坑就出在代码生成环节。王老师总结了四类典型问题：

• 非确定性：同一场景，两次生成的结果可能不同，变量名、调用接口都可能变化，这会直接影响下游写测试用例、做回归测试的成本；

• 测试预言问题（Test Oracle）：AI的输出往往没有唯一标准答案，到底什么算“对”，需要重新定义；

• 幻觉：AI会编造不存在的接口与函数，代码逻辑看起来满足要求，编译或上车时才发现底层根本没有这个接口；

• 合规风险：汽车软件要满足编码规范与功能安全认证要求，生成式代码可能违反MISRA、ISO 26262等规则。

▲ 新挑战：当AI成为代码生产者（王静 PPT）

 

针对这些问题，王老师给到的解法一是把AI Coding Agent当作一类“锁定式AI系统”（Locked AI System）来对待。模型版本固定后行为是确定的，但每次Agent升级或提示词变更，就要视为一个新系统，重新做回归测试。围绕这一点，搭起三层质量门禁：

• 静态规则回归集：把编码规则变成AI输出的验收门禁，让规则去判断生成结果能不能过关；

• 模型版本回归：每次Agent升级或提示词变更后，自动跑一遍规则集；

• 人工抽检样本库：持续补充真实缺陷样本，验证门禁的拦截效果。

门禁要拦得住、又不能淹没开发。王老师给到的第二个解法是用真实数据训练“什么算问题”：先从真实项目中积累的缺陷出发，总结静态检查规则集，再把AI的判断结果与现有静态检查工具的规则集做映射与校验——两边冲突的问题单独成案，交由代码复盘会议人工判定，再回写规则库。这样一来，像初始化未使用变量这类“可优化但不影响逻辑”的提示被过滤掉，开发者只需要关注真正的隐患，效率与质量同时守住。

 

支撑这一切的，是代码评审+规则导入的常态化会议机制：一次会议两个固定议题，一边复盘检查结果与测试反馈、跟踪修复趋势，一边把新问题模式沉淀为新规则、经利益相关方确认后纳入清单，形成持续进化的“规则飞轮”。

 

▲ 实践：门禁规则的持续进化（王静 PPT）

 

5.交流互动

两个被反复追问的问题

问答环节，与会代表的问题很聚焦。

其一，AI生成文档和测试用例时存在非确定性，怎么办？ 

王老师的建议是"约束+校验+人工复核"：先给模板、要求按模板生成，再校验内容是否符合模板、是否有数据来源，人类工程师复核通过后才流转给下游。同时刘老师进一步补充，在CT-GenAI模块中有更具体的方法。CT-AI与CT-GenAI—— 前者聚焦AI系统的系统性测试，后者聚焦生成式AI（含文档、用例生成）的测试方法，两者合起来正好承接非确定性问题的完整解法。

 

其二，token成本怎么管？ 

会上讨论实践办法是：先做用量计量，把token消耗落到应用、落到每个Agent、落到每个人，做到“心中有数”；再按问题复杂度做智能路由——复杂问题用能力更强的模型，简单问题用更经济的模型；同时通过内部分享与用量日志分析，给出针对性的优化建议。

 

6.聚力向前

共建AI测试人才生态

 

从“用AI做测试”到“测AI系统”，人工智能正在重塑软件测试的能力边界。

对个人来说，这是一次看得见的能力升级——AI系统的测试方法、质量门禁与验收思路正在成为测试岗位的通用要求，早一步掌握，就早一步在岗位变化中站稳。

对企业来说，把“AI的产出能不能信”从个人经验沉淀成可复用的流程与规则，AI落地就更敢往前走，质量责任也更有据可依。

对行业而言，国内培训机构与讲师围绕这一模块共议本地化落地后续的教材、案例与讲师能力建设也有了共同的着力点。

 

未来，CSTQB®将持续推进CT-AI v2.0的本地化推广、讲师赋能与配套资源建设，为行业输出贴合国内AI实践场景的标准化测试能力体系，让更多从业者在AI时代拥有可迁移的专业竞争力。

 

关于CT-AI考试认证

 

ISTQB® CT-AI 模块学习资料

目前CT-AI v2.0相关配套资料正在进行中文本地化工作，预计11月上旬左右正式对外发布。大家可对官网现有资料下载查阅。

 

ISTQB® CT-AI资料下载链接

 

ISTQB® CT-AI 考试报名

ISTQB® CT-AI考试报名链接

 

ISTQB® CT-AI 系列直播

后续还会有重磅主题直播分享，更多行业干货，敬请锁定CSTQB®公众号。