Article · AI translation
随着组织内部质量保证（QA）自动化的采用日益普及，一个与编写测试无关的新问题出现了。平台团队建立测试自动化后，第二个团队想加入，接着又有十几个团队加入。很快，数百个测试用例分属不同的产品和团队，而每个人都能看到其他所有人的测试。没人能一眼回答一个基本问题：这个应用当前的测试覆盖情况是否良好？编写测试不再是瓶颈。组织测试以及控制谁能操作测试，成了主要工作。紧接着又出现第二个相关问题：谁拥有这个应用及其测试？当测试覆盖情况变差时，谁应负责？如果没有明确的负责人，健康状况问题就无人承担。在第一篇文章中，我们介绍了使用 Amazon Nova Act 构建的参考解决方案 QA Studio。团队用它以自然语言定义测试，并通过 AI 驱动的可视化导航运行测试。在第二篇文章中，我们加入了测试套件和 CLI，用于持续集成和持续交付（CI/CD）流水线中的批量回归测试。本文介绍帮助 QA Studio 在整个组织内扩展的两项功能。第一项是应用，用于组织测试和报告健康指标。第二项是基于团队的用户管理，用于控制谁能查看和更改哪些内容。使用应用组织测试 QA Studio 中的应用代表被测系统：网站、Web 应用或服务前端。它是承载一组测试的容器，为这些测试提供归属和负责人。用例（第 1 部分中的单项测试）和测试套件（第 2 部分中的回归测试集合）都属于某个应用，并继承该应用的归属关系。各团队不必面对部署环境中所有测试组成的单一列表，而是在自己拥有的应用内工作。创建应用需要名称、基础 URL，以及一组可选环境，例如开发、预发布和生产环境。在应用页面，团队可以直接在相应应用中创建新用例、添加现有用例，并将它们组成测试套件。QA Studio 也在这里报告其运行的测试的健康状况。图 1：应用详情页面，显示通过率、执行次数和失败次数，以及用例和测试套件选项卡。通过指标了解应用健康状况 测试会产生结果。了解这些结果随时间的变化，才能让团队判断应用的开发生命周期是否健康，而不只是某个构建版本是否已准备好发布。QA Studio 将每次执行的结果记录为 Amazon CloudWatch 自定义指标，并按应用和环境划分维度。它将这些指标转换为应用页面上的健康状况视图。页面顶部用三个数字回答眼前的问题：所选时间范围内的通过率、执行总次数和当前失败次数。此外，QA Studio 还会计算一个 0–100 的健康评分。该评分以通过率为起点，再扣除不稳定测试带来的分值。这样一来，即使某个应用的测试能够通过，但结果在通过与失败之间反复变化，也不会呈现出虚假的满分状态。团队浏览一组应用时，无须打开每条结果，就能区分哪些应用稳定、哪些需要关注。指标选项卡展示的不只是当前快照，还有变化趋势。团队可以选择按小时显示的 7 天时间范围，或按天显示的 30 天时间范围；QA Studio 会绘制该时段内的执行次数、成功次数、失败次数和平均耗时。由于底层指标包含环境维度，团队可以将视图筛选到单个环境。例如，他们可以比较同一组测试在预发布环境和生产环境中的表现。有两个视图专门呈现最耗费团队时间的测试。不稳定测试视图根据用例在过去 7 天内于通过和失败之间切换的频率对其排名。这有助于在间歇性失败导致生产环境漏检之前，找出那些削弱团队对测试套件信任的问题。近期失败视图列出最新的失败执行记录，供团队快速排查。每条记录都链接到第 1 部分介绍的 Amazon Nova Act 运行轨迹日志和会话录制。这样，从“这个测试失败了”到查看“代理当时究竟看到了什么”，只需点击一次。图 2：指标选项卡：所选时间范围内的通过率、执行次数和平均耗时，以及每日成功与失败图表、失败集中区域和不稳定用例排名。通过团队和角色控制访问权限 指标告诉团队其应用运行得如何。基于团队的用户管理则决定哪些应用归该团队管理。QA Studio 围绕团队组织访问权限，每个应用只属于一个团队。该团队的成员可以使用其应用。其他人则看不到这些应用。每位团队成员拥有以下 5 种角色之一，每种角色都包含其下级角色的权限：管理员：拥有对整个 Studio 中所有团队、应用和用户的访问权限，包括创建团队和分配应用。管理员是面向整个 Studio 的角色，而不是按团队分配的角色。团队负责人：管理自己团队的成员，并为团队创建应用。编辑者：在团队的应用内创建和编辑用例及测试套件。执行者：运行用例和测试套件，但不能修改它们。查看者：对团队的应用和结果拥有只读访问权限。由于角色权限是累积的，团队负责人拥有编辑者的全部权限，依此类推，直至查看者。用例或测试套件的访问权限取决于其所属的应用。如果成员可以使用某个应用，就可以在自身角色允许的范围内使用该应用的测试。这样，权限管理可以在应用级别进行，而无须针对数千项单独的测试设置权限。管理员可以看到整个 Studio。用户页面集中列出每个账户及其团队和角色。管理员可以查看哪些人在什么团队担任团队负责人，以及谁拥有整个 Studio 的管理员权限。这里展示的参考部署中，4 名用户分属 2 个团队：2 名团队负责人、1 名查看者和 1 名整个 Studio 的管理员。团队页面按团队汇总相同的数据，并列显示每个团队的成员数量和应用数量。管理员无须打开各个团队，就能看到哪些团队正在扩张。图 3：整个 Studio 的用户页面：列出每个账户及其团队和角色，并可按团队和角色筛选。同样的成员数据按团队汇总后，也会显示在团队页面。图 4：团队页面：显示每个团队的成员数量和应用数量。从团队切换到应用后，整个 Studio 的应用列表会显示所有团队的每个应用。图 5：整个 Studio 的应用列表：显示每个应用的基础 URL、所属团队、用例数量和最近一次执行状态。在团队之间共享应用 团队很少完全独立地工作。平台团队可能拥有一个功能团队需要运行测试的应用，但不希望交出更改该应用的权限。QA Studio 通过共享访问权限支持这种情形：所属团队可以授予另一个团队对某个应用的查看、执行或完全访问权限。共享访问权限遵循上限规则。用户对共享应用的实际权限，取其自身角色和所获授权级别中的较低者。即使查看者获得了对共享应用的完全访问授权，其权限仍限于查看，因为其角色就是权限上限。这样，所属团队可以广泛共享应用，同时不会授予超出接收方角色允许范围的权限。团队负责人看到的内容 团队负责人在单个团队内工作，而不是管理整个 Studio。打开“我的团队”后，会看到涵盖其管理事项的 4 个选项卡：成员、应用、用例和共享访问权限。成员选项卡列出团队中的人员。负责人可以直接修改任一成员的角色，也可以添加新成员，因此日常访问权限管理由最熟悉相关工作的人负责。在这里展示的 AWS Team 中，负责人管理着 2 名成员，其中 1 名是团队负责人，1 名是查看者。图 6：团队负责人的成员选项卡，可直接为每名成员分配角色。应用选项卡只显示该团队拥有的应用，并显示每个应用的测试用例数量和最近一次运行时间。这使负责人能够专注于自己团队负责的范围，而不是整个 Studio 的应用清单。共享访问权限选项卡展示团队之间共享的具体情况。在这里，AWS Team 已授予 AMZN Team 对某个应用的查看权限，负责人可以授予、撤销或更改该访问权限的级别。由于授予的是查看级别的权限，即使 AMZN Team 的编辑者也只能以只读方式查看这个共享应用：这就是上一节所述上限规则的实际应用。图 7：团队负责人的应用选项卡，范围限于团队自己的应用。同一位团队负责人的共享访问权限选项卡记录了哪些其他团队可以访问本团队的应用，以及各自的访问级别。图 8：团队负责人的共享访问权限选项卡，显示向另一个团队授予的查看级别权限。工作原理 QA Studio 在前几篇文章介绍的同一个无服务器基础架构上构建基于团队的访问控制和指标功能，并加入了几项 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 如何将代理式 QA 自动化从单项测试扩展到整个组织。应用为每个团队的用例和测试套件提供归属位置。它们通过基于 Amazon CloudWatch 指标构建的通过率、趋势图表、考虑不稳定测试因素的健康评分和失败排查功能，报告健康状况。由 Amazon Cognito 支持的基于团队的用户管理，使各团队在自己拥有的应用范围内工作，并通过明确的上限规则约束跨团队共享。这些功能建立在第 1 部分的自然语言测试编写功能，以及第 2 部分的测试套件和 CI/CD 集成之上。它们共同帮助 QA 自动化扩展到众多团队，同时保持可见性和控制力。要在自己的环境中试用，请从 QA Studio GitHub 存储库部署参考解决方案，创建第一个团队和应用，然后运行几个用例，观察指标逐步形成。要进一步了解其背后的代理，请参阅 Amazon Nova Act 产品页面。作者简介 Vinicius Pedroni Vinicius 是 AWS 旅游与酒店行业的高级解决方案架构师，专注于边缘服务和生成式 AI。Vinicius 也热衷于协助客户完成云之旅，让他们在合适的时机采用合适的策略。Jan Wiemers Jan 是 AWS 的高级解决方案架构师，与旅游、运输和物流行业的客户合作。他在软件行业拥有超过 20 年的经验，专注于 AI 产品开发生命周期和测试自动化，帮助客户加快构建、测试和部署 AI 驱动解决方案的速度。