[Amazon Bedrock] 用 Amazon Nova Act 的 agentic QA 自动化加速软件交付 —— 第 3 部分

人工智能

用 Amazon Nova Act 的 agentic QA 自动化加速软件交付 —— 第 3 部分

随着质量保证（QA）自动化在一个组织内被越来越广泛地采用，一个新问题浮现出来，而它与编写测试毫无关系。一个平台团队搭起测试自动化，第二个团队也想加入，然后是十来个团队。很快，几百个测试用例分属不同的产品和小组，而且每个人都能看到其他人的测试。没人能一眼回答一个基本问题：这个应用的测试覆盖状况现在健康吗？编写测试不再是瓶颈，整理测试并控制谁能改动它们才是。

紧随其后的是第二个相关问题：这个应用及其测试归谁所有，覆盖率滑坡时又由谁负责？没有明确的归属，健康问题就无人担责。

在第一篇里，我们介绍了 QA Studio——一个用 Amazon Nova Act 构建的参考解决方案。团队用它以自然语言定义测试，并通过 AI 驱动的视觉导航运行这些测试。在第二篇里，我们加入了测试套件，以及一个用于在持续集成与持续交付（CI/CD）流水线中批量跑回归测试的 CLI。本文介绍两项能帮助 QA Studio 在整个组织内扩展的能力。第一项是应用，负责组织测试并报告健康指标。第二项是基于团队的用户管理，负责控制谁能看到什么、修改什么。

用应用组织测试

QA Studio 中的一个应用代表被测系统：一个网站、一个 Web 应用、一个服务前端。它是那组测试的容器，让它们有归属、有主人。用例（第 1 篇里的单项测试）和测试套件（第 2 篇里的回归测试集合）都属于某个应用，并继承该应用的归属关系。这样一来，各个团队就在自己拥有的应用里工作，而不是面对一份把部署中所有测试拉平堆在一起的清单。

创建应用需要填写名称、基础 URL，以及一组可选的环境（比如开发、预发布和生产）。在应用页面上，团队可以直接新建用例、添加已有用例，并把它们编成测试套件。这里也是 QA Studio 汇报它所运行测试的健康状况的地方。

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

用指标了解应用健康状况

测试会产生结果。持续理解这些结果，才能告诉团队某个应用的开发生命周期是否健康，而不只是判断某一次构建是否准备好发布。QA Studio 把每次执行的结果记录为 Amazon CloudWatch 自定义指标，维度按应用和环境划分，再把这些指标汇成应用页面上的健康视图。

页面顶部用三个数字回答最直接的问题：所选时间窗口内的通过率、执行总次数，以及当前的失败数。在它们旁边，QA Studio 还会算出一个 0–100 的健康分。这个分数以通过率为起点，再扣掉偶发失败测试（flaky test）带来的扣分。这样一来，一个测试时而过时而失败的用例，就不会呈现出一幅虚假的完美图景。团队扫一眼应用组合，就能分出哪些稳定、哪些需要处理，而不必逐条打开结果。

指标标签页从当前快照转向趋势。团队可以选 7 天窗口（按小时粒度）或 30 天窗口（按天粒度），QA Studio 会在这段时间内绘制执行次数、成功数、失败数和平均耗时。由于底层指标带有环境维度，团队还可以把视图过滤到某一个环境，比如对比同一批测试在预发布和生产环境下的表现。

有两个视图专门盯住最耗团队时间的测试。偶发失败测试视图按最近七天内在通过与失败之间反复横跳的频率给用例排名，把那些间歇性失败挑出来——它们还没变成线上事故，就已经在侵蚀对一个测试套件的信任。最近失败视图则列出最新的失败执行，便于快速分诊。每一条都能链回第 1 篇里介绍的 Amazon Nova Act 轨迹日志和会话录制。从「这个测试挂了」到「这正是 agent 看到的」，只需点一下。

图 2：指标标签页，显示所选窗口内的通过率、执行次数和平均耗时，以及每日成功与失败图表、失败热点和偶发失败用例排名

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

指标告诉团队自己的应用做得怎么样。基于团队的用户管理则决定哪些应用本来就属于他们。QA Studio 以团队为线索组织访问权限，一个应用恰好属于一个团队。该团队的成员可以操作它的应用，其他人则看不到它们。

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

Admin：在整个 Studio 范围内访问所有团队、应用和用户，包括创建团队和分配应用。Admin 是 Studio 级角色，而不是按团队逐个指派的。 Team Lead：管理自己团队的成员，并为该团队创建应用。 Editor：在团队的应用内创建和编辑用例与测试套件。 Executor：运行用例和测试套件，但不做修改。 Viewer：对团队的应用和结果只有只读权限。

