用 Amazon Nova Act 实现智能体 QA 自动化，加速软件交付（第三部分）

随着质量保证（QA）自动化在组织内部的采用不断增长，一个与编写测试无关的新问题随之出现。一个平台团队搭建了测试自动化，接着第二个团队想要加入，然后又来了十几个团队。很快，数百个测试用例分属不同的产品和团队，每个人都能看到其他人的测试。没有人能一眼回答一个基本问题：这个应用当前的测试覆盖是否健康？编写测试不再是瓶颈。组织测试并控制谁可以接触它们，成了主要工作。

紧随其后的是第二个相关问题：谁拥有这个应用及其测试，当覆盖率下滑时由谁负责？如果没有明确的所有者，健康问题就无人承担。

在第一篇文章中，我们介绍了 QA Studio，这是一个使用 Amazon Nova Act 构建的参考解决方案。团队使用它以自然语言定义测试，并通过 AI 驱动的视觉导航来运行它们。在第二篇文章中，我们添加了测试套件和一个 CLI，用于在持续集成和持续交付（CI/CD）流水线中进行批量回归测试。在本文中，我们介绍两项帮助 QA Studio 在组织范围内扩展的能力。第一项是应用，用于组织测试并报告健康指标。第二项是基于团队的用户管理，用于控制谁可以查看和更改什么。

用应用来组织测试

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

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

图 1：应用详情页，显示通过率、执行次数和失败次数，以及用例和测试套件选项卡

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

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

页面顶部用三个数字回答眼前的问题：所选时间窗口内的通过率、执行总次数和当前失败数。与此同时，QA Studio 计算一个 0–100 的健康分数。该分数从通过率出发，并对不稳定测试进行扣分。这样，一个测试虽然通过但在通过和失败之间反复波动的应用，就不会呈现出虚假的完美画面。团队在浏览一组应用时，无需打开每个结果，就能分辨出哪些是稳定的，哪些需要关注。

指标标签页从当前的快照视图改为趋势视图。团队可以选择按小时粒度的 7 天窗口，或按天粒度的 30 天窗口，QA Studio 会绘制该时间段内的执行次数、成功数、失败数和平均时长。由于底层指标带有环境维度，团队可以将视图筛选到单一环境。例如，他们可以针对同一组测试，比较预发布环境与生产环境的表现。

有两个视图专门针对最耗费团队时间的测试。不稳定测试视图按过去七天内用例在通过和失败之间翻转的频率进行排名。这能在间歇性失败演变成生产环境漏检之前，将其暴露出来——这类失败会侵蚀人们对测试套件的信任。最近失败视图列出最新的失败执行，便于快速分诊。每一条都链接回第 1 部分介绍的 Amazon Nova Act 轨迹日志和会话录制。这样，从“这个测试失败了”到“这就是智能体当时看到的确切内容”只需一次点击。

图 2：指标标签页：所选窗口内的通过率、执行次数和平均时长，以及每日成功与失败图表、失败热点和不稳定用例排名

用团队和角色控制访问权限

指标告诉团队他们的应用运行得如何。基于团队的用户管理则首先决定哪些应用属于他们。QA Studio 围绕团队来组织访问权限，一个应用只属于一个团队。该团队的成员可以使用其应用。其他人都看不到这些应用。

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

• Admin：对整个 Studio 的所有团队、应用和用户拥有访问权限，包括创建团队和分配应用。Admin 是 Studio 级别的角色，而不是按团队分配的角色。
• Team Lead：管理自己团队的成员，并为团队创建应用。
• Editor：在团队的应用中创建和编辑用例与测试套件。
• Executor：运行用例和套件，但不能修改它们。
• Viewer：对团队的应用和结果拥有只读访问权限。

由于角色是累积的，Team Lead 拥有 Editor 的所有权限，依此类推直到 Viewer。对某个用例或测试套件的访问权限跟随包含它的应用。如果某个成员可以使用该应用，那么在其角色允许的范围内，他们也可以使用该应用的测试。这样就把权限管理保持在应用级别，而不是分散在成千上万个单独的测试上。

管理员可以看到整个 Studio。Users 页面在一个地方列出每个账户及其所属团队和角色。管理员可以知道谁在哪个团队担任 Team Lead，以及谁拥有 Studio 级别的 Administrator 权限。在此处展示的参考部署中，四个用户分属两个团队：两个 Team Lead、一个 Viewer 和一个 Studio 级别的 Administrator。Teams 页面按团队汇总同样的数据，并排显示每个团队的成员数和应用数。管理员无需打开任何团队，就能看出哪些团队正在扩张。

图 3：Studio 级别的 Users 页面：每个账户及其团队和角色，可按团队和角色筛选

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

