用 Nova Act 管理团队级自动化测试

用自然语言写测试、让 AI 操作浏览器，只解决了自动化测试的入口问题。等十几个团队、几百条用例挤进同一个平台，更难的问题会变成：测试归谁管，谁能修改，出了问题找谁，以及一个应用的测试现在到底稳不稳。

AWS 这篇 QA Studio 系列第三篇，重点就是这些组织问题。作者用应用归属、健康指标和团队权限，把 Amazon Nova Act 驱动的测试接入日常管理。对准备把 AI 测试从个人试用推向团队共用的开发者，这套思路比再加一个测试生成按钮更值得参考。

测试越来越多，为什么要先给它们找个归属

QA Studio 是基于 Amazon Nova Act 构建的参考方案。系列第一篇支持用自然语言定义测试，再通过 AI 视觉导航执行；第二篇增加测试套件和 CLI，让批量回归能够进入持续集成与持续交付（CI/CD）流水线。第三篇处理的是接入团队增多之后的管理问题。

如果平台只有一张全局测试列表，用例再多，也很难回答某个应用由谁负责、哪些回归应该一起执行。作者增加了 application，也就是被测应用：它可以是网站、Web 应用或某个服务的前端。

创建应用需要名称、基础 URL，以及可选的环境，例如 development、staging、production。单条测试叫 use case，回归集合叫 test suite，两者都归属于应用，并继承应用的所有权。团队可以在应用页面直接创建用例、纳入已有用例，再组织成套件。

应用同时成为测试归属、责任归属和权限判断的共同边界。

这让平台管理有了明确的落点。某个应用的测试持续失败，可以找到负责团队；成员权限调整，也可以沿着应用影响其内部测试，不必逐条配置。

不过，文章开头提出了「测试覆盖是否健康」，后续展示的主要是执行通过率、失败数量和稳定性。这些指标能描述已有测试的运行情况，却不能证明关键业务已经被覆盖。一个从未测试过支付流程的应用，也可能拥有很好看的通过率。

健康分能帮助排查，但不能代替发布判断

QA Studio 将每次执行结果写入 Amazon CloudWatch 自定义指标，并按应用和环境区分。应用页先展示三个数字：所选时间窗口的通过率、执行总数和当前失败数量，另外计算一个 0–100 的健康分。

这个分数从通过率出发，再扣除不稳定测试的惩罚。所谓不稳定测试（flaky tests），就是结果经常在通过和失败之间切换的用例。单看最近一次通过，会掩盖这种反复变化；把它纳入健康分，有助于团队扫描多个应用时发现异常。

但原文没有给出惩罚公式、权重或计算示例。我们只能确认它考虑了不稳定性，无法判断不同应用之间的分数是否足够可比。

趋势页面提供两种时间尺度：7 天窗口按小时展示，30 天窗口按天展示。图表覆盖执行次数、成功次数、失败次数和平均耗时，还能按环境过滤，分别查看 staging 与 production 的表现。

这比单次构建结果更适合观察持续变化。例如，通过率相近时，平均耗时持续增加也可能提示需要排查。但具体原因仍需结合执行记录确认，图表自身无法给出归因。

平台还提供两个排查入口：

• 不稳定测试视图按照最近 7 天内通过与失败的切换频率，对用例排序。
• 最近失败视图列出最新失败执行，并链接到 Amazon Nova Act 的轨迹日志和会话录像。

后者尤其适合 AI 浏览器测试。失败可能发生在应用、页面状态或代理操作过程里，能直接回看代理看到了什么、做了什么，比只收到一个失败状态更有用。不过，原文没有提供误判率或排查耗时的对照数据，不能据此断言它已经提高了多少效率。

跨团队共享，为什么要取两种权限的较低值

QA Studio 以团队组织访问权限，每个应用只属于一个团队。默认情况下，其他团队看不到它；单条用例和套件沿用应用权限。

平台定义了五种逐级包含下级权限的角色：