由于权限是逐级叠加的，Team Lead 拥有 Editor 的全部权限，依次类推直到 Viewer。对某个用例或测试套件的访问权跟随包含它的应用：成员只要能操作这个应用，就能操作它的测试，但边界仍由其角色限定。这让权限管理停留在应用层面，而不是落在成千上万个单项测试上。

管理员能看到整个 Studio。Users 页面把每个账号连同其团队和角色集中列在一处，管理员一眼就能看出谁在哪个团队担任 Team Lead、谁拥有 Studio 级 Administrator 权限。这里展示的参考部署中，4 个用户分布在两个团队：2 个 Team Lead、1 个 Viewer 和 1 个 Studio 级 Administrator。Teams 页面把同样的数据按团队汇总，并排显示每个团队的成员数和应用数，管理员在打开任何一个团队之前就能看出哪些团队正在扩张。

图 3：全局 Users 页面，列出每个账号及其团队和角色，可按团队和角色筛选

同样按团队汇总的成员数据，出现在 Teams 页面上。

图 4：Teams 页面，显示每个团队的成员数和应用数

从团队切换到应用，全局的 Applications 列表会显示所有团队的全部应用。

图 5：全局 Applications 列表，显示每个应用的基础 URL、归属团队、用例数和最近一次执行状态

在团队之间共享应用

团队很少完全隔绝地工作。某个平台团队可能拥有一个应用，功能团队需要对着它跑测试，但并不想把改动权限一并交出去。QA Studio 用共享访问支持这种做法：拥有该应用的团队可以把访问权授予另一个团队，级别分为查看、执行或完全访问。

共享访问遵循一条上限规则：用户在共享应用上的实际权限，取其自身角色与授权级别中较低的那个。被授予完全访问的 Viewer 在共享应用上仍然只能查看，因为他们的角色就是上限。这样，拥有方团队可以广泛共享，而不会授予超出接收方角色所允许的权限。

Team Lead 能看到什么

Team Lead 在单个团队内工作，而不是整个 Studio。打开 My Team 会看到四个标签页，涵盖这位负责人所掌控的一切：Members、Applications、Use Cases 和 Shared Access。Members 标签页列出团队成员。负责人可以直接就地修改任何成员的角色，也可以新增成员，这样日常的权限管理就留在最贴近这项工作的人手里。这里展示的 AWS Team 有两名成员，一位 Team Lead 和一位 Viewer，由这位负责人管理。

图 6：Team Lead 的 Members 标签页，可为每位成员就地指定角色

Applications 标签页只显示该团队拥有的应用，并附上各自的测试用例数和最近运行时间，这让负责人专注于自己负责的这块，而不是整个 Studio 的清单。跨团队共享则体现在 Shared Access 标签页上。这里 AWS Team 给 AMZN Team 授予了某个应用的查看权限，负责人可以授予、撤销或调整这一授权的级别。由于授予的是查看级别，AMZN Team 的 Editor 看到的共享应用仍是只读的——这正是上一节那条上限规则的实际应用。

图 7：Team Lead 的 Applications 标签页，范围限定在该团队自己的应用上

同一位 Team Lead 的 Shared Access 标签页记录着哪些其他团队可以访问该团队的应用，以及访问级别。

图 8：Team Lead 的 Shared Access 标签页，显示向另一个团队授予的查看级别权限

工作原理

QA Studio 在前面几篇介绍的同一套无服务器（serverless）基础设施之上，构建了基于团队的访问控制与指标体系，并额外引入了几项 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 如何把 agentic QA 自动化从单个测试扩展到整个组织。应用为每个团队的用例和测试套件提供了归属之所，并通过通过率、趋势图、扣除偶发失败影响后的健康分，以及基于 Amazon CloudWatch 指标构建的失败分诊来报告健康状况。以 Amazon Cognito 为后盾的基于团队的用户管理，让各团队在自己拥有的应用内开展工作，跨团队共享则由一条明确的上限规则划定边界。

这些能力建立在第 1 篇的自然语言测试编写和第 2 篇的测试套件与 CI/CD 集成之上。合在一起，它们帮助 QA 自动化在多个团队间扩展，同时不失去可见性与控制力。想在自己的环境里试试，可以从 QA Studio GitHub 仓库部署参考解决方案，创建第一个团队和应用，跑几个用例，看着指标逐渐成形。想了解背后的 agent，可以查看 Amazon Nova Act 产品页。

关于作者