AWS发布QA Studio第三部分：新增应用级指标与基于团队的角色权限
AWS机器学习博客介绍QA Studio参考方案的新增功能：用“应用”组织测试并按环境统计健康指标，用团队和五种角色控制访问权限，支持跨团队共享设置权限上限。
AI解读：这篇AWS博客面向已部署QA Studio参考方案的团队：当组织内多个团队、数百个测试用例集中在一起时，测试编写不再是瓶颈，弄清某应用当前覆盖是否健康、谁负责该应用及其测试成为主要问题。
应用是QA Studio中代表被测系统的容器，需要名称、基础URL和可选的环境集合（如开发、预发、生产）；用例和测试套件归属应用并继承其所有权，权限按应用而非单个测试管理。
健康视图基于CloudWatch自定义指标（按应用和环境维度），显示所选窗口的通过率、执行总数和当前失败数，并给出0到100的健康分；该分数以通过率为基础，对不稳定测试扣分。
指标页支持7天小时粒度或30天日粒度，可按环境过滤以比较预发与生产；另有“不稳定测试”视图按过去七天在通过和失败间翻转的频率排序，最近失败视图可一键跳到Nova Act的轨迹日志和会话录制。
团队角色共五种且权限逐级累加：Admin为全工作室范围，Team Lead管理本团队成员并创建应用，Editor编辑用例和套件，Executor只能运行，Viewer只读。跨团队共享访问分查看、执行、全部三级，用户的实际权限取自身角色与共享级别的较低者。
部署仍通过AWS CDK在自己账户内完成，测试数据、结果和指标保留在账户边界内；团队与角色映射到Amazon Cognito组，后端在Lambda授权和资源归属检查两层执行访问控制，CI流水线可用OAuth客户端凭证以机器身份按需授权。
AWS机器学习博客发布QA Studio系列第三篇，作者Vinicius Pedroni介绍该参考方案新增的两项能力：用“应用”组织测试并报告健康指标，以及基于团队的用户管理，控制谁能查看和修改哪些内容。QA Studio是构建在Amazon Nova Act上的参考方案，部署在用户自己的AWS账户中。
博客称，随着组织内QA自动化推广，难题从编写测试转向组织测试与权限管理：多个团队的数百个用例混在一个列表里，难以一眼判断某应用的测试覆盖是否健康，也缺少明确的责任人。应用这一容器为用例和测试套件提供归属，并带有所有者。
用应用与CloudWatch指标组织测试健康视图
在QA Studio中，一个应用代表被测系统，即网站、Web应用或服务前端。创建应用需要名称、基础URL，以及可选的开发、预发、生产等环境。第一篇中的用例和第二篇中的测试套件都归属于应用并继承其所有权，团队只在自己拥有的应用内工作。
QA Studio把每次执行结果记录为Amazon CloudWatch自定义指标，按应用和环境两个维度划分，并在应用页面汇总为健康视图：所选时间窗口的通过率、执行总数和当前失败数，以及一个0到100的健康分。博客说明，该分数以通过率为起点，对不稳定测试扣分，避免测试虽通过但反复翻转时呈现出虚假的完美状态。
指标页提供7天（按小时）或30天（按天）窗口，展示执行、成功、失败和平均耗时趋势，并可按单一环境过滤，例如比较同一组测试在预发和生产中的表现。不稳定测试视图按过去七天在通过和失败间翻转的频率对用例排序；最近失败视图列出最新失败执行，每条可一键跳转到第一篇介绍的Nova Act轨迹日志和会话录制。
团队、五种角色与共享访问的权限上限
访问控制以团队组织，一个应用只属于一个团队，其他团队看不到。团队成员拥有五种角色之一，且权限逐级累加：Admin可在整个工作室范围内访问所有团队、应用和用户，并创建团队、分配应用；Team Lead管理本团队成员并为团队创建应用；Editor在团队应用内创建和编辑用例与测试套件；Executor可以运行但不能修改；Viewer只读访问团队应用和结果。用户对某个用例或套件的访问权限跟随其所属应用，受其角色限制。
跨团队协作通过共享访问实现：拥有方团队可按查看、执行或全部三级向另一团队授予应用访问权。博客描述了一条“上限规则”：用户在共享应用上的实际权限取自身角色与授权级别中较低者，因此即使给Viewer授予全部权限，该用户仍是只读。
管理界面包括工作室范围的Users页（列出每个账号所属团队和角色，可按团队、角色过滤）、Teams页（按团队汇总成员数和应用数）和Applications列表（显示基础URL、拥有团队、用例数和最近执行状态）。Team Lead的My Team页有成员、应用、用例和共享访问四个标签，可在其中直接修改成员角色或授予、撤销、调整跨团队共享级别。
实现方式与部署条件
博客说明，这些能力沿用了前两篇描述的无服务器基础：每个团队映射到一组Amazon Cognito组，每个角色对应一组；AWS Lambda授权器在每次请求时把调用者的组解析为API作用域和团队上下文。团队、成员关系、应用所有权和跨团队共享授权存储在现有的DynamoDB单表设计中。执行指标写入QAStudio/Executions命名空间；Lambda和API Gateway在角色授予的作用域和资源归属检查两层执行后端访问控制。
由于访问权限来自Cognito组成员身份，第二篇所述的OAuth客户端凭证流程也适用，CI流水线可作为机器身份以所需且仅需的作用域完成认证。
QA Studio参考方案通过AWS CDK部署在用户自己的AWS账户中，博客称所有测试数据、结果和指标都保留在账户边界内。部署后，管理员创建团队、分配成员和角色、将应用分配给团队，各团队的指标随测试运行开始填充。部署说明和配置细节见QA Studio的GitHub仓库及文档。