用 Nova Act 搭建多租户 UI 测试服务

用自然语言写 UI 测试，能省掉多少选选择器、补等待和处理弹窗的工作？Epsilon 给出的内部结果是：一个 18 步流程，用 Amazon Nova Act 编写需要 5–10 分钟，对应的 Playwright 脚本需要 30–90 分钟。但他们保留了 Playwright，新增的是一层按意图执行的测试能力。

这篇 AWS ML Blog 案例更有价值的地方，是把模型、托管浏览器和测试结果封装成共享服务。读它要分清两件事：编写测试变快的工程路径，以及「回放通过率 100%」究竟证明了什么。

自然语言测试补的是哪一块

Epsilon 隶属 Publicis Groupe，业务涉及数亿消费者档案和数千个品牌关系。其 Agentic Platform 团队有 50 名工程师，负责让其他产品团队使用统一的 AI Agent 基础设施，包括身份、授权、Model Context Protocol（MCP）集成和跨账号资源配置。

他们已有的 Playwright 回归测试运行良好，至今仍是回归主干。新增能力针对两个问题：测试脚本与选择器、页面结构耦合；每个产品团队单独搭建浏览器、依赖和身份集成，又会重复投入。

Nova Act 承担的是把意图转成浏览器操作。例如，「确认奖励余额可见」比绑定具体 CSS 层级更接近业务要求；「如果出现引导框就跳过」「目标不可见就继续滚动」则把条件处理写进自然语言。

Epsilon 的做法是在 Playwright 之上增加意图测试，并通过平台统一交付。

这里的收益首先是减少编写操作脚本的工作。自然语言也更方便产品经理和 QA 负责人参与评审。不过，指令容易读懂，不等于验证标准足够严格。「余额可见」能检查展示，却未必能证明数值正确，后者仍需要明确预期。

从一句指令到可追踪的测试，中间还需要什么

这套服务分成三层：平台 API 创建工作流，后台任务执行工作流，Nova Act 联合 Amazon Bedrock AgentCore Browser Tool 控制浏览器。

用户提交 target_url 和自然语言步骤，平台在 AWS 注册 Nova Act 工作流定义。执行时，后台通过 Celery 处理异步任务，打开托管浏览器，再通过 Chrome DevTools Protocol（CDP）的 WebSocket 连接驱动页面。

下面这段代码解决的是「让 Nova Act 接管托管浏览器」：

import boto3
from bedrock_agentcore.tools.browser_client import browser_session
from nova_act import NovaAct

boto_session = boto3.Session(region_name=region)

with browser_session(region) as client:
    ws_url, headers = client.generate_ws_headers()
    with NovaAct(
        cdp_endpoint_url=ws_url,
        cdp_headers=headers,
        boto_session=boto_session,
        starting_page=url
    ) as nova_act:
        result = nova_act.act(instruction)

关键是 client.generate_ws_headers()：它生成连接地址和请求头，再通过 cdp_endpoint_url、cdp_headers 交给 Nova Act。这只是浏览器集成的核心，租户隔离、结果存储和执行调度都在外围。

平台入口经过 API Gateway 的认证和权限检查，由 Django REST 提供工作流、执行、测试套件和统计接口。任务经 Amazon SQS 排队，由 Amazon ECS 上的 Runner Service 消费。系统逐步记录通过或失败、截图和整体通过率，把结果 JSON、截图、执行轨迹及 HTML 报告存入 Amazon S3，并通过完成钩子回写平台。

对使用方，能力表现为 ui-test-agent 的两个技能：ui-test-recorder 负责交互探索并记录步骤，ui-test-executor 负责执行并返回结构化结果。

新团队接入时，平台配置跨账号 IAM 角色、登记目标 URL，再授予 Agent 权限。Nova Act 使用标准 AWS 凭证链；通过 AWS STS AssumeRole，测试可在各团队自己的账号和受限角色下运行。

AgentCore Browser Tool 则负责临时隔离会话、浏览器生命周期、实时查看、人工接管、会话录制和 AWS CloudTrail 审计。所谓「每团队零基础设施开销」，指产品团队不必各自管理浏览器；共享平台仍然有人建设和维护。

提效数据，要连同探索和回放一起看

原文的代表性案例是「创建 Agent」流程，共 18 步，覆盖登录、表单填写、条件处理、滚动和验证。其中第 4 步处理可能出现的引导框，第 7 步处理目标不可见时的滚动。不过，提供的正文没有列出完整的 18 步指令，无法直接复现整条测试。

据 Epsilon 内部基准，Nova Act 编写这个流程需要 5–10 分钟，对应 Playwright 脚本需要 30–90 分钟、80–150 行代码。作者概括为编写速度提升 4–6 倍。这些时间区间不能直接推出统一倍数，原文也没有说明样本量和统计方式，适合当作他们团队的测量结果。

更关键的是执行分为两个阶段：草稿状态下探索、重试，通常经过 4–5 轮提示词迭代；成功后保存执行轨迹，进入激活状态再回放。重复运行因此可以跳过部分 LLM 推理，降低延迟和成本，但原文没有给出节省金额或耗时。

他们报告保存轨迹的重复回放通过率为 100%。

这个 100% 描述的是探索成功后的轨迹回放，不是任意新流程的首次成功率。

它也没有回答页面改版、数据变化、权限变化后还能保持多高通过率。回放是否能跨这些变化复用，原文没给测试范围。

运行环境还有几个具体约束。他们用独立的 FastAPI sidecar 固定 nova-act 3.x 及 AgentCore Browser Tool 客户端依赖，支持 Workflow 和 IAM 认证，避免与主后端的 Strands Agent 技术栈冲突。Runner 关闭时，worker 可以退回进程内执行。

团队还发现，Nova Act 签名端点指向 us-east-1，与浏览器会话区域无关。滚动指令则要考虑 AgentCore Browser Tool 的默认视口，不能假定目标已经进入可见区域。

我的判断

我认可这套方案把「测试怎么写」和「测试怎么运行」一起处理。单独接入模型，只能减少部分脚本工作；统一身份、浏览器、任务队列和调试材料，才能让多个团队持续使用。

但它的适用前提很鲜明：Epsilon 已有 50 人的平台团队、AWS 账号体系和统一 Agent 入口。普通前端团队如果只是维护一个站点，照搬整套服务，可能先增加平台建设成本。作者的组织条件不能从收益里扣掉。

自然语言也没有天然消除测试脆弱性。它可能降低对 DOM 结构的依赖，却增加对指令清晰度和模型判断的依赖。页面上有多个同名按钮、余额存在多种口径时，测试仍需要说明目标和预期。

与继续维护 Playwright 相比，这个案例支持「增加一种编写和执行方式」，还不足以证明全面迁移更划算。原文没有提供两种方案在相同页面变更下的维护工时、漏报率、误报率和长期总成本对照；有关稳健性和成本的判断，仍有相当部分属于团队经验。

能拿来做什么

• 保留现有 Playwright 回归主干，选一条包含弹窗、滚动和表单操作的业务流程试用意图测试，同时记录编写时间、提示词迭代次数和失败原因。
• 把自然语言步骤写成可判断的业务目标，并补齐必要条件。例如检查余额时，明确账号、余额类型和预期值，避免只验证页面上出现了一个数字。
• 为每一步保存截图、结果和会话标识，并区分首次探索与轨迹回放。统计通过率时分别计算，才能看出模型探索和重复执行各自的可靠程度。
• 多团队确有共享需求时，再建设统一执行入口，并隔离 Nova Act 的运行依赖；采用 AWS 跨账号模式时，用受限 IAM 角色明确每个团队的执行权限。