AWS · ML 博客

First Orion利用Amazon Nova Act加速QA自动化

First Orion accelerates QA automation using Amazon Nova Act

二〇二六年八月十七日 · 英文原文

First Orion与AWS合著,采用Amazon Nova Act将QA自动化从基于selector的脚本转向自然语言驱动的AI agent。其工程团队因web应用激增导致测试瓶颈,Nova Act使QA分析师直接用英语编写测试,无需维护脆弱selector。QA周期缩短20–25%,工程时间节省25–30%,测试覆盖率提升15%以上。架构基于Amazon S3、ECS、Fargate及AgentCore Browser,支持并行执行和会话录制。

本文与 First Orion 的 Mark Himelfarb 和 Garrett Wilkerson 合著。First Orion 的工程团队交付速度一度超过质量保证(QA)团队的测试能力,直到 Amazon Nova Act 改变了 QA 自动化的面貌。作为一家品牌通信公司,其解决方案覆盖美国、加拿大、英国和德国运营商网络中的数亿通电话,First Orion 需要其 QA 团队跟上快速开发节奏。解决方案是从基于脚本的测试自动化转向由 AI 驱动的 agent,以人类的方式理解 web 界面。本文描述了 First Orion 如何采用 Amazon Nova Act、围绕它构建的架构,以及取得的成果。

First Orion 成立于 2008 年,秉持一个信念:每一次通信都应清晰、可信、可识别。如今,他们在北小石城、西雅图、伦敦和迪拜设有办公室,团队成员超过 300 人。其解决方案覆盖美国所有主要运营商,包括 T-Mobile、Verizon、AT&T 和 Boost Mobile,以及加拿大主要运营商、英国 Vodafone 和德国 Deutsche Telekom。覆盖范围正通过其 Global Exchange 不断扩大。他们通过品牌呼叫、消息和身份解决方案帮助企业连接客户,同时保护双方免受垃圾信息、诈骗和伪造的侵害。客户涵盖从小型企业到全球企业(包括财富 500 强公司)的广泛群体。其产品套件覆盖完整通信生命周期:INFORM 品牌呼叫、ENRICH 品牌消息、AFFIRM 号码监控、SENTRY 呼叫拦截和 PROTECT+ 风险检测。他们相信通信的未来建立在信任、透明和智能技术之上,创新是其战略核心。他们投资于 AI、对话智能和数据驱动平台,持续改善品牌与客户的互动方式。

这种增长带来了工程挑战。随着 First Orion 在服务企业客户的同时扩展到中小型企业(SMB)市场,其 web 应用数量激增,QA 测试负担也随之加重。

分散化门户超出 QA 团队能力

First Orion 从单体 web 门户转向分散化、产品特定、模块化、基于 cell 的架构。在这种模式下,每个团队拥有自己业务线的应用,仅通过底层平台的一小部分共享组件进行同步。这让团队能够以更高速度并行推进,尽管需要大量平台重构来支撑。与此同时,随着 First Orion 进一步深入 SMB 市场,客户使用的设备形态和浏览器版本范围显著扩大,每个应用需要测试的组合数量成倍增加。UI 测试迅速成为瓶颈。

QA 团队无法跟上不断扩张的 web 应用集,后果不断累积:发布速度停滞,新功能交付质量下降,工程时间越来越多地被回归测试消耗,而非用于新能力开发。First Orion 的 QA 团队包括 QA 分析师和 QA 自动化工程师。自动化工程师根据测试用例定义和其他文档构建持久测试套件,而 QA 分析师专注于需求分析、测试用例定义、探索性测试和软件质量风险管理。

但他们依赖的现有测试自动化框架本质上很脆弱,三个问题尤其拖慢了团队速度。首先,回归测试不是自助式的。开发人员需要在将代码交付到测试环境之前,对其涉及的路径运行回归测试,但现有测试用例带有大量依赖,难以按需运行。其次,新功能存在测试用例缺口。要为新功能编写测试,该功能必须先开发并部署到测试环境,这样 QA 自动化工程师才能在文档对象模型(DOM)中获得所需的 selector、标签和其他元素。这迫使 QA 分析师和工程师在等待期间切换上下文去做其他工作,而功能快速连续交付,结果是认知负荷不断增加,依赖关系处理持续纠缠。

