内部流出：快手质量中台用大模型做“智能冒烟”，提测就打回，研发再也不敢敷衍

从“人肉验尸”到“AI门神”，研发提测通过率从43%干到91%

大家好，我是快手质量中台的一名技术负责人，负责研发质量门禁体系建设。

今天想聊一个让所有测试同学都解气的话题——用大模型做智能冒烟测试，把研发提测质量的门槛焊死。

先上数据：系统上线半年，研发提测通过率从43%提升到91% ，冒烟测试的人力投入从每版本4人天压缩到完全自动化，研发被“打回重做”的次数从平均每版本2.3次降到0.4次。

研发同学再也不敢拿“我本地跑过了”来敷衍了。

一、冒烟测试为什么成了“形同虚设”？

先说说冒烟测试这个环节在快手是怎么沦陷的。

我们的业务迭代速度有多快？主站每天几百次代码合入，每周几十个版本提测。冒烟测试的本意是“提测前快速验证核心功能是否可用”，但在实际执行中，这个环节基本废了。

研发侧的问题：提测前自己跑一遍冒烟？不存在的。大部分人把代码一合、本地随便点两下就算“自测过了”。更离谱的是，有人连编译都没过就直接提测了。

测试侧的问题：接手的测试同学得先花半天到一天跑一遍冒烟用例，跑不通就打回让研发修，修好了再提测，再跑一遍。一个版本来回折腾两三次是常态。

最坑的是：冒烟用例本身是人工维护的，业务迭代快，用例根本跟不上代码变更。测试同学花大量时间维护冒烟用例，结果覆盖的都是一些“过时”的功能，真正容易出问题的核心链路反而没覆盖到。

说白了，冒烟测试成了测试团队替研发擦屁股的环节，而不是质量门禁。

二、转折：把冒烟测试做成“智能门禁”

去年下半年，质量中台启动了一个项目——把冒烟测试从“人肉执行”升级为“AI自动门禁” 。

目标很明确：研发提交代码合入请求时，AI自动执行冒烟测试，不通过就直接拦在门外，不让合入。

这个想法听起来简单，但落地过程中踩了无数坑。下面我把整个方案拆开来讲。

三、技术方案：三层架构

我们的智能冒烟系统分成三层：

第一层：用例生成层 —— AI自动生成和维护冒烟用例

第二层：执行引擎层 —— 自动化执行 + AI结果判定

第三层：门禁控制层 —— 与Git/CI系统打通，自动拦截

第一层：AI自动生成冒烟用例（这是最核心的突破）

传统冒烟用例全靠人工维护，业务一变就废。我们让AI来做这件事。

第一步：从PRD和代码变更里“读懂”要测什么

当研发提交一个MR（Merge Request）时，系统自动拉取：

• 本次变更涉及的代码文件
• 关联的需求文档（PRD）
• 变更影响的功能模块

然后AI分析这些信息，自动生成针对本次变更的冒烟用例集合。

举个例子：研发改了“直播间礼物赠送”的逻辑，AI会自动生成：

• 打开直播间 → 点击礼物面板 → 选择礼物 → 点击赠送 → 验证礼物数量扣减 → 验证主播收到礼物通知

完全不需要人工写一行用例。

第二步：从历史Bug里学“哪些地方最容易出事”

光靠PRD生成的用例太“正”了，容易漏掉边界场景。

我们把过去三年的几千个线上Bug喂给了大模型，让它学会：

• 哪些功能模块历史上出事最多
• 哪些场景下最容易触发Bug
• 哪些“看起来没问题”的地方其实藏着雷

然后AI在生成冒烟用例时，会自动补充这些高风险场景。

真实案例：有一次一个研发改了“评论点赞”的逻辑，改动很小。但AI从历史Bug里检索到——这个模块在高并发场景下出过两次P0（点赞数错乱）。于是AI自动在冒烟用例里加了一条：“模拟100个用户同时点赞同一评论，验证计数是否准确”。

