---
title: "事件驱动测试自动化"
language: "zh"
url: "https://docs.testany.io/zh/docs/event-driven-testing-automation/"
markdown_url: "https://docs.testany.io/zh/docs/event-driven-testing-automation.md"
translation: "https://docs.testany.io/en/docs/event-driven-testing-automation.md"
last_updated: "2026-03-03T14:24:54+08:00"
---

# 事件驱动测试自动化

## 将任何事件转化为自动化质量保障

现代软件系统不是孤立运行的——它们需要响应部署、告警、事件和外部服务变更。您的测试策略也应如此。**事件驱动测试自动化**将您的QA流程从手动把关转变为智能响应系统，在正确的时间触发正确的测试。

Testany 通过三个集成组件提供完整的事件驱动测试生态系统：

| 组件 | 方向 | 用途 |
|-----------|-----------|---------|
| **门卫** | Webhook 接入 | 接收外部事件，自动触发测试 |
| **计划** | 定时调度 | 基于时间的周期性测试执行 |
| **Webhook Dispatch** | Webhook 发出 | 将测试结果发送到下游系统 |

本指南将向您展示如何组合这些组件，构建完全自动化的测试工作流，响应真实世界的事件——无需人工干预。

**适合阅读本指南的人员：**
- 将测试集成到 CI/CD 流水线的 DevOps 工程师
- 设计自动化测试策略的 QA 负责人
- 构建事件驱动质量系统的平台架构师
- 实施事件驱动诊断的运维团队

---

## Testany 事件驱动生态系统

### 理解三大支柱

Testany 的事件驱动架构建立在三个相互补充的组件之上，它们协同工作以创建完整的自动化循环：

**1. 门卫（Webhook 接入）**

门卫接收来自外部系统的 Webhook 并触发测试流水线执行。当您的 CI/CD 系统部署代码、监控系统检测到异常、或第三方服务报告问题时，门卫会自动启动相应的测试。

主要功能：
- 接收来自任何支持 HTTP 的系统的 Webhook
- 触发预定义的测试流水线
- 处理来自 CI/CD、监控、第三方服务状态页等的事件

**2. 计划（定时执行）**

计划提供基于时间的测试调度，用于周期性质量检查。用于夜间回归套件、每小时健康检查或每周安全扫描——这些测试应按可预测的节奏运行，不受外部事件影响。

主要功能：
- Cron 风格调度（每小时、每天、每周、自定义）
- 每个计划可包含多个测试流水线
- 一致的执行时间，便于合规和审计

**3. Webhook Dispatch（Webhook 发出）**

Webhook Dispatch在执行完成后将测试结果发送到下游系统。将结果路由到 Slack 进行团队通知、Jira 创建工单、PagerDuty 进行升级，或任何接受 Webhook 的系统。

主要功能：
- 可按计划或门卫配置
- 结构化 JSON 载荷，包含完整执行详情
- 支持任何兼容 Webhook 的端点

### 架构概览

下图展示了这些组件如何协同工作：

