QA Studio是一个使用Amazon Nova Act构建的参考解决方案。第一部分介绍了如何用自然语言定义测试，以及如何借助人工智能驱动的视觉导航执行相关操作。第二部分加入了测试套件和命令行界面，使批量回归测试能够进入CI/CD流水线。第三部分进一步处理测试规模扩大后出现的组织与运行问题：怎样把用例归入明确的测试对象，怎样从每次执行中形成可观察的健康信息，以及怎样控制不同用户可以查看、运行或修改哪些资源。

应用既代表测试对象，也界定所有权

在QA Studio中，应用代表一个被测系统。它不仅是一个名称或入口，也是该系统相关用例与测试套件的容器和所有权边界。属于同一被测系统的内容因此能够聚合在一个应用之下，而应用的归属又为这些内容提供清楚的管理范围。测试组织、结果查看和权限判断都可以围绕同一个对象展开。

创建应用时必须提供名称和基础URL。用户还可以选择配置一组环境，例如开发环境、预发布环境和生产环境。环境不是独立于应用的另一套组织单元，而是应用内部用于区分执行上下文的维度。这样，同一应用的用例和套件可以保持统一归属，同时每次运行的结果仍能表明它对应哪个环境。

这种结构把被测系统、测试内容和运行环境联系起来。应用回答“这些测试属于哪个系统”，环境回答“这次执行发生在哪个上下文”，所有权则回答“哪个团队负责这个应用”。三者共同构成后续指标展示与访问控制所依赖的范围，但不会把一个应用拆成互不相关的记录集合。

每次执行都进入应用健康视图

QA Studio会把每次执行的结果记录为Amazon CloudWatch自定义指标。指标以应用和环境作为维度，随后用于构建应用健康视图。因此，单次成功或失败不仅保留为某次运行的结果，还会进入与特定应用、特定环境相关的汇总信息。查看者既能关注当前结果，也能从统一视图理解所选范围内的整体状态。

应用页面显示所选时间窗口内的通过率、执行总数以及当前失败数量。页面还提供一个从0到100的健康分数。该分数根据通过率计算，并对不稳定测试施加惩罚。健康分数因此并非只把成功次数换算成一个数字；当测试结果在成功与失败之间变化时，这种不稳定性也会影响最终分数。

通过率、执行总数、当前失败数和健康分数承担不同作用。执行总数说明汇总中包含多少次运行，通过率呈现这些运行的总体成功比例，当前失败数突出仍需关注的失败，而健康分数把通过表现和测试不稳定性结合起来。它们在同一应用页面出现，使读者可以从数量、比例、当前问题与综合状态等角度查看相同的执行范围。

七天与三十天的指标粒度

指标标签页提供两种时间视图。七天视图采用小时粒度，适合查看最近七天内指标随小时变化的情况；三十天视图采用日粒度，用每天的数据覆盖更长的时间范围。两个视图所展示的指标包括执行次数、成功次数、失败次数和平均持续时间。用户还可以使用环境过滤条件，把图表限制在选定环境中。

不同粒度并没有改变指标的含义，而是改变了它们在时间轴上的汇总方式。小时级的七天视图保留更细的近期变化，日级的三十天视图则以较长窗口呈现每天的情况。配合应用和环境维度，读者可以明确自己正在观察哪个被测系统、哪个环境以及哪个时间范围，避免把不同上下文中的执行混为一个无法区分的总数。

识别不稳定测试并进入失败记录

QA Studio包含专门的不稳定测试视图。该视图根据过去七天内用例在通过与失败之间发生转换的情况进行排序。排序关注的不是单纯的执行次数，也不是只列出所有失败，而是突出结果发生变化的用例。由于应用健康分数会对不稳定测试施加惩罚，这个视图也为理解健康汇总中的不稳定因素提供了更具体的入口。

解决方案还提供最近失败视图，其中的条目可以链接到Amazon Nova Act轨迹日志和会话录制。应用页面与指标图表给出汇总层面的信号，最近失败条目则把查看者带到与具体失败执行相关的记录。汇总信息、失败列表、轨迹日志和会话录制由此形成从整体状态到单次执行材料的查看路径。

不稳定测试视图与最近失败视图解决的是两个相邻但不同的问题。前者根据七天内的通过或失败转换对用例排序，强调结果变化；后者集中展示近期失败，并提供指向轨迹日志与会话录制的链接。一个用于发现反复变化的测试，另一个用于查看具体失败对应的执行记录，两者都建立在已记录的执行结果之上。

