专场：LLM赋能下测试实践与流程再造
本专场聚焦大语言模型（LLM）如何革新软件测试全流程，覆盖测试设计、执行到缺陷分析的关键环节。通过行业的优秀案例探讨LLM如何解决传统测试的效率瓶颈（如用例生成耗时、脚本维护难）并推动流程再造（如人机协同转型）。同时，分享落地路径：从“测试设计，脚本生成”等低风险高价值场景切入，逐步扩展至全流程智能化，赋能测试团队从执行向AI团队转型。
专场出品人：任红亮
中兴通讯 AI专职教练 AI研发提效项目规划组组长
测试领域10多年工作经验，担任测试总工等核心岗位。现在作为AI专职教练，AI研发提效项目规划组组长，测试领域公司AI研发提效负责人。负责AI在中兴研发领域的整体规划和落地，包括模型，工具，知识库，评测等，参与信通院智能化测试能力规范等规范编写。
黄立华
华为 GTS测试专家
GTS测试专家，目前主要负责GTSLLM辅助测试设计&AI大模型测试。
待定
待定
基于数据飞轮多轮知识库AI辅助测试用例生成测试实践
1. 产品测试验证挑战：新老特性交互、验证点设计不全
2. 如何提取全面提取测试点避免遗漏？
3. 测试过程如何构建领域测试设计知识库，知识库如何用于LLM辅助测试设计
2. 如何提取全面提取测试点避免遗漏？
3. 测试过程如何构建领域测试设计知识库，知识库如何用于LLM辅助测试设计
内容大纲
1. 测试设计工作模式改变
2. 整体解决方案
3. 关键技术1：DSL切片研发文档
4. 关键技术2：数据质量提升-测试需求分析
5. 关键技术3：多轮prompt输出测试设计方法测试用例
6. 关键技术4：数据飞轮知识库构建
7. 冠军技术5：数据飞轮知识库应用于LLM辅助测试用例
听众收益
1. 解决测试过程中测试领域知识库构建
2. 多轮prompt提升测试用例生成采纳率
3. 数据飞轮知识库如何应用于LLM负责测试用例生成
王旭峰
饿了么 高级测试开发专家
饿了么测试开发专家，目前就职于饿了么技术中心质量效能团队，主要负责研发测试环节质量工具的建设以及效能优化工作，近两年主要专注于AI+领域,包括基于AI的前端自动化工具能力建设、基于AI的客诉故障预警能力建设,在利用大模型解决互联网相关领域的一些问题积累了一些经验。
待定
待定
基于大模型的客诉故障探测方案实践与思考
在互联网平台中，客户投诉不仅是服务质量的“晴雨表”，更是系统故障的重要“哨兵”。传统上用以防范故障的常规监控手段,无论从投入产出比考量，还是业务场景的复杂度考量，很难做到百分之百的覆盖，其中的一部分问题通过客诉的形式最终被发现。
因此，一旦风险被触发后，如果在客诉中及时感知，就能尽快发现问题，解决问题，减小影响范围。
随着大模型技术的快速发展，我们尝试将AI能力引入到客诉数据处理中，探索一条从用户视角自动识别潜在系统问题的新路径。
内容大纲
1. 背景介绍
2. 项目成果：低危故障显著下降
3. 解决方案：利用大模型、视觉模型、Embedding、工具调用，结合工程能力，提升问题召回准确性、排查效率
3.1 总体流程
3.2 能力建设
3.3 工程实践
4. 方案落地：落地策略—>快速迭代优化->大规模推广
5. 问题、未来展望
听众收益
1. 获得通过客诉问题保障生产业务质量的新思路：构建用户反馈-技术干预的闭环机制，替代部分人工监控盲区
2. 了解如何利用大模型技术+工程能力,构建一套可用的、有稳定预期的客诉故障预警系统
3. 启发跨领域协作、共建、落地模式
因此，一旦风险被触发后，如果在客诉中及时感知，就能尽快发现问题，解决问题，减小影响范围。
随着大模型技术的快速发展，我们尝试将AI能力引入到客诉数据处理中，探索一条从用户视角自动识别潜在系统问题的新路径。
内容大纲
1. 背景介绍
2. 项目成果：低危故障显著下降
3. 解决方案：利用大模型、视觉模型、Embedding、工具调用，结合工程能力，提升问题召回准确性、排查效率
3.1 总体流程
3.2 能力建设
3.3 工程实践
4. 方案落地：落地策略—>快速迭代优化->大规模推广
5. 问题、未来展望
听众收益
1. 获得通过客诉问题保障生产业务质量的新思路：构建用户反馈-技术干预的闭环机制，替代部分人工监控盲区
2. 了解如何利用大模型技术+工程能力,构建一套可用的、有稳定预期的客诉故障预警系统
3. 启发跨领域协作、共建、落地模式
李远康
科大讯飞 测试部副总监
五级测试专家，拥有10年+软件测试领域深耕经验，历任测试负责人、测试总监、高级测试工程师，主导教育类、团队管理类等核心系统的质量保障及效能提升项目，为系统稳定迭代提供关键支撑。
深耕测试工具研发与自动化体系搭建，主导开发系统用例管理平台、系统监控平台，实现测试流程数字化与质量风险实时预警；精通端自动化框架实战应用，在元素定位策略、动态页面适配、用例自愈机制等领域有深入研究。
尤其擅长大模型测试工具落地中的 “可控性与稳定性平衡”，曾推动测试团队从 “脚本编写” 向 “用例设计” 转型，显著提升团队质量保障效率与核心竞争力。
深耕测试工具研发与自动化体系搭建，主导开发系统用例管理平台、系统监控平台，实现测试流程数字化与质量风险实时预警；精通端自动化框架实战应用，在元素定位策略、动态页面适配、用例自愈机制等领域有深入研究。
尤其擅长大模型测试工具落地中的 “可控性与稳定性平衡”，曾推动测试团队从 “脚本编写” 向 “用例设计” 转型，显著提升团队质量保障效率与核心竞争力。
待定
待定
智解用例・自生脚本・自愈执行：效率与可控的测试新解
一、行业痛点：大模型自主测试的落地难题
大模型技术在测试领域的应用虽受关注，但 “自然语言描述场景、AI 自动生成执行脚本” 的工具难以常态化落地，核心问题集中在 “不可控” 与 “不稳定”：
语义理解易偏差：大模型对测试用例中的业务术语、隐含条件易产生误判，导致测试逻辑偏离预期；
执行过程黑箱化：全链路自动化模式缺乏人工干预，页面元素变化或操作有前置依赖时，脚本易失效且难定位问题；
结果稳定性差：同一用例在不同场景下执行结果差异大，难以纳入常态化回归流程；
依赖大模型能力：核心功能过度依赖大模型多模态理解效果，复杂场景下识别准确率骤降，通用性不足；
回归测试成本高：页面微调易引发脚本失效，传统工具需人工逐一排查修复，拖累迭代进度。
二、破局思路：平衡效率与可控性，融入 “用例自愈” 能力
解决大模型自主测试落地难的关键，在于平衡效率与可控性，同时应对脚本易失效问题：
植入人工确认锚点：将流程拆分为 “用例分析→步骤生成→人工确认→脚本生成→执行验证”，仅在步骤生成环节人工干预，确保逻辑与业务预期一致；
动态循环执行：摒弃一次性生成完整脚本模式，改为 “单步生成→执行验证→保存成功脚本→循环下一步”，实时适配页面变化，提升稳定性；
工具化封装核心能力：弱化对大模型的依赖，用独立页面分析引擎、优先级定位策略、本地调试环境保障稳定性与可控性；
沉淀成功案例：将经确认且执行成功的脚本存入用例库，供相似场景复用，减少重复成本；
加入用例自愈能力：回归测试中脚本失败时，自动判断失败类型。若为步骤执行失败，立即重新分析页面、生成新脚本并替换原失败脚本，减少人工修复频率。
三、最终目标：推动自然语言测试实用化
通过上述设计，实现三大目标：
从手动编写到自动生成脚本，提升脚本设计效能；
释放测试人员精力，聚焦用例逻辑与异常场景；
支撑常态化回归测试，降低脚本维护成本；
最终达成 “人工仅一次确认，工具自动完成后续流程且具备自愈能力” 的高效模式，让自然语言驱动的自动化测试从 “演示工具” 变为 “生产工具”。
内容大纲
1. 问题分析：大模型自主测试的落地困局与核心挑战
1.1 行业现状：从 “热捧” 到 “遇冷” 的现实落差
1.1.1 大模型在测试领域的应用热潮：自然语言生成脚本的技术愿景与行业期待
1.1.2 落地瓶颈：为何多数工具停留在 “演示阶段”，难以进入生产环境？
1.2 核心痛点拆解（结合真实场景案例）
1.2.1 语义理解偏差：业务术语误判导致测试逻辑失效（如 “最后一项”“提交后” 等隐含条件解析错误）
1.2.2 执行黑箱失控：全链路自动化缺乏干预节点，元素变化后脚本失效且排查困难
1.2.3 结果稳定性差：同一用例在不同页面状态下执行成功率波动（实测数据：某工具相同用例执行成功率
大模型技术在测试领域的应用虽受关注，但 “自然语言描述场景、AI 自动生成执行脚本” 的工具难以常态化落地，核心问题集中在 “不可控” 与 “不稳定”：
语义理解易偏差：大模型对测试用例中的业务术语、隐含条件易产生误判，导致测试逻辑偏离预期；
执行过程黑箱化：全链路自动化模式缺乏人工干预，页面元素变化或操作有前置依赖时，脚本易失效且难定位问题；
结果稳定性差：同一用例在不同场景下执行结果差异大，难以纳入常态化回归流程；
依赖大模型能力：核心功能过度依赖大模型多模态理解效果，复杂场景下识别准确率骤降，通用性不足；
回归测试成本高：页面微调易引发脚本失效，传统工具需人工逐一排查修复，拖累迭代进度。
二、破局思路：平衡效率与可控性，融入 “用例自愈” 能力
解决大模型自主测试落地难的关键，在于平衡效率与可控性，同时应对脚本易失效问题：
植入人工确认锚点：将流程拆分为 “用例分析→步骤生成→人工确认→脚本生成→执行验证”，仅在步骤生成环节人工干预，确保逻辑与业务预期一致；
动态循环执行：摒弃一次性生成完整脚本模式，改为 “单步生成→执行验证→保存成功脚本→循环下一步”，实时适配页面变化，提升稳定性；
工具化封装核心能力：弱化对大模型的依赖，用独立页面分析引擎、优先级定位策略、本地调试环境保障稳定性与可控性；
沉淀成功案例：将经确认且执行成功的脚本存入用例库，供相似场景复用，减少重复成本；
加入用例自愈能力：回归测试中脚本失败时，自动判断失败类型。若为步骤执行失败，立即重新分析页面、生成新脚本并替换原失败脚本，减少人工修复频率。
三、最终目标：推动自然语言测试实用化
通过上述设计，实现三大目标：
从手动编写到自动生成脚本，提升脚本设计效能；
释放测试人员精力，聚焦用例逻辑与异常场景；
支撑常态化回归测试，降低脚本维护成本；
最终达成 “人工仅一次确认，工具自动完成后续流程且具备自愈能力” 的高效模式，让自然语言驱动的自动化测试从 “演示工具” 变为 “生产工具”。
内容大纲
1. 问题分析：大模型自主测试的落地困局与核心挑战
1.1 行业现状：从 “热捧” 到 “遇冷” 的现实落差
1.1.1 大模型在测试领域的应用热潮：自然语言生成脚本的技术愿景与行业期待
1.1.2 落地瓶颈：为何多数工具停留在 “演示阶段”，难以进入生产环境？
1.2 核心痛点拆解（结合真实场景案例）
1.2.1 语义理解偏差：业务术语误判导致测试逻辑失效（如 “最后一项”“提交后” 等隐含条件解析错误）
1.2.2 执行黑箱失控：全链路自动化缺乏干预节点，元素变化后脚本失效且排查困难
1.2.3 结果稳定性差：同一用例在不同页面状态下执行成功率波动（实测数据：某工具相同用例执行成功率
差异达 40%）
1.2.4 大模型依赖陷阱：复杂交互场景（如拖拽、悬浮菜单）中 MCP 识别准确率骤降（低于 50%）
1.2.5 回归测试成本高：页面微调引发批量脚本失效，人工修复占测试周期的 60% 以上
2. 技术抉择：从 “理想方案” 到 “落地可行” 的权衡
2.1 核心设计理念确立
2.1.1 拒绝 “全自动化神话”：为何必须保留 “人工确认锚点”？（从 3 次失败尝试中得出的结论）
2.1.2 “小步快跑” 优于 “一步到位”：动态循环执行的必要性论证
2.2 关键技术路径选择
2.2.1 大模型依赖 vs 工具化封装：为何放弃 “纯大模型生成”，转向独立页面分析引擎？
对比数据：大模型生成脚本在动态页面中的稳定性（65%）vs 工具化定位策略（92%）
2.2.2 定位策略优先级设计：如何平衡 “稳定性” 与 “兼容性”？
技术选型：data-testid→Role→Text→CSS→Xpath 的层级策略（基于 1000 + 页面元素的属性稳定性分析）
2.2.3 自愈能力触发机制：为何仅针对 “步骤失败” 而非 “断言失败”？（功能缺陷与脚本问题的本质区别）
3. 实践踩坑：从 “理论可行” 到 “工程落地” 的避坑指南
3.1 技术实现中的典型问题
3.1.1 页面分析引擎性能瓶颈：首次扫描耗时过长（初期版本单页面分析需 8 秒，优化后降至 1.2 秒）
3.1.2 动态元素定位冲突：同一控件多属性匹配时的优先级失效（如 “确认” 按钮同时存在文本与data-id）
3.1.3 自愈流程死循环：步骤失败后重新生成脚本仍失败，导致无限循环（解决方案：设置 3 次重试上限 +
1.2.4 大模型依赖陷阱：复杂交互场景（如拖拽、悬浮菜单）中 MCP 识别准确率骤降（低于 50%）
1.2.5 回归测试成本高：页面微调引发批量脚本失效，人工修复占测试周期的 60% 以上
2. 技术抉择：从 “理想方案” 到 “落地可行” 的权衡
2.1 核心设计理念确立
2.1.1 拒绝 “全自动化神话”：为何必须保留 “人工确认锚点”？（从 3 次失败尝试中得出的结论）
2.1.2 “小步快跑” 优于 “一步到位”：动态循环执行的必要性论证
2.2 关键技术路径选择
2.2.1 大模型依赖 vs 工具化封装：为何放弃 “纯大模型生成”，转向独立页面分析引擎？
对比数据：大模型生成脚本在动态页面中的稳定性（65%）vs 工具化定位策略（92%）
2.2.2 定位策略优先级设计：如何平衡 “稳定性” 与 “兼容性”？
技术选型：data-testid→Role→Text→CSS→Xpath 的层级策略（基于 1000 + 页面元素的属性稳定性分析）
2.2.3 自愈能力触发机制：为何仅针对 “步骤失败” 而非 “断言失败”？（功能缺陷与脚本问题的本质区别）
3. 实践踩坑：从 “理论可行” 到 “工程落地” 的避坑指南
3.1 技术实现中的典型问题
3.1.1 页面分析引擎性能瓶颈：首次扫描耗时过长（初期版本单页面分析需 8 秒，优化后降至 1.2 秒）
3.1.2 动态元素定位冲突：同一控件多属性匹配时的优先级失效（如 “确认” 按钮同时存在文本与data-id）
3.1.3 自愈流程死循环：步骤失败后重新生成脚本仍失败，导致无限循环（解决方案：设置 3 次重试上限 +
人工介入阈值）
3.2 业务适配中的挑战
3.2.1 复杂业务逻辑拆解困难：如 “多级审批流程” 等长链路用例的步骤拆分准确率低（初期不足 70%）
3.2.2 行业特殊控件兼容：富文本编辑器、日期选择器等非标准控件的操作生成失败（通过定制化控件库解决）
4. 工程实践：构建 “稳定 + 高效” 的自动化测试体系
4.1 流程设计：分阶段闭环机制
4.1.1 用例分析→步骤生成→人工确认→脚本生成→执行验证的全链路拆解
4.1.2 人工确认节点的颗粒度控制：为何仅需 “步骤级确认”，而非 “脚本级干预”？（效率与可控性的平衡）
4.2 核心模块实现细节
4.2.1 页面分析引擎：实时控件提取与结构化存储（基于 Playwright API 的二次开发）
4.2.2 自愈能力模块：失败类型智能判断（断言失败 vs 步骤失败）与自动重试逻辑
4.2.3 用例库沉淀机制：脚本 + 场景 + 环境的关联存储，支持相似场景复用（复用率提升至 65%）
4.3 与现有平台的无缝衔接
4.3.1 用例生成及管理：测试平台提供功能用例生成及管理，使用大模型从需求到用例的生成
4.3.2 执行结果与报告：测试平台提供任务编排及执行能力，并形成测试分析报告，实现从功能用例到脚本生成，
3.2 业务适配中的挑战
3.2.1 复杂业务逻辑拆解困难：如 “多级审批流程” 等长链路用例的步骤拆分准确率低（初期不足 70%）
3.2.2 行业特殊控件兼容：富文本编辑器、日期选择器等非标准控件的操作生成失败（通过定制化控件库解决）
4. 工程实践：构建 “稳定 + 高效” 的自动化测试体系
4.1 流程设计：分阶段闭环机制
4.1.1 用例分析→步骤生成→人工确认→脚本生成→执行验证的全链路拆解
4.1.2 人工确认节点的颗粒度控制：为何仅需 “步骤级确认”，而非 “脚本级干预”？（效率与可控性的平衡）
4.2 核心模块实现细节
4.2.1 页面分析引擎：实时控件提取与结构化存储（基于 Playwright API 的二次开发）
4.2.2 自愈能力模块：失败类型智能判断（断言失败 vs 步骤失败）与自动重试逻辑
4.2.3 用例库沉淀机制：脚本 + 场景 + 环境的关联存储，支持相似场景复用（复用率提升至 65%）
4.3 与现有平台的无缝衔接
4.3.1 用例生成及管理：测试平台提供功能用例生成及管理，使用大模型从需求到用例的生成
4.3.2 执行结果与报告：测试平台提供任务编排及执行能力，并形成测试分析报告，实现从功能用例到脚本生成，
再到报告输出的全流程打通
5. 收益量化：从 “技术创新” 到 “业务价值” 的转化
5.1 效能提升数据（AI听说课堂项目）
5.1.1 脚本设计效率：手动编写（30 分钟 / 用例）→自动生成（5 分钟 / 用例），耗时降低 83%
5.1.2 回归测试成本：人工修复脚本占比从 60% 降至 15%，测试周期缩短 40%
5.1.3 脚本稳定性：动态页面中执行成功率从 65%（传统工具）提升至 92%
5.2 质量保障升级
5.2.1 测试覆盖率：因脚本生成效率提升，回归用例覆盖率从 50% 提升至 85%
5.2.2 缺陷发现时效：线上问题反馈量减少 35%（早期拦截能力增强）
5.3 团队价值释放
测试人员精力分配变化：脚本编写（原 60%）→用例逻辑设计与异常分析（现 70%）
6. 总结与展望
6.1 核心经验：
6.1.1 可控性优先于 “全自动”：在效率与稳定性的博弈中，必须保留 “人工确认关键节点”，用最小化干预换取
5. 收益量化：从 “技术创新” 到 “业务价值” 的转化
5.1 效能提升数据（AI听说课堂项目）
5.1.1 脚本设计效率：手动编写（30 分钟 / 用例）→自动生成（5 分钟 / 用例），耗时降低 83%
5.1.2 回归测试成本：人工修复脚本占比从 60% 降至 15%，测试周期缩短 40%
5.1.3 脚本稳定性：动态页面中执行成功率从 65%（传统工具）提升至 92%
5.2 质量保障升级
5.2.1 测试覆盖率：因脚本生成效率提升，回归用例覆盖率从 50% 提升至 85%
5.2.2 缺陷发现时效：线上问题反馈量减少 35%（早期拦截能力增强）
5.3 团队价值释放
测试人员精力分配变化：脚本编写（原 60%）→用例逻辑设计与异常分析（现 70%）
6. 总结与展望
6.1 核心经验：
6.1.1 可控性优先于 “全自动”：在效率与稳定性的博弈中，必须保留 “人工确认关键节点”，用最小化干预换取
最大化可控（如步骤拆解环节的人工校验，使后续脚本生成准确率提升至 95%）
6.1.2 工具化能力高于 “大模型依赖”：将核心逻辑（如元素定位、失败重试）沉淀为可复用的工具模块，而非依赖
6.1.2 工具化能力高于 “大模型依赖”：将核心逻辑（如元素定位、失败重试）沉淀为可复用的工具模块，而非依赖
大模型的 “黑箱输出”，是应对复杂业务场景的关键（工具化封装后，复杂控件支持率从 58% 提升至 91%）
6.1.3 自愈设计要区分 “脚本问题” 与 “功能缺陷”：仅对 “步骤执行失败” 触发自愈，避免将功能 bug 误判为脚本
6.1.3 自愈设计要区分 “脚本问题” 与 “功能缺陷”：仅对 “步骤执行失败” 触发自愈，避免将功能 bug 误判为脚本
问题，确保测试结果的准确性（该机制使缺陷误判率控制在 3% 以内）
6.2 未来迭代方向：
6.2.1 大模型辅助优化：如何让 AI 在 “人工确认” 环节提供更精准的步骤建议？
6.2.2 跨端适配：扩展至 APP、小程序等场景的技术路径
6.2 未来迭代方向：
6.2.1 大模型辅助优化：如何让 AI 在 “人工确认” 环节提供更精准的步骤建议？
6.2.2 跨端适配：扩展至 APP、小程序等场景的技术路径
6.3 行业启示：测试工具的 “务实主义”—— 从 “炫技” 到 “解决问题” 的回归
关注QECon公众号
议题投稿
lijie@qecon.net
商务合作
151-2264-3988 木子
票务联系
135-2067-8913 郭梦媛
媒体合作
135-1619-6409 皮皮
添加QECon小助手，获取
会议最新资讯
购票咨询
13520678913 郭梦媛