这条用例如果靠人工写，大概率会被忽略。而正是这条用例，在冒烟阶段就拦住了那次提测——代码在高并发下确实有问题。

第三步：用例的“自进化”

冒烟用例不是生成一次就完了。每次冒烟执行后，系统会自动分析：

• 哪些用例经常发现Bug → 标记为“高价值用例”，永久保留
• 哪些用例从来没发现过问题 → 标记为“低价值”，自动降频或淘汰
• 哪些新场景没有被覆盖 → 自动补充

这就是快手在AI测试探索中强调的 “自检测&自进化”能力。目前我们的冒烟用例库已经积累了超过120万条自动生成的用例，每天还在持续迭代。

第二层：AI自动执行 + 智能判定

用例生成了，谁来执行？怎么判断结果对不对？

执行层面：我们有一套自研的UI自动化执行引擎，可以模拟用户在真实App上的操作。AI生成的用例是自然语言描述的（比如“点击礼物面板”），执行引擎会自动理解并转化为具体操作。

判定层面：这是最大的技术难点。

传统自动化测试的“通过/失败”判断靠的是断言——比如“检查某个元素是否出现”。但冒烟测试的场景千变万化，没法写死断言。

我们的方案是：用多模态大模型做结果判定。

执行完一个操作后，系统截取当前屏幕截图，喂给多模态模型，让它判断：

• 页面是否正常加载（没有白屏、崩溃）
• 操作是否生效（比如点击“赠送”后，礼物数量是否扣减了）
• 有没有出现异常弹窗或报错

判断依据不是写死的规则，而是模型对“正常状态”的理解。

这个方案我们迭代了很长时间。初期误判率很高——模型有时候把“网络慢导致的加载中”误判为“页面异常”。后来我们加了置信度阈值和人工复核兜底，误判率才从最初的30%降到了现在的不到5% 。

第三层：门禁控制 —— 不过就不让合入

这是让研发“再也不敢敷衍”的关键。

系统跟我们的Git平台和CI流水线打通。流程是这样的：

1. 研发提交MR
2. CI自动触发智能冒烟测试
3. AI生成用例 → 自动执行 → AI判定结果
4. 如果不通过：MR自动标记为“Blocked”，并生成详细的失败报告——哪个用例失败了、失败截图是什么、AI判断的失败原因是什么
5. 研发必须修复问题后重新提测，冒烟通过才能合入

以前：研发提测 → 测试跑冒烟 → 发现不行 → 打回 → 研发修 → 再提测 → 测试再跑……来回折腾

现在：研发提交MR → AI自动冒烟 → 不通过直接拦住 → 研发自己看报告修 → 修好了重新提交 → AI再跑一遍

测试同学全程不需要介入，除非AI判定置信度低需要人工复核。

人工智能技术学习交流群

四、研发的真实反应：“再也不敢敷衍了”

系统上线第一个月，研发的反馈是一片哀嚎。

“怎么又被打回了？”“我本地明明跑过了啊！”“这个用例谁写的？太变态了吧！”

但三个月后，风向变了。

第一个变化：研发开始主动在本地先跑一遍冒烟再提测。因为被打回太丢人了——MR上清清楚楚写着“冒烟未通过”，全组都看得见。

第二个变化：研发开始认真对待自测。以前“本地点两下”就算自测了，现在他们会对照AI生成的冒烟用例，逐条验证。因为AI会覆盖他们没想到的场景，不提前验证的话，提测大概率被打回。

第三个变化：研发开始反向优化代码质量。有些模块频繁在冒烟阶段被打回，研发团队会主动做代码重构或补充单元测试。因为被打回太多次会影响团队的效能度量。

有个研发Leader私下跟我说：“以前测试打回提测，我们觉得是测试在'卡'我们。现在AI打回，我们没话说——报告上写得清清楚楚，哪个场景挂了、为什么挂，确实是我们的问题。”

