用 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 围绕团队来组织访问权限，一个应用只属于一个团队。该团队的成员可以使用其应用。其他人都看不到这些应用。

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

管理员：对整个工作室的所有团队、应用和用户拥有访问权限，包括创建团队和分配应用。管理员是工作室级别的角色，而不是按团队分配的。
团队负责人：管理自己团队的成员，并为团队创建应用。
编辑者：在团队的应用中创建和编辑用例与测试套件。
执行者：运行用例和套件，但不能修改它们。
查看者：对团队的应用和结果拥有只读访问权限。

由于角色是累积的，团队负责人拥有编辑者的所有权限，依此类推直到查看者。对用例或测试套件的访问权限跟随包含它的应用。如果成员可以使用该应用，他们就可以使用其测试，但受其角色限制。这样就把权限管理保持在应用级别，而不是分散在成千上万个单独的测试上。

管理员可以看到整个工作室。用户页面在一个地方列出每个账户及其团队和角色。管理员可以知道谁在哪个团队担任团队负责人，以及谁拥有工作室范围的管理员权限。在此处展示的参考部署中，四个用户跨越两个团队：两名团队负责人、一名查看者和一名工作室范围的管理员。团队页面按团队汇总相同的数据，并排显示每个团队的成员数和应用数。管理员无需打开任何团队，就能看出哪些团队正在扩张。

图 3：工作室范围的用户页面：每个账户及其团队和角色，可按团队和角色筛选

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

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

从团队切换到应用，工作室范围的应用列表显示所有团队中的每个应用。

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

在团队之间共享应用程序

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

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

团队负责人看到的内容

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

图 6：团队负责人的“成员”选项卡，可为每个成员内联分配角色

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

图 7：团队负责人的“应用程序”选项卡，范围限定为团队自己的应用程序

同一团队负责人的“共享访问”选项卡记录了哪些其他团队可以访问该团队的应用程序，以及以什么级别访问。

图 8：团队负责人的“共享访问”选项卡，显示向另一个团队授予的查看级别权限

工作原理

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 云开发工具包（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 驱动的解决方案。