第三,测试脚本本身很脆弱。QA 自动化工程师通常只能在开发人员完成代码后才拿到应用,且总是接近发布节点。当他们处理 Selenium 和 Playwright 脚本时,元素 ID、class 以及其他 DOM 和 JavaScript 属性的变化速度超过了他们修复的速度。传统自动化对特定发布的辅助效果不足以产生实质影响,发布因此可能延期。扩大 QA 团队规模在边际上有所帮助,但并未解决根本原因。

First Orion 意识到他们需要的不是更多同类方案,而是一种根本不同的方法。他们不想编写描述如何导航 UI 的代码,而是想用自然语言描述要测试什么,让智能 agent 处理其余工作。这一需求将他们引向了 Amazon Nova Act。

为什么 Amazon Nova Act 符合 First Orion 的需求

First Orion 的需求归结为两个问题:基于 selector 的测试在 UI 变化时崩溃,以及编写新测试所需的时间。Nova Act 通过让 QA 分析师用自然语言描述测试而非编写和维护代码,同时解决了这两个问题。当他们的 AWS 客户团队在 2025 年 3 月介绍 Nova Act 时,First Orion 成为预发布采用者,并在正式可用之前就发现了价值。

使用 Nova Act,First Orion 用自然语言描述想要完成的目标,而非如何完成。例如:“登录门户,导航到计费页面,验证发票总额。”agent 会推理当前 UI 状态,识别元素,并自主执行多步骤序列。这是与 Selenium 和 Playwright 的关键区别。那些框架要求 QA 自动化工程师编写和维护显式元素 selector,而这些 selector 在每次 sprint 中都会失效。Nova Act 则推理屏幕上看到的内容:标签、布局和上下文。像“点击提交按钮”这样的 Nova Act 指令无论底层 CSS class 如何都能生效。模型能适应变化的页面布局,处理动态内容,关闭弹窗,并在无需人工干预的情况下从错误中恢复。

开发人员还可以将 Python 代码、断言、断点和并行化直接与 Nova Act 命令交错使用。对 First Orion 而言,这意味着三点:QA 分析师可以直接编写测试——无需等待自动化工程师将测试用例转换为代码;测试能经受 UI 变化——因为 Nova Act 不依赖固定 selector,脚本不再每次 sprint 都崩溃;无需管理浏览器基础设施——AgentCore Browser 负责资源调配、会话录制和并行执行。

First Orion 如何使用 Nova Act

First Orion 使用 Amazon Nova Act 的主要场景是测试其客户门户应用。他们围绕 Amazon Nova Act SDK 构建了一个端到端系统,涵盖从 QA 分析师用英语编写测试用例、自动化执行到集成报告的全流程。下图展示了架构,下面逐一介绍各组件。

图 1:First Orion Nova Act 测试自动化系统架构概览

工作流从测试用例编写 UI 开始,这是一个 React 前端,QA 分析师可以在其中用自然语言浏览、创建、编辑和验证测试用例。自定义模板引擎处理动态变量(电话号码、电子邮件地址、企业名称),使同一测试集合在每次运行时生成唯一且真实的数据。测试集合以 JSON 格式存储在 Amazon Simple Storage Service(Amazon S3)中,作为中央存储库。

当 QA 分析师触发测试运行时,Nova Act 测试运行器从 Amazon S3 获取测试用例。该运行器是部署在 Amazon Elastic Container Service(Amazon ECS)和 AWS Fargate 上的 Python 应用,通过 Amazon Nova Act SDK 编排执行。运行器不直接管理浏览器,而是将浏览器操作委托给 Amazon Bedrock AgentCore Browser。AgentCore Browser 提供托管浏览器实例,处理会话录制,并支持在多因素认证(MFA)后并行执行,无需修改目标应用的认证流程。浏览器配置文件可以在特定浏览器状态下启动测试,避免每次运行都执行完整登录流程。

