亚马逊Nova Act助力QA自动化：自然语言描述测试，周期大幅缩短

This post is co-written with Mark Himelfarb and Garrett Wilkerson from First Orion.

First Orion 的工程团队此前交付速度远超质量保障（QA）的测试能力，直到 Amazon Nova Act 改变了 QA 自动化。作为一家品牌通信公司，其解决方案覆盖美国、加拿大、英国和德国运营商的数亿次通话，First Orion 需要让 QA 跟上快速开发的节奏。解决方案是从基于脚本的测试自动化转变为由 AI 驱动的 Agent，这些 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 门户迁移到了去中心化、针对产品的模块化、基于单元的架构。在这种模式下，每个团队拥有自己业务线对应的应用程序，只在底层平台的小型共享部分进行同步。这使得团队能够以更高的速度并行推进，尽管这需要对平台进行大量重新工程化。与此同时，随着 First Orion 进一步渗透 SMB 市场，客户使用的设备形态和浏览器版本范围显著扩大，每个应用程序需要测试的组合数量成倍增加。

UI 测试很快成为瓶颈。QA 团队无法跟上不断扩展的 Web 应用程序集，后果不断累积：发布速度停滞，新功能交付质量下降，工程时间越来越多地消耗在回归测试而非新功能开发上。

First Orion 的 QA 团队包括 QA 分析师和 QA 自动化工程师。自动化工程师从测试用例定义和其他文档构建持久的测试套件，而 QA 分析师则专注于需求分析、测试用例定义、探索性测试和软件质量风险管理。但他们依赖的现有测试自动化框架本质上是脆弱的，三个特殊问题拖慢了团队的速度。

首先，回归测试不是自助式的。开发人员需要一个简单的方式在他们发布到测试环境之前对自己涉及的路径运行回归测试，但现有的测试用例带有大量依赖，使得它们难以按需运行。

其次，新功能面临测试用例缺口。要为一个新功能编写测试，该功能首先必须已开发完成并部署到测试环境，以便 QA 自动化工程师获得他们在文档对象模型（DOM）中所需的选择器、标签和其他元素。这迫使 QA 分析师和工程师在等待期间切换到其他工作，而在如此多的功能快速接连发布的情况下，结果是认知负担不断增加和持续的依赖管理。

第三，测试脚本本身很脆弱。QA 自动化工程师通常只在开发人员完成代码后、临近发布时才收到应用程序。当他们编写 Selenium 和 Playwright 脚本时，元素 ID、类以及其他 DOM 和 JavaScript 属性的变化速度超过了他们修复的速度。传统自动化无法足够快地增强手动工作以对特定发布产生影响，发布可能因此延误。扩大 QA 团队规模在边际上有帮助，但没有解决根本原因。

First Orion 意识到他们不需要更多相同的东西。他们需要一种根本不同的方法。与其编写描述如何导航 UI 的代码，他们希望用纯英文描述要测试的内容，让智能 Agent 处理其余一切。这一需求促使他们选择了 Amazon Nova Act。

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

First Orion 的需求归结为两个问题：基于选择器的测试在 UI 变化时会失效，以及创作新测试所需的时间。Nova Act 通过让 QA 分析师用纯英文描述测试而不是编写和维护代码来解决这两个问题。当他们的 AWS 客户团队在 2025 年 3 月向他们介绍 Nova Act 时，First Orion 成为预发布采用者，并在正式发布之前就发现了价值。

借助 Nova Act，First Orion 用自然语言描述他们想要完成的事情，而不是如何完成。例如："登录门户，导航到账单页面，验证发票总额。" Agent 会推理当前 UI 状态，识别元素，并自主执行多步骤序列。这与 Selenium 和 Playwright 的关键区别在于。这些框架要求 QA 自动化工程师编写和维护明确的选择器，而这些选择器在每个冲刺周期都会失效。Nova Act 则推理它在屏幕上看到的内容：标签、布局和上下文。像"点击提交按钮"这样的 Nova Act 指令，无论底层 CSS 类是什么都能工作。模型能够适应变化的页面布局、处理动态内容、关闭弹窗，并在无需人工干预的情况下从错误中恢复。开发人员还可以将 Python 代码、断言、断点和并行化直接与 Nova Act 命令交织使用。

对 First Orion 而言，这意味着三件事：

QA 分析师可以直接创作测试——无需等待自动化工程师将测试用例翻译成代码。

测试在 UI 变化中存活下来——因为 Nova Act 不依赖固定选择器，脚本不再在每个冲刺周期失效。

无需管理浏览器基础设施——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）上的 Python 应用程序，使用 AWS Fargate，通过 Amazon Nova Act SDK 编排执行。运行器不直接管理浏览器；相反，它将浏览器操作委托给 Amazon Bedrock AgentCore Browser。AgentCore Browser 提供托管浏览器实例、处理会话录制，并支持多因素认证（MFA）后的并行执行，无需更改目标应用程序的认证流程。浏览器配置文件可以让测试从特定浏览器状态开始，避免每次运行都执行完整的登录流程。

