Amazon Nova Act 驱动的 QA Studio 新增应用管理与团队权限

AWS 博客在 QA Studio 系列第三篇中介绍了两项面向组织规模的能力：用“应用”组织测试并呈现健康度，以及基于团队的用户权限管理。QA Studio 是使用 Amazon Nova Act 构建的参考方案，前两篇分别介绍了用自然语言定义测试、通过 AI 视觉导航执行，以及测试套件和用于 CI/CD 批量回归的 CLI。

应用成为测试的容器

在 QA Studio 中，一个应用代表被测系统，可以是网站、Web 应用或服务前端。第一篇中的用例（单个测试）和第二篇中的测试套件都归属于某个应用，并继承其归属关系。创建应用需要名称、基础 URL，以及可选的开发、预发布、生产等环境集合。团队在应用页面内直接新建用例、加入已有用例并编组为测试套件。

健康指标怎么看

QA Studio 将每次执行结果记录为 Amazon CloudWatch 自定义指标，按应用和环境两个维度区分，并在应用页面汇总为健康视图。页面顶部给出所选时间窗口内的通过率、执行总数和当前失败数，同时计算 0–100 的健康分：以通过率为基础，对不稳定测试扣分，避免“测试都通过但结果反复横跳”被呈现为完美状态。

指标页提供趋势视图：可选 7 天窗口按小时粒度、或 30 天窗口按天粒度，展示执行数、成功数、失败数和平均耗时。由于底层指标带环境维度，团队可只看单一环境，例如对比同一组测试在预发布与生产环境的表现。另有两个视图针对最耗时的测试：不稳定测试视图按过去七天在通过和失败之间翻转的频率排序用例；最近失败视图列出最新失败执行，并可一键跳转到第一篇介绍的 Amazon Nova Act 轨迹日志和会话录制，从“这个测试失败了”直接看到“智能体当时看到了什么”。

团队与角色控制访问

权限围绕团队组织，一个应用只属于一个团队，团队成员才能看到并操作该团队的应用。角色共五级，权限逐级累加：Admin 拥有整个 Studio 的访问权，可创建团队和分配应用，属于 Studio 级角色而非按团队分配；Team Lead 管理本团队成员并为团队创建应用；Editor 在团队应用内创建和编辑用例与测试套件；Executor 可运行用例和套件但不能修改；Viewer 只读。用例和套件的访问权跟随其所属应用，权限管理停留在应用层级，而不是分散到成千上万个单独测试上。管理员可在 Users 页面集中查看每个账号所属团队和角色。

编辑部观察

这套设计的重点不在测试编写，而在测试规模扩大后的归属与可见性问题：应用提供归属边界，健康分把“通过但抖动”的情况显性化，团队角色则把权限收敛到应用粒度。对准备把 QA 自动化从单团队推广到多团队的组织，值得先明确应用划分与环境维度是否与现有 CI/CD 流程对齐，再评估角色分配是否覆盖实际协作方式。原文未给出健康分扣分的具体权重、角色数量之外的限制条件，也未提供性能或成本数据，落地前需自行验证。