专场：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 执行增强测试弹性，通过报告与验证机制保障结果可信。
王文明
淘天集团 测试开发工程师
淘天集团营销交易技术团队测试开发工程师，目前负责营销中台技术质量，保障商家营销工具以及淘系氛围等产品的稳定性，深度参与营销质量与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. 借鉴分层探索与去重机制的设计思路：可直接复用主链路/边界/发散三级模型及向量去重方案，快速构建自己的智能探索系统，避免无效循环。
卓庆荣
岩山科技二三四五网科 高级测试经理
岩山旗下二三四五网科高级测试经理，长期专注测试平台建设与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 媛媛