五、踩过的坑（说几个真实的）

坑一：AI生成的用例“太泛了”，没法直接执行

V1.0的时候，AI生成的用例是这样的：“验证直播间功能正常”——太宽泛了，执行引擎根本不知道该做什么。

解法：我们在Prompt里加了严格的格式约束，要求AI输出的每条用例必须包含：前置条件、操作步骤（每一步都要具体到点击什么元素）、预期结果。同时用Few-shot示例教会AI什么是“可执行的用例”。

坑二：不同机型的UI差异导致执行失败

同一个“点击礼物面板”，在华为和小米上的UI位置可能不同。执行引擎经常找不到元素。

解法：引入了多模态视觉定位——不依赖XPath或ID，而是用视觉模型在屏幕上“找”目标元素。只要文字或图标语义一致，不管位置在哪都能识别。这个方案让执行成功率从67%提升到了94% 。

坑三：AI判定太敏感，误报率居高不下

初期AI看到任何“异常”都报失败——网络慢加载转圈、广告弹窗、甚至是系统更新提示，都被判为“页面异常”。

解法：建立了分层判定体系：

• 明显崩溃/白屏 → 直接判失败
• 疑似异常（加载慢、弹窗）→ 标记为“需人工复核”
• 正常 → 判通过

同时用大量历史执行数据持续微调判定阈值。现在误报率控制在5%以内，人工复核的工作量每版本不到30分钟。

六、效果数据总结

说几个硬数据：

最关键的变化：冒烟测试从“测试团队的负担”变成了“研发团队的自检工具”。测试同学不用再替研发擦屁股了，省下来的时间用来做更有价值的探索性测试和测试策略设计。

七、给同行的一些建议

如果你也在做类似的尝试，我有几点掏心窝的话：

1. 先从“门禁”切入，别一上来就搞全流程智能化

我们是从“MR门禁”这一个点切进去的——只做提测前的自动冒烟拦截。跑通了再逐步扩展到全流程。一上来就想覆盖所有测试环节，大概率会失败。

2. “用例可执行”比“用例多”重要得多

V1.0我们生成率只有8%，因为生成的用例“太泛了，没法直接用”。后来我们在Prompt里加了严格的格式约束和Few-shot示例，生成率才慢慢爬上来。宁可少生成几条能用的，也不要生成一堆不能用的。

3. 让AI学会“历史踩过的坑”

这是我们的核心经验。光靠PRD生成的用例太“正”了，覆盖不了真实线上出过的问题。一定要把历史Bug数据喂给模型，让它学会“哪些地方容易出事”。历史缺陷是最好的训练数据。

4. 接受AI的不完美，但门禁标准不能妥协

AI判定会有误报，但我们从来没有因为“AI可能误判”就放行不通过的提测。宁可误报让研发多修一次，也不能漏报让问题上线。门禁就是门禁，标准不能降。

5. 给研发“看得懂”的反馈

被打回不可怕，可怕的是不知道为什么被打回。我们在每个失败报告里都附上了失败截图、AI判断依据、建议修复方向。研发拿到报告就知道问题在哪，不用猜。

最后

AI做冒烟测试，不是为了“取代测试工程师”，而是把测试工程师从“人肉门禁”的岗位上解放出来。

现在我们的测试同学不用再花大量时间跑冒烟、跟研发扯皮“这个算不算Bug”了。大家把精力放在了更有价值的事上——设计更精准的测试策略、分析线上质量数据、持续优化AI模型的效果。

而研发同学，也因为有了这道“AI门神”，被迫提升了自测质量。长期来看，这对整个研发团队的代码质量意识是一次彻底的洗礼。

如果你团队还在被“研发提测质量差”的问题困扰，我建议你认真考虑一下这个方向。技术门槛没有想象中那么高——一个大模型 + 一套自动化执行引擎 + 历史Bug数据，就能搭起来。

关键是：你敢不敢把门禁焊死？