AWS博客：Epsilon用Amazon Nova Act将UI测试改为自然语言编写
AWS机器学习博客介绍，Epsilon的Agentic Platform团队把基于Amazon Nova Act与Amazon Bedrock AgentCore Browser Tool的UI测试作为多租户托管服务提供给各产品团队，测试步骤用自然语言编写；Epsilon内部基准称 18 步流程编写耗时 5–10 分钟，而等效Playwright脚本需 30–90 分钟、约 80–150 行代码。
AI解读：这是AWS官方博客发布的一篇客户案例，介绍Epsilon（Publicis Groupe旗下数据、技术与营销服务公司）如何用Amazon Nova Act和Amazon Bedrock AgentCore Browser Tool构建“意图驱动”的UI测试服务。文中架构、代码与数据均来自Epsilon团队自述，属于厂商与客户的主张，博客未提供第三方验证。
按文中说法，Epsilon并未替换原有Playwright回归测试，而是把它保留为回归基线，在其上叠加自然语言步骤测试，并以多租户平台服务形式交付：每个产品团队通过既有平台API使用ui-test-agent的两个技能（录制与执行），无需自建浏览器基础设施或单独配置身份与安全。
文中给出的效果数字均标注为Epsilon内部基准：典型 18 步工作流用Nova Act编写约 5–10 分钟，等效Playwright脚本约 30–90 分钟（4–6 倍差距）；在探索阶段通过（通常 4–5 轮提示迭代）后保存轨迹并确定性重放，重复运行通过率为 100%。这些数字对应Epsilon自身的测试场景，不能外推为通用节省比例。
适用范围也有限定：自然语言步骤适合对外观变化不敏感的意图型检查，Playwright仍负责确定性回归；自然语言测试的可读性使非测试工程师也能参与审阅，但这只是Epsilon的实践描述，博客未给出缺陷检出率或维护成本的量化对比。
AWS机器学习博客发布客户案例，介绍数据与营销服务公司Epsilon（Publicis Groupe旗下）如何用Amazon Nova Act与Amazon Bedrock AgentCore Browser Tool构建“意图驱动”的UI测试，并将其作为多租户托管服务提供给内部产品团队。
按博客描述，Epsilon原有的Playwright回归测试保持不动，新的自然语言测试作为叠加层；测试步骤由纯英文指令构成，由Nova Act在AWS托管的临时浏览器会话中执行。该服务已在多个团队投入生产使用，但文中效果数字均被标注为Epsilon内部基准。
服务形态：把UI测试做成平台的一项托管能力
Epsilon的Agentic Platform团队有 50 名工程师，负责构建共享基础设施，让其他产品团队能够构建、部署、治理和运行AI代理。该平台提供基于技能的代理构建器、联邦身份与预检授权、MCP集成和跨账户配置；UI测试是其中一项被托管的能力。
博客称，新团队接入时，平台团队为其配置跨账户IAM角色、登记目标应用URL，并通过既有平台API授予ui-test-agent的访问权限。此后团队用与其他平台代理相同的接口创建工作流、触发执行和取回结果，不需要额外管理浏览器二进制、Selenium grid或显示服务器。
ui-test-agent包含两个技能：ui-test-recorder用于交互式探索场景并录制自然语言步骤；ui-test-executor用于运行已录制的步骤并返回结构化结果。
技术路径：自然语言步骤加托管浏览器
按文中描述，工作流创建时用户指定target_url和一组自然语言步骤，平台在AWS上注册Nova Act工作流定义；执行时由基于Celery的后台任务运行器打开Amazon Bedrock AgentCore Browser Tool浏览器会话，通过CDP WebSocket逐步驱动Nova Act，支持条件逻辑，例如“如果出现导览框就跳过它”。
系统为每一步截图、记录通过或失败、计算整体通过率，并把结果JSON、截图和会话ID存入Amazon S3，完成后通过回调写回平台。测试任务经Amazon SQS排队，由运行在Amazon ECS上的Runner Service消费。
博客给出的核心集成代码是：先通过bedrock_agentcore的browser_session生成WebSocket地址与请求头，再用NovaAct以该CDP端点和starting_page初始化，最后调用act(instruction) 执行单条指令。Epsilon在此之上叠加了多租户编排、结果采集与可观测层。
示例工作流与工程注意事项
文中展示了一个 18 步的“创建代理”代表性流程，覆盖登录、表单填写、条件处理、滚动和校验，其中第 4 步要求“若出现导览框则选择跳过导览并确认页面正确加载”，第 7 步要求“若技能搜索框不可见则滚动直到出现”。博客称这类条件分支在传统框架中需要显式编写，而Nova Act通过语言理解直接处理。
Epsilon建议将Nova Act运行时与主后端隔离：用独立的FastAPI sidecar固定nova-act 3.x及AgentCore Browser Tool客户端版本。文中提到一个具体经验——Nova Act的签名端点无论浏览器会话在哪个区域都指向us-east-1，独立服务加独立依赖锁文件可避免难以排查的冲突。
其他建议包括：步骤写意图而非选择器；对草稿状态使用轨迹重试、保存成功轨迹并在活跃状态重放以减少重复的LLM推理；从一开始就用跨账户AssumeRole和受限IAM策略设计多租户；利用AgentCore Browser Tool自带的实时查看、会话录制和CloudTrail审计；编写滚动类步骤时要考虑该浏览器工具的默认视口。
结果与边界
博客给出的对比表称：同一 18 步工作流，Nova Act用 18 条自然语言步骤、无需选择器或DOM检查，编写约 5–10 分钟；等效Playwright脚本约 80–150 行代码，编写约 30–90 分钟，每个交互步骤都需要检查DOM、选择稳定选择器并编写显式等待、断言和条件分支。
Epsilon还称，工作流在初始探索阶段通过（通常 4–5 轮提示迭代）后保存轨迹并确定性重放，重复运行通过率为 100%；每步截图提供了更细的失败定位信息。博客将这些数字标注为内部基准。
博客未披露所测应用的数量、自然语言测试相对Playwright的缺陷检出差异，也未给出跨团队接入后的维护成本数据。Epsilon团队在引述中称，Nova Act让UI测试从追逐选择器的琐碎工作变为托管平台能力，测试用纯英文描述意图，接入的每个产品团队无需额外配置即可获得测试能力。