View a markdown version of this page

发布测试 - AWS DevOps 代理人
发布测试的工作原理支持的测试类型定义测试配置文件从测试配置文件运行测试通过 DevOps 代理聊天运行测试从 IDE 运行测试CI/CD 管道中的发布测试查看测试结果

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

发布测试

发布测试生成并执行测试计划，以验证真实环境中的代码更改。发布测试代理针对您部署的 Web 应用程序和 REST API 运行探索性 UAT 和回归测试（功能回归、用户旅程验证、集成测试和边缘案例探索）。

发布测试的工作原理

重要

发布测试会针对您的目标应用程序执行真实请求，包括写入操作（POST、PUT、DELETE）。代理探索端点、提交表单并测试错误处理——这些操作可能会在目标应用程序中创建、修改或删除数据。仅在您的风险状况可以接受变更操作的地方使用，作为探索性测试的一部分。确保您的应用程序可以容忍探索性写入操作，而不会产生意想不到的后果，例如发送客户通知、处理付款或永久删除记录。我们建议在暂存部署中运行；只有当您的应用程序的写入操作可以安全地进行自动测试时，才应将生产应用程序作为目标。

触发后，发布测试代理：

  1. 生成测试计划-根据代码更改或用户提供的测试意图创建测试计划。当从拉取请求或分支触发时，该计划将针对受影响的功能。当手动触发或通过聊天触发时，您可以提供描述要验证的内容的测试意图。该计划涵盖功能正确性、集成行为和面向用户的场景。

  2. 对正在运行的应用程序执行测试 — 给定目标 URL（Web 应用程序或 API 端点），代理会探索应用程序并执行生成的测试。对于 Web 应用程序，这包括基于浏览器的用户界面交互和目视检查。对于 API，这包括直接 HTTP 端点测试、架构验证和错误处理验证。

  3. 报告调查结果-返回的结果包括特定的故障、受影响的功能、复制步骤和建议的修复方法。

发布测试支持 Web 应用程序（React、Angular、Vue、服务器渲染）和 REST API。

支持的测试类型

  • 用户界面 Browser-based 测试 — 使用可视化交互对 Web 应用程序进行测试

  • API 测试 — 针对 REST API 进行直接 HTTP 端点测试

定义测试配置文件

测试配置文件定义了要测试的 Web 和 API 应用程序以及必要的配置。每个测试配置文件都指定了目标应用程序及其测试类型。

要创建测试配置文件，请执行以下操作：

  1. 在 A DevOps gent Web 应用程序中，导航到左侧导航栏中的版本管理器。

  2. 选择 “测试配置文件” 按钮。

  3. 选择添加测试配置文件。

  4. 在表格中填写以下详细信息：

    • 名称-测试配置文件的描述性名称（例如，“MyApp 暂存”）

    • 目标 URL-应用程序的暂存或测试部署的 URL。代理发送真实的 HTTP 流量，包括写入操作（POST、PUT、DELETE）。除非您了解并接受数据修改的风险，否则请勿使用正式版网址。

    • 测试类型-选择 UI 测试（基于浏览器的可视化交互测试）或 API 测试（直接 HTTP 端点测试）

  5. 选择添加测试配置文件进行保存。

从测试配置文件运行测试

在测试配置文件页面上，您可以手动触发测试运行：

  1. 在列表中找到您的测试档案。

  2. 选择 “开始测试”。

  3. （可选）在 “测试意图” 中指定具体说明和要测试的内容。例如，“验证结账流程是否正确处理过期的优惠券” 或 “使用无效的输入测试用户注册表单”。

代理将根据您的意图生成测试计划（如果未提供意图，则进行广泛探索），执行测试，并在版本管理器部分的建议变更下报告结果。

通过 DevOps 代理聊天运行测试

在 DevOps 代理聊天中，您可以请求发布测试。要求代理列出您的测试配置文件或指定要运行的测试配置文件。代理将询问任何所需的后续信息，例如要测试什么或要重点关注哪些领域。