Amazon Nova Act 模型接收来自测试运行器的自然语言指令,推理目标 web 应用的当前 UI 状态,并自主执行指定操作。Nova Act 自行处理浏览器操作,调用代码无需管理 selector、等待或页面转换。结果流入 Allure 报告仪表板,并通过 Microsoft Teams 集成发送通知。First Orion 依赖 AgentCore 进行会话录制,并直接在报告中链接视频回放。Microsoft Teams 和 Allure 需要自定义集成。Nova Act 测试运行器使用 Python 脚本编排 SDK 调用。

采用这一架构加强了 QA 与工程团队之间的集成。随着更多测试进入 agentic 流程,对其他供应商的依赖减少。First Orion 还采用了 Kiro IDE 进行原型开发。Kiro 内置的 AWS 服务知识和读取代码库的能力使整体搭建变得直接。下图展示了在 React UI 中编写的示例测试用例。QA 分析师用自然语言编写指令(例如:“导航到计费页面,验证发票总额与预期金额一致,并下载 PDF”)。Amazon Nova Act SDK 在运行时将这些指令转换为浏览器操作,无需测试编写者具备元素 selector 或编程知识。

图 2:在 React UI 中用自然语言编写的测试用例

Allure 仪表板提供测试级别的通过/失败状态、执行时间线,以及用于调试失败测试的 AgentCore Browser 会话录制链接。

图 3:Allure 报告仪表板

图 4:Allure 测试结果

在 Nova Act 之前,QA 自动化工程师需要手动识别 DOM selector、编写脚本、调试脆弱的 selector 并反复迭代。每个测试用例可能需要数天时间。使用这一架构,QA 分析师可以将相同的英语测试用例在几分钟内运行完毕。对于支持的场景,从测试用例定义到自动化运行的时间从数天缩短到几分钟。

成果与影响

虽然 Amazon Nova Act 仍处于采用期,First Orion 正在围绕它添加功能以适应自身环境,但他们已在特定类型的测试中实现了 QA 周期缩短 20–25%。随着覆盖范围扩展到更多应用模块,他们预计效率将进一步提升。他们估计使用 Nova Act 节省了 25–30% 的工程时间,减少了功能之间的上下文切换。此前用于支持 QA 功能的工程能力已被重新导向功能工程和价值创造,使 First Orion 能更好地服务客户。

全自动 Nova Act 运行支持早期回归检测和快速新功能测试,在某些情况下测试覆盖率提升了 15% 以上。通过针对每次构建运行测试而无需等待人工 QA 可用,First Orion 在开发周期更早阶段(问题进入生产环境之前)捕获回归。

经验教训与最佳实践

组织层面的认同至关重要。First Orion 尝试新事物和快速交付的文化使采用成为可能。考虑 agentic 自动化的团队需要领导层支持和实验空间。对于考虑 agentic 自动化的团队:要有计划但保持灵活。这个领域发展迅速,上个月失败的方法可能在本月的新模型更新下就能奏效。

一个早期挑战是模型导航路径的可预测性。First Orion 的 QA 工程师希望确认 agent 在相同前置条件下会走相同的站点路径,但最初 Nova Act 会通过不同路径到达目标状态。通过调整 Amazon Nova Act SDK 暴露的参数,他们显著改善了行为一致性。

另一个经验是清晰 prompt 的重要性。虽然英语测试用例可以直接用于 SDK,但 prompt 仍需要调优才能与模型良好配合。遵循 AWS 文档中关于 prompt 结构化的指导提高了测试可靠性。

一个相关但不同的问题是 AI agent 不共享机构知识。未言明的前置条件、导航模式和企业规则必须在 prompt 中明确提供。将这种上下文构建到测试用例定义中是实现一致结果的关键。

