Ease Ops - E2E 让 AI 写用例、流水线调度与分布式执行连成闭环
Hyman 2026/11/14 实践总结Ease Ops
# 引言
端到端测试的难点，从来不是启动一个浏览器，而是让「用例从哪来、凭什么可信、何时执行、跑在哪里」这四个问题有同一个答案。ease-ops 的 E2E 能力线给出的答案是：一条版本契约，串起四个角色。
做 E2E 的团队通常卡在三个地方：用例散落在代码仓库、文档和个人脚本里，没人说得清哪份是准的；AI 能批量写用例，但产物没人把关，直接上线又不敢信；执行依赖某台机器上的临时脚本，跑多了就互相污染、难以复现。
ease E2E 是 ease-ops 平台内的一条端到端测试能力线，不造新引擎，也不做低代码。它把用例变成平台里的版本化资产，把 AI 变成受约束的写作者，把执行变成流水线里的一个标准阶段，把算力交给一组可扩展的执行 Agent。本文从宏观层面讲清这套设计的思路与优势，不展开接口与实现细节；文中的流程图由笔记自动渲染，涉及真实产品界面的配图暂以占位块标注。
# 一、整体思路：四个角色，一条版本契约
图 1 端到端闭环：AI 生成、平台落库、流水线调度、分布式执行
| 角色 | 职责 |
|---|---|
| AI 客户端 | 生成用例文本，离代码与页面最近 |
| MCP 写入接口 | 把产物安全落库，只到草稿为止 |
| 流水线 | 选已发布版本，决定执行时机与失败策略 |
| 分布式执行 Agent | 提供算力、运行隔离与结果回传 |
平台自己只维护两样东西：版本化的用例资产，以及贯穿全链路的版本契约。既不做生成模型，也不做测试引擎——生成交给离上下文最近的客户端，执行交给成熟的测试生态。
# 二、用例从哪来：AI 写，接口收，人来放行
- 生成在客户端，约束在服务端。AI 编程助手手上有仓库代码、页面组件和用户意图，平台没必要复制一份上下文；平台的职责是让 AI 的产物可控、可审、可复现。
- MCP 是标准写入通道。AI 通过用例写入接口保存草稿，这条通道与人工控制台共用同一套业务规则与权限，不是给 AI 另开的后门。写作规范、幂等写入、逻辑名引用、危险等级标注、密钥边界，都写在模型一定会看到的地方。
- 草稿与发布两态分离。任何编辑先落草稿；人工审阅版本差异后发布，冻结为不可变版本；流水线只执行已发布版本。此后 AI 再改草稿，也不会污染正在跑的版本。
- 资产化带来复现能力。用例不随被部署的代码一起签出，独立演进；每次运行记录当时使用的版本快照，结果可复现、可回溯、可回滚；凭据由平台在执行时注入，不进入用例内容或对话。
界面
# 三、何时执行：把 E2E 做成流水线的一等阶段
- 位置明确：放在部署之后，作为流水线里的标准阶段，而不是挂在外部的一段脚本；用例资产与执行细节彻底解耦。
- 配置面收敛：步骤只关心选哪个用例集、哪些标签、哪个运行时、被测地址与失败策略；临时工程、登录态准备、报告路径等一律由执行端按模板生成。
- 触发灵活：可手动触发，也可由平台接口或 AI 客户端经 MCP 发起；代码推送自动触发与定时全量属于后续演进。
- 软硬门禁渐进：初期用例失败只记录报告与产物、不阻断流水线；稳定后关闭软失败开关即升级为硬阻断，无需改动引擎。重试统一放在测试框架侧，避免两层重试叠加放大噪声。
界面
# 四、跑在哪里：分布式 Agent 提供算力与隔离
- 可横向扩展：执行 Agent 通过长连接注册到平台，心跳上报在线状态与资源状况，新节点需审批后接入。
- 按策略选机：结合环境归属、能力标签与健康状态挑选节点，让同类任务尽量稳定落在同一节点以复用缓存；专用测试节点优先，缺失时平滑回退到通用节点。
- 定向派发、类型路由：任务由平台推送到指定节点，而不是节点轮询领取；执行端按任务类型路由到不同处理器，天然具备插件化扩展能力。
- 运行隔离：每次运行使用独立、干净的工作空间，容器资源设上限，支持容器与宿主机两种方式；登录态与凭据由平台注入，用例里只保留业务断言。
- 刻意轻量：不引入消息队列与额外中间件，分布式协调压在长连接、心跳与调度策略上，运维面最小。
# 五、结果到哪去：报告与产物闭环
- 复用既有体系：结果以标准化报告回传，平台沿用既有报告模型与统计口径，不新增一套报表体系；通过率、用例明细与耗时直接呈现在流水线详情里。
- 失败可排查：失败时保留截图、追踪与录屏等产物，归档失败不影响测试判定；运行版本快照让「当时跑了什么」可追溯，历史数据也能用于识别不稳定用例。
# 六、优势亮点
| 亮点 | 价值 |
|---|---|
| AI 生成与安全落库分离 | 生成贴近代码上下文，服务端零模型成本，产物天然可审 |
| 版本化资产 + 人工发布闸门 | AI 产出不会直接进生产验证，只有冻结版本可跑 |
| 面向 AI 的接口契约 | 写入幂等、引用不易幻觉、密钥不过对话，协作可控 |
| 流水线一等阶段 + 软硬门禁演进 | 从「先观察」到「硬阻断」只改一个策略，不改引擎 |
| 分布式执行与运行隔离 | 算力可横向扩展，多任务互不污染，专用节点可灰度接入 |
| 复用成熟测试生态与既有报告体系 | 直接享受生态红利，建设与维护成本最低 |
| 凭据与权限统一收口 | 安全边界清晰，用例内容与日志都不接触敏感信息 |
# 七、落地路径
- 为 AI 客户端接入平台的 MCP 通道并配置访问凭证。
- 让 AI 按规范生成用例并写入草稿；人工在用例库审阅版本差异后发布。
- 在流水线部署阶段之后加入端到端测试步骤，选用例集与标签，保持软失败。
- 在项目里配置被测地址与测试账号等环境变量。
- 触发一次完整流水线，查看测试报告与失败产物。
- 稳定运行一段时间后关闭软失败，升级为硬门禁。
# 八、边界与演进
- 平台当前不内置 AI 生成用例与失败用例自愈；生成能力来自客户端 AI，资产模型已为 AI 来源预留位置。
- 用例是可执行的标准测试脚本，不是低代码或自然语言用例。
- 目前以手动与接口触发为主；代码推送自动触发、定时全量、不稳定用例自动隔离均在后续规划。
- 软失败阶段目前是「流程继续、报告标失败、产物保留」，告警与人工放行链路尚未完全落地。
- 分布式执行不依赖消息队列与任务租约，靠长连接与调度策略实现。
# 结语
把「生成」交给离代码最近的 AI 客户端，把「可信」交给版本化资产与人工发布闸门，把「调度」交给流水线，把「算力」交给分布式 Agent；平台只用一条标准接口与一份版本契约把四者粘起来。这样 AI 写得再快，也越不过「已发布版本」这条线——这大概是这套设计里最值得复用的一条原则。