人工智能
使用 Amazon Nova Act 通过智能体 QA 自动化加速软件交付——第 3 部分随着质量保证（QA）自动化在组织内部的采用不断增长，一个与编写测试毫无关系的新问题出现了。一个平台团队搭建了测试自动化，接着第二个团队想加入，然后又有十几个团队加入。很快，数百个测试用例分属不同的产品和小组，每个人都能看到其他人的测试。没有人能一眼回答一个基本问题：这个应用当前的测试覆盖率是否健康？编写测试不再是瓶颈。组织测试并控制谁能接触这些测试成了主要工作。
紧随其后的第二个相关问题：谁拥有这个应用及其测试，当覆盖率下滑时谁负责？如果没有明确的负责人，健康问题就无人承担。
在 第一篇博文中，我们介绍了 QA Studio，这是一个使用 Amazon Nova Act构建的参考解决方案。团队使用它以自然语言定义测试，并通过 AI 驱动的视觉导航来运行这些测试。在 第二篇博文中，我们添加了测试套件和一个 CLI，用于在持续集成和持续交付（CI/CD）流水线中进行批量回归测试。在本文中，我们介绍两项帮助 QA Studio 在组织范围内扩展的能力。第一项是 应用（applications），它组织测试并报告健康指标。第二项是 基于团队的用户管理，它控制谁可以查看和更改什么。
用应用来组织测试
QA Studio 中的应用代表被测系统：一个网站、一个 Web 应用、一个服务前端。它是为测试集合提供归属和所有者的容器。用例（第 1 部分中的单个测试）和测试套件（第 2 部分中的回归集合）都属于某个应用，并继承其所有权。团队不再面对部署中所有测试的一个扁平列表，而是在各自拥有的应用内工作。
创建应用需要名称、基础 URL，以及可选的环境集合，例如开发、预发布和生产。在应用页面上，团队可以直接在上下文中创建新用例、添加现有用例，并将它们分组为测试套件。这里也是 QA Studio 报告其运行测试健康状况的地方。
图 1：应用详情页，显示通过率、执行次数和失败次数，以及用例和测试套件选项卡
通过指标了解应用健康状况
测试会产生结果。随时间理解这些结果，才能告诉团队某个应用的开发生命周期是否健康，而不仅仅是某次构建是否已准备好发布。QA Studio 将每次执行的结果记录为 Amazon CloudWatch 自定义指标，按应用和环境设置维度。它将这些指标转化为应用页面上的健康视图。
页面顶部用三个数字回答眼前的问题：所选时间窗口内的通过率、执行总次数和当前失败次数。与此同时，QA Studio 计算一个 0–100 的健康分。该分数从通过率出发，并对不稳定（flaky）测试扣分。这样，一个测试虽然通过但在通过和失败之间反复波动的应用，就不会呈现出虚假的完美画面。团队在浏览应用组合时，无需打开每个结果就能分辨出哪些是稳定的，哪些需要关注。
指标选项卡从当前快照转向趋势。团队可以选择 7 天窗口（按小时粒度）或 30 天窗口（按天粒度），QA Studio 会绘制该时间段内的执行次数、成功次数、失败次数和平均时长。由于底层指标带有环境维度，团队可以将视图筛选到单个环境。例如，他们可以比较同一组测试在预发布环境和生产环境中的表现。
有两个视图针对最耗费团队时间的测试。不稳定测试视图按过去七天内用例在通过和失败之间翻转的频率进行排名。这能在间歇性失败演变成生产事故之前，将其暴露出来——这些失败会侵蚀对测试套件的信任。最近失败视图列出最新的失败执行，便于快速分诊。每一项都链接回第 1 部分中描述的 Amazon Nova Act 轨迹日志和会话录制。这样，从“这个测试失败了”到“这就是智能体当时看到的确切内容”只需一次点击。
图 2：指标选项卡：所选窗口内的通过率、执行次数和平均时长，以及每日成功与失败图表、失败热点和不稳定用例排名
用团队和角色控制访问
指标告诉团队他们的应用表现如何。基于团队的用户管理则首先决定哪些应用属于他们。QA Studio 围绕团队组织访问权限，一个应用只属于一个团队。该团队的成员可以使用其应用。其他人都看不到这些应用。
每个团队成员拥有五种角色之一，每个角色都包含其下级角色的权限：
- 管理员（Admin）：对整个工作室的所有团队、应用和用户拥有访问权限，包括创建团队和分配应用。管理员是工作室级别的角色，而不是按团队分配的。
- 团队负责人（Team Lead）：管理自己团队的成员，并为团队创建应用。
- 编辑者（Editor）：在团队的应用内创建和编辑用例与测试套件。
- 执行者（Executor）：运行用例和套件，但不能修改它们。
- 查看者（Viewer）：对团队的应用和结果拥有只读访问权限。
由于角色是累积的，团队负责人拥有编辑者的所有权限，依此类推直到查看者。对用例或测试套件的访问权限跟随包含它的应用。如果成员可以使用该应用，他们就可以使用其测试，但受其角色限制。这将权限管理保持在应用级别，而不是数千个单独测试的级别。
管理员可以看到整个工作室。Users 页面在一个地方列出每个账户及其所属团队和角色。管理员可以分辨谁在哪个团队担任 Team Lead，以及谁拥有工作室范围的 Administrator 权限。在此处展示的参考部署中，四个用户分属两个团队：两名 Team Lead、一名 Viewer 和一名工作室范围的 Administrator。Teams 页面按团队汇总相同的数据，并排显示每个团队的成员数和应用数。管理员无需打开任何团队，就能看出哪些团队正在扩张。
图 3：工作室范围的 Users 页面：每个账户及其团队和角色，可按团队和角色筛选
同样的成员数据按团队汇总后显示在 Teams 页面上。
图 4：Teams 页面：每个团队及其成员数和应用数
从团队切换到应用，工作室范围的 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 产品页面.