Accelerating software delivery with agentic QA automation using Amazon Nova Act – Part 3

标题：使用 Amazon Nova Act 进行智能 QA 自动化以加速软件交付 – 第 3 部分 | 亚马逊网络服务

URL 来源：https://aws.amazon.com/blogs/machine-learning/accelerating-software-delivery-with-agentic-qa-automation-using-amazon-nova-act-part-3/

发布时间：2026-10-28T10:12:13-08:00

Markdown 内容： 随着组织内部 QA 自动化采用率的提高，一个新的问题逐渐浮现，这与编写测试本身无关。平台团队搭建了测试自动化后，第二个团队希望加入，随后又有十几个团队陆续参与。很快，数百个测试用例归属于不同的产品和小组，所有人都能看见彼此的测试。但没有人能一目了然地回答一个基本问题：当前这个应用的测试覆盖率是否健康？测试编写不再是瓶颈，测试的组织和控制谁可以操作它们，反而成为新的工作重点。

随之而来的一个相关问题是：谁负责这个应用及其测试？当覆盖率下降时，谁需要为此负责？缺乏明确负责人时，健康问题将无处落脚。

在第一篇文章中，我们介绍了 QA Studio，这是一个基于 Amazon Nova Act 构建的参考解决方案。团队可以使用它通过自然语言定义测试，并通过 AI 驱动的视觉导航执行测试。在第二篇文章中，我们增加了测试套件和用于 CI/CD 管道批量回归测试的 CLI 工具。在本文中，我们将介绍两项帮助 QA Studio 在组织内扩展的能力。第一个是 应用，用于组织测试并报告健康指标；第二个是 基于团队的用户管理，用于控制谁可以查看和修改内容。

通过应用组织测试

QA Studio 中的“应用”代表被测系统：一个网站、一个 Web 应用或一个服务前端。它是为测试集合提供归属和负责人的容器。用例（第一部分中的单个测试）和测试套件（第二部分中的回归集合）都归属于某个应用，并继承其所有权。团队不再面对所有部署测试的单一列表，而是各自在自己拥有的应用中工作。

创建应用时需要指定名称、基础 URL 以及可选的环境（如开发、预发布和生产环境）。从应用页面，团队可以直接在上下文中创建新用例、添加现有用例，并将它们分组到测试套件中。这也是 QA Studio 报告其运行测试健康状况的位置。

图 1：应用详情页面，显示用例和测试套件标签上方的通过率、执行次数和失败次数

通过指标理解应用健康状况

测试会产生结果。随着时间的推移理解这些结果，可以告诉团队一个应用程序的开发周期是否健康，而不仅仅是某个构建是否准备好发布。QA Studio 将每次执行的结果记录为 Amazon CloudWatch 的自定义指标，按应用程序和环境进行维度划分。它将这些指标转化为应用程序页面上的健康视图。

页面顶部通过三个数据快速回答核心问题：所选时间段内的通过率、总执行次数和当前失败次数。同时，QA Studio 会计算一个 0-100 的健康评分。该评分以通过率为基础，再对不稳定的测试进行扣分。这样，即使测试通过但频繁在通过和失败之间切换的应用程序，也不会呈现出虚假的完美画面。团队在查看应用组合时，无需打开每个结果，即可区分出稳定的应用和需要关注的应用。

指标标签页从当前快照转向趋势分析。团队可以选择 7 天窗口期（每小时粒度）或 30 天窗口期（每日粒度），QA Studio 会在此期间绘制执行次数、成功次数、失败次数和平均持续时间的趋势图。由于底层指标包含环境维度，团队可以将视图过滤到单一环境。例如，他们可以比较相同测试集在预发布环境和生产环境中的表现差异。

两个视图聚焦于消耗团队最多时间的测试。不稳定的测试视图按过去七天内测试用例在通过和失败之间切换的频率进行排序。这能提前揭示那些破坏测试套件可信度的间歇性故障。最近失败视图则列出最新的失败执行记录，便于快速排查。每个失败记录都会链接到第一部分中描述的 Amazon Nova Act 轨迹日志和会话录像。这样，从“这个测试失败了”到“这里就是代理看到的完整画面”只需一次点击。

图 2：指标标签页：所选窗口期内的通过率、执行次数和平均持续时间，包含每日成功与失败图表、失败热点和不稳定的测试用例排名

通过团队和角色控制访问权限

指标能告诉团队他们的应用程序运行状况如何。基于团队的用户管理决定了哪些应用程序属于该团队。QA Studio 围绕团队组织访问权限，每个应用程序只属于一个团队。该团队成员可以操作其应用程序，其他人员则无法看到这些应用程序。

每个团队成员拥有五种角色中的一种，每个角色包含其下所有角色的权限：

• 管理员: 拥有对工作室内所有团队、应用和用户的完全访问权限，包括创建团队和分配应用。管理员是面向整个工作室的角色，而非针对每个团队的分配。
• 团队负责人: 管理其团队成员并在团队内创建应用。
• 编辑者: 在团队的应用中创建和编辑用例及测试套件。
• 执行者: 运行用例和测试套件但无法对其进行修改。
• 查看者: 仅可查看团队的应用和测试结果。

由于角色权限是累积的，团队负责人拥有编辑者的所有权限，依此类推直至查看者。对用例或测试套件的访问权限遵循包含它的应用。如果成员可以操作应用，即可操作其测试，但权限范围受角色限制。这将权限管理集中在应用层级，而非针对成千上万个单独的测试。

