一、项目背景
随着交易业务的快速增长，对质量保障工作提出了更高标准与全新要求。为提升研发体验和架构升级，大量后台页面经历从 Vue -> React -> 全栈的迁移过程。业务演进过程中，后台能力持续迭代与优化；团队在交付新能力的同时，同步保障存量链路的稳定与可预期行为。为进一步完善测试用例覆盖范围，高效支撑回归测试与重构验证工作，需通过技术手段升级质量保障模式，为业务与架构迭代提供更充分的质量支撑。
E2E 测试： 即端到端测试，是一种从用户视角出发，模拟真实操作验证应用完整业务流程的自动化测试方法。自动化生成用例： 用线上内部运营操作日志自动生成 E2E 测试用例，快速覆盖核心流程，解决用例缺失问题。智能元素定位： 自动识别重构等场景 UI 变化并调整定位策略，实现维护流程的自动化。平台化管理： 通过数据看板管理用例和执行结果，让 E2E 测试可追踪、可优化，提升测试效率。
基于以上分析，我们致力于构建一套自动化 + 智能化的 E2E 测试方案，该方案旨在支撑快速迭代开发模式，有效应对用例覆盖与重构验证等场景，从而在现有资源条件下，持续为业务快速迭代和技术架构升级提供可靠的质量保障。
二、价值收益
提供基于线上真实运营行为的自动化 E2E 测试能力，能够实际发现页面线上/重构等场景的体验问题。在页面重构等迭代任务中，通过优化回归测试流程与资源分配，有效进一步提升测试支持效率。测试的页面代码覆盖率≥X%；无代码覆盖率场景步骤执行成功率≥X%。
页面代码覆盖率：页面用例在测试过程中 运行的代码行数 / 该页面关联的所有代码行数 * 100%步骤执行成功率：页面用例在测试过程中 执行成功的步骤数 / 用例总步骤数 * 100%。
三、方案选型
传统 E2E（DOM）
| 名词解释 | 核心差异 | |
|---|---|---|
| 传统 E2E | 基于 DOM 的测试方案，主要通过操作和验证浏览器中的页面元素，来模拟用户行为的测试方案。 | 定位方式：依赖 XPath/CSS 选择器。用例生成：手动编写或录制。维护成本：高（DOM 变化需手动更新用例）。 |
AI E2E
| 名词解释 | 核心差异 | |
|---|---|---|
| AI E2E | 指利用人工智能技术，增强传统 E2E 测试的智能化、自适应性和效率的测试方案。 | 定位方式：视觉识别、语义化分析（如按钮文本、图标）。用例生成：自动生成（基于用户行为日志或需求描述）。维护成本：低（AI 自动适应 UI 变化）。 |
方案对比
传统 E2E 优势： 贴近真实用户操作：实际触发页面渲染和事件。跨页面流程验证：适合测试多步骤业务场景（如登录→下单）。传统 E2E 劣势： 脆弱性：DOM 结构变化易导致用例失败（需频繁维护定位表达式）。执行速度慢：依赖浏览器渲染和网络请求。
AI E2E 优势： 降低维护成本：减少因 UI 微调导致的用例失败。提升覆盖率：AI 可探索非预期路径（如异常输入）。AI E2E 劣势： 黑盒性：AI 决策过程不透明，调试困难。高成本：需积累足够数据优化模型，复杂视觉处理需要更高性能。
基于上述对比分析，我们选用 AI 驱动的 E2E 测试方案，能够在支持重构场景的同时，显著提升用例生成的自动化水平，从而形成高效可持续的自动化测试解决方案。
四、AI 工具选型
| 特征 | |
|---|---|
| Midscene | 原生 JavaScript + WebExtensions API；开源 AI 驱动 UI 自动化工具； 支持 Playwright、Puppeteer 定制行为逻辑；支持 Dom 分析和视觉分析，如 Qwen-vl、Chain-vl。 |
| browser-use | Python + 大语言模型（LLM）+ 浏览器驱动；基于 Playwright；同时支持视觉和非视觉模型；同时支持 DOM 分析和视觉分析。 |
Midscene优点： 基于 JS 技术栈，前端友好，开发成本较低；支持 Playwright、Puppeteer 定制行为逻辑；公开渠道反馈与迭代节奏相对清晰；支持 DOM 与视觉多模态分析。如上优点对工程化落地更友好。Midscene缺点： 调用视觉/大模型时存在 Token 消耗与成本。
browser-use优点： 支持 Playwright 定制行为逻辑；支持 DOM 与视觉分析，能力面较全。browser-use缺点： 同样存在 Token 消耗与成本；基于 Python 技术栈，有开发语言熟悉成本。
综合评估后采用 Midscene，主要考量：与现有技术栈匹配： 以 JavaScript 为主，便于与前端工程、现有工具链协同，降低接入与维护成本。能力与扩展方式符合需求： 支持 DOM 与视觉等多路径信息输入，并可在需要时用 Puppeteer / Playwright 补充确定性、可编排的自动化逻辑，覆盖模型不稳定或不适用的环节。工程化与定制空间： 定制与扩展路径清晰，便于按业务拆解控制流、做兜底与回归，贴合当前团队的交付方式。
五、流程设计
核心流程图：
Midscene 测试过程详情：
核心流程可以概括为：将运营真实操作记录转化为可执行的测试用例，并通过智能化的方式在测试环境中回放验证。具体实现链路分为四个阶段：
阶段一：智能用例生成——从“行为记录”到“可执行脚本”
这是整个流程的源头与起点，目标是实现测试用例的“自动化生产”。
阶段二：灵活执行触发——从“静态资产”到“动态任务”
本阶段负责调度，将静态的测试用例转化为具体的执行任务。
阶段三：AI驱动执行——从“指令”到“结果”的转化
阶段四：平台化数据运营——从“结果”到“决策”的质量闭环
通过这四个阶段的闭环，系统实现了从真实运营行为到自动化测试用例的完整转化，并将执行结果转化为可运营的质量数据。
六、技术亮点
基于真实环境中的运营行为生成测试用例
基于 Midscene+Qwen2.5-VL-72B 执行用例
AI 驱动的精准 UI 交互测试
代码覆盖率作为硬指标
七、平台化效果
我们在页面上实现了以下可运营能力，将 E2E 测试从黑盒脚本转变为可管理、可追踪、可复盘的平台系统。
整体数据看板
页面列表（入口）：
展示内容：按业务域 / 系统 / 负责人筛选、页面级 PV/UV、用例数量、步骤执行成功率、代码覆盖率等指标。系统能力：页面维度汇总视图，将访问热度（PV/UV）与自动化质量指标（成功率 / 覆盖率）结合，指导用例优先级（高 PV 页面优先铺用例、优先治理）。
用例详情视图
用例列表（抽屉）：
展示内容：每条用例绑定监控系统信息、点击行为数量、执行结果、步骤成功率、打标及备注、执行/删除操作。系统能力：以线上运营行为列表为用例数据，将 可执行性评估/识别执行结果与预期偏差/可信度（打标）统一实现。
执行详情（弹窗）：
展示内容：按步骤展示 CLICK 结果、详细错误堆栈/描述、页面截图缩略图、单步覆盖率、页面地址与 监控系统链接。系统能力：将每一步的线上行为与 E2E 执行对照落库，让失败从黑盒变为可复盘的证据链。
点击明细（单页面的用例序列）：
展示内容：点击序号、点击描述（如点击某某预览弹窗/眼睛按钮）、点击行为数量等。系统能力：系统会为 Click Scope 生成更可读的描述，便于非开发同学理解与复盘，也是后续策略库/稳定性治理的输入。
八、总结展望
面对交易业务快速增长、技术栈频繁迁移、测试资源紧张的多重挑战，我们成功实现了基于真实运营行为的 AI 驱动E2E 测试方案。通过 Midscene 的视觉 AI 能力结合 Puppeteer 的精准控制，实现了用例自动化生成、智能交互执行和质量数据闭环。
之后我们将持续优化 AI 模型的准确率和稳定性，逐步实现从「用例执行」到「质量预测」的升级。同时推动平台向标准化、智能化方向发展，让质量保障真正成为业务创新的加速器而非瓶颈。
往期回顾
1.生成式召回在得物的落地技术分享与思考
2.立正请站好：一个组件复用 Skill 的工程化实践｜得物技术
3.财务数仓 Claude AI Coding 应用实战｜得物技术
4.日志诊断 Skill：用 AI + MCP 一键解决BUG｜得物技术
5.Redis 自动化运维最佳实践｜得物技术
文 /卓翎
关注得物技术，每周更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。