Amazon Nova Act 模型从测试运行器接收自然语言指令，推理目标 Web 应用程序的当前 UI 状态，并自主执行指定的操作。Nova Act 自行处理浏览器操作，调用代码无需管理选择器、等待或页面转换。

结果流入 Allure 报告仪表板，并集成了 Microsoft Teams 通知。First Orion 依赖 AgentCore 进行会话录制，并在报告中直接链接视频回放。Microsoft Teams 和 Allure 需要定制集成。Nova Act 测试运行器使用 Python 脚本编排 SDK 调用。

采用这种架构加强了 QA 和工程团队之间的集成。随着更多测试进入 Agent 化流程，对其他供应商的依赖减少。First Orion 还采用了 Kiro IDE 进行原型开发和开发。Kiro 内置的 AWS 服务知识和读取代码库的能力使所有集成变得简单。

下图展示了一个在 React UI 中创作的示例测试用例。QA 分析师用纯英文编写指令（例如，"导航到账单页面，验证发票金额与预期金额匹配，并下载 PDF"）。Amazon Nova Act SDK 在运行时将这些翻译成浏览器操作，无需测试作者具备元素选择器或编程知识。

图 2：在 React UI 中用纯英文创作的测试用例

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

图 3：Allure 报告仪表板

图 4：Allure 测试结果

在 Nova Act 之前，QA 自动化工程师需要手动识别 DOM 选择器、编写脚本、调试脆弱的选择器并迭代。每个测试用例这个过程可能需要数天。借助这种架构，QA 分析师可以在几分钟内获取相同的英文测试用例并运行。从测试用例定义到自动化运行的周转时间从数天缩短到数分钟，适用于支持的场景。

虽然 Amazon Nova Act 仍处于采用期，First Orion 正在围绕它添加功能以适应他们的环境，但他们已经看到某些类型测试的 QA 周期减少了 20-25%。随着覆盖范围扩展到更多应用程序模块，他们预计会看到更高的效率提升。

他们估计使用 Nova Act 节省了 25-30% 的工程时间，减少了功能之间的上下文切换。以前需要支持 QA 功能的工程能力已重新定向到功能工程和价值创造，使 First Orion 能够更好地专注于服务客户。

完全自动化的 Nova Act 运行支持提前进行回归检测和快速新功能测试，在某些情况下测试覆盖率提高了 15% 以上。通过对每个构建版本运行测试而无需等待人工 QA 可用，First Orion 能够在开发周期中更早地捕获回归，防止它们进入生产环境。

经验教训和最佳实践

组织认同很重要。First Orion 尝试新事物和快速交付的文化使采用成为可能。考虑 Agent 化自动化的团队需要领导层支持和实验空间。对于考虑 Agent 化自动化的团队：要有计划但保持灵活。这个领域发展很快，上个月失败的东西可能在今天的新模型更新中就能工作。

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

另一个学习是清晰提示的重要性。虽然英文测试用例可以为 SDK 编写，但提示仍需要调整以更好地与模型配合。遵循 AWS 文档中关于构建提示的指南提高了测试可靠性。

一个相关但不同的问题是 AI Agent 不共享组织知识。未明确说明的预条件、导航模式和业务规则必须在提示中提供。将这些上下文构建到测试用例定义中是实现一致结果的关键。

First Orion 与 Amazon Nova Act 的路线图雄心勃勃。他们 QA 特定用例的下一步包括使用 Kiro 和模型上下文协议（MCP）服务器进行自动化测试生成，这些服务器为 AI 工具提供代码变更和需求文档的访问。通过让 Kiro 查看代码变更并检查需求，First Orion 设想一个完全自动化的测试生成管道，直接接入他们的 Nova Act 实现，进一步解放 QA 工程师去做更高价值的工作。

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

First Orion 对 Amazon Nova Act 的采用展示了 Agent 化 AI 如何将 QA 工作流从瓶颈转化为竞争优势。通过从脆弱的、基于选择器的自动化转变为自然语言驱动的测试，First Orion 缩短了 QA 周期时间，将工程能力解放出来用于功能开发，并提高了提前捕获回归的能力。他们愿意尽早采用新技术，并作为发布合作伙伴与我们的团队紧密合作，使它们能够更快地行动，并构建随其不断增长的产品组合扩展的测试架构。

First Orion CTO Mark Himelfarb 总结道：

"这不仅仅是一个工具。这是一种竞争优势。以前需要数小时的任务现在只需几分钟，所以我们在扩展的同时保持高标准。"

——Mark Himelfarb，CTO，First Orion

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