角色	可以做什么
Admin	管理整个 Studio 的团队、应用和用户，创建团队并分配应用
Team Lead	管理本团队成员，为团队创建应用
Editor	创建和编辑团队应用内的用例、套件
Executor	执行用例和套件
Viewer	只读查看应用与结果

Admin 是 Studio 全局角色，不是单个团队内部的角色。Team Lead 的 My Team 页面包含 Members、Applications、Use Cases、Shared Access 四个标签，可以就地调整成员角色，并管理本团队应用及共享关系。

文章的参考部署展示了 4 个用户、2 个团队：2 名 Team Lead、1 名 Viewer 和 1 名全局管理员。这只是功能演示规模，不能当成大组织落地的验证结果。

跨团队协作通过共享授权完成，级别分为 view、execute、full。这里最关键的规则是：用户的最终权限，取自身角色权限与共享授权级别中较低的那个。

例如，Viewer 即使拿到 full 共享，也只能查看；AWS Team 向 AMZN Team 授予 view 后，AMZN Team 的 Editor 仍然只能只读访问。共享扩大了资源可见范围，但不会突破原有角色限制。

这些限制也落实在服务端。每个团队对应一组 Amazon Cognito groups，每个角色一个 group；AWS Lambda authorizer 在每次请求中将调用方所属组解析为 API scopes 和团队上下文。

AWS Lambda 与 Amazon API Gateway 再执行两层检查：角色授予的 scope 是否允许该操作，以及调用方团队是否拥有该应用或取得共享授权。Amazon DynamoDB 则在已有的单表设计中保存团队、成员、应用归属和共享记录。

指标使用 Amazon CloudWatch 的 QAStudio/Executions 命名空间，指标 API 再读取数据构建页面。第二篇使用的 OAuth client credentials flow 也能沿用这套权限模型，让 CI 流水线以机器身份申请所需 scopes。

我的判断

我认同它把管理边界放在应用这一层。对于多个业务团队共用测试平台的情况，按应用继承权限，比给每条用例单独授权更容易维护；跨团队共享取权限较低值，也是一条容易解释和检查的规则。

它的前提是，团队能够明确划分应用所有权。每个应用只属于一个团队，适合责任边界清楚的组织；如果多个团队共同维护一个大型前端，仍需先约定谁负责应用、谁负责共享。原文没有展开多方共同负责时的处理办法。

健康分则应该谨慎使用。通过率与不稳定性适合帮助团队决定先排查哪里，但不能直接充当发布门禁。原文没有交代业务关键程度如何计入，也没有给出评分公式和对照实验，因此这里更像一套管理设计经验。

与按仓库组织的传统测试报告相比，QA Studio 增加了跨应用视图、团队管理和代理执行回放。如果团队规模较小、仓库归属已经清楚，现有 CI 报告可能足够，不一定需要单独部署平台。

部署本身也有成本。参考方案通过 AWS Cloud Development Kit（AWS CDK）部署在自己的 AWS 账户中，测试数据、结果和指标保留在账户边界内；相应地，团队也要维护 Cognito、DynamoDB、CloudWatch、Lambda 和 API Gateway。原文没有给出部署费用、运维投入或规模测试结果。

能拿来做什么

• 准备让多个前端团队共用 AI 测试时，先为每个被测应用登记基础 URL、环境和负责团队，再把用例与套件挂进去，减少后续补归属的工作。
• 为测试报告同时保留通过率、执行量、失败数和平均耗时，并观察最近 7 天的结果切换情况；使用这些数据安排排查顺序，另行检查关键业务是否被覆盖。
• 把 AI 浏览器测试的失败记录链接到执行轨迹与会话录像，让接手排查的人能够直接查看代理操作过程。
• 接入 CI 时，为机器身份配置完成回归所需的 scopes，并在服务端同时检查操作权限和应用访问权限；跨团队共享也沿用取较低权限的规则。