图 4：Teams 页面：每个团队及其成员数和应用数

从团队切换到应用，Studio 级别的 Applications 列表显示所有团队中的每个应用。

图 5：工作室范围内的 Applications 列表：每个应用及其基础 URL、所属团队、用例数量和最近一次执行状态

在团队之间共享应用

团队很少完全孤立地工作。平台团队可能拥有某个应用，而功能团队需要针对它运行，但又不移交修改它的能力。QA Studio 通过共享访问支持这一点：所属团队以查看、执行或完全级别向另一个团队授予对某个应用的访问权限。

共享访问遵循上限规则。用户对共享应用的有效权限是其自身角色与授权级别中较低者。被授予完全访问权限的 Viewer 对共享应用仍然只能查看，因为其角色就是上限。这样，所属团队可以广泛共享，而不会授予超出接收者角色所允许的权限。

团队负责人看到的内容

团队负责人在单个团队内工作，而不是整个工作室。打开 My Team 会显示四个标签页，涵盖负责人控制的所有内容：Members、Applications、Use Cases 和 Shared Access。Members 标签页列出团队中的人员。负责人可以内联更改任何成员的角色或添加新成员，因此日常访问管理由最接近工作的人负责。在此处显示的 AWS Team 中，负责人管理两名成员：一名 Team Lead 和一名 Viewer。

图 6：团队负责人的 Members 标签页，可为每位成员内联分配角色

Applications 标签页仅显示该团队拥有的应用，每个应用都带有其测试用例数量和最近运行时间。这让负责人专注于自己的范围，而不是整个工作室的清单。Shared Access 标签页是跨团队共享变得具体的地方。在这里，AWS Team 已授予 AMZN Team 对某个应用的查看访问权限，负责人可以授予、撤销或更改该访问级别。由于授权是查看级别，AMZN Team 的 Editor 仍然只能以只读方式查看共享应用：上一节的上限规则在实践中得到了应用。

图 7：团队负责人的 Applications 标签页，范围限定为该团队自己的应用

同一个 Team Lead 的 Shared Access 标签页记录了哪些其他团队可以访问该团队的应用，以及以什么级别访问。

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

工作原理

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

• Amazon Cognito：每个团队映射到一组 Cognito 组，每个角色一个组。AWS Lambda 授权器在每次请求时将调用者的组解析为 API 作用域和团队上下文。
• Amazon DynamoDB：团队、成员关系、应用所有权和跨团队共享授权存储在现有的单表设计中。
• Amazon CloudWatch：每次执行都会在 QAStudio/Executions 命名空间中发出自定义指标，按应用和环境维度划分。指标 API 会读取它们以构建健康视图和趋势图。
• AWS Lambda 和 Amazon API Gateway：后端在两层强制执行访问控制：调用者角色授予的作用域，以及确认调用者团队拥有该应用或已被共享该应用的资源检查。

由于访问权限源自 Cognito 组成员身份，第 2 部分中的 OAuth 客户端凭证流程也适用于同一模型。CI 流水线以机器身份进行身份验证，仅获取其所需的作用域，不多不少。

入门

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

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

结论

在这篇文章中，我们展示了 QA Studio 如何将智能体 QA 自动化从单个测试扩展到整个组织。应用程序为每个团队提供了其用例和测试套件的归属。它们通过通过率、趋势图、经不稳定调整的健康评分以及基于 Amazon CloudWatch 指标构建的故障分类来报告健康状况。由 Amazon Cognito 支持的基于团队的用户管理，确保每个团队在其拥有的应用程序范围内工作，跨团队共享受明确上限规则的约束。

这些功能建立在第 1 部分的自然语言测试编写和第 2 部分的套件与 CI/CD 集成之上。它们共同帮助 QA 自动化在众多团队中扩展，同时不失去可见性或控制力。要在您自己的环境中试用，请从 QA Studio GitHub 仓库部署参考解决方案，创建您的第一个团队和应用程序，并运行几个用例以观察指标的形成。要了解更多关于其背后智能体的信息，请参阅 Amazon Nova Act 产品页面。

关于作者

Vinicius Pedroni

Vinicius 是 AWS 旅游与酒店行业的资深解决方案架构师，专注于边缘服务和生成式 AI。Vinicius 还热衷于帮助客户踏上云之旅，使他们能够在正确的时机采用正确的策略。

Jan Wiemers

Jan 是 AWS 的资深解决方案架构师，服务于旅游、运输与物流行业的客户。他在软件行业拥有超过 20 年的经验，专注于 AI 产品开发生命周期和测试自动化，帮助客户加速构建、测试和部署 AI 驱动的解决方案。