![事件驱动测试架构](https://docs.testany.io/docs/images/zh/event-driven-architecture.svg)

**事件流程：**

1. **事件源** → 外部系统产生事件（部署、告警、命令、状态变更）
2. **门卫** → 接收 Webhook 并触发相应的测试流水线
3. **计划** → 或者，定时计划按定义的间隔触发测试
4. **测试引擎** → 执行配置的测试流水线
5. **Webhook Dispatch** → 将结果发送到下游通知和工单系统

### 完整事件生命周期

Testany 中的每次测试执行都遵循以下生命周期：

1. **事件接收**：门卫接收传入的 Webhook 或计划在预定时间触发
2. **验证**：验证触发器并匹配到配置的测试流水线
3. **管道触发**：匹配的管道进入执行队列
4. **测试执行**：测试用例在配置的运行时上运行
5. **结果处理**：编译执行结果并确定状态
6. **结果分发**：配置的 Webhook 接收执行载荷
7. **下游操作**：外部系统处理结果（通知、工单、升级）

---

## Testany 与传统 CI/CD 测试的对比

### 范式转变

传统 CI/CD 测试遵循"构建后测试"模式：代码提交、构建、然后按顺序测试。虽然对代码变更验证有效，但这种方法有局限性：

- **触发源有限**：测试仅在代码提交时运行
- **无运维集成**：监控告警不会触发诊断测试
- **结果孤立**：测试结果仅停留在 CI 仪表板中
- **人工事件响应**：生产问题需要人工干预才能启动测试

Testany 实现了**事件驱动持续测试**：测试响应任何系统事件，而不仅仅是代码变更。您的监控告警可以触发诊断测试，第三方依赖状态变更可以触发集成验证，未来还将支持 ChatOps 命令启动测试。

### 功能对比

| 能力 | 传统 CI/CD | Testany 事件驱动 |
|------------|-------------------|----------------------|
| **触发源** | 仅代码提交 | 任何 Webhook 事件 |
| **监控集成** | 需要单独工具链 | 通过门卫原生支持 |
| **事件响应** | 人工启动测试 | 自动触发诊断 |
| **ChatOps** | 依赖插件，配置复杂 | 可通过门卫 Webhook 集成（原生支持规划中） |
| **定时测试** | Cron 作业，与 CI 分离 | 集成的计划功能 |
| **结果分发** | 仅 CI 仪表板 | 任何 Webhook 端点 |
| **第三方依赖** | 无标准方法 | Statuspage Webhook 集成 |

### 何时使用各种方法

**使用 CI/CD 测试：**
- 构建验证
- 与代码变更相关的单元和集成测试
- 合并前质量门禁

**使用 Testany 事件驱动测试：**
- 部署后冒烟测试
- 生产健康监控
- 告警触发的诊断
- 定时回归和合规测试
- 第三方依赖验证
- 按需 ChatOps 测试（需自行集成，原生支持规划中）

这两种方法是互补的。许多团队使用 CI/CD 进行部署前测试，使用 Testany 进行生产阶段和运维测试。

---

## 选择触发策略

### 决策框架

使用此决策树选择正确的触发机制：

![触发策略决策树](https://docs.testany.io/docs/images/zh/trigger-decision-tree.svg)

**何时使用计划（定时）：**
- 测试应按一致的间隔运行
- 没有外部事件启动需求
- 合规或审计要求定期测试
- 您需要可预测的执行时间用于报告

**何时使用门卫（事件驱动）：**
- 测试应响应外部系统事件
- 时机取决于事件发生的时间
- 您需要在变更后获得即时反馈
- 测试作为诊断或验证工具

### 场景选择矩阵

| 场景 | 计划 | 门卫 | 原因 |
|----------|:----:|:----------:|-----------|
| 夜间回归套件 | ✓ | | 可预测的调度，全面覆盖 |
| 部署后冒烟测试 | | ✓ | 每次部署后即时验证 |
| 每小时生产健康检查 | ✓ | | 固定间隔的持续监控 |
| 告警触发的诊断 | | ✓ | 响应监控异常 |
| ChatOps 按需测试 | | ✓ | 通过 Slack/Teams 命令团队发起（需自行集成，原生支持规划中） |
| 每周安全合规扫描 | ✓ | | 具有一致时间的审计跟踪 |
| 第三方服务状态变更 | | ✓ | 依赖变更时验证集成 |
| 发布前回归 | ✓ | | 发布窗口前的定时门禁 |

### 组合触发器

许多测试策略结合两种方法：

- **每日计划**用于全面回归 + **门卫**用于部署验证
- **每小时计划**用于健康检查 + **门卫**用于事件诊断
- **每周计划**用于安全扫描 + **门卫**用于漏洞告警

---

## 端到端工作流场景

本节介绍五个完整的工作流，展示 Testany 的事件驱动能力。每个工作流包含架构图和配置示例。

### 场景 1：CI/CD 流水线集成

**用例**：在代码部署到测试环境或生产环境后，自动触发冒烟测试。

**流程**：代码推送 → CI/CD 部署 → 门卫 Webhook → Testany 测试 → Webhook Dispatch → 团队通知

![CI/CD 集成工作流](https://docs.testany.io/docs/images/zh/workflow-cicd.svg)

#### 触发即忘模式

触发即忘模式是最简单的集成方式：CI/CD 流水线触发测试后立即继续执行，不等待测试结果。测试结果通过 Webhook Dispatch 异步通知团队。

**Jenkins 实现：**

使用 [HTTP Request 插件](https://plugins.jenkins.io/http_request/)：

```groovy
pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                sh 'deploy.sh'
            }
        }
        stage('Trigger Testany Tests') {
            steps {
                httpRequest(
                    // 国际版: https://<tenant_name>.testany.io/api/v2/gatekeeper/webhook/...
                    // 中国版: https://<tenant_name>.testany.com.cn/api/v2/gatekeeper/webhook/...
                    url: 'https://<YOUR_TENANT>.testany.io/api/v2/gatekeeper/webhook/YOUR_GATEKEEPER_TOKEN',
                    httpMode: 'POST',
                    contentType: 'APPLICATION_JSON',
                    requestBody: '{"source": "jenkins", "environment": "staging"}'
                )
            }
        }
    }
}
```

**GitHub Actions 实现：**

```yaml
name: Deploy and Test
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to staging
        run: ./deploy.sh

      - name: Trigger Testany smoke tests
        # 国际版 URL: https://<tenant_name>.testany.io/...
        # 中国版 URL: https://<tenant_name>.testany.com.cn/...
        run: |
          curl -X POST "${{ secrets.TESTANY_BASE_URL }}/api/v2/gatekeeper/webhook/${{ secrets.TESTANY_GATEKEEPER_TOKEN }}" \
               -H "Content-Type: application/json" \
               -d '{"source": "github-actions", "environment": "staging", "commit": "${{ github.sha }}"}'
```

**Webhook Dispatch配置：**

在门卫上配置 Webhook Dispatch，以便在测试完成时通知 Slack 团队。有关设置详情，请参阅[管理 Testany 通知](https://docs.testany.io/zh/docs/introduction-of-testany-notifications.md)。

**其他 CI/CD 平台：**
- **GitLab CI**：在 `.gitlab-ci.yml` 中使用 `curl`
- **Azure DevOps**：使用 [InvokeRESTAPI 任务](https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/invoke-rest-api-v1)
- **CircleCI**：在 `run` 步骤中使用 `curl`

#### CI/CD 质量门禁模式

上述示例使用"触发即忘"的方式——流水线触发测试后继续执行，无需等待结果。对于**质量门禁**场景，流水线需要阻塞直到测试通过/失败，请使用 Testany 的 Webhook 回调机制。

**工作原理：**

1. CI/CD 流水线通过门卫触发测试
2. 流水线在指定端点等待回调
3. 测试完成时，Testany 的 Webhook Dispatch将结果发送到该端点
4. 流水线根据测试结果决定继续或失败

**Jenkins 实现（Webhook 回调）：**

```groovy
pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                sh 'deploy.sh'
            }
        }
        stage('Trigger Testany Tests with Quality Gate') {
            steps {
                script {
                    // 使用 Jenkins 的 Webhook 触发器创建唯一的回调 URL
                    def callbackUrl = "${env.JENKINS_URL}generic-webhook-trigger/invoke?token=${env.BUILD_TAG}"

                    // 触发 Testany，在载荷中包含回调 URL
                    httpRequest(
                        url: 'https://<YOUR_TENANT>.testany.io/api/v2/gatekeeper/webhook/YOUR_GATEKEEPER_TOKEN',
                        httpMode: 'POST',
                        contentType: 'APPLICATION_JSON',
                        requestBody: """{"source": "jenkins", "environment": "staging", "callback_id": "${env.BUILD_TAG}"}"""
                    )
                }
            }
        }
        stage('Wait for Test Results') {
            steps {
                // 等待 Testany 的 Webhook 回调
                // 配置 Testany Webhook Dispatch回调到 Jenkins
                timeout(time: 30, unit: 'MINUTES') {
                    waitForWebhook(hookUrl: 'testany-result-hook')
                }
            }
        }
        stage('Evaluate Quality Gate') {
            steps {
                script {
                    // 解析 Webhook 载荷以确定通过/失败
                    // status: 1 = 通过, 2 = 失败, 3 = 阻塞
                    def testStatus = readJSON(text: env.WEBHOOK_PAYLOAD).status
                    if (testStatus != 1) {
                        error("质量门禁失败: 测试状态 = ${testStatus}")
                    }
                    echo "质量门禁通过!"
                }
            }
        }
    }
}
```

**GitHub Actions 实现（Webhook 回调）：**

对于 GitHub Actions，使用 `repository_dispatch` 事件和回调端点的组合：

```yaml
name: Deploy with Quality Gate
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to staging
        run: ./deploy.sh

      - name: Trigger Testany smoke tests
        run: |
          curl -X POST "${{ secrets.TESTANY_BASE_URL }}/api/v2/gatekeeper/webhook/${{ secrets.TESTANY_GATEKEEPER_TOKEN }}" \
               -H "Content-Type: application/json" \
               -d '{"source": "github-actions", "environment": "staging", "run_id": "${{ github.run_id }}"}'

      - name: Wait for test results
        id: wait-for-results
        uses: peter-evans/wait-for-check@v3
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          sha: ${{ github.sha }}
          check-name: 'testany-quality-gate'
          timeout: 1800  # 30 分钟

      - name: Quality Gate Decision
        run: |
          if [ "${{ steps.wait-for-results.outputs.conclusion }}" != "success" ]; then
            echo "质量门禁失败!"
            exit 1
          fi
          echo "质量门禁通过!"
```

**质量门禁的 Webhook Dispatch配置：**

配置门卫的 Webhook Dispatch以回调到您的 CI/CD 系统：

1. 导航到门卫的**结果通知**部分
2. 添加指向 CI/CD 回调端点的 Webhook Dispatch：
   - **Jenkins**：使用 Generic Webhook Trigger 插件 URL
   - **GitHub Actions**：使用 GitHub App Webhook 或 `repository_dispatch` 端点
   - **GitLab CI**：使用流水线触发器 token URL
3. Webhook 载荷包含 `status` 字段（1=通过，2=失败，3=阻塞）

**载荷状态值：**

| 状态 | 含义 | 质量门禁操作 |
|--------|---------|---------------------|
| 1 | 通过 | 继续流水线 |
| 2 | 失败 | 阻断/失败流水线 |
| 3 | 阻塞 | 阻断/失败流水线 |

有关完整载荷结构，请参阅[理解通知 Webhook 的载荷](https://docs.testany.io/zh/docs/understanding-the-payload-of-a-notification-webhoo.md)。


> **备注**
>
> Testany 使用 Webhook 回调实现同步等待。没有用于查询执行状态的轮询 API——您的 CI/CD 系统必须等待 Webhook 回调，而不是反复检查结果。


---

### 场景 2：监控系统集成

**用例**：当监控检测到异常（错误率上升、延迟增加）时，自动触发诊断测试以帮助快速定位问题。

**流程**：监控告警 → 门卫 Webhook → 诊断测试 → Webhook Dispatch → 事件管理

![监控集成工作流](https://docs.testany.io/docs/images/zh/workflow-monitoring.svg)

**Splunk 实现：**

1. 在 Splunk 中创建检测异常条件的业务查询。

   ![Splunk 查询](https://docs.testany.io/docs/images/zh/image-20240114-125102_42b8936f.png)

2. 将搜索保存为具有适当触发条件的告警。

   ![Splunk 告警](https://docs.testany.io/docs/images/zh/image-20240114-125201_27ffde9c.png)

3. 配置告警操作使用 Webhook，粘贴您的 Testany 门卫 URL。

   ![Splunk Webhook](https://docs.testany.io/docs/images/zh/image-20240114-130138_3fa6b20b.png)

4. 保存并启用告警。

**Webhook Dispatch配置：**

配置 Webhook Dispatch将测试结果发送到 PagerDuty 或您的事件管理系统。当测试识别出根本原因时，响应者可立即获得诊断信息。

**其他监控平台：**
- **Datadog**：[Webhooks Integration](https://docs.datadoghq.com/integrations/webhooks/)
- **Dynatrace**：[Problem Notifications - Webhook](https://docs.dynatrace.com/docs/observe-and-explore/notifications-and-alerting/problem-notifications/webhook-integration)
- **Prometheus + Alertmanager**：[Webhook Config](https://prometheus.io/docs/alerting/latest/configuration/#webhook_config)
- **New Relic**：使用 Webhook 通知渠道

---

### 场景 3：定时回归与升级

**用例**：按每日计划运行全面回归测试，在失败时自动升级。

**流程**：计划调度 → 回归套件 → Webhook Dispatch → [邮件 + Jira + Slack]

![定时回归工作流](https://docs.testany.io/docs/images/zh/workflow-scheduled.svg)

**实现：**

1. **创建计划**，设置每日调度（例如 UTC 02:00）

2. **添加回归测试流水线**到计划

3. **配置多个 Webhook Dispatch端点：**

   - **Slack**：团队通知频道，即时可见
   - **Jira**：为失败自动创建缺陷工单（使用 Jira 的 Webhook 到工单自动化）
   - **邮件**：发送摘要给相关方

**计划配置：**

导航到计划 → 创建计划并配置：
- 调度：每日 UTC 02:00
- 管道：选择您的回归测试流水线
- 通知：为每个目标配置 Webhook Dispatch

有关详细设置说明，请参阅[管理测试计划](https://docs.testany.io/zh/docs/managing-test-plan.md)。

**Webhook 载荷处理：**

您的下游系统可以解析 Webhook 载荷以采取适当操作。例如，Jira 自动化规则可以：
- 如果 `status === 2`（失败）则创建缺陷
- 在描述中包含失败的测试用例名称
- 分配给管道所有者

有关载荷结构详情，请参阅[理解通知 Webhook 的载荷](https://docs.testany.io/zh/docs/understanding-the-payload-of-a-notification-webhoo.md)。

---

### 场景 4：ChatOps 驱动的测试（规划中）


> **说明**
>
> 此功能目前处于规划阶段。如果您对此功能感兴趣，请联系我们的产品团队提交需求。


**愿景**：允许团队成员通过 Slack/Teams 命令触发测试，无需登录 Testany。

**预期流程**：Slack 命令 → 门卫 Webhook → API 测试 → Webhook Dispatch → Slack 结果

**当前替代方案**：

在 ChatOps 原生集成推出之前，您可以通过以下方式实现类似效果：

1. **使用 Slack Workflow Builder + Webhook**：
   - 创建 Slack Workflow，配置触发器（如 emoji 反应或快捷方式）
   - 在 Workflow 中添加"发送 Webhook"步骤，调用 Testany 门卫 URL
   - 这样团队成员可以通过简单操作触发测试

2. **使用外部自动化工具**：
   - 通过 Zapier、Make (Integromat) 或 n8n 连接 Slack 与 Testany
   - 配置触发条件和 Webhook 调用

3. **自定义 Bot**：
   - 开发自定义 Slack/Teams Bot，监听特定命令
   - Bot 收到命令后调用 Testany 门卫 Webhook

---

### 场景 5：第三方依赖监控

**用例**：当第三方服务（支付网关、短信提供商、云存储）出现问题时，自动运行集成测试以评估对您系统的影响。

**流程**：Statuspage 告警 → 门卫 Webhook → 集成测试 → Webhook Dispatch → Teams 通知

![依赖监控工作流](https://docs.testany.io/docs/images/zh/workflow-dependency.svg)

**Statuspage 实现：**

1. **创建门卫**，配置与第三方服务相关的集成测试流水线

2. **登录服务的 Statuspage**（例如 [Stripe Status](https://status.stripe.com/)）

3. **添加 Webhook 订阅者：**
   - 进入 **Subscribers** → **Webhook Subscribers** → **Add Subscriber**
   - **Endpoint URL**：粘贴您的门卫 Webhook URL
   - **Components**：选择要监控的组件

4. **配置 Webhook Dispatch**通过 Microsoft Teams 通知您的团队

**常见的第三方服务 Statuspage：**
- [AWS Status](https://health.aws.amazon.com/health/status)
- [Stripe Status](https://status.stripe.com/)
- [Twilio Status](https://status.twilio.com/)
- [GitHub Status](https://www.githubstatus.com/)

**主动影响评估：**

当 Stripe 报告性能下降时，您的支付集成测试会自动运行。您的团队可以在客户报告问题之前了解您的系统是否受到影响。

---

## 实施指南

### 设置门卫

1. 导航到您的工作区 → **门卫**部分
2. 点击**创建门卫**并提供名称
3. 复制生成的 Webhook URL
4. 添加要触发的测试流水线
5. 配置 Webhook Dispatch用于结果通知
6. 记录触发条件供团队参考

有关详细设置说明，请参阅[管理测试门卫](https://docs.testany.io/zh/docs/managing-test-gatekeeper.md)。

### 配置计划

1. 导航到您的工作区 → **计划**部分
2. 点击**添加计划**并提供名称
3. 配置调度（时间、重复模式）
4. 选择要执行的测试流水线
5. 配置 Webhook Dispatch用于结果通知
6. 查看即将执行的时间以验证调度

有关详细设置说明，请参阅[管理测试计划](https://docs.testany.io/zh/docs/managing-test-plan.md)。

### 设置 Webhook Dispatch

计划和门卫都支持 Webhook Dispatch配置：

1. 打开您的计划或门卫详情页面
2. 导航到**结果通知**部分
3. 点击 **Webhook Dispatch**标签
4. 点击 **+** 添加新的 Webhook
5. 提供：
   - 应用名称（例如 "Slack"、"Jira"）
   - 用于识别的 Webhook 名称
   - 从目标系统获取的 Webhook URL
6. 保存配置

有关详细设置说明，请参阅[管理 Testany 通知](https://docs.testany.io/zh/docs/introduction-of-testany-notifications.md)。

有关载荷结构详情，请参阅[理解通知 Webhook 的载荷](https://docs.testany.io/zh/docs/understanding-the-payload-of-a-notification-webhoo.md)。

---

## 高级模式

### 级联测试链

通过使用一个触发器的 Webhook Dispatch激活另一个门卫，连接多个测试阶段：

**示例：部署 → 冒烟 → 完整回归**

1. **门卫 A**：接收部署 Webhook，运行冒烟测试
2. **Webhook Dispatch A**：成功时调用门卫 B
3. **门卫 B**：运行完整回归套件
4. **Webhook Dispatch B**：通知团队最终结果

此模式支持渐进式测试，昂贵的回归套件仅在冒烟测试通过后运行。

### 多环境测试

为不同环境配置多个门卫：

- **门卫-测试环境**：触发测试环境测试，使用测试环境凭证
- **门卫-生产环境**：触发生产环境测试，使用生产环境凭证

您的 CI/CD 流水线根据部署目标调用相应的门卫。

### 条件通知路由

战略性地使用 Webhook Dispatch：

- **所有结果**：发送到日志/审计系统
- **仅失败**：发送到 PagerDuty/事件管理
- **仅成功**：发送到部署自动化以继续下一阶段

在 Webhook Dispatch设置中按接收者配置通知偏好。

---

## 最佳实践

### 门卫命名规范

使用描述性名称，指示触发源和测试目的：
- `cicd-staging-smoke` - 由 CI/CD 触发的测试环境冒烟测试
- `monitor-api-diagnostic` - 由监控触发的 API 诊断
- `statuspage-payment-check` - 由第三方状态页触发的支付检查

### 计划调度策略

- **非高峰时段**：在低流量时段安排资源密集型测试
- **时区**：在为人工审查安排时考虑团队位置
- **错开执行**：避免同时安排多个重型计划
- **缓冲时间**：在计划之间留出足够的完成时间

### Webhook 可靠性

- **验证 URL**：在生产使用前测试 Webhook 端点
- **监控投递**：检查 Webhook Dispatch日志是否有失败
- **实现重试**：Testany 对失败的 Webhook 重试 3 次
- **处理超时**：Webhook 在 15 秒后超时——确保端点快速响应

### 文档和维护

- **记录触发条件**：记录每个门卫由什么事件触发
- **定期审查**：每季度审计计划和门卫
- **更新管道**：保持触发的管道与当前测试需求一致
- **归档未使用的**：删除不再需要的门卫/计划

---

## 故障排除

### 常见问题

| 问题 | 可能原因 | 解决方案 |
|-------|----------------|----------|
| 门卫未触发 | Webhook URL 无效 | 验证 URL 是否正确复制 |
| | 防火墙阻止 | 检查网络规则是否允许 Testany IP |
| 计划未执行 | 调度错误 | 验证时区和 cron 表达式 |
| Webhook Dispatch失败 | 端点 URL 无效 | 使用手动 POST 请求测试 URL |
| | 端点超时 | 确保端点在 15 秒内响应 |
| | SSL 证书问题 | 验证证书链是否有效 |

### 调试步骤

1. **检查门卫/计划日志**：在 Testany 中查看执行历史
2. **手动测试 Webhook**：使用 curl 验证端点连通性
3. **审查载荷格式**：确保下游系统正确解析 JSON
4. **检查权限**：验证门卫/计划所有者具有所需访问权限

---

## 快速参考

### 关键 URL

| 资源 | URL 模式 |
|----------|-------------|
| 门卫 Webhook（国际版） | `https://<tenant_name>.testany.io/api/v2/gatekeeper/webhook/{TOKEN}` |
| 门卫 Webhook（中国版） | `https://<tenant_name>.testany.com.cn/api/v2/gatekeeper/webhook/{TOKEN}` |


> **备注**
>
> 请将 `<tenant_name>` 替换为您的租户名称，`{TOKEN}` 替换为门卫 Webhook Token（hook token），不是门卫密钥。


### 相关文档

- [管理测试门卫](https://docs.testany.io/zh/docs/managing-test-gatekeeper.md) - 完整的门卫设置指南
- [管理测试计划](https://docs.testany.io/zh/docs/managing-test-plan.md) - 计划配置详情
- [管理测试流水线](https://docs.testany.io/zh/docs/managing-test-pipeline.md) - 管道配置
- [管理 Testany 通知](https://docs.testany.io/zh/docs/introduction-of-testany-notifications.md) - Webhook Dispatch设置
- [理解通知 Webhook 的载荷](https://docs.testany.io/zh/docs/understanding-the-payload-of-a-notification-webhoo.md) - 载荷结构

### 总结

Testany 的事件驱动测试生态系统结合了**门卫**（Webhook 接入）、**计划**（定时）和 **Webhook Dispatch**（Webhook 发出），创建完全自动化的测试工作流。这种方法将测试从手动把关转变为智能系统：

- 响应真实世界的事件，而不仅仅是代码变更
- 与您现有的 DevOps 工具链集成
- 将结果分发到任何下游系统
- 无需人工干预持续运行

从单个集成开始——CI/CD 部署后测试通常是最简单的第一步——随着您看到自动化、响应式质量保障的好处，逐步扩展您的事件驱动测试策略。

## 本页术语

- [门卫 (Gatekeeper)](https://docs.testany.io/zh/docs/glossary.md#gatekeeper)
- [计划任务 (Plan)](https://docs.testany.io/zh/docs/glossary.md#plan)
- [测试执行 (Test Execution)](https://docs.testany.io/zh/docs/glossary.md#test-execution)
- [Webhook Dispatch](https://docs.testany.io/zh/docs/glossary.md#webhook-dispatch)
- [测试流水线 (Test Pipeline)](https://docs.testany.io/zh/docs/glossary.md#test-pipeline)
- [执行 (Execution)](https://docs.testany.io/zh/docs/glossary.md#execution)
- [命令 (Command)](https://docs.testany.io/zh/docs/glossary.md#command)
- [测试用例 (Test Case)](https://docs.testany.io/zh/docs/glossary.md#test-case)
- [运行时 (Runtime)](https://docs.testany.io/zh/docs/glossary.md#runtime)
- [环境 (Environment)](https://docs.testany.io/zh/docs/glossary.md#environment)
- [订阅 (Subscription)](https://docs.testany.io/zh/docs/glossary.md#subscription)
- [工作区 (Workspace)](https://docs.testany.io/zh/docs/glossary.md#workspace)
- [计划所有者 (Plan Owner)](https://docs.testany.io/zh/docs/glossary.md#plan-owner)