下一步计划

First Orion 与 Amazon Nova Act 的路线图雄心勃勃。QA 特定用例的下一步包括使用 Kiro 和 Model Context Protocol(MCP)服务器实现自动化测试生成,使 AI 工具能够访问代码变更和需求文档。通过让 Kiro 查看代码变更并检查需求,First Orion 设想一个完全自动化的测试生成流水线,直接输入其 Nova Act 实现,进一步释放 QA 工程师从事更高价值任务。

他们还计划使用 Nova Act 进行关键路径分析,了解 AI 如何导航其站点,以识别产品改进点。将这些信息输入其他系统,可以为 web 设计师和营销团队提供反馈,帮助他们构建更高效的网页,从而带来更好的客户体验。

结论

First Orion 采用 Amazon Nova Act 证明了 agentic AI 如何将 QA 工作流从瓶颈转化为竞争优势。通过从脆弱的、基于 selector 的自动化转向自然语言驱动的测试,First Orion 缩短了 QA 周期时间,释放了工程能力用于功能开发,并提升了早期捕获回归的能力。他们早期采用新技术的意愿以及与我们的团队作为发布合作伙伴的紧密协作,使他们能够更快行动,并构建一个可随产品组合增长而扩展的测试架构。

First Orion CTO Mark Himelfarb 总结道:“这不仅仅是一个工具,而是一种竞争优势。过去需要数小时的任务现在只需几分钟,因此我们能在扩展的同时保持高标准。”—— Mark Himelfarb,First Orion CTO

准备好开始了吗?访问 Nova Act Playground,无需编写代码即可原型化你的第一个工作流。准备好构建时,安装适用于 VS Code、Kiro 或 Cursor 的 Nova Act IDE 扩展,从你的 IDE 开发和部署 agent。有关生产级架构指南,请参阅 Agentic QA Automation using Amazon Bedrock AgentCore Browser and Amazon Nova Act,并参考 Amazon Nova Act 文档了解更多详情。

关于作者

Avinash Ranganath Avinash 是 AWS 的首席技术客户经理,支持美国各地的大型企业客户。凭借 17 年以上的云架构、网络安全和网络经验,他帮助组织应对复杂的云转型——从 AI/ML 采用到安全现代化。Avinash 是事件检测与响应和统一运营的主题专家。

Libin Roy Libin 是 AWS 的高级解决方案架构师,支持美国各地的大型企业客户。凭借 11 年的云解决方案设计经验,他帮助组织在 AWS 上设计、迁移和现代化其基础设施。Libin 与高管层和技术团队紧密合作,使架构决策与业务成果对齐,并加速规模化云采用。

Mark Himelfarb Mark Himelfarb 自 2009 年起担任 First Orion 的 CTO,拥有 25 年以上的软件工程和架构经验。他领导公司的软件架构和工程实践,专注于电信领域的呼叫保护和品牌通信,同时整合数据科学和 AI/ML 能力。Mark 还负责采用生成式 AI 和最先进工具来增强工程实践、提高效率,并培养技能和职业发展文化。他拥有 UALR 的计算机科学和数学/德语学士学位,并在那里完成了由 NASA 资助的视频传输压缩和远程医疗研究顶点项目。

Garrett Wilkerson Garrett Wilkerson 于 2021 年加入 First Orion,拥有约 5 年的软件工程经验,涵盖移动开发、后端系统和 QA 自动化。他在 First Orion 担任过多个工程领域的角色,包括 Android 开发、后端工程和测试自动化,此前在 Selenium 和 Robot Framework 方面的经验为 Nova Act 等 agentic 测试工具提供了宝贵背景。目前,Garrett 专注于推进 QA 自动化和 AI 驱动计划,将 AI 服务集成到自动化框架中,以更早识别缺陷并减少手动测试开销。他拥有阿肯色大学小石城分校(UALR)的会计学学士学位。

译自 AWS · ML 博客 · 录于 二〇二六年八月十七日