管理员可以看到整个工作室的全貌。用户页面集中展示了每个账户所属的团队及其角色。管理员可以清楚看到哪些人担任了特定团队的团队负责人，以及谁拥有工作室管理员权限。在本示例的参考部署中，四个用户分布在两个团队中：两名团队负责人、一名查看者和一名工作室管理员。团队页面则按团队汇总显示相同数据，同时并列展示每个团队的成员数量和应用数量。管理员无需打开具体团队即可了解哪些团队正在扩展。

图3：工作室级用户页面：所有账户及其所属团队和角色，支持按团队和角色筛选

相同的成员数据按团队汇总后显示在团队页面上。

图4：团队页面：每个团队的成员数量和应用数量

从团队切换到应用，工作室级的应用列表展示了所有团队中的每个应用。

图5：工作室级应用列表：每个应用的基础URL、所属团队、用例数量和最后一次执行状态

跨团队共享应用

团队很少完全独立运作。平台团队可能拥有某个应用，而功能团队需要运行该应用但无需获得修改权限。QA Studio通过共享访问权限支持这种场景：拥有应用的团队可以向其他团队授予查看、执行或完全访问权限。

共享访问遵循上限规则。用户对共享应用的有效权限是其自身角色与授权级别中较低的那个。如果一个查看者被授予对共享应用的完全访问权限，其权限仍仅限于查看，因为其角色是上限。这样，拥有团队可以在不授予超出接收者角色权限的条件下广泛共享。

团队负责人看到的内容

团队负责人在单个团队内工作，而非整个工作室。打开“我的团队”会显示四个标签页，涵盖负责人所控制的所有内容：成员、应用、用例和共享访问。成员标签页列出团队中的人员。负责人可以内联修改任何成员的角色或添加新成员，因此日常的访问管理由最接近工作的人员负责。在本例中的AWS团队中，负责人管理两名成员，一名团队负责人和一名查看者。

图6：团队负责人的成员标签页，为每个成员提供内联角色分配

应用标签页仅显示团队拥有的应用，每个应用均标注测试用例数量和最后运行时间。这使负责人专注于自己的工作范围，而非整个工作室的全部库存。共享访问标签页是跨团队共享的具体体现。在此示例中，AWS团队已向AMZN团队授予某应用的查看权限，负责人可以授予、撤销或更改该权限级别。由于授权级别为查看，AMZN团队的编辑人员仍只能以只读方式查看该共享应用：这是前一部分提到的上限规则在实际中的应用。

图7：团队负责人的应用标签页，仅显示团队拥有的应用

同一团队负责人的共享访问标签页会记录哪些其他团队可以访问本团队的应用，以及访问级别。

图8：团队负责人的共享访问标签页，显示对另一个团队的查看级别授权

实现方式

QA Studio 在之前文章中描述的无服务器架构基础上构建了基于团队的访问控制和指标，同时添加了几个AWS服务：

• [Amazon Cognito](https://aws.amazon.com/cognito/): 每个团队对应一组 Cognito 组，每个角色对应一个组。AWS Lambda 授权器会在每次请求时将调用者的组解析为 API 作用域和团队上下文。
• [Amazon DynamoDB](https://aws.amazon.com/dynamodb/): 团队、成员关系、应用所有权和跨团队共享授权信息存储在现有单表设计中。
• Amazon CloudWatch: 每次执行都会在 QAStudio/Executions 命名空间中生成自定义指标，并按应用和环境进行划分。指标 API 会读取这些指标以构建健康视图和趋势图表。
• AWS Lambda 和 [Amazon API Gateway](https://aws.amazon.com/api-gateway/): 后端在两个层级上强制访问控制：调用者角色授予的作用域，以及验证调用者团队是否拥有或已被共享应用的资源检查。

由于访问权限来源于 Cognito 组成员身份，第二部分中描述的 OAuth 客户端凭证流程同样适用于此模型。CI 流水线以机器身份进行身份验证，并仅使用其所需的范围权限。

入门指南

应用、指标和基于团队的访问控制属于 QA Studio 参考解决方案的一部分，您可以通过 AWS Cloud Development Kit (AWS CDK) 在自己的 AWS 账户中部署该方案。所有测试数据、结果和指标均保留在您的账户范围内。部署完成后，管理员将创建团队、分配成员和角色，并将应用分配给团队。随着测试的运行，每个团队的健康指标将开始填充。

有关部署说明和配置细节，请参阅 QA Studio GitHub 仓库 及其文档。

结论

在本文中，我们展示了 QA Studio 如何将智能 QA 自动化从单个测试扩展到整个组织。应用为每个团队提供了其用例和测试套件的专属空间。它们通过通过率、趋势图表、基于 Amazon CloudWatch 指标的调整后健康评分以及故障分类来报告健康状态。基于 Amazon Cognito 的基于团队的用户管理确保每个团队在其拥有的应用内工作，跨团队共享受到明确的上限规则约束。

这些功能构建在第一部分的自然语言测试编写、第二部分的测试套件和 CI/CD 集成基础上。它们共同帮助 QA 自动化在多个团队中扩展，同时保持可见性和控制力。要在自己的环境中尝试，从 QA Studio GitHub 仓库部署参考解决方案，创建第一个团队和应用，并运行几个用例以观察指标的形成。要了解背后的代理技术，请参阅 Amazon Nova Act 产品页面。

• * *

作者简介