示例：

  • “列出我的测试档案”

  • “运行测试配置文件 my-test-profile”

  • “在我的应用程序上运行发布测试https://staging.myapp.com并验证付款流程”

代理在探索应用程序时报告进度，并返回包含特定发现、屏幕截图（用于用户界面测试）和复制步骤的结果。

从 IDE 运行测试

在 Kiro IDE 或 Claude Code 中，编码代理可以调用发布测试：

首先，安装 Kiro power 或 Claude Code 插件。

  • 指定描述要验证的内容的测试要求或意图（例如，“验证重构身份验证后登录流程是否有效”）

  • 编码代理将测试意图和目标测试配置文件传递给发布测试代理

  • 发布测试代理生成并执行测试，然后将结果报告回来

  • 如果发现问题，编码代理会主动提出将其修复到位

CI/CD 管道中的发布测试

GitHub 行动

Acti aws-actions/devops-agent-release-testing@v1 GitHub on 会在部署后触发发布测试代理，并在提交或拉取请求时以 GitHub Check Run 的形式报告结果。

先决条件

步骤 1：配置 GitHub 存储库密钥

在你的 GitHub 仓库中，前往设置 → 机密和变量 → 操作 → 仓库密码，然后添加：

Secret 说明
DEVOPS_AGENT_WEBHOOK_URL 来自你的代理空间的 webhook 网址
DEVOPS_AGENT_WEBHOOK_SECRE 来自 Agent Space 的 webhook 签名秘密

有关创建 webhook 端点的信息，请参阅通过 Webhook 调用 DevOps 代理。

步骤 2：将操作添加到您的工作流程中

将发布测试步骤添加到您的工作流程中（例如，.github/workflows/release-tests.yml）：

name: Release Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  checks: write
  contents: read
  pull-requests: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Release Tests
        uses: aws-actions/devops-agent-qa@v1
        with:
          webhook-url: ${{ secrets.DEVOPS_AGENT_WEBHOOK_URL }}
          webhook-secret: ${{ secrets.DEVOPS_AGENT_WEBHOOK_SECRET }}
          test-profile-id: <YOUR_TEST_PROFILE_ID>
          test-requirement: <WHAT_TO_TEST>  # optional
        env:
          GITHUB_TOKEN: ${{ github.token }}

<YOUR_TEST_PROFILE_ID>替换为代理空间中的测试配置文件 ID（开头为ki-）。test-requirement输入是可选的——使用它可以将代理的注意力集中在特定区域（例如，“在身份验证重构后验证登录流程”）。

动作输入

Input 必需 说明
webhook-url 是 来自你的代理空间的 webhook 网址
webhook-secret 是 用于 HMAC-SHA256 身份验证的 webhook 签名密钥
测试配置文件 ID 是 要触发的测试配置文件 ID（开头为ki-）
测试要求 否 用于测试的可选对焦区域

所需的工作流程权限

权限 Reason
内容：阅读 actions/checkout 在私有存储库中是必需的
拉取请求：读取 解析合并提交 SHA 中的 PR 号码

工作原理

  1. 您的工作流程触发器（例如，部署到暂存环境之后）。

  2. 该操作在提交或 PR 上创建一个 Check Run (in_progress)，它显示为待处理的检查。

  3. 操作会签名并向你的特工空间发送一个 webhook。

  4. 发布测试代理接起任务并对您的应用程序运行测试。

  5. 结果以 GitHub Check Run 的形式报告（pass/fail 附有详细摘要）。

您可以在从 Agent Space 链接的 A DevOps gent Web 应用程序中查看完整的执行细节（时间表、测试用例、界面测试的屏幕截图）。

查看测试结果

测试结果显示在 A DevOps gent Web 应用程序的 “更改” 部分的建议更改下。每次测试运行都显示：

  • 状态-已完成、失败或进行中

  • 类别-发布测试

  • 持续时间-测试运行花了多长时间

  • 来源-无论是手动触发、聊天触发还是通过 CI/CD 管道触发

选择测试运行以查看详细结果，包括特定的测试失败、屏幕截图（用于界面测试）、复制步骤和建议的修复方法。