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

# 发布测试
<a name="release-management-release-testing"></a>

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

## 发布测试的工作原理
<a name="how-release-testing-works"></a>

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

触发后，释放测试代理：

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

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

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

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

## 支持的测试类型
<a name="supported-test-types"></a>
+ **用户界面 Browser-based 测试 ** — 使用 Web 应用程序的视觉交互进行测试
+ **API 测试 ** — REST API 的直接 HTTP 端点测试

## 定义测试配置文件
<a name="defining-test-profiles"></a>

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

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

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

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

1. 选择 “**添加测试配置文件” **。

1. 在表格中填写以下详细信息：
   + **名称 ** — 测试配置文件的描述性名称（例如，“MyApp Staging”）
   + **目标 URL ** — 应用程序的暂存或测试部署的 URL。代理发送真实的 HTTP 流量，包括写入操作（POST、PUT、DELETE）。除非您了解并接受数据修改的风险，否则不要使用生产 URL。
   + **测试类型 **-选择 ** UI 测试**（基于浏览器的测试和可视化交互）或 ** API 测试**（直接 HTTP 端点测试）

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

**注意：**该应用程序必须可通过公共互联网访问。目前不支持私有网络端点。

## 从测试配置文件运行测试
<a name="running-tests-from-a-test-profile"></a>

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

1. 在列表中找到您的测试资料。

1. 选择 “**开始测试” **。

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

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

## 通过 DevOps 代理聊天运行测试
<a name="running-tests-from-devops-agent-chat"></a>

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

示例：
+ “列出我的测试资料”
+ “运行测试配置文件 my-test-profile”
+ “在我的应用程序上运行发布测试https://staging.myapp.com并验证付款流程”

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

## 在您的 IDE 中运行测试
<a name="running-tests-from-your-ide"></a>

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

首先，安装 [ Kiro 电源]()或 [ Claude Code 插件。]()
+ 指定描述要验证的内容的测试要求或意图（例如，“验证身份验证重构后登录流程是否有效”）
+ 编码代理将测试意图和目标测试配置文件传递给发布测试代理
+ 发布测试代理生成并执行测试，然后将结果报告回来
+ 如果发现问题，编码代理会主动提出将其修复到位

**注意：目前不支持针对直接来自 IDE 的拉取请求**进行测试。使用带有已部署应用程序 URL 的测试配置文件，并提供测试要求以集中测试。

## CI/CD 管道中的发布测试
<a name="release-testing-in-cicd-pipelines"></a>

### GitHub 行动
<a name="github-actions"></a>

该`aws-actions/devops-agent-release-testing@v1` GitHub 操作在部署后触发发布测试代理，并将结果报告为提交或拉取请求的 GitHub Check Run。

#### 先决条件
<a name="prerequisites"></a>
+ 在代理空间中[配置的](#defining-test-profiles)测试配置文件
+ 在您的代理空间中[通过 Webhook 调用 DevOps 代理](configuring-integrations-and-knowledge-invoking-devops-agent-through-webhook.md)配置的

#### 第 1 步：配置 GitHub 仓库密钥
<a name="step-1-configure-github-repository-secrets"></a>

在您的 GitHub 仓库中，转到**设置 → 密钥和变量 → 操作 → 存储库密钥**并添加：


| Secret | 说明 | 
| --- | --- | 
| DEVOPS\_AGENT\_WEBHOOK\_URL | 来自代理空间的 webhook URL | 
| DEVOPS\_AGENT\_WEBHOOK\_SECRET | 来自代理空间的 webhook 签名密钥 | 

有关创建 webhook 端点的信息，请参阅[通过 Webhook 调用 DevOps 代理](configuring-integrations-and-knowledge-invoking-devops-agent-through-webhook.md)。

#### 第 2 步：将操作添加到您的工作流程中
<a name="step-2-add-the-action-to-your-workflow"></a>

将发布测试步骤添加到您的工作流程中（例如，`.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`输入是可选的——使用它可以让代理专注于特定区域（例如，“重构身份验证后验证登录流程”）。

#### 操作输入
<a name="action-inputs"></a>


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

#### 所需的工作流程权限
<a name="required-workflow-permissions"></a>


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

#### 工作原理
<a name="how-it-works"></a>

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

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

1. 该操作会签署并向您的代理空间发送一个 webhook。

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

1. 结果以 GitHub 检查运行的形式报告（pass/fail 包含详细摘要）。

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

## 查看测试结果
<a name="reviewing-test-results"></a>

测试结果显示在 DevOps Agent Web 应用程序的 ** “**发布” 部分的拟议更改下。每次测试都会显示：
+ **状态 **-已完成、失败或进行中
+ **类别 ** — 发布测试
+ **持续时间 ** — 测试运行花了多长时间
+ **来源 ** — 无论是手动触发、通过聊天触发还是通过 CI/CD 管道触发

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