专场：专项测试
汇聚业界顶尖专家与领先企业，共同探讨专项测试领域的最新技术、实践与创新应用。本专场涵盖性能与可扩展性测试、安全测试、兼容性测试、用户体验测试、大数据与AI测试、区块链测试、IoT与边缘计算测试、数据质量、测试自动化、测试工具平台等相关话题，致力于推动专项测试技术的发展，提升产品质量与用户体验，助力企业实现持续的技术创新与市场竞争力提升。
专场出品人：马鑫
京东 零售架构师
拥有10年以上互联网及传统行业丰富测试经验，2010年底入职京东，一直专注于业务质量测试、自动化测试、性能测试以及持续集成等多个领域；现在负责京东零售618/双11以及大型项目的压测推动与实施、前沿压测技术的探索与实践，以及带领团队构建适用于京东的分布式压测平台；同时也在探索研发效能提升的工程实践与平台的建设。
梁慧
阿里巴巴 测试开发专家
目前主要负责AliExpress泛导购及大促质量保障工作，专注于保障招选搭投核心业务场景的高可用性与稳定性。在面向电商大促的质量保障方面，有丰富的实战经验，建设多场景巡检、AI用例规划执行及断言能力实现一周内完成3万个大促场景的验证。同时，在自动化测试及工具平台建设方面有较深入的实践，致力于通过高效的工具链提升测试效率和质量保障能力。此外，还具备资金安全和性能压测领域的丰富经验，能够从系统到业务层面全面保障平台的可靠性与稳定性。
待定
待定
电商多场景AI巡检
对AliExpress导购巡检平台建设进行分享，分享在业务场景多、动态变化的场域通过巡检实现图片内容检测、日志和数据检测的自动化测试过程。
从导购域当前背景与挑战出发，思考问题的解决思路，介绍具体的实现方案，包含利用AI大模型诊断图片问题、通过日志和数据白盒化诊断问题，最后将巡检平台成功落地。基于当前AI大模型发展迅速，视觉模型准确度明显提升，分享巡检平台结合AI大模型进行后续扩展的方向。
内容大纲
1. 前言
2. 背景与挑战
2.1 业务背景
2.2 质量挑战
3. 解决思路
4. 实现方案
4.1 技术架构
4.2 核心流程
4.3 问题分析
4.4 检测能力建设
4.4.1 静态图片AI检测类
4.4.2 动态交互AI检测类
4.4.3 日志检测类
4.4.4 数据检测类
5. 落地效果
5.1 平台效果
5.2 成果数据
6. 结合AI后续扩展
6.1 扩展方向
6.2 实现思路
6.2.1 AI规划执行
6.2.2 AI用例断言
6.3 实现效果
听众收益
巡检自动化、AI用例执行建设可借鉴
从导购域当前背景与挑战出发，思考问题的解决思路，介绍具体的实现方案，包含利用AI大模型诊断图片问题、通过日志和数据白盒化诊断问题，最后将巡检平台成功落地。基于当前AI大模型发展迅速，视觉模型准确度明显提升，分享巡检平台结合AI大模型进行后续扩展的方向。
内容大纲
1. 前言
2. 背景与挑战
2.1 业务背景
2.2 质量挑战
3. 解决思路
4. 实现方案
4.1 技术架构
4.2 核心流程
4.3 问题分析
4.4 检测能力建设
4.4.1 静态图片AI检测类
4.4.2 动态交互AI检测类
4.4.3 日志检测类
4.4.4 数据检测类
5. 落地效果
5.1 平台效果
5.2 成果数据
6. 结合AI后续扩展
6.1 扩展方向
6.2 实现思路
6.2.1 AI规划执行
6.2.2 AI用例断言
6.3 实现效果
听众收益
巡检自动化、AI用例执行建设可借鉴
张琪
京东健康 即时零售&数据算法质量团队
负责人
历任京东集团POP业务、7FRESH业务、全渠道及京喜四大业务板块的质量负责人，当前负责京东健康数据算法质量团队。在质量体系的建设及落地、数据算法质量管理、研发效能提升及DevOps能力建设、门店运营效能提升及业务流程数字化自动化方面有所擅长。
待定
待定
把脉大模型-AI大模型评测能力建设及实践
建设AI大模型评测能力建设的背景：
随着大模型的不断发展，越来越多基于大模型的产品相继涌现。此类产品亟需建立专业的评测平台和机制，以实现对其质量的有效保障。同时，我们结合用户实际与大模型交互的数据，建立高效的测试模型，能够更加有效地完成评测任务。可以更有针对性地对模型进行评测。
内容大纲
1. 建设AI大模型评测能力的背景
2. AI大模型评测能力的实现方案
2.1 数据集管理
2.2 模型管理
2.3 评测任务管理
3. AI大模型评测能力的应用场景
3.1 评测场景1：单轮会话，数据集的每行数据单独评测，没有上下文关系
3.2 评测场景2：多轮会话，数据集中有问题列，每行是一轮对话，每一轮都用问题和推理出的答案作为上下文进行
随着大模型的不断发展，越来越多基于大模型的产品相继涌现。此类产品亟需建立专业的评测平台和机制，以实现对其质量的有效保障。同时，我们结合用户实际与大模型交互的数据，建立高效的测试模型，能够更加有效地完成评测任务。可以更有针对性地对模型进行评测。
内容大纲
1. 建设AI大模型评测能力的背景
2. AI大模型评测能力的实现方案
2.1 数据集管理
2.2 模型管理
2.3 评测任务管理
3. AI大模型评测能力的应用场景
3.1 评测场景1：单轮会话，数据集的每行数据单独评测，没有上下文关系
3.2 评测场景2：多轮会话，数据集中有问题列，每行是一轮对话，每一轮都用问题和推理出的答案作为上下文进行
下一轮的推理
3.3 评测场景3：多轮会话，数据集中有问题列和答案列，每行是一轮对话，每一轮都用问题列和答案列作为上下文
3.3 评测场景3：多轮会话，数据集中有问题列和答案列，每行是一轮对话，每一轮都用问题列和答案列作为上下文
进行下一轮的推理
3.4 评测场景4：多轮会话，但整个会话内容放在一行进行整体评测
3.5 评测场景5：主动构建多轮会话数据集
3.6 评测场景6：对接AutoBots智能体完成评测
3.7 评测场景7：多模型推理结果的比对
3.8 评测场景8：端到端对接业务接口
4. AI大模型评测能力的落地案例
4.1 案例1
4.2 案例2
3.4 评测场景4：多轮会话，但整个会话内容放在一行进行整体评测
3.5 评测场景5：主动构建多轮会话数据集
3.6 评测场景6：对接AutoBots智能体完成评测
3.7 评测场景7：多模型推理结果的比对
3.8 评测场景8：端到端对接业务接口
4. AI大模型评测能力的落地案例
4.1 案例1
4.2 案例2
听众收益
1. 了解AI大模型评测的方法。
2. 了解AI大模型评测的各种可能得场景及相关能力
3. 针对真实场景了解AI大模型评测能力
徐志刚 / 苗悦莹
bilibili
资深开发工程师 / 高级测试开发工程师
徐志刚：曾就职于网易游戏测试工具中台，负责测试工具开发。现在哔哩哔哩工程效率团队担任资深测试开发工程师，主要负责移动端测试工具建设，包括智能Monkey遍历引擎、兼容性测试框架以及AI在自动化测试中的应用探索，期望基于大模型多模态技术构建自然语言UI自动化平台，支撑B站各业务的测试效能提升。
苗悦莹：2021年加入哔哩哔哩，目前担任OGV业务的测试负责人，涵盖pgc播放、动画&影视频道页以及短剧业务等，保障业务迭代质量，达成交付的同时建立健全业务线的质量体系。有丰富的业务质量保障、稳定性治理、测试效能平台工具开发经验。
待定
待定
基于AI录制回放的自动化探索与实践
本议题聚焦： 如何利用大模型（特别是其多模态能力）构建一套新型的UI自动化测试框架，实现自然语言驱动的、跨平台的UI自动化，解决传统方案的碎片化、高成本、脆弱性问题。
1. 核心痛点：UI自动化测试的“碎片化”困境
1. 核心痛点：UI自动化测试的“碎片化”困境
1.1 平台/技术栈割裂： Android, iOS, 鸿蒙原生、Flutter, React Native, H5, 小程序... 每种平台和技术栈都需要特定的自动化框架（Appium, Airtest, UIAutomator, Puppeteer等）和适配代码，测试脚本无法复用，维护成本指数级增长。缺乏一种真正“一次编写，到处运行”的UI自动化解决方案，难以应对当前混合应用、跨平台框架和小程序生态的复杂性。
1.2 开发与维护成本高昂： 测试工程师需要精通多种框架和编程语言（Java, Python, JavaScript等），学习曲线陡峭。脚本严重依赖XPath, ID, Accessibility ID等属性定位元素，UI结构、属性值的微小变化（如资源ID动态生成、布局调整）极易导致脚本执行失败，稳定性差。UI元素频繁变更导致脚本大规模失效，需要投入大量人力进行脚本维护和调试。
1.2 开发与维护成本高昂： 测试工程师需要精通多种框架和编程语言（Java, Python, JavaScript等），学习曲线陡峭。脚本严重依赖XPath, ID, Accessibility ID等属性定位元素，UI结构、属性值的微小变化（如资源ID动态生成、布局调整）极易导致脚本执行失败，稳定性差。UI元素频繁变更导致脚本大规模失效，需要投入大量人力进行脚本维护和调试。
2. 思考方向：拥抱AI，回归“自然”
2.1 大模型多模态能力：大型语言模型（LLM）理解自然语言指令的能力，结合计算机视觉（CV）模型理解屏幕内容（文本、图像、控件）的能力，为解决上述痛点提供了全新可能。
2.2 “所想即所得”的自动化： 能否让测试人员像描述给真人测试员一样，用自然语言（如“点击登录按钮”，“在搜索框输入'手机'并搜索”，“验证购物车里有1件商品”）直接驱动自动化执行。
2.3 跨平台统一入口：基于视觉和语言理解，理论上可以屏蔽底层平台差异（Android/iOS/HarmonyOS）和前端技术栈差异（原生/Flutter/H5/小程序），提供一个统一的自动化交互界面。
2.4 降低门槛，提升效率：让不懂编程的业务测试人员也能快速创建和执行自动化用例，释放专业测试人员的生产力，专注于更复杂的场景设计和质量分析。
2.2 “所想即所得”的自动化： 能否让测试人员像描述给真人测试员一样，用自然语言（如“点击登录按钮”，“在搜索框输入'手机'并搜索”，“验证购物车里有1件商品”）直接驱动自动化执行。
2.3 跨平台统一入口：基于视觉和语言理解，理论上可以屏蔽底层平台差异（Android/iOS/HarmonyOS）和前端技术栈差异（原生/Flutter/H5/小程序），提供一个统一的自动化交互界面。
2.4 降低门槛，提升效率：让不懂编程的业务测试人员也能快速创建和执行自动化用例，释放专业测试人员的生产力，专注于更复杂的场景设计和质量分析。
内容大纲
1. 引言：传统UI自动化的困局与AI带来的曙光
1. 引言：传统UI自动化的困局与AI带来的曙光
1.1 快速回顾现有主流UI自动化技术及其痛点（碎片化、高成本、脆弱性、高门槛）。
引出大模型（LLM + CV）在理解和执行自然语言指令、理解屏幕内容方面的潜力。
提出核心愿景：自然语言 -> 自动化执行。
引出大模型（LLM + CV）在理解和执行自然语言指令、理解屏幕内容方面的潜力。
提出核心愿景：自然语言 -> 自动化执行。
2. 整体架构设计：构建AI驱动的自动化引擎
2.1 核心组件：
视觉感知层 (CV Module): 基于YOLOv5等目标检测模型实时识别屏幕截图中的控件（按钮、输入框、文本标签等）及其位置、类型、文本内容。生成屏幕的“结构化描述”（控件列表、位置、属性）。
自然语言理解层 (LLM Module): 接收测试人员的自然语言指令或录制的用例描述。理解指令意图（操作类型：点击、输入、滑动、验证？）和目标对象（哪个控件？）。
意图-控件匹配与坐标生成层 (Alignment & Planning): 将LLM理解的意图（操作+目标描述）与CV层识别的控件列表进行匹配。将匹配到的控件位置转换为设备屏幕上的可执行坐标（或控件引用）。
执行引擎层 (Execution Engine): 调用底层自动化框架（如ADB/SCRCPY/WDA, 或自研轻量级驱动）执行坐标点击、输入文本、滑动等操作。处理断言逻辑。
缓存与优化层 (Cache & Optimizer): 关键组件，提升效率和稳定性。
2.2 核心挑战与“踩坑”经验：
挑战1:执行效率低，token消耗大：视觉模型接口请求慢（10-20s/次），输入包括截图编码，导致token消耗比较多。解法：增加缓存机制，将执行过的步骤和图片缓存，通过图片相似度匹配历史操作步骤，命中则直接复用结果，提升执行效率，同时降低token的消耗。
挑战2：测试用例的描述影响测试用例的执行，例如在测试用例执行步骤：“点击书架”，当图片中有多个“书架”空间的时候，就有可能执行失败。解法：在描述测试步骤的时候，给出空间的大概位置，比如“点击左下角的书架按钮”，“点击第一个视频封面等”
挑战3：部分空间无法定位，一些APP特有的图标，而且没有文字说明的图片，大模型可能无法准确识别。解法：在提示词中加入这些特定信息，比如“向上向外的箭头表示分享按钮”
挑战4：由于大模型的缓存机制，导致测试用例在不同分辨率的设备上执行，返回相同的坐标，比如测试用例在A设备上执行成功之后，在B设备上执行的时候，大模型会直接返回在A设备上识别的结果，导致在B设备上执行失败。解法：将坐标识别替换成空间序号识别，在图片上标注出所有的控件，以及控件的序号，大模型在识别成功之后，直接返回控件的序号，这样就避免了由于大模型的缓存机制导致执行失败的问题。
挑战5：缓存假命中问题。当用例执行时，根据整体图片相似度（如95%）判断缓存命中。但若两张图整体相似度高，而局部关键操作区域不同（如按钮图标变化），导致使用错误的缓存坐标，操作失败。解法：在整体图片相似度判断的基础上，增加对关键区域的局部相似度校验。具体方法：根据上一次执行该步骤时的操作坐标，在缓存图片和当前图片的相同区域（以坐标为中心，扩展一定区域）分别截取子图，计算子图相似度。只有整体相似度和局部区域相似度都满足阈值，才认为缓存命中。否则，重新调用CV模型识别。
视觉感知层 (CV Module): 基于YOLOv5等目标检测模型实时识别屏幕截图中的控件（按钮、输入框、文本标签等）及其位置、类型、文本内容。生成屏幕的“结构化描述”（控件列表、位置、属性）。
自然语言理解层 (LLM Module): 接收测试人员的自然语言指令或录制的用例描述。理解指令意图（操作类型：点击、输入、滑动、验证？）和目标对象（哪个控件？）。
意图-控件匹配与坐标生成层 (Alignment & Planning): 将LLM理解的意图（操作+目标描述）与CV层识别的控件列表进行匹配。将匹配到的控件位置转换为设备屏幕上的可执行坐标（或控件引用）。
执行引擎层 (Execution Engine): 调用底层自动化框架（如ADB/SCRCPY/WDA, 或自研轻量级驱动）执行坐标点击、输入文本、滑动等操作。处理断言逻辑。
缓存与优化层 (Cache & Optimizer): 关键组件，提升效率和稳定性。
2.2 核心挑战与“踩坑”经验：
挑战1:执行效率低，token消耗大：视觉模型接口请求慢（10-20s/次），输入包括截图编码，导致token消耗比较多。解法：增加缓存机制，将执行过的步骤和图片缓存，通过图片相似度匹配历史操作步骤，命中则直接复用结果，提升执行效率，同时降低token的消耗。
挑战2：测试用例的描述影响测试用例的执行，例如在测试用例执行步骤：“点击书架”，当图片中有多个“书架”空间的时候，就有可能执行失败。解法：在描述测试步骤的时候，给出空间的大概位置，比如“点击左下角的书架按钮”，“点击第一个视频封面等”
挑战3：部分空间无法定位，一些APP特有的图标，而且没有文字说明的图片，大模型可能无法准确识别。解法：在提示词中加入这些特定信息，比如“向上向外的箭头表示分享按钮”
挑战4：由于大模型的缓存机制，导致测试用例在不同分辨率的设备上执行，返回相同的坐标，比如测试用例在A设备上执行成功之后，在B设备上执行的时候，大模型会直接返回在A设备上识别的结果，导致在B设备上执行失败。解法：将坐标识别替换成空间序号识别，在图片上标注出所有的控件，以及控件的序号，大模型在识别成功之后，直接返回控件的序号，这样就避免了由于大模型的缓存机制导致执行失败的问题。
挑战5：缓存假命中问题。当用例执行时，根据整体图片相似度（如95%）判断缓存命中。但若两张图整体相似度高，而局部关键操作区域不同（如按钮图标变化），导致使用错误的缓存坐标，操作失败。解法：在整体图片相似度判断的基础上，增加对关键区域的局部相似度校验。具体方法：根据上一次执行该步骤时的操作坐标，在缓存图片和当前图片的相同区域（以坐标为中心，扩展一定区域）分别截取子图，计算子图相似度。只有整体相似度和局部区域相似度都满足阈值，才认为缓存命中。否则，重新调用CV模型识别。
3. 应用AI录制回放的自动化实践
3.1 项目选型介绍：
埋点测试介绍：介绍埋点的定义与价值，埋点测试的核心特点，pgc播放业务核心埋点介绍，埋点测试过程介绍，埋点测试的困境
埋点自动化方案选型调研：传统UI自动化方案痛点，基于埋点自动化特点，拥抱新技术，思考采用ocr或者AI的方案进行测试，通过对比ocr和AI的特点，介绍AI录制回放的优势，
AI录制回放与埋点的结合：介绍PGC播放场景的操作特性，用户操作高度标准化，核心行为为高频基础操作，播控识别操控等。选型AI录制回放，解决元素定位脆弱性和跨端可用性问题
3.2 埋点自动化框架设计:
埋点自动化框架采用分层设计，分为测试数据层，基础服务层，用例层，数据断言层和结果层。基于AI驱动的自动化引擎，进行测试用例录制作为埋点的用例步骤，通过DOM语义理解引擎解析自然语言测试步骤，定位目标元素并模拟交互行为。
核心设计：
用例组织设计：埋点自动化用例分为数据前置准备（mock操作，预期结果准备），执行埋点操作的步骤，埋点的断言。使用了BDD模式，通过自然语言书写自动化用例，映射到steps来调用代码。Given对应是前置埋点数据准备，通过mock服务固化初始条件，不同的测试用例对应不同的mock规则，统一使用mock服务管理。When对应是埋点的测试用例步骤的实现，测试步骤为AI执行用例的步骤，可重复使用用例步骤。Then对应是埋点上报的断言实现。
用例执行设计：基于AI驱动的自动化引擎做用例录制和用例执行组件，执行埋点操作步骤。解决核心问题：
1 )元素根据实际当前界面的实际情况智能识别, 不会因为元素的微小变动导致定位失败
2) 跨端只需使用一套用例
断言模块设计：平台提供断言模块，识别元素在页面展示，例如进入页面和退出页面成功等操作，框架设计基于埋点上报特性，可自定义断言模块，增加数据校验模块。
3.3 核心挑战与“踩坑”经验：
挑战一：跨平台操作模块AI录制回放可以解决跨平台录制问题，但无法解决不同平台初始化代理的操作步骤不同，所以不同平台的驱动需要统一管理。利用跨平台模块，根据环境变量初始化，对驱动进行统一管理。调用时自动调用对应平台的底层操作，操控使用同一套测试用例，只在测试步骤进行区分。
挑战二：AI执行用例失败的重试机制基于埋点执行失败报告的截图以及日志，进行反复尝试，寻找最优解，如何描述用例使AI录制和执行成功的探索，加重试机制。通过日志和报告分析，得出失败的原因，重新优化case描述，重新执行，不断提高通过率。
3.4 实践结果展示
支持端的情况、支持场景、准确率和通过率等实践结果
埋点测试介绍：介绍埋点的定义与价值，埋点测试的核心特点，pgc播放业务核心埋点介绍，埋点测试过程介绍，埋点测试的困境
埋点自动化方案选型调研：传统UI自动化方案痛点，基于埋点自动化特点，拥抱新技术，思考采用ocr或者AI的方案进行测试，通过对比ocr和AI的特点，介绍AI录制回放的优势，
AI录制回放与埋点的结合：介绍PGC播放场景的操作特性，用户操作高度标准化，核心行为为高频基础操作，播控识别操控等。选型AI录制回放，解决元素定位脆弱性和跨端可用性问题
3.2 埋点自动化框架设计:
埋点自动化框架采用分层设计，分为测试数据层，基础服务层，用例层，数据断言层和结果层。基于AI驱动的自动化引擎，进行测试用例录制作为埋点的用例步骤，通过DOM语义理解引擎解析自然语言测试步骤，定位目标元素并模拟交互行为。
核心设计：
用例组织设计：埋点自动化用例分为数据前置准备（mock操作，预期结果准备），执行埋点操作的步骤，埋点的断言。使用了BDD模式，通过自然语言书写自动化用例，映射到steps来调用代码。Given对应是前置埋点数据准备，通过mock服务固化初始条件，不同的测试用例对应不同的mock规则，统一使用mock服务管理。When对应是埋点的测试用例步骤的实现，测试步骤为AI执行用例的步骤，可重复使用用例步骤。Then对应是埋点上报的断言实现。
用例执行设计：基于AI驱动的自动化引擎做用例录制和用例执行组件，执行埋点操作步骤。解决核心问题：
1 )元素根据实际当前界面的实际情况智能识别, 不会因为元素的微小变动导致定位失败
2) 跨端只需使用一套用例
断言模块设计：平台提供断言模块，识别元素在页面展示，例如进入页面和退出页面成功等操作，框架设计基于埋点上报特性，可自定义断言模块，增加数据校验模块。
3.3 核心挑战与“踩坑”经验：
挑战一：跨平台操作模块AI录制回放可以解决跨平台录制问题，但无法解决不同平台初始化代理的操作步骤不同，所以不同平台的驱动需要统一管理。利用跨平台模块，根据环境变量初始化，对驱动进行统一管理。调用时自动调用对应平台的底层操作，操控使用同一套测试用例，只在测试步骤进行区分。
挑战二：AI执行用例失败的重试机制基于埋点执行失败报告的截图以及日志，进行反复尝试，寻找最优解，如何描述用例使AI录制和执行成功的探索，加重试机制。通过日志和报告分析，得出失败的原因，重新优化case描述，重新执行，不断提高通过率。
3.4 实践结果展示
支持端的情况、支持场景、准确率和通过率等实践结果
4. 未来展望
4.1 技术能力提升：更精准、更稳定、更智能
更精准：识别控件更贴合业务语义：
提升通用控件识别准确率，支持多语言、多样式 UI。针对业务特有控件（如播放页定制按钮、图标型功能键等），通过建立控件知识库或训练小型专用模型，实现高精度识别与标注。融合图像、文字、布局等多模态信息，提升语义级控件识别能力。
更稳定：跨设备自动适配，减少环境依赖：
引入空间结构匹配机制，构建控件的相对位置模型，适配不同设备界面布局。
支持控件语义级识别与引用，不依赖像素级坐标，避免因分辨率、DPI 差异导
致的误操作。实现一次录制、多端回放，增强用例迁移能力，显著降低维护成本。
更智能：操作更可靠，系统具备自我校正能力
多个相似控件（如多个“播放”按钮）共存时，系统可结合上下文、位置信息、历史操作等，智能推理正确目标。增强模型对错误执行的感知与修正能力，例如通过断言失败自动重试、提示词重构、切换备选控件等方式提升稳定性。逐步构建“反馈-优化-再执行”的闭环，让系统在执行中持续学习和进化。
4.2 测试用例自动生成：从“人写”到“AI写”
基于探索式执行生成用例：AI在应用中模拟用户操作，自动点击、滑动、跳转等，通过视觉感知与语义理解自主探索页面逻辑，记录每一步操作路径。将探索过程中形成的“操作轨迹”结构化为标准测试用例，包含：步骤描述、控件引用、预期结果、断言逻辑等。
基于操作日志回溯生成用例：结合用户真实操作行为（如点击轨迹、页面跳转、输入内容等）自动生成标准化的测试用例。可广泛应用于冒烟测试、回归测试等。
自然语言生成测试用例描述：测试人员只需用自然语言描述业务流程，如“打开播放页并点击第一个视频”，系统即可自动生成对应的结构化测试用例，包括控件匹配、坐标规划、断言逻辑等。
4.3 自动化测试覆盖更多场景
全链路业务流程自动化：不仅限于前端 UI 操作，也将逐步融合后端接口测试、埋点校验、数据一致性校验，实现完整链路的端到端验证。
更精准：识别控件更贴合业务语义：
提升通用控件识别准确率，支持多语言、多样式 UI。针对业务特有控件（如播放页定制按钮、图标型功能键等），通过建立控件知识库或训练小型专用模型，实现高精度识别与标注。融合图像、文字、布局等多模态信息，提升语义级控件识别能力。
更稳定：跨设备自动适配，减少环境依赖：
引入空间结构匹配机制，构建控件的相对位置模型，适配不同设备界面布局。
支持控件语义级识别与引用，不依赖像素级坐标，避免因分辨率、DPI 差异导
致的误操作。实现一次录制、多端回放，增强用例迁移能力，显著降低维护成本。
更智能：操作更可靠，系统具备自我校正能力
多个相似控件（如多个“播放”按钮）共存时，系统可结合上下文、位置信息、历史操作等，智能推理正确目标。增强模型对错误执行的感知与修正能力，例如通过断言失败自动重试、提示词重构、切换备选控件等方式提升稳定性。逐步构建“反馈-优化-再执行”的闭环，让系统在执行中持续学习和进化。
4.2 测试用例自动生成：从“人写”到“AI写”
基于探索式执行生成用例：AI在应用中模拟用户操作，自动点击、滑动、跳转等，通过视觉感知与语义理解自主探索页面逻辑，记录每一步操作路径。将探索过程中形成的“操作轨迹”结构化为标准测试用例，包含：步骤描述、控件引用、预期结果、断言逻辑等。
基于操作日志回溯生成用例：结合用户真实操作行为（如点击轨迹、页面跳转、输入内容等）自动生成标准化的测试用例。可广泛应用于冒烟测试、回归测试等。
自然语言生成测试用例描述：测试人员只需用自然语言描述业务流程，如“打开播放页并点击第一个视频”，系统即可自动生成对应的结构化测试用例，包括控件匹配、坐标规划、断言逻辑等。
4.3 自动化测试覆盖更多场景
全链路业务流程自动化：不仅限于前端 UI 操作，也将逐步融合后端接口测试、埋点校验、数据一致性校验，实现完整链路的端到端验证。
强强
华为云 高级渗透测试专家
华为云云服务产品集成与验证部高级渗透测试专家，先后就职于 360集团和华为云计算，目前主要负责华为混合云产品的渗透测试、场景测试、测试 AI工程等专项工作，致力于构建全链路的云安全防护体系，未来将继续聚焦云原生安全与 AI测试前沿领域，以“攻防对抗”思维驱动产品安全能力迭代，助力华为云先进测试生态的构建。
待定
待定
Al Agent 驱动的云计算客户场景测试全链路自动化实践
云计算客户场景测试面临三大核心挑战：
1. 客户业务场景复杂多样，难以覆盖全量场景，传统人工设计易遗漏边缘场景；
2. 基础设施与云服务协同关系动态变化，测试环境搭建耗时长、一致性差；
3. 自动化测试瓶颈突出，客户应用系统模拟、行为数据生成与基础设施部署的端到端联动效率低下。
本议题聚焦如何通过 Al Agent 技术突破这些痛点，实现从客户应用生成到测试执行、环境部署的全流程智能化，为云计算场景测试提供高效解决方案。
1. 客户业务场景复杂多样，难以覆盖全量场景，传统人工设计易遗漏边缘场景；
2. 基础设施与云服务协同关系动态变化，测试环境搭建耗时长、一致性差；
3. 自动化测试瓶颈突出，客户应用系统模拟、行为数据生成与基础设施部署的端到端联动效率低下。
本议题聚焦如何通过 Al Agent 技术突破这些痛点，实现从客户应用生成到测试执行、环境部署的全流程智能化，为云计算场景测试提供高效解决方案。
内容大纲
1. 云计算客户场景测试的困境与破局思路
1.1 全量场景覆盖难题：客户业务多样性与边缘场景隐蔽性
1.2 协同测试困局：基础服务与云服务的动态适配挑战
1.3 自动化瓶颈：传统工具在端到端流程中的局限
1.4 破局方向：Al Agent技术在测试全链路的应用潜力
2. Al Agent 赋能客户应用系统生成：从需求到可运行实例
2.1 基于多模态输入的应用模型构建（含客户场景设计、客户业务逻辑设计）
2.2 智能生成可运行应用实例：代码自动生成与自动调试机制
2.3 实践案例：机场票务系统的AI模拟生成效果」
2.1 基于多模态输入的应用模型构建（含客户场景设计、客户业务逻辑设计）
2.2 智能生成可运行应用实例：代码自动生成与自动调试机制
2.3 实践案例：机场票务系统的AI模拟生成效果」
3. AI驱动的客户行为与数据测试系统
3.1 客户行为建模：基于历史数据的动态行为路径生成
3.2 高仿真测试数据生成：兼顾数据隐私与业务真实性的合成策略
3.3 实时反馈机制：AI Agent根据测试结果动态调整行为与数据参数
3.4 效能收益：测试数据准备时间缩短80%，异常场景发现率提升50%
3.1 客户行为建模：基于历史数据的动态行为路径生成
3.2 高仿真测试数据生成：兼顾数据隐私与业务真实性的合成策略
3.3 实时反馈机制：AI Agent根据测试结果动态调整行为与数据参数
3.4 效能收益：测试数据准备时间缩短80%，异常场景发现率提升50%
4. 基础设施自动化部署的端到端实现
4.1 AI生成 Terraform 部署脚本：基于云资源需求的智能编排逻辑
4.2 全链路联动：应用生成、行为模拟与基础设施部署的无缝衔接流程
4.3 实践成效：部署环境一致性达99%，端到端测试周期从x周压缩至1.5天
4.1 AI生成 Terraform 部署脚本：基于云资源需求的智能编排逻辑
4.2 全链路联动：应用生成、行为模拟与基础设施部署的无缝衔接流程
4.3 实践成效：部署环境一致性达99%，端到端测试周期从x周压缩至1.5天
5. 总结与展望
5.1 技术落地关键经验：测试AI Agent开发和Multi-Agent协同测试
5.2 未来方向：自愈&自进化测试体系
5.1 技术落地关键经验：测试AI Agent开发和Multi-Agent协同测试
5.2 未来方向：自愈&自进化测试体系
敬请期待
......
.....
待定
待定
敬请期待
....
关注QECon公众号
议题投稿
lijie@qecon.net
商务合作
151-2264-3988 木子
票务联系
135-2067-8913 郭梦媛
媒体合作
135-1619-6409 皮皮
添加QECon小助手，获取
会议最新资讯
购票咨询
13520678913 郭梦媛
