专场：Agent 驱动的智能化测试：从辅助到自治
测试是智能体落地最成熟的场景。完整拆解 AI 测试演进链路：从 AI 辅助生成测试用例、Agent 自主执行测试、自主研判结果到自主闭环修复，落地 LLM 赋能下测试左移、测试右移一体化自治测试体系，输出覆盖需求到上线全流程的智能化质量落地实践。
专场出品人：岑坚
淘天集团 营销技术质量负责人 高级测试开发专家
淘天集团营销技术质量负责人，高级测试开发专家，2010年校招入职阿里，深耕电商质量工程16年。连续8届担任双11、618集团业务质量负责人（PTM），协调35+BU保障大促业务确定性；从0到1构建大促预演平台并推动SAAS化，打造"未来版淘宝"实现体验确定性前置。《阿里测试之道》联合作者。
近两年，带领团队全面转向AI原生质量工程，完整经历了专题所述的演进链路：从AI辅助用例生成与代码评审（测试左移），到数字员工自主执行会场验收、端智能路径规划（Agent自主执行），再到AI驱动的结果分析与问题定位、AI值守自主修复（测试右移）。大促端到端执行效率、深度超10倍提升，营销域验收人力投入降低80%，AI值守准确率、稳定性99.9%。同时定义了面向营销业务的智能体评测方法论，构建营销标准评测集，推动"AI评测AI"的新范式落地。
王一勃
58同城 高级研发工程师
58同城高级研发工程师，具备深厚的一线研发与质量保障实战经验，拥有多项 AI 测试领域的发明专利。曾深耕 AI 代码辅助工具的研发，对 AI 技术的底层实现机制与工程落地风险有极其深刻的洞察。近年来，全面聚焦 AI 技术与软件测试的深度融合，主导设计并落地了新一代智能测试解决方案。致力于依托大语言模型与自动化技术的双轮驱动重塑测试体系，为企业级研发效能的跃升提供坚实支撑。
待定
待定
基于业务链路的 Web UI Agent 智能化测试实践
议题背景：
Web UI 测试正从脚本化执行进入智能化探索阶段。传统 UI 自动化依赖显式脚本和稳定元素定位，在业务快速迭代、页面频繁变化的场景下，往往面临维护成本高、链路复用弱、失败定位困难等问题。Agent 的引入，为自然语言驱动测试提供了新的可能，但也暴露出执行不确定、验证不充分、结果难追溯等工程化挑战。
本议题以业务链路管理为切入点，分享结合 Agent 执行、视觉证据与结果校验的 Web UI 智能测试实践，探索如何将一次性的智能执行沉淀为可复用、可验证、可持续演进的测试能力。
内容大纲：
1. Agent 测试的背景与机遇
Web UI 测试正从脚本化执行进入智能化探索阶段。传统 UI 自动化依赖显式脚本和稳定元素定位，在业务快速迭代、页面频繁变化的场景下，往往面临维护成本高、链路复用弱、失败定位困难等问题。Agent 的引入，为自然语言驱动测试提供了新的可能，但也暴露出执行不确定、验证不充分、结果难追溯等工程化挑战。
本议题以业务链路管理为切入点，分享结合 Agent 执行、视觉证据与结果校验的 Web UI 智能测试实践，探索如何将一次性的智能执行沉淀为可复用、可验证、可持续演进的测试能力。
内容大纲：
1. Agent 测试的背景与机遇
1.1 传统 UI 自动化测试面临的挑战
1.2 Agent 带来的能力变化
1.3 AI 测试落地的关键问题
1.2 Agent 带来的能力变化
1.3 AI 测试落地的关键问题
2. Web UI 智能测试架构
2.1 整体架构设计
2.2 核心流程闭环
2.3 需求智能探索测试演示
2.2 核心流程闭环
2.3 需求智能探索测试演示
3. 关键技术实践
3.1 需求难落地：测试意图建模
3.1.1 业务目标与验证意图解析
3.1.2 结构化任务生成与校验
3.1.3 短周期规划与路径调整
3.1.2 结构化任务生成与校验
3.1.3 短周期规划与路径调整
3.2 元素难找准：语义视觉定位
3.2.1 页面快照与候选元素构建
3.2.2 语义、结构、视觉多证据匹配
3.2.3 SOM 标注与有界视觉仲裁
3.2.2 语义、结构、视觉多证据匹配
3.2.3 SOM 标注与有界视觉仲裁
3.3 流程易跑偏：状态感知执行
3.3.1 执行前后页面状态观测
3.3.2 反思恢复与动态重规划
3.3.3 登录、风控、异常状态栅栏
3.3.2 反思恢复与动态重规划
3.3.3 登录、风控、异常状态栅栏
3.4 结果难可信：多层验证闭环
3.4.1 操作效果与页面状态验证
3.4.2 任务级业务目标验证
3.4.3 报告证据链与链路沉淀
3.4.2 任务级业务目标验证
3.4.3 报告证据链与链路沉淀
4. 未来规划与展望
听众收益：
1. 建立对 Web UI Agent 测试的系统认知，理解其从“页面操作自动化”走向“业务目标驱动执行”的能力边界与落地价值。
2. 掌握以业务链路为核心的智能测试设计思路，理解业务链路、Agent 执行、视觉证据与结果验证之间的协同机制。
3. 获得一套可落地的轻量化建设路径：通过链路沉淀提升资产复用，通过 Agent 执行增强测试弹性，通过报告与验证机制保障结果可信。
听众收益：
1. 建立对 Web UI Agent 测试的系统认知，理解其从“页面操作自动化”走向“业务目标驱动执行”的能力边界与落地价值。
2. 掌握以业务链路为核心的智能测试设计思路，理解业务链路、Agent 执行、视觉证据与结果验证之间的协同机制。
3. 获得一套可落地的轻量化建设路径：通过链路沉淀提升资产复用，通过 Agent 执行增强测试弹性，通过报告与验证机制保障结果可信。
郭梦茹
腾讯音乐 高级测试开发工程师
QQ音乐研发效能中心专项测试开发组高级测试开发工程师，主要负责QQ音乐、全民k歌等业务线下全部APP的性能专项测试保障体系建设、包括标准制定，大型、创新型项目的性能质量保障工作；同时主导CICD、AI代码漏洞挖掘专项工作。
待定
待定
双引擎驱动 + 调用链穿透：AI时代代码问题挖掘的规模化落地实践
议题背景：
AI Coding 时代代码产出效率飙升，但内存泄漏、crash、跨模块异常等深层逻辑缺陷仍高度依赖资深专家人工Review，传统Lint规则仅覆盖表层规范，漏报率超60%；且单次扫描动辄数百条告警，误报率超30%，人工二次分析成本居高不下。我们系统性建设了静态代码问题挖掘与质量左移工具链，核心创新在于：
AI Coding 时代代码产出效率飙升，但内存泄漏、crash、跨模块异常等深层逻辑缺陷仍高度依赖资深专家人工Review，传统Lint规则仅覆盖表层规范，漏报率超60%；且单次扫描动辄数百条告警，误报率超30%，人工二次分析成本居高不下。我们系统性建设了静态代码问题挖掘与质量左移工具链，核心创新在于：
① 双引擎融合检测——CI阶段传统Lint快速拦截规范问题，转测阶段AI智能检测覆盖隐式逻辑缺陷；
② 代码调用链图谱——突破单文件局限，精准追踪跨模块异常传播路径；
③ 误报分析自闭环Agent——实现“检测-分析-沉淀-优化”自动化循环。该体系各业务常态化运行，单季度累计发现有效问题2500+例，前置发现率从6%提升至20%+，沉淀规则1000余条、Agent及Skill 10余个，并提交相关专利7篇
内容大纲：
1. 困境：传统Lint为什么“管得了格式，管不住质量”
内容大纲：
1. 困境：传统Lint为什么“管得了格式，管不住质量”
1.1 AI生成代码带来的深层隐患：内存泄漏、crash、并发竞争等依赖上下文分析的缺陷占比激增
1.2 传统Lint的“三座大山”：规则覆盖不全、误报率高、跨文件分析能力缺失
1.3 目标设定：将静态问题前置发现率从个位数提升至20%以上，同时压降人工二次分析成本
1.2 传统Lint的“三座大山”：规则覆盖不全、误报率高、跨文件分析能力缺失
1.3 目标设定：将静态问题前置发现率从个位数提升至20%以上，同时压降人工二次分析成本
2. 破局：双引擎融合检测体系的设计与演进
2.1 整体架构：CI/CD流水线嵌入传统Lint（合入前自动拦截）+ 转测阶段AI智能检测（深度隐式问题挖掘）的分层策略
2.2 规则分层治理：SwiftLint/FindBugs等传统规则的场景化裁剪与阈值调优，降低基础误报
2.3 AI规则引擎：基于大模型的代码语义理解，覆盖传统工具无法检出的复杂逻辑缺陷
2.2 规则分层治理：SwiftLint/FindBugs等传统规则的场景化裁剪与阈值调优，降低基础误报
2.3 AI规则引擎：基于大模型的代码语义理解，覆盖传统工具无法检出的复杂逻辑缺陷
3. 核心突破：代码调用链图谱的构建与上下文穿透分析
3.1 调用链自动生成：基于代码提交diff，动态构建函数级调用关系图谱的技术实现
3.2 AICR（AI Code Review）增强：将完整调用链路作为上下文注入检测模型，实现跨模块异常传播路径的精准追踪
3.3 实战效果量化：跨文件缺陷检出率提升的具体倍数/百分比，以某次内存泄漏跨三层调用被成功捕获为例
3.2 AICR（AI Code Review）增强：将完整调用链路作为上下文注入检测模型，实现跨模块异常传播路径的精准追踪
3.3 实战效果量化：跨文件缺陷检出率提升的具体倍数/百分比，以某次内存泄漏跨三层调用被成功捕获为例
4. 闭环：误报分析Agent与规则自沉淀机制
4.1 痛点：AI检测引入新误报，人工二次分析成本如何可控？
4.2 误报自动分析Agent：如何自动研判告警真实性、生成误报知识库
4.3 规则缺陷单自动闭环：从“发现问题→分析误报→沉淀规则→规则自动更新”的全链路自动化
4.4 踩坑实录：Agent“自我循环”导致的规则退化问题及应对策略（引入人工抽检Guard机制）
4.2 误报自动分析Agent：如何自动研判告警真实性、生成误报知识库
4.3 规则缺陷单自动闭环：从“发现问题→分析误报→沉淀规则→规则自动更新”的全链路自动化
4.4 踩坑实录：Agent“自我循环”导致的规则退化问题及应对策略（引入人工抽检Guard机制）
5. 规模化落地：从单点到全端、从工具到能力矩阵
5.1 能力横向扩展：需求完整度检测、UI异常检测、上报异常检测、双端实现不一致检测等衍生工具的共建模式
5.2 多端覆盖实战：Android（自定义Gradle插件）、iOS（Xcode插件化）、Web（ESLint增强）、后台（SpotBugs扩展）的技术适配差异与统一接入层设计
5.3 核心量化成果：接入Q1累计有效问题2000+例，前置发现率6%→20%+，沉淀规则500+条，Agent/Skill 10+个，专利7篇
5.2 多端覆盖实战：Android（自定义Gradle插件）、iOS（Xcode插件化）、Web（ESLint增强）、后台（SpotBugs扩展）的技术适配差异与统一接入层设计
5.3 核心量化成果：接入Q1累计有效问题2000+例，前置发现率6%→20%+，沉淀规则500+条，Agent/Skill 10+个，专利7篇
6. 未来展望：从“辅助发现”到“自动修复”
6.1 当前瓶颈：AI修复准确率不足、修复引入新Bug的风险
6.2 探索方向：基于调用链的精准修复补丁生成 + 修复后自动化回归验证
6.2 探索方向：基于调用链的精准修复补丁生成 + 修复后自动化回归验证
听众收益：
1. 一套可直接复用的“双引擎检测+调用链分析”架构方案：了解如何在不推翻现有Lint体系的前提下，引入AI能力实现检测深度跃升，并获得跨文件上下文分析的落地实现细节，可用于自身团队的代码质量左移建设。
2. 误报治理的“自闭环”实战经验：学习如何通过Agent自动化处理AI引入的新误报问题，形成规则自沉淀的正向循环，避免“上了AI反而增加人工成本”的尴尬局面，并收获实际踩坑（如规则退化）的应对策略。
3. 规模化推广的“避坑指南”：了解在多端（Android/iOS/Web/后台）、多业务（Q音/K歌/JOOX/Wesing）场景下统一接入层的设计取舍与技术适配差异，为跨团队、跨技术栈推广提供真实参考。
1. 一套可直接复用的“双引擎检测+调用链分析”架构方案：了解如何在不推翻现有Lint体系的前提下，引入AI能力实现检测深度跃升，并获得跨文件上下文分析的落地实现细节，可用于自身团队的代码质量左移建设。
2. 误报治理的“自闭环”实战经验：学习如何通过Agent自动化处理AI引入的新误报问题，形成规则自沉淀的正向循环，避免“上了AI反而增加人工成本”的尴尬局面，并收获实际踩坑（如规则退化）的应对策略。
3. 规模化推广的“避坑指南”：了解在多端（Android/iOS/Web/后台）、多业务（Q音/K歌/JOOX/Wesing）场景下统一接入层的设计取舍与技术适配差异，为跨团队、跨技术栈推广提供真实参考。
王睿
中国工商银行 金融科技经理
长期从事软件质量保障、测试效能提升和智能研发工具建设工作。近年重点关注大模型在软件测试领域的工程化应用，参与推进测试设计、测试执行、研发知识工程、多智能体编排等方向的落地实践。2025年起，围绕智能测试，推动测试设计、测试执行智能化体系建设，逐步形成从“案例设计”到“执行验证”的闭环能力。关注AI能力从“能生成”走向“可评审、可入库、可执行、可度量”的真实落地。
待定
待定
从用例生成到执行闭环：工商银行智能测试落地与实践
议题背景：
大模型在测试领域的应用越来越多，但不少实践仍停留在“生成测试用例”阶段，但测试人员真正耗时的地方，往往是理解需求变更、拆分测试对象、准备测试数据、构造接口报文、适配页面操作和判断执行结果。在银行复杂业务场景中，这些问题更加明显，本次分享将结合测试智能体在银行研发测试场景中的实践，介绍如何从“用例生成”出发，逐步打通“规约—案例—数据—报文—执行—断言”的测试链路。
内容大纲：
1. 测试设计智能体：四轮迭代优化，用“规约+方法”约束模型输出
内容大纲：
1. 测试设计智能体：四轮迭代优化，用“规约+方法”约束模型输出
1.1 测试设计智能体迭代进程：从单纯使用测试设计方法，到引入规约驱动生成，到两者结合
1.2 阶段效果
1.2 阶段效果
2. 测试执行智能体：打通“案例—数据—报文—执行”
2.1 基于测试案例提取执行约束，生成接口报文和自动化脚本草稿；对无法确认的字段保留人工确认，避免模型编造
2.2 测试数据的由来：围绕客户、账户、产品等业务实体，建立案例约束、字段映射和测试数据资产之间的连接
2.3 阶段效果
2.2 测试数据的由来：围绕客户、账户、产品等业务实体，建立案例约束、字段映射和测试数据资产之间的连接
2.3 阶段效果
3. 工程化复盘和后续思路：测试智能体真正要沉淀什么
3.1 复盘经验1：Skill不只是提示词，而是模板、状态机、文件协议、确认机制和异常处理的组合
3.2 复盘经验2：能规则化的部分规则化，能资产化的部分资产化，模型主要负责理解、归纳、匹配和生成
3.3 后续方向：资产整理
3.2 复盘经验2：能规则化的部分规则化，能资产化的部分资产化，模型主要负责理解、归纳、匹配和生成
3.3 后续方向：资产整理
听众收益：
1. 拆解测试设计、测试执行的建设思路和方式。
2. 了解智能测试落地中的典型坑：需求拆分不准、字段映射复杂、数据资产不足、UI控件适配、断言不完善、模型编造内容等问题，以及相应处理思路。
1. 拆解测试设计、测试执行的建设思路和方式。
2. 了解智能测试落地中的典型坑：需求拆分不准、字段映射复杂、数据资产不足、UI控件适配、断言不完善、模型编造内容等问题，以及相应处理思路。
王文明
淘天集团 测试开发工程师
淘天集团营销交易技术团队测试开发工程师，目前负责营销中台技术质量，保障商家营销工具以及淘系氛围等产品的稳定性，深度参与营销质量与Ai结合工作，去年投入建设营销Ai图片校验专项，今年建设UI自动化路径智能规划项目。毕业后曾就职于作业帮，从事端基础、vip等业务质量工作。
待定
待定
基于多模态Agent的UI自动化路径智能规划：
从“写脚本”到“生成高质量用例”的跃迁
议题背景：
传统UI自动化依赖人工编写脚本，存在维护成本高、覆盖不全、边界场景遗漏等问题。我们提出 基于多模态Agent的智能路径规划方案，融合DOM结构、页面截图与业务知识，通过AI自动生成高覆盖、低重复的测试路径。系统采用分阶段探索策略（主链路/边界/发散），结合RAG注入校验规则、视觉状态识别、向量去重防循环等技术，在淘系营销中台落地应用。
传统UI自动化依赖人工编写脚本，存在维护成本高、覆盖不全、边界场景遗漏等问题。我们提出 基于多模态Agent的智能路径规划方案，融合DOM结构、页面截图与业务知识，通过AI自动生成高覆盖、低重复的测试路径。系统采用分阶段探索策略（主链路/边界/发散），结合RAG注入校验规则、视觉状态识别、向量去重防循环等技术，在淘系营销中台落地应用。
内容大纲：
1. 问题本质：为什么传统UI自动化“写不动”了？
1.1 脚本维护成本高
页面微调（如按钮文案变更、组件重构）常导致大量脚本失效，回归、维护成本增高。
1.2 覆盖盲区多
人工难以穷举空填、格式错误、非法操作等边界情况，多数用例仅覆盖正向流程。
1.3 缺陷发现滞后
自动化沦为“验证工具”，无法主动暴露潜在风险，质量左移效果有限。
2. 技术突破：如何实现“智能探索”？
2.1 架构演进：从“录制回放”到“AI驱动的多Agent流水线”
2.1.1 构建闭环协作的Agent链：
○ 状态分析Agent：解析DOM + 截图 → 输出页面类型、可操作元素、弹窗状态
○ 策略选择Agent：根据路径阶段决定走主链路或触发异常
○ 指令生成Agent：输出结构化操作指令（如“点击：开始时间”）
○ 断言判断Agent：动态判断是否完成路径并保存结果
○ 策略选择Agent：根据路径阶段决定走主链路或触发异常
○ 指令生成Agent：输出结构化操作指令（如“点击：开始时间”）
○ 断言判断Agent：动态判断是否完成路径并保存结果
2.1.2 所有Agent共享上下文，形成“感知-决策-执行-反馈”闭环。
2.2 多模态输入融合：不只是DOM，更是“看得见”的交互
2.2.1 输入包括四部分：
○ DOM结构（text、placeholder、disabled属性）
○ 页面截图（Base64编码，用于视觉识别）
○ 历史操作轨迹
○ 历史规划路径
○ 页面截图（Base64编码，用于视觉识别）
○ 历史操作轨迹
○ 历史规划路径
2.2.2 关键实践：纯DOM易误判！例如某个输入框未禁用但截图显示为灰色，或弹窗遮挡背景按钮。必须结合视觉信号才能准确判断可操作性。
3. 核心技术创新点
3.1 分阶段探索策略设计
3.1.1 主链路：走通标准流程，确保必填项填写，达成业务目标
3.1.2 边界探索：通过RAG召回业务规则（如“活动名称不能为空”），故意留空或填错，验证前端提示是否正确
3.1.3 发散探索：利用LLM随机性尝试非主流程按钮（如“预览”“帮助”），发现隐藏跳转或异常路径
3.1.2 边界探索：通过RAG召回业务规则（如“活动名称不能为空”），故意留空或填错，验证前端提示是否正确
3.1.3 发散探索：利用LLM随机性尝试非主流程按钮（如“预览”“帮助”），发现隐藏跳转或异常路径
3.2 双重防重复机制保障探索效率
3.2.1 操作去重：记录已点击元素的文本+位置上下文，避免反复点击同一按钮
3.2.2 路径去重：将路径操作序列压缩计算余弦相似度，高于阈值则判定为重复并终止
3.2.3 用例去重：将历史规划用例作为规划参考，防止规划相同case
3.2.2 路径去重：将路径操作序列压缩计算余弦相似度，高于阈值则判定为重复并终止
3.2.3 用例去重：将历史规划用例作为规划参考，防止规划相同case
3.3 特殊控件精准处理
3.3.1 弹窗优先：一旦检测到遮罩或弹窗标题，强制优先处理弹窗内按钮
3.3.2 日期控件：若日历已展开，不生成“输入日期”，改为“点击具体日期”；跳过isDisabled或视觉置灰的日期
3.3.3 下拉菜单：展开状态下优先选第一个可用选项
3.3.2 日期控件：若日历已展开，不生成“输入日期”，改为“点击具体日期”；跳过isDisabled或视觉置灰的日期
3.3.3 下拉菜单：展开状态下优先选第一个可用选项
4. 工程落地：从原型到平台化交付
4.1 平台化建设
4.1.1 提供Web平台，支持配置目标URL、登录方式、探索深度、步骤数、生成数量
4.1.2 后端通过MQ异步调度任务，完成后返回所有生成路径
4.1.3 输出标准YAML格式，兼容现有执行引擎，无缝集成CI/CD
4.1.2 后端通过MQ异步调度任务，完成后返回所有生成路径
4.1.3 输出标准YAML格式，兼容现有执行引擎，无缝集成CI/CD
4.2 落地效果
4.2.1 单任务平均生成有效路径数：15条以上
4.2.2 边界类用例占比达 60%
4.2.3 脚本生成耗时：平均 3.2分钟/用例
4.2.2 边界类用例占比达 60%
4.2.3 脚本生成耗时：平均 3.2分钟/用例
听众收益：
参会者将获得以下实战级启发与可复用经验：
1. 掌握可落地的“AI+自动化”架构设计方法：如何将LLM嵌入现有框架，构建具备“认知-决策-执行”能力的智能Agent系统，而非简单调用prompt；
2. 获取“视觉+DOM”协同分析的关键技巧：了解如何通过截图识别特殊case，解决传统自动化因“看不见”导致的误判问题；
3. 借鉴分层探索与去重机制的设计思路：可直接复用主链路/边界/发散三级模型及向量去重方案，快速构建自己的智能探索系统，避免无效循环。
参会者将获得以下实战级启发与可复用经验：
1. 掌握可落地的“AI+自动化”架构设计方法：如何将LLM嵌入现有框架，构建具备“认知-决策-执行”能力的智能Agent系统，而非简单调用prompt；
2. 获取“视觉+DOM”协同分析的关键技巧：了解如何通过截图识别特殊case，解决传统自动化因“看不见”导致的误判问题；
3. 借鉴分层探索与去重机制的设计思路：可直接复用主链路/边界/发散三级模型及向量去重方案，快速构建自己的智能探索系统，避免无效循环。
郑天德
腾讯音乐 高级测试开发工程师
腾讯音乐高级测试开发工程师，目前主要负责腾讯音乐应用质量监控与定位分析平台开发，保障QQ音乐、全民K歌、酷狗音乐、酷我音乐、懒人听书等产品的基础质量。
待定
待定
让每一个 Crash 都被高效修复：
Crash智能修复 Agent 的工程化落地
议题背景：
客户端崩溃治理长期面临"发现不全、修复太慢"两大瓶颈：Top 问题占满注意力、长尾问题无人问津，而单个生产 Bug 修复全流程耗时 2–10 小时，且严重依赖开发者个人经验。我们针对 Android/iOS 双端 Crash 构建了"动态归因 + 自动修复"的智能体流水线：提单后问题自动进入修复队列，Agent 基于堆栈、Metrickit 全线程堆栈、内存镜像、上报附件等完整现场数据做深度归因，自动生成修复方案、执行编译校验并提交 MR，结果自动回写 tapd。
内容大纲：
1. 问题背景：崩溃治理的双重瓶颈
客户端崩溃治理长期面临"发现不全、修复太慢"两大瓶颈：Top 问题占满注意力、长尾问题无人问津，而单个生产 Bug 修复全流程耗时 2–10 小时，且严重依赖开发者个人经验。我们针对 Android/iOS 双端 Crash 构建了"动态归因 + 自动修复"的智能体流水线：提单后问题自动进入修复队列，Agent 基于堆栈、Metrickit 全线程堆栈、内存镜像、上报附件等完整现场数据做深度归因，自动生成修复方案、执行编译校验并提交 MR，结果自动回写 tapd。
内容大纲：
1. 问题背景：崩溃治理的双重瓶颈
1.1 发现不全：Top 问题占满注意力，长尾崩溃沉默拖累大盘（今天影响 2 台设备，明天可能波及上万用户）
1.2 修复太慢：单个生产 Bug 修复全流程 2–10 小时，写代码仅占 10–15%，其余耗在定位与流程
1.3 经验鸿沟：同一个 Native Crash，资深与初级开发者定位耗时差异达数倍
2. 技术方案：AI 介入 Crash 治理全链路
2.1 端到端流水线：提单 → 自动进队列 → 动态归因 → 生成修复方案 → 编译校验 → 提交 MR → 回写 tapd
2.2 双端差异化设计：iOS Crash/watchdog 与 Android Crash/内存泄漏的不同归因策略
2.3 深度动态归因：结合堆栈、源码上下文、Metrickit 全线程堆栈、内存镜像对象引用链、进程/线程信息、用户操作路径还原现场
2.4 "看代码 vs 看现场"分类：逻辑异常（空指针/类型转换）通用 Agent 可解，运行时异常（OOM/内存泄漏）必须依赖平台完整现场数据
2.2 双端差异化设计：iOS Crash/watchdog 与 Android Crash/内存泄漏的不同归因策略
2.3 深度动态归因：结合堆栈、源码上下文、Metrickit 全线程堆栈、内存镜像对象引用链、进程/线程信息、用户操作路径还原现场
2.4 "看代码 vs 看现场"分类：逻辑异常（空指针/类型转换）通用 Agent 可解，运行时异常（OOM/内存泄漏）必须依赖平台完整现场数据
3. 关键技术实现
3.1 数据 MCP 服务化：14 项能力（Crash 详情、附件查询、堆栈解析、下钻分析、防劣化指标等）
3.2 Agent 部署工程化：服务器接收任务自动调用，所有正式版本 Crash 提单后自动运行
3.3 多轮对话与模型选型：切换 多个模型，支持多轮对话更优分析、历史会话保留、自主选模型、二级聚类单独分析
3.4 修复闭环:一 Issue 一分支一 MR、报告自动上传 COS、tapd 单自动附加修复结论与评论、MR 状态自动追踪
3.2 Agent 部署工程化：服务器接收任务自动调用，所有正式版本 Crash 提单后自动运行
3.3 多轮对话与模型选型：切换 多个模型，支持多轮对话更优分析、历史会话保留、自主选模型、二级聚类单独分析
3.4 修复闭环:一 Issue 一分支一 MR、报告自动上传 COS、tapd 单自动附加修复结论与评论、MR 状态自动追踪
4. 落地效果与数据收益
4.1 覆盖率：整体 Crash 自动修复覆盖率 70+%
4.2 采纳率：iOS Crash 80%、安卓 Crash 82.1%
4.3 接入规模：共 8 应用，MCP 周调用 1.2W–3.3W 次
4.4 能力边界：已从单一 Crash 扩展至 ANR/watchdog、内存泄漏，并联动大盘指标波动自动分析
4.2 采纳率：iOS Crash 80%、安卓 Crash 82.1%
4.3 接入规模：共 8 应用，MCP 周调用 1.2W–3.3W 次
4.4 能力边界：已从单一 Crash 扩展至 ANR/watchdog、内存泄漏，并联动大盘指标波动自动分析
5. 未来演进
5.1 场景扩展：从"新版本新增问题"到"历史长尾清理""指标告警应急""开发阶段日常新增"
5.2 防患于未然：在问题还是"小问题"时修掉，不给它突变为"大故障"的机会
5.2 防患于未然：在问题还是"小问题"时修掉，不给它突变为"大故障"的机会
听众收益：
1. 完整的 Crash 自动修复工程化落地范式：如何把"提单 → 动态归因 → 生成 MR → 回写 tapd"做成端到端可追溯、可度量的自动化闭环，并用数据（覆盖率 70+%、采纳率 80%+）验证收益，可直接迁移到自己的质量治理体系。
2. 平台级现场数据是运行时异常归因的胜负手：为什么第三方 AI 代码工具做不好 OOM/内存泄漏归因——差距在于能否拿到 Metrickit 全线程堆栈、内存镜像引用链等完整现场；听众可借鉴"数据 MCP 服务化 + Agent"的架构思路。
1. 完整的 Crash 自动修复工程化落地范式：如何把"提单 → 动态归因 → 生成 MR → 回写 tapd"做成端到端可追溯、可度量的自动化闭环，并用数据（覆盖率 70+%、采纳率 80%+）验证收益，可直接迁移到自己的质量治理体系。
2. 平台级现场数据是运行时异常归因的胜负手：为什么第三方 AI 代码工具做不好 OOM/内存泄漏归因——差距在于能否拿到 Metrickit 全线程堆栈、内存镜像引用链等完整现场；听众可借鉴"数据 MCP 服务化 + Agent"的架构思路。
向天宇
蚂蚁集团 测试开发专家
支付宝-用户技术部测试开发专家，负责推荐评测体系建设，AI智能测试体系建设。多年AI质量技术、研发效能研究和项目经验，主导智能测试、算法评测、质量大模型、知识图谱、多模态等多项质量技术建设和落地。通过AI评测助力算法优化迭代、AI技术创新助力业务效果迭代提升。
擅长领域：智能化测试、AI评测、大数据、搜推、大模型
擅长领域：智能化测试、AI评测、大数据、搜推、大模型
待定
待定
AI时代质量新范式 — IQH 全链路智能质量防御体系
议题背景：
AI时代，AICoding占比越来越高，AI 产出的代码越多，人工验收的负担越重，传统质量保障成为瓶颈，我们在支付宝用户域打造了AI智能测试中枢，建设了数字专家团队，通过AI Delivery Loop重塑了AI质量研发范式，体系成熟度从L1 AI辅助升级到L3 AI专家协同
内容大纲：
1. 体系成熟度的阶段分析—我们走到了哪里？
AI时代，AICoding占比越来越高，AI 产出的代码越多，人工验收的负担越重，传统质量保障成为瓶颈，我们在支付宝用户域打造了AI智能测试中枢，建设了数字专家团队，通过AI Delivery Loop重塑了AI质量研发范式，体系成熟度从L1 AI辅助升级到L3 AI专家协同
内容大纲：
1. 体系成熟度的阶段分析—我们走到了哪里？
1.1 AI 质量保障的成熟度模型（五阶段）
1.2 各阶段特征与痛点
1.3 行业现状定位
1.2 各阶段特征与痛点
1.3 行业现状定位
2. 困局—AI 写了 90% 的代码，谁来保障 100% 的质量？
2.1 AI Coding 浪潮下的质量断层
2.2 传统质量体系的失灵信号
2.3 核心矛盾
2.2 传统质量体系的失灵信号
2.3 核心矛盾
3. AI Delivery 下的质量 LOOP—流程嵌入的质量自进化体系
3.1 核心理念：质量不是阶段，是 LOOP
3.2 AI Delivery 全流程中的质量嵌入点
3.3 自进化机制
3.2 AI Delivery 全流程中的质量嵌入点
3.3 自进化机制
4. 整体方案介绍—从"被动验收"到"全链路智能防御"
4.1 设计哲学
4.2 整体架构分层
4.2 整体架构分层
5. 方案核心能力介绍
5.1 AI 数字专家团队—让专家经验成为"可复制的资产"
5.2 可持续进化的 AI 框架
5.2 可持续进化的 AI 框架
5.2.1 知识工程—从"文档堆砌"到"可推理的知识资产"
5.2.2 LOOP 集成与实践
5.2.2 LOOP 集成与实践
5.3 AI 资产管理—质量能力的"App Store"
6. AI 智能测试能力介绍
6.1 AI 测试能力全景图
6.2 SPEC 风险检测—质量风险的"前哨哨兵"
6.3 智能测试设计—测试策略的"AI 规划师"
6.4 智能接口测试—接口质量的"自动化流水线"
6.5 智能端到端测试—用户体验质量的"守护者"
6.6 智能回归测试—版本质量的"安全网"
6.2 SPEC 风险检测—质量风险的"前哨哨兵"
6.3 智能测试设计—测试策略的"AI 规划师"
6.4 智能接口测试—接口质量的"自动化流水线"
6.5 智能端到端测试—用户体验质量的"守护者"
6.6 智能回归测试—版本质量的"安全网"
7. 业务实践效果
8. 总结和展望
8. 总结和展望
8.1 总结
8.2 未来展望
8.2 未来展望
听众收益：
1. 一套可落地的 AI 质量成熟度演进路线图：听众可以拿到从 L1（工具辅助）到 L5（自进化生态）的五阶段成熟度模型，用于评估自身团队当前位置、识别瓶颈、规划下一步路径——不再是"AI写了代码但质量跟不上"的模糊焦虑，而是有框架可对齐、有标杆可参照。
2. 数字专家 + 知识自进化的可复制方案：听众可以理解如何将个人专家经验转化为可复制、可进化、可团队共享的数字专家资产，以及知识沉淀闭环机制——解决"AI能力单次消耗无法累积"的核心痛点，让质量能力越用越强而非每次从零开始。
3. 质量 LOOP 的流程嵌入范式：听众可以学到如何将质量从"交付末端的闸门"重构为"嵌入 AI Delivery 全流程的持续闭环"（感知→分析→执行→验证→沉淀→进化），并通过看到不同场景下的具体实践效果
1. 一套可落地的 AI 质量成熟度演进路线图：听众可以拿到从 L1（工具辅助）到 L5（自进化生态）的五阶段成熟度模型，用于评估自身团队当前位置、识别瓶颈、规划下一步路径——不再是"AI写了代码但质量跟不上"的模糊焦虑，而是有框架可对齐、有标杆可参照。
2. 数字专家 + 知识自进化的可复制方案：听众可以理解如何将个人专家经验转化为可复制、可进化、可团队共享的数字专家资产，以及知识沉淀闭环机制——解决"AI能力单次消耗无法累积"的核心痛点，让质量能力越用越强而非每次从零开始。
3. 质量 LOOP 的流程嵌入范式：听众可以学到如何将质量从"交付末端的闸门"重构为"嵌入 AI Delivery 全流程的持续闭环"（感知→分析→执行→验证→沉淀→进化），并通过看到不同场景下的具体实践效果
卓庆荣
岩山科技二三四五网科 高级测试经理
岩山旗下二三四五网科高级测试经理，长期专注测试平台建设与AI 测试方向的研究与落地，负责企业级测试体系规划、自动化平台设计、测试效能提升，以及 AI 技术在测试领域的实践与推广，主导测试技术从工具化、平台化向智能化演进。在大规模系统质量保障、测试平台落地、智能化测试实践等方面拥有丰富实战经验。
待定
待定
AI 测试新路径：AI 驱动的流程革新与落地
议题背景：
在大模型加速渗透研发体系的当下，测试实践却仍大量停留在「人工建计划、多系统切换、人肉找报告」的阶段：
质量活动与需求、代码割裂，AI 能力也多停在零散的点工具尝试，难以真正改变交付方式。
我们希望探索的，不是再增加一个「AI 测试小功能」，而是用 AI 重新编排测试全链路——从提测那一刻就完成质量门禁与需求关联，让质量自然前移；在统一 Skill 能力层之上，通过多端接入口，以对话式方式完成计划编排、任务调度与结果回收；最终让报告和风险主动触达相关角色，把质控从「流程尾部的检查点」升级为「贯穿协作场景的底层能力」，为团队提供一条可复制、可演进的 AI 测试新路径。
内容大纲：
1.为什么需要 AI 测试新路径
在大模型加速渗透研发体系的当下，测试实践却仍大量停留在「人工建计划、多系统切换、人肉找报告」的阶段：
质量活动与需求、代码割裂，AI 能力也多停在零散的点工具尝试，难以真正改变交付方式。
我们希望探索的，不是再增加一个「AI 测试小功能」，而是用 AI 重新编排测试全链路——从提测那一刻就完成质量门禁与需求关联，让质量自然前移；在统一 Skill 能力层之上，通过多端接入口，以对话式方式完成计划编排、任务调度与结果回收；最终让报告和风险主动触达相关角色，把质控从「流程尾部的检查点」升级为「贯穿协作场景的底层能力」，为团队提供一条可复制、可演进的 AI 测试新路径。
内容大纲：
1.为什么需要 AI 测试新路径
1.1 传统测试流程的痛点：人工建计划、多系统切换、报告难找、文档与需求脱节
1.2 从「人驱动流程」到「AI 驱动流程」的转变目标
1.3 本议题聚焦：以 AI 重构测试全链路的运行范式——通过「提测即门禁/需求关联」实现质量左移，以「统一 Skill 层 + 多端接入」实现对话式编排与结果主动触达，让质控从外围职能变成自然生长在协作场景里的底层能力。
1.2 从「人驱动流程」到「AI 驱动流程」的转变目标
1.3 本议题聚焦：以 AI 重构测试全链路的运行范式——通过「提测即门禁/需求关联」实现质量左移，以「统一 Skill 层 + 多端接入」实现对话式编排与结果主动触达，让质控从外围职能变成自然生长在协作场景里的底层能力。
2. 整体架构与核心能力：AI 驱动的测试全链路
2.1 流程全景与设计原则
流程全景：
提测 → AI 送测（单测 + 文档 + 需求关联）→ 接入口对话创建计划流程 → 接口调用 Skill 调度执行 → AI 整合报告 → 对话式触达。
设计原则：
①接入口与能力解耦：入口可多端（企微 / Web / 其他 IM / API），底层统一通过接口调用 Skill 执行。
②AI 先行，人做校准：能自动的交给 AI，人工主要做校准、决策与兜底。
③全程可追溯：需求、用例、执行结果与报告之间有清晰链路。
提测 → AI 送测（单测 + 文档 + 需求关联）→ 接入口对话创建计划流程 → 接口调用 Skill 调度执行 → AI 整合报告 → 对话式触达。
设计原则：
①接入口与能力解耦：入口可多端（企微 / Web / 其他 IM / API），底层统一通过接口调用 Skill 执行。
②AI 先行，人做校准：能自动的交给 AI，人工主要做校准、决策与兜底。
③全程可追溯：需求、用例、执行结果与报告之间有清晰链路。
2.2 AI 送测：提测即带文档、带门禁、带需求
自动触发：开发提测代码时，平台自动触发 AI 送测，无需额外操作。
三项核心能力：
①自动触发 AI 单元测试，前置发现基础问题，缩短反馈周期；
②自动生成提测文档，减轻开发写文档负担，保证信息完整；
③自动关联需求，打通「需求–代码–测试」链路。
价值：提测那一刻就带上文档、质量门禁和需求追踪，质量左移，减少反复问、反复补的沟通成本。
三项核心能力：
①自动触发 AI 单元测试，前置发现基础问题，缩短反馈周期；
②自动生成提测文档，减轻开发写文档负担，保证信息完整；
③自动关联需求，打通「需求–代码–测试」链路。
价值：提测那一刻就带上文档、质量门禁和需求追踪，质量左移，减少反复问、反复补的沟通成本。
2.3 对话式入口与计划创建：接入口 + Skill 能力
接入口只是入口：不绑定具体端，当前以企微为例，后续可扩展到 Web、其他 IM、API 等。
底层实现：接入口将自然语言意图转成结构化请求，通过接口调用 Skill 完成测试计划创建和子计划配置。
对话式体验：
①测试伙伴在接入口里用「聊天」的方式说出测试需求；
②Skill 侧 AI 根据需求和变更，推荐子计划组合（功能 / 接口 / 自动化等），支持人工调整。
价值：计划创建不再依赖表格和记忆，「对话即操作」，缩短建计划时间，且架构天然支持多入口复用同一套能力。
底层实现：接入口将自然语言意图转成结构化请求，通过接口调用 Skill 完成测试计划创建和子计划配置。
对话式体验：
①测试伙伴在接入口里用「聊天」的方式说出测试需求；
②Skill 侧 AI 根据需求和变更，推荐子计划组合（功能 / 接口 / 自动化等），支持人工调整。
价值：计划创建不再依赖表格和记忆，「对话即操作」，缩短建计划时间，且架构天然支持多入口复用同一套能力。
2.4 执行层概览：统一触发、统一反馈
统一触发：测试计划生成后，由接入口一句话触发，接口调用 Skill 调度各类子计划（功能、接口、自动化、稳定性、合规、兼容、安全、性能、回归等）。
统一反馈：所有子计划都回流到统一的明细报告 + 执行状态页。
人机分工：人主要负责用例校准、风险判断、例外处理；AI/Skill 负责生成、调度与汇总。
说明：本次分享中执行层仅做架构与体验概览，不展开各子计划技术细节。
统一反馈：所有子计划都回流到统一的明细报告 + 执行状态页。
人机分工：人主要负责用例校准、风险判断、例外处理；AI/Skill 负责生成、调度与汇总。
说明：本次分享中执行层仅做架构与体验概览，不展开各子计划技术细节。
2.5 对话式触达：从「人找报告」到「报告找人」
AI 整合报告：将各子计划结果由 AI 整合为统一测试报告（通过率、失败分析、风险提示、建议动作等）
对话式触达：通过当前接入口（如企微）主动推送报告摘要与关键风险，一键跳转查看详情。
多入口可扩展：触达同样由接口/Skill 驱动，可扩展为 Web 站内信、其他 IM 通知、API 回调等多种形态。
价值：从过去「到处找报告」变为「报告主动找人」，提高风险暴露及时性，减少遗漏与反复沟通。
对话式触达：通过当前接入口（如企微）主动推送报告摘要与关键风险，一键跳转查看详情。
多入口可扩展：触达同样由接口/Skill 驱动，可扩展为 Web 站内信、其他 IM 通知、API 回调等多种形态。
价值：从过去「到处找报告」变为「报告主动找人」，提高风险暴露及时性，减少遗漏与反复沟通。
3. 落地要点与效果展望
落地要点：分阶段推进（先送测 + 计划 + 对话触达，再扩展执行层）；知识图谱与数据建设；明确人机分工边界；接入口与 Skill 解耦，便于先上一端再多端、
效果：效率（计划创建、报告整合时间缩短，接入口对话减少多系统切换）；质量（覆盖更全、可追溯性更强，统一接入口降低漏执行）。
展望：多入口扩展（Web、其他 IM、API、审批/提醒/数据卡片等），能力层统一由接口调用 Skill，进一步强化「对话即流程」、多端一致体验。
落地要点：分阶段推进（先送测 + 计划 + 对话触达，再扩展执行层）；知识图谱与数据建设；明确人机分工边界；接入口与 Skill 解耦，便于先上一端再多端、
效果：效率（计划创建、报告整合时间缩短，接入口对话减少多系统切换）；质量（覆盖更全、可追溯性更强，统一接入口降低漏执行）。
展望：多入口扩展（Web、其他 IM、API、审批/提醒/数据卡片等），能力层统一由接口调用 Skill，进一步强化「对话即流程」、多端一致体验。
听众收益：
启发：理解「AI 送测 + 对话式触达」如何把 AI 嵌进真实协作场景，而不是停留在单点工具；获得「提测即带文档/门禁/需求」「报告主动触达」的可落地方向。
借鉴：可直接参考「开发提测自动触发 + 对话式接入口（接口调 Skill）+ 报告主动触达」的链路与接入口与能力解耦的架构，用于自家流程改造或平台规划；入口可先上一端（如企微），再多入口接入，能力层复用。
少走弯路：明确分阶段落地顺序（先送测与接入口/触达，再扩展执行层）；接口 + Skill 分层便于多端复用，避免把能力绑死在某一个端；重视业务知识图谱与需求关联等基础建设。
直接采用：接入口与 Skill 解耦后，可先选一种接入口（如企微、Web、API）落地「对话式计划创建与报告触达」，再按需扩展多入口；AI 送测的「自动单元测试 + 自动文档 + 需求关联」三项能力可拆解为可独立落地的子项，按资源分步实施。
程瑾
快手 海外质量团队负责人
现负责海外直播短视频质量保障团队，主导测试领域 AI 能力建设，包括服务端智能化测试、GUI Agent 智能测试、AI 模型及 Agent 评测体系等方向，应用过往AI从业经验，带业务型QA团队向智能化转型。
擅长领域：AI 模型及 Agent 评测体系、服务端接口自动化、移动端 GUI Agent、智能测试工程体系、压测与稳定性保障、测试人才转型
过往经历：从业 11 年，历经百度、美团、快手三家大厂，覆盖 AI 算法、大模型应用、智能硬件、移动端 SDK、直播短视频APP等多类产品形态，具备从 0 到 1 搭建测试体系和团队的完整经历，具体介绍如下：
1、百度（测试架构师）：主导视觉智能方向 CI/CD 能力建设，将服务端测试模式从"本地写代码手工执行"升级为流水线持续集成范式，测试人员并发度由 1~3 提升至流水线并行，研发自测率从 30% 提升至 60%，测试吞吐提升 3 倍，成为公司级效能提升专项的标杆团队。
2、美团（测试经理）：先后负责视觉智能和大模型平台/语音两大方向。主导 AIGC 文生图、文生视频、数字人、Agent 评测体系建设，支持 50+ 次评测，拦截 100+ 缺陷；主导人脸系统与安全审核系统稳定性专项，COE 故障量降低 50%，线上告警从 10 次/天压降至 10 次/周，近 3 年无 S9 级以上故障。
3、快手（高级测试经理，现任）：负责海外直播短视频质量保障团队，主导服务端智能测试（KATFlow 工作流体系）和移动端 GUI Agent 智能测试的建设与规模化推广。
擅长领域：AI 模型及 Agent 评测体系、服务端接口自动化、移动端 GUI Agent、智能测试工程体系、压测与稳定性保障、测试人才转型
过往经历：从业 11 年，历经百度、美团、快手三家大厂，覆盖 AI 算法、大模型应用、智能硬件、移动端 SDK、直播短视频APP等多类产品形态，具备从 0 到 1 搭建测试体系和团队的完整经历，具体介绍如下：
1、百度（测试架构师）：主导视觉智能方向 CI/CD 能力建设，将服务端测试模式从"本地写代码手工执行"升级为流水线持续集成范式，测试人员并发度由 1~3 提升至流水线并行，研发自测率从 30% 提升至 60%，测试吞吐提升 3 倍，成为公司级效能提升专项的标杆团队。
2、美团（测试经理）：先后负责视觉智能和大模型平台/语音两大方向。主导 AIGC 文生图、文生视频、数字人、Agent 评测体系建设，支持 50+ 次评测，拦截 100+ 缺陷；主导人脸系统与安全审核系统稳定性专项，COE 故障量降低 50%，线上告警从 10 次/天压降至 10 次/周，近 3 年无 S9 级以上故障。
3、快手（高级测试经理，现任）：负责海外直播短视频质量保障团队，主导服务端智能测试（KATFlow 工作流体系）和移动端 GUI Agent 智能测试的建设与规模化推广。
待定
待定
「大脑不够，还要有手脚」 ——智能测试规模化落地的工程真相
议题背景：
大多数测试团队引入 AI 后都遭遇同一困境：模型接进来了，效果却远不达预期。根因往往不在模型不够强，而在 AI 缺乏可靠的执行基础设施——有大脑，没有手脚。
以服务端测试为例，AI 能生成接口调用代码，但改 conf 配置、准备多角色账号、查 DB 验数据、验缓存和消息队列这些环节仍靠人工，形成"夹心自动化"：前后都是人，中间夹了一段 AI。移动端同样如此，GUI 执行成功率长期卡在低位，根因不是模型判断失误，而是 AB 实验没打通、设备环境不稳定、三方配置系统无法自动化前置。
本次分享来自快手海外业务智能测试团队的真实实践。团队围绕服务端、GUI、压测三大场景系统性构建 AI 测试能力，核心方案包括：KATFlow Skill 分层架构（AI 推理层 + AI Infra 层 + 数据构造飞轮）、GUI Agent 工程框架（Qwen多模态决策 + platform_tools 层与 AI 解耦 + LangGraph 状态机编排）、MCP 驱动的智能压测助手，以及新孵化项目中需求分类驱动的研测协同重构工作流。
最终落地效果：服务端自动化测试代码率从低于 10% 提升至 90%+，GUI 执行成功率从 47% 跃升至 85%+，压测方案生成效率提升 60%。在新孵化项目中通过需求分类驱动的责任重分配，重构研测协同范式。
大多数测试团队引入 AI 后都遭遇同一困境：模型接进来了，效果却远不达预期。根因往往不在模型不够强，而在 AI 缺乏可靠的执行基础设施——有大脑，没有手脚。
以服务端测试为例，AI 能生成接口调用代码，但改 conf 配置、准备多角色账号、查 DB 验数据、验缓存和消息队列这些环节仍靠人工，形成"夹心自动化"：前后都是人，中间夹了一段 AI。移动端同样如此，GUI 执行成功率长期卡在低位，根因不是模型判断失误，而是 AB 实验没打通、设备环境不稳定、三方配置系统无法自动化前置。
本次分享来自快手海外业务智能测试团队的真实实践。团队围绕服务端、GUI、压测三大场景系统性构建 AI 测试能力，核心方案包括：KATFlow Skill 分层架构（AI 推理层 + AI Infra 层 + 数据构造飞轮）、GUI Agent 工程框架（Qwen多模态决策 + platform_tools 层与 AI 解耦 + LangGraph 状态机编排）、MCP 驱动的智能压测助手，以及新孵化项目中需求分类驱动的研测协同重构工作流。
最终落地效果：服务端自动化测试代码率从低于 10% 提升至 90%+，GUI 执行成功率从 47% 跃升至 85%+，压测方案生成效率提升 60%。在新孵化项目中通过需求分类驱动的责任重分配，重构研测协同范式。
内容大纲：
1. 开场：一个反直觉的发现
1.1 行业困境：买了模型接了API，落地效果为何不达预期
1.2 核心框架："大脑+手脚"缺一不可
1.2 核心框架："大脑+手脚"缺一不可
- 大脑：LLM的生成、理解、推理能力
- 手脚：ADB链路、环境稳态、三方配置系统、平台工具链
在工程基建没做好之前，换更强的模型是没用的——瓶颈不在那里。先把手脚配齐，再谈模型的天花板
- 手脚：ADB链路、环境稳态、三方配置系统、平台工具链
在工程基建没做好之前，换更强的模型是没用的——瓶颈不在那里。先把手脚配齐，再谈模型的天花板
1.3 今天分享的四个场景：服务端 / GUI / 压测 / 工作流重塑
2. GUI Agent智能测试：给AI大脑装上手脚
2.1 反直觉结论：成功率从47%提升至85%，工程基建的贡献超过模型本身
2.2 为什么通用方案不够
2.2 为什么通用方案不够
- 四类瓶颈：架构链路过长 / 平台能力非专属 / 断言口径松 / 失败不可恢复/业务场景复杂
- 结论：数据驱动决策，自建Agent差异化在"稳态前置+工程链路"
- 结论：数据驱动决策，自建Agent差异化在"稳态前置+工程链路"
2.3 工程基建：AI的手脚（核心）
- 手——执行动作的可靠性
· ADB链路标准化（截图前主动唤醒、ATX自动安装修复）
· 专用真机机架、KRN包预加载、环境崩溃快速恢复
· 专用真机机架、KRN包预加载、环境崩溃快速恢复
- 脚——与业务系统打通
· AB实验/KSwitch/Push/Mock/登录/切换环境全部前置，与AI指令解耦
· 泳道注入，打通IDC内网跨环境转发
· 泳道注入，打通IDC内网跨环境转发
· Deeplink/快捷入口，缩短链路减少VLM决策步数
2.4 AI能力层设计
- 用例分级打底：二维×四级打标（A可转化/B部分/C无需/D不可），15个子业务全量
- D类攻坚优先级：P1平台依赖→P2多设备→P3动效→P4声音
- 独立断言+视觉闭环：多步截图+思考链送验证模型+3s视频抽帧
- 状态机编排+Reflect重试：LangGraph子任务编排，断言失败自动重试
- D类攻坚优先级：P1平台依赖→P2多设备→P3动效→P4声音
- 独立断言+视觉闭环：多步截图+思考链送验证模型+3s视频抽帧
- 状态机编排+Reflect重试：LangGraph子任务编排，断言失败自动重试
2.5 成功率演进拆解
- 47% → 60%（自建重写）→ 70%+（工程优化）→ 85%+（专项收敛）
- 四条优化线贡献量化：
- 四条优化线贡献量化：
环境稳态+5~8% / 工程链路+8~12% / 独立断言+5~8% / 状态机重试+8~12%
2.6 数据结果
- 封板回测准化智能GUI方式占比50%+；执行成功率47%→80%+
- 设备吞吐提升80%；模型成本降低50%
- 设备吞吐提升80%；模型成本降低50%
3. 服务端智能测试：需求进来，报告出去
3.1 痛点：AI只能做一半，另一半还得人来
3.1.1 表面痛点（大家都有）：
- 手工为主，单Case编写10~30分钟，自动化率长期<10%
- 测完即丢，每次迭代从零开始
- 测完即丢，每次迭代从零开始
3.1.2深层痛点（更难解决的）：
场景化用例是测试里最有价值、也最难自动化的部分。
一个典型场景长这样：
① 改kconf配置 / 拨AB实验开关 ← 人工登平台操作
↓
② 准备不同角色的测试账号 ← 人工在测试环境注册/配置
↓
③ 按顺序调用多个接口 ← AI能生成这段代码
↓
④ 查DB验证数据是否写入正确 ← 人工连DB查询
↓
⑤ 验证缓存/MQ消息是否符合预期 ← 人工查Redis/看消息队列
AI能做的只有第③步——生成接口调用代码。其余四个环节全靠人，自动化实际上是"夹心自动化"：前后都是人工，中间夹了一段AI。
结论：
"不是AI不行，是AI没有手——
配不了conf、造不了账号、查不了DB，
这样的AI只是个代码补全工具，不是测试Agent"
一个典型场景长这样：
① 改kconf配置 / 拨AB实验开关 ← 人工登平台操作
↓
② 准备不同角色的测试账号 ← 人工在测试环境注册/配置
↓
③ 按顺序调用多个接口 ← AI能生成这段代码
↓
④ 查DB验证数据是否写入正确 ← 人工连DB查询
↓
⑤ 验证缓存/MQ消息是否符合预期 ← 人工查Redis/看消息队列
AI能做的只有第③步——生成接口调用代码。其余四个环节全靠人，自动化实际上是"夹心自动化"：前后都是人工，中间夹了一段AI。
结论：
"不是AI不行，是AI没有手——
配不了conf、造不了账号、查不了DB，
这样的AI只是个代码补全工具，不是测试Agent"
3.2 KATFlow技术方案：给AI配齐手脚
3.2.1 大脑：AI推理能力层
- 流程：PRD/MR输入 → 9阶段Stage流水线→ 用例代码 + 执行报告 + 回归资产
- 核心AI Skill：
kat-case-ai 用例生成
kat-test-case-gate Gate门禁（P0阻塞/P1放行）
kat-test-code-style 代码风格对齐（Examples驱动）
- 核心AI Skill：
kat-case-ai 用例生成
kat-test-case-gate Gate门禁（P0阻塞/P1放行）
kat-test-code-style 代码风格对齐（Examples驱动）
- 关键设计：拆Stage拆Skill，Stage契约串联，不追求一个大Prompt解决所有
3.2.2 手脚①——AI Infra层：解决"夹心自动化"
专门针对上述痛点，逐一打通每个人工环节
配置类（解决①——AI能自己改开关）：
kat-kconf kconf配置项自动读写验证
kat-abtest AB实验分组自动配置注入
kat-kswitch KSwitch开关自动拨打验证
→ 不再需要人工登平台，AI执行前自动配好环境
账号类（解决②——AI能自己备账号）：
kat-account 测试账号自动选取与角色分配
→ 多角色场景（买家/卖家/主播/观众）AI自动匹配
数据验证类（解决④⑤——AI能自己查结果）：
kat-db DB数据查询与状态断言
kat-cache Redis/Memcached缓存验证
kat-mq 消息队列发送与消费验证
→ 接口跑完，AI自己连DB验数据、查缓存、看消息
→ 断言不再是"返回200就算过"，而是端到端验证
踩坑：
"接口测试通了不代表真的对，DB没校验、缓存没验证， AI写的断言就是假断言——
Infra层是让断言有实际意义的基础"
配置类（解决①——AI能自己改开关）：
kat-kconf kconf配置项自动读写验证
kat-abtest AB实验分组自动配置注入
kat-kswitch KSwitch开关自动拨打验证
→ 不再需要人工登平台，AI执行前自动配好环境
账号类（解决②——AI能自己备账号）：
kat-account 测试账号自动选取与角色分配
→ 多角色场景（买家/卖家/主播/观众）AI自动匹配
数据验证类（解决④⑤——AI能自己查结果）：
kat-db DB数据查询与状态断言
kat-cache Redis/Memcached缓存验证
kat-mq 消息队列发送与消费验证
→ 接口跑完，AI自己连DB验数据、查缓存、看消息
→ 断言不再是"返回200就算过"，而是端到端验证
踩坑：
"接口测试通了不代表真的对，DB没校验、缓存没验证， AI写的断言就是假断言——
Infra层是让断言有实际意义的基础"
3.2.3 手脚②——数据构造飞轮：解决长链路数据准备
场景化用例的另一个卡点：
复杂数据（如已下单+待支付状态的订单）靠人工构造，
一个场景准备半小时，外包完全不会做
飞轮设计：
读取仓库已有构造方法 → 建立DB_REGISTRY注册表
↓
新Case生成时检索注册表 → 匹配复用已有方法
无匹配 → AI自动生成新构造方法 → 入库
↓
CI一致性校验防漂移
↓
用得越多 → 资产越厚 → 构造成本越低 → 生成越准
踩坑：
- "长链路数据构造（电商下单→支付→履约）拆成原子方法组合，比一次性生成稳定10倍"
- "数据构造方法塞Prompt会漂移，做成带索引的注册表加CI校验才能长期稳"
复杂数据（如已下单+待支付状态的订单）靠人工构造，
一个场景准备半小时，外包完全不会做
飞轮设计：
读取仓库已有构造方法 → 建立DB_REGISTRY注册表
↓
新Case生成时检索注册表 → 匹配复用已有方法
无匹配 → AI自动生成新构造方法 → 入库
↓
CI一致性校验防漂移
↓
用得越多 → 资产越厚 → 构造成本越低 → 生成越准
踩坑：
- "长链路数据构造（电商下单→支付→履约）拆成原子方法组合，比一次性生成稳定10倍"
- "数据构造方法塞Prompt会漂移，做成带索引的注册表加CI校验才能长期稳"
3.2.4 三层架构回扣痛点
痛点环节 解决手段
① 改conf/AB开关 → AI Infra层：kat-kconf/abtest/kswitch
② 准备测试账号 → AI Infra层：kat-account
③ 调用多个接口 → 大脑层：kat-case-ai生成调用代码
④ 查DB验数据 → AI Infra层：kat-db断言
⑤ 验缓存/消息队列→ AI Infra层：kat-cache/mq验证
从"夹心自动化"变成"全链路自动化"
┌──────────────────────────────────┐
│ 大脑：AI推理层 │ 生成、判断、决策
├──────────────────────────────────┤
│ 手脚①：AI Infra层 │ 配置/账号/DB/缓存/MQ
│ 让AI能摸到系统每个角落 │ 断言真实有据可查
├──────────────────────────────────┤
│ 手脚②：数据构造飞轮 │ 长链路数据自动构造
│ 让AI能造出复杂测试场景 │ 越用越厚的资产底座
└──────────────────────────────────┘
① 改conf/AB开关 → AI Infra层：kat-kconf/abtest/kswitch
② 准备测试账号 → AI Infra层：kat-account
③ 调用多个接口 → 大脑层：kat-case-ai生成调用代码
④ 查DB验数据 → AI Infra层：kat-db断言
⑤ 验缓存/消息队列→ AI Infra层：kat-cache/mq验证
从"夹心自动化"变成"全链路自动化"
┌──────────────────────────────────┐
│ 大脑：AI推理层 │ 生成、判断、决策
├──────────────────────────────────┤
│ 手脚①：AI Infra层 │ 配置/账号/DB/缓存/MQ
│ 让AI能摸到系统每个角落 │ 断言真实有据可查
├──────────────────────────────────┤
│ 手脚②：数据构造飞轮 │ 长链路数据自动构造
│ 让AI能造出复杂测试场景 │ 越用越厚的资产底座
└──────────────────────────────────┘
3.3 数据结果
自动化前置率：<10% → >90%，提升80%+
后补Case人力投入：降低80%
单Case编写耗时：提升95%（10~30min → 1min）
同规模需求测试时长：降低30%，智能生成率80%+
已在电商、商业化、UG等多团队推广
后补Case人力投入：降低80%
单Case编写耗时：提升95%（10~30min → 1min）
同规模需求测试时长：降低30%，智能生成率80%+
已在电商、商业化、UG等多团队推广
3.4 小结
"服务端测试的手脚是Infra层和数据飞轮——
让AI从'只会写接口调用代码'
进化成'能改配置、备账号、查DB、验缓存'的完整测试Agent；
消灭夹心自动化，才是真正的全链路AI化。"
让AI从'只会写接口调用代码'
进化成'能改配置、备账号、查DB、验缓存'的完整测试Agent；
消灭夹心自动化，才是真正的全链路AI化。"
4. 智能压测：压测也能自己跑
4.1 痛点：方案依赖个人经验，隔离策略易出错；报告手工撰写，归因能力有限
4.2 MCP驱动的智能压测助手
- 输入：接口拓扑 + 历史方案 + 监控数据
- 输出①压测方案：链路拓扑图 / 隔离策略预期vs实际配置比对 / 下游QPS聚合通报
- 输出②压测报告：容量结论 / 最优QPS推荐 / 一级下游自动归因 / 3AZ流量均衡自动校验
4.3 效果
- 方案生成效率提升60%+，报告生成效率提升50%
4.2 MCP驱动的智能压测助手
- 输入：接口拓扑 + 历史方案 + 监控数据
- 输出①压测方案：链路拓扑图 / 隔离策略预期vs实际配置比对 / 下游QPS聚合通报
- 输出②压测报告：容量结论 / 最优QPS推荐 / 一级下游自动归因 / 3AZ流量均衡自动校验
4.3 效果
- 方案生成效率提升60%+，报告生成效率提升50%
5. 工作流重塑：研测协同范式重构
5.1 触发背景
- 研发侧AI代码贡献率80%+，交付节奏加快，传统测试体系成为瓶颈
- Wanas项目：每周大回测，人撑不住了
5.2 核心设计：需求分类驱动的责任重分配
- 评估AgentA：PRD/MR → 自动识别资金类/核心类/普通类
- AgentC：Case生成、Case任务分类（研发/测试）、Case执行工具分类（人工/智能测试Agent）
- Case评审会：责任分配到RD/QA
- RD负责普通类，QA负责资金类+核心场景
- 准出Checklist：覆盖率+Bug+UI/埋点确认 → 自动推送KIM
5.3 角色重构
- RD：只写代码 → 负责普通类功能质量（第二阶段扩展至核心场景）
- QA：全量测试责任 → 专注资金类+核心场景（第二阶段仅负责资金类）
- 新增：Agent开发角色，负责评估/打标Agent建设与迭代
5.4 落地实录（真实工程成本）
- ✅ 需求群自动创建Skill（含cookie失效自动重登）
- ✅ PRD质量评测 → KIM卡片推送研发/测试/产品
- ✅ AgentA：MR/PRD资金核心识别+KIM推送
- 🔄 AgentC：Case生成、Case任务分类（研发/测试）、Case执行工具分类（人工/智能测试Agent）
- 🔄 客户端覆盖率接入，准出Checklist自动化推送
5.5 效果：大回测人力8PD/周 → 2~3PD/周，降低60%+
5.6 关键认知："QA从执行者变成规则制定和AI工具链的开发者，AI测试的价值上限在研发侧"
- 研发侧AI代码贡献率80%+，交付节奏加快，传统测试体系成为瓶颈
- Wanas项目：每周大回测，人撑不住了
5.2 核心设计：需求分类驱动的责任重分配
- 评估AgentA：PRD/MR → 自动识别资金类/核心类/普通类
- AgentC：Case生成、Case任务分类（研发/测试）、Case执行工具分类（人工/智能测试Agent）
- Case评审会：责任分配到RD/QA
- RD负责普通类，QA负责资金类+核心场景
- 准出Checklist：覆盖率+Bug+UI/埋点确认 → 自动推送KIM
5.3 角色重构
- RD：只写代码 → 负责普通类功能质量（第二阶段扩展至核心场景）
- QA：全量测试责任 → 专注资金类+核心场景（第二阶段仅负责资金类）
- 新增：Agent开发角色，负责评估/打标Agent建设与迭代
5.4 落地实录（真实工程成本）
- ✅ 需求群自动创建Skill（含cookie失效自动重登）
- ✅ PRD质量评测 → KIM卡片推送研发/测试/产品
- ✅ AgentA：MR/PRD资金核心识别+KIM推送
- 🔄 AgentC：Case生成、Case任务分类（研发/测试）、Case执行工具分类（人工/智能测试Agent）
- 🔄 客户端覆盖率接入，准出Checklist自动化推送
5.5 效果：大回测人力8PD/周 → 2~3PD/周，降低60%+
5.6 关键认知："QA从执行者变成规则制定和AI工具链的开发者，AI测试的价值上限在研发侧"
6. 未来展望：AI原生质量体系（5min）
6.1 近期工程可见目标
- 服务端：覆盖率反向驱动，未覆盖代码分支自动入队补Case
- GUI：从"人写Prompt"跨越到"AI自动生成Prompt"
- 压测：自主学习+自动发通告+二级下游归因
- 工作流：Wanas模式向更多项目推广，重塑工作流，业务QA转型测试开发
- GUI：从"人写Prompt"跨越到"AI自动生成Prompt"
- 压测：自主学习+自动发通告+二级下游归因
- 工作流：Wanas模式向更多项目推广，重塑工作流，业务QA转型测试开发
6.2 三个行业判断
- 工程基建是护城河：模型谁都能调，手脚的积累不可复制
- 评测体系决定可持续：没有自校准，AI系统会缓慢退化
- 价值上限在研发侧：联调阶段触发AI自测，才是全链路闭环
- 评测体系决定可持续：没有自校准，AI系统会缓慢退化
- 价值上限在研发侧：联调阶段触发AI自测，才是全链路闭环
6.3 结语："今天分享的，都是踩过坑之后找到的路。
欢迎来讨论你们还没踩、但快要踩的那个坑。"
听众收益：
1. 一套解决"夹心自动化"的完整工程方法论
AI 能生成接口调用代码，但改配置、备账号、查 DB、验缓存这些环节还得人来——这是绝大多数团队 AI 测试卡在半自动化阶段的真实原因。本次分享会给出服务端（KATFlow Skill 分层架构 + AI Infra 层 + 数据构造飞轮）和移动端（GUI Agent 工程基建 + platform_tools 层与 AI 解耦）两套可直接对照落地的工程框架，不止讲"做了什么"，更拆解每个关键技术决策背后的判断依据和踩坑经验。
2. 破解"AI 测试成功率上不去"的工程真相
GUI 执行成功率从 47% 提升至 85%，贡献最大的不是换了更强的模型，而是 ADB 链路标准化、AB 实验自动化注入、设备稳态这些"脏活"。分享会完整拆解四条优化线（环境稳态 / 工程链路 / 独立断言 / 状态机重试）各自的量化贡献，给出一个可以直接套用到自己团队的诊断框架——在提模型之前，先问手脚是否配齐了。
3. 有据可查的研测协同转型路径
如何推动 QA 团队从"执行者"转型为"门禁设计者和 Agent 开发者"，不只是方向判断，而是有具体的落地方案：需求分类驱动的责任重分配（资金类 / 核心类 / 普通类）、两阶段角色重构节奏、Agent 打标准确率的冷启动方式。对于正在考虑推动团队转型的测试管理者，这套方案可以直接拿去对照自己团队的现状做裁剪，而不是从零摸索。
李景华
腾讯 应用宝质效体系负责人
深耕研发领域10+年，现任腾讯应用宝质效体系负责人，主导全链路质效体系从0到1搭建，通过“敏捷+精益”流程重构、AI辅助智能自动化测试、质效度量闭环，助应用宝成为高效能研发团队。曾就职于全球顶尖的IT咨询公司Thoughtworks（，作为核心创始成员创立BeeArt系列提效工具矩阵，服务10+行业头部客户。核心能力聚焦质效体系构建、智能自动化测试、团队效能激活，用数据驱动突破瓶颈，打造高效能团队。
待定
待定
通用智能体质量体系如何搭建？
来自腾讯Marvis智能助手的质量保障体系实战
议题背景：
随着大模型的快速发展，加之Openclaw和Hermes的带动，通用智能助手如雨后春笋般涌现出来，然而，与传统的B/S和C/S的互联网软件相比，AI智能体需要保障在一个“不确定性的自主系统中”能否达成目标，由于自主系统的不确定性、测试环境多样性以及智能体与用户意图之间的差距，导致质量保障体系非常困难；Marvis作为腾讯新型AI智能助手，从2026年5月20日发布以来，一周内DAU突破10W，一个月DAU突破30万，面对如此快速的增长，Marvis构建了一套“自动化评测+自动化E2E测试+人工Review”的测试新模式，保障了每天一个版本的快速迭代；本次分享将以Marvis智能体测试实战案例入手，阐述通用智能体质量保障中各个难点的解决方案！
内容大纲：
1. 通用智能体质量保障难点和痛点
随着大模型的快速发展，加之Openclaw和Hermes的带动，通用智能助手如雨后春笋般涌现出来，然而，与传统的B/S和C/S的互联网软件相比，AI智能体需要保障在一个“不确定性的自主系统中”能否达成目标，由于自主系统的不确定性、测试环境多样性以及智能体与用户意图之间的差距，导致质量保障体系非常困难；Marvis作为腾讯新型AI智能助手，从2026年5月20日发布以来，一周内DAU突破10W，一个月DAU突破30万，面对如此快速的增长，Marvis构建了一套“自动化评测+自动化E2E测试+人工Review”的测试新模式，保障了每天一个版本的快速迭代；本次分享将以Marvis智能体测试实战案例入手，阐述通用智能体质量保障中各个难点的解决方案！
内容大纲：
1. 通用智能体质量保障难点和痛点
1.1 腾讯Marvis智能体介绍
1.2 Marvis质量保障的难点
1.2 Marvis质量保障的难点
2. 腾讯Marvis质量保障实战
2.1 腾讯Marvis质量保障方案整体设计
2.2 腾讯Marvis的自动化测试体系
2.3 腾讯Marvis的评测体系
2.4 腾讯Marvis的质量保障样例
2.2 腾讯Marvis的自动化测试体系
2.3 腾讯Marvis的评测体系
2.4 腾讯Marvis的质量保障样例
3. 腾讯Marvis质量保障效果评估
3.1 质量效果评估指标体系
3.2 质量评估指标与发版指标关系
3.3 重点评估指标详解
3.2 质量评估指标与发版指标关系
3.3 重点评估指标详解
敬请期待
......
.....
待定
待定
敬请期待
....
关注QECon公众号
议题投稿
speaker@qecon.com.cn
商务合作
151-2264-3988 木子
票务联系
135-2067-8913 媛媛
媒体合作
135-1619-6409 皮皮
添加QECon小助手，获取
会议最新资讯
购票咨询
13520678913 媛媛
