事件驱动测试自动化

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

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

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

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

适合阅读本指南的人员：

• 将测试集成到 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 的端点

架构概览

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

事件流程：

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 事件驱动测试：

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

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

---

选择触发策略

决策框架

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

何时使用计划（定时）：

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

何时使用门卫（事件驱动）：

• 测试应响应外部系统事件
• 时机取决于事件发生的时间
• 您需要在变更后获得即时反馈
• 测试作为诊断或验证工具

场景选择矩阵

组合触发器

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

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

---

端到端工作流场景

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

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

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

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

触发即忘模式

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

Jenkins 实现：

使用 HTTP Request 插件 ↗：

GroovyCopy
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 实现：

YAMLCopy
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 通知。

其他 CI/CD 平台：

• GitLab CI：在 .gitlab-ci.yml 中使用 curl
• Azure DevOps：使用 InvokeRESTAPI 任务 ↗
• CircleCI：在 run 步骤中使用 curl

CI/CD 质量门禁模式

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

工作原理：

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

Jenkins 实现（Webhook 回调）：

GroovyCopy
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 事件和回调端点的组合：

YAMLCopy
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=阻塞）

载荷状态值：

有关完整载荷结构，请参阅理解通知 Webhook 的载荷。

---

场景 2：监控系统集成

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

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

Splunk 实现：

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

   

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

   

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

   

4. 保存并启用告警。

Webhook Dispatch配置：

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

其他监控平台：

• Datadog：Webhooks Integration ↗
• Dynatrace：Problem Notifications - Webhook ↗
• Prometheus + Alertmanager：Webhook Config ↗
• New Relic：使用 Webhook 通知渠道

---

场景 3：定时回归与升级

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

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

实现：

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

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

3. 配置多个 Webhook Dispatch端点：

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

计划配置：

导航到计划 → 创建计划并配置：

• 调度：每日 UTC 02:00
• 管道：选择您的回归测试流水线
• 通知：为每个目标配置 Webhook Dispatch

有关详细设置说明，请参阅管理测试计划。

Webhook 载荷处理：

您的下游系统可以解析 Webhook 载荷以采取适当操作。例如，Jira 自动化规则可以：

• 如果 status === 2（失败）则创建缺陷
• 在描述中包含失败的测试用例名称
• 分配给管道所有者

有关载荷结构详情，请参阅理解通知 Webhook 的载荷。

---

场景 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 通知

Statuspage 实现：

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

2. 登录服务的 Statuspage（例如 Stripe Status ↗）

3. 添加 Webhook 订阅者：

   • 进入 Subscribers → Webhook Subscribers → Add Subscriber
   • Endpoint URL：粘贴您的门卫 Webhook URL
   • Components：选择要监控的组件

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

常见的第三方服务 Statuspage：

• AWS Status ↗
• Stripe Status ↗
• Twilio Status ↗
• GitHub Status ↗

主动影响评估：

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

---

实施指南

设置门卫

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

有关详细设置说明，请参阅管理测试门卫。

配置计划

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

有关详细设置说明，请参阅管理测试计划。

设置 Webhook Dispatch

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

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

有关详细设置说明，请参阅管理 Testany 通知。

有关载荷结构详情，请参阅理解通知 Webhook 的载荷。

---

高级模式

级联测试链

通过使用一个触发器的 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 秒后超时——确保端点快速响应

文档和维护

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

---

故障排除

常见问题

调试步骤

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

---

快速参考

关键 URL

相关文档

• 管理测试门卫 - 完整的门卫设置指南
• 管理测试计划 - 计划配置详情
• 管理测试流水线 - 管道配置
• 管理 Testany 通知 - Webhook Dispatch设置
• 理解通知 Webhook 的载荷 - 载荷结构

总结

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

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

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