用 Amazon Nova Act 实现智能体 QA 自动化加速软件交付（三）：QA Studio 新增应用组织与团队权限管理

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

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

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

使用应用程序组织测试

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

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

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

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

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

页面顶部用三个数字回答了最直接的问题：所选时间窗口内的通过率、执行总次数以及当前的失败数。除此之外，QA Studio 还会计算一个 0–100 的健康分数。该分数从通过率出发，并针对不稳定的测试进行扣分。这样一来，测试虽然能通过但在通过和失败之间反复跳动的应用，就不会呈现出虚假的完美形象。浏览应用组合的团队无需打开每个结果，就能区分出稳定的应用和需要关注的应用。

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

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

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

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

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

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

管理员（Admin）：跨整个 Studio 访问所有团队、应用和用户，包括创建团队和分配应用。管理员是 Studio 级别的角色，而不是针对单个团队的分配。
团队负责人（Team Lead）：管理自己团队的成员，并为团队创建应用。
编辑者（Editor）：在团队的应用内创建和编辑用例与测试套件。
执行者（Executor）：可以运行用例和套件，但不能修改它们。
查看者（Viewer）：对团队的应用和结果拥有只读访问权限。

由于角色是累积式的，团队负责人拥有编辑者的一切权限，以此类推直到查看者。对某个用例或测试套件的访问权限取决于包含它的应用。如果成员可以操作该应用，就可以在其角色允许的范围内操作其中的测试。这将权限管理保持在应用层面，而不是分散在成千上万个单独的测试上。

管理员可以看到整个 Studio。用户页面在一个地方列出所有账户及其团队和角色。管理员可以查看谁是哪个团队的团队负责人，谁拥有 Studio 级管理员权限。在本文所示的参考部署中，四名用户分属两个团队：两名团队负责人、一名查看者和一名 Studio 级管理员。团队页面将相同的数据按团队汇总，并排显示每个团队的成员数量和应用数量。管理员在打开任何单个团队之前，就能看到哪些团队在扩张。

图 3：Studio 级用户页面：所有账户及其团队和角色，可按团队和角色筛选

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

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

从团队切换到应用，Studio 级应用列表显示所有团队的全部应用。

图 5：工作室级应用列表：每个应用及其基础 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 产品页面。