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

# 发布测试
<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. 在 A DevOps gent Web 应用程序中，导航到左侧导航栏中的**版本管理器**。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 从 IDE 运行测试
<a name="running-tests-from-your-ide"></a>

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

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

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

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

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

Acti `aws-actions/devops-agent-release-testing@v1` GitHub on 会在部署后触发发布测试代理，并在提交或拉取请求时以 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 网址 | 
| DEVOPS\_AGENT\_WEBHOOK\_SECRE | 来自 Agent Space 的 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 网址 | 
| 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 Check Run 的形式报告（pass/fail 附有详细摘要）。

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

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

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

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