团队是访问管理的基本单位

QA Studio围绕团队组织访问权限。每个应用只属于一个团队，所属团队的成员依据自己的角色与应用交互。其他用户默认看不到该应用，除非应用的访问权被共享给他们。团队所有权因此既规定谁负责应用，也构成默认的可见性边界；共享则是在这条边界之外提供访问的明确机制。

解决方案定义了五种累积角色。Admin拥有整个工作室范围的访问权。Team Lead可以管理团队成员，并为团队创建应用。Editor可以创建和编辑用例及测试套件。Executor可以运行这些内容，但不能修改它们。Viewer只有只读访问权。角色具有累积性，因此较高角色包含较低角色已有的权限范围。

这些角色把管理成员、创建应用、编辑测试内容、执行测试和只读查看区分开来。Team Lead负责团队成员以及团队应用的创建，Editor负责用例和套件的内容变化，Executor只负责运行而不改变定义，Viewer只能查看。Admin的范围覆盖整个工作室。累积结构使角色之间形成由低到高的权限层次，而不是五组彼此无关的操作清单。

共享权限同时受授予级别和个人角色限制

应用的所属团队可以把应用共享给另一个团队，并选择查看、执行或完全访问三个级别之一。共享并不会使接收方自动获得该级别内的全部能力。最终生效的权限取接收者自身角色与共享授予级别两者中较低的一项。这个规则同时保留应用所有者设定的边界和接收者自身角色的边界。

例如，从规则本身可以看出，授予较宽的共享级别不会让接收者超越其固有角色，而较高的个人角色也不会突破所有者只授予的较低共享级别。决定结果时需要同时检查两个条件：所属团队愿意向接收团队开放到什么程度，以及具体接收者的角色允许其执行什么操作。任何一侧的限制都会保留下来。

团队所有权、默认不可见、显式共享和“取较低权限”共同形成完整的访问逻辑。应用先由唯一团队拥有；非所属团队的用户在未共享时看不到它；所有者选择向另一团队授予查看、执行或完全访问；系统再把该授予级别与接收者角色相比较。这样，可见性和操作范围都可以沿着同一套资源关系确定。

身份组、数据记录与资源检查

在实现层面，每个团队都会映射到Amazon Cognito中与其角色对应的组。Amazon DynamoDB保存团队、成员关系、应用所有权以及共享授权。这些数据分别描述有哪些团队、用户属于哪些团队、应用由谁拥有，以及所有者向其他团队开放了什么级别的访问。它们为界面中呈现的团队和共享模型提供持久化记录。

AWS Lambda和Amazon API Gateway负责执行角色范围与资源访问检查。检查不仅涉及用户具有哪种角色，还涉及用户要访问的具体资源及其所有权或共享关系。因此，角色定义、团队成员关系、应用所有权和共享授权并非只用于展示，而是参与资源访问判断。最终权限仍遵循接收者角色和授予级别两者取较低值的规则。

这一实现把不同职责分配给明确的组成部分：Amazon Cognito组承载团队角色映射，Amazon DynamoDB保存团队与资源关系，AWS Lambda和Amazon API Gateway执行角色范围及资源访问检查。它们共同支持应用只属于一个团队、成员按角色工作、其他用户默认不可见以及跨团队共享受双重上限约束等规则。

部署位置与数据边界

应用、指标和基于团队的访问控制都包含在QA Studio参考解决方案中。该解决方案使用AWS CDK部署到用户自己的AWS账户。测试数据、测试结果和指标保留在该账户的边界之内。因此，新增的组织、观测和权限能力与参考解决方案一起部署，其运行记录也处在用户账户所界定的范围中。

第三部分并没有取代前两部分的能力，而是在其上增加管理上下文。自然语言测试定义和人工智能视觉导航提供测试交互方式，测试套件与命令行界面支持组织测试以及在CI/CD流水线中进行批量回归执行。应用进一步把用例和套件归入被测系统，CloudWatch指标把运行结果转化为健康视图，团队、角色和共享规则则规定资源由谁拥有、谁能看到以及谁能执行修改。

从整体结构看，应用是贯穿这些能力的中心边界。它连接基础URL、可选环境、用例、测试套件、执行指标和所属团队；健康页面与指标标签页在这一边界内汇总结果；不稳定测试和最近失败视图帮助查看变化与失败记录；五种角色及三种共享级别控制人员能进行的操作。QA Studio第三部分由此为测试内容、运行信息和访问关系提供了统一的组织方式。