自有票务平台队列与 checkout 的 CAPTCHA staging 测试

安全范围： 本指南仅适用于你自有或经授权的 QA、staging 与预发布环境。内容覆盖针对你自己 CAPTCHA 集成的诊断、测试与可观测性模式 — 不涉及第三方站点或未授权流程。

活动开票前，你的票务系统经得起真实并发的考验吗？把 CAPTCHA 测试直接放到生产环境验证风险太高——一次配置错误就可能锁死正式队列。更稳妥的做法是在 staging 环境用虚拟活动、测试座位和模拟支付，把队列进入与 checkout 的 CAPTCHA 集成走一遍。以下是一套可直接复用的 QA 方案，全程不触碰真实门票或第三方平台。

测试边界先说清楚

• 仅测试自有或经授权的票务平台，不涉及第三方站点。
• 全程使用虚拟活动、测试座位、虚拟门票和模拟支付 token。
• 只验证内部队列与 QA 接口，不接触公开开售的真实队列。
• 不发生任何真实门票购买行为。

搭建虚拟队列与虚拟 checkout

复制一份队列架构放进 staging：QA 用户进入 https://staging.example.com/ticketing/queue-test 的虚拟队列并获取一个位置；slot 释放后，被引导至 https://staging.example.com/ticketing/checkout-test。虚拟活动、座位和支付 token 都用固定的测试数据，方便每次运行复现同样的场景：

FAKE_EVENT = {
    'id': 'evt_qa_001',
    'url': 'https://staging.example.com/ticketing/fake-event',
    'seats': [{'row': 'A', 'col': i, 'price_cents': 5000} for i in range(1, 21)],
}
FAKE_PAYMENT = {'token': 'qa_pm_token_demo'}

国内票务平台（如大麦网、猫眼演出）演唱会开票时也是同样的高并发排队 + CAPTCHA 集成问题，先在预发环境跑通再放量上线的思路是相通的。

从 staging 提交 CaptchaAI 任务

队列页和 checkout 页触发的 CAPTCHA 通过同一套逻辑提交给 CaptchaAI，轮询获取识别结果：

import os, requests, time
API_KEY = os.environ['CAPTCHAAI_API_KEY']

def solve_recaptcha_v2(sitekey, pageurl):
    r = requests.post('https://ocr.captchaai.com/in.php', data={
        'key': API_KEY, 'method': 'userrecaptcha',
        'googlekey': sitekey, 'pageurl': pageurl, 'json': 1,
    }).json()
    tid = r['request']
    while True:
        time.sleep(5)
        rr = requests.get('https://ocr.captchaai.com/res.php', params={
            'key': API_KEY, 'action': 'get', 'id': tid, 'json': 1,
        }).json()
        if rr['status'] == 1:
            return rr['request']

在 QA 后端校验结果

拿到 token 后提交到内部 QA 票务订单接口，后端校验 token、锁定虚拟座位，返回一个模拟订单编号 —— 不会触发任何真实门票处理。

判定 pass/fail 与可观测性

测试通过的标准很简单：token 被后端接受、虚拟座位成功锁定、端到端时延低于内部阈值。把这三项按 qa_case_id 记录下来，只作为 staging 环境的参考值。

每次 QA 运行都生成结构化日志，至少采集 token 耗时、HTTP 响应码、任务编号、队列深度。不同环境分开写入独立通道，用 correlation id（例如 OpenTelemetry）关联起来，凭一个 id 就能重放整场测试。

上线前检查清单

• 测试范围严格限定在自有应用或经授权的资源。
• CaptchaAI key 存放在 CI secret 仓库或 vault，绝不进入源代码。
• 每次运行都记录调用耗时和响应状态码。
• 为瞬时错误配置幂等的重试策略，并设置重试上限。
• 测试能在 CI 中可复现地重复运行。

完整示例：测试一个登录页 CAPTCHA

下面是在自有 staging 环境中，用 CaptchaAI 测试一个 CAPTCHA widget 的最小流程：

import os
import requests

API_KEY = os.environ['CAPTCHAAI_KEY']
QA_PAGE_URL = os.environ['QA_PAGE_URL']  # 例如 https://staging.example.com/qa-login
QA_SITE_KEY = os.environ['QA_SITE_KEY']


def submit_qa_recaptcha() -> str:
    payload = {
        'clientKey': API_KEY,
        'task': {
            'type': 'NoCaptchaTaskProxyless',
            'websiteURL': QA_PAGE_URL,
            'websiteKey': QA_SITE_KEY,
        },
    }
    response = requests.post(
        'https://api.captchaai.com/createTask',
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()['taskId']


def fetch_qa_result(task_id: str) -> dict:
    payload = {'clientKey': API_KEY, 'taskId': task_id}
    response = requests.post(
        'https://api.captchaai.com/getTaskResult',
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

故障排查

常见问题

这套测试流程会不会影响真实用户或线上库存？

不会。所有示例都假设运行在 staging.example.com 等授权环境中，虚拟座位和模拟支付不会写入生产库存。

CaptchaAI 的 API key 能直接写进代码仓库吗？

不能。请通过 CI secret 管理器、环境变量或 vault 注入，一旦 key 被提交进仓库必须立即轮换。

测试过程中遇到瞬时错误该怎么重试？

用幂等重试配合指数退避（例如 1 秒、2 秒、4 秒）并设置上限。网络错误、5xx 响应和 ERROR_NO_SLOT_AVAILABLE 适合重试，持久性的鉴权错误不应重试。

国内团队搭这套 staging 环境要注意什么？

依赖安装建议走国内镜像，例如 pip install -i https://pypi.tuna.tsinghua.edu.cn/simple，能明显减少 CI 里的下载超时；测试流程本身只跑在你自己的 staging 域名内，不依赖任何外部真实票务站点。

安全相关指南

• CaptchaAI 快速入门
• 授权 CAPTCHA QA 测试
• 自有表单的 CAPTCHA 接口测试
• 浏览器测试失败但 API 测试通过怎么排查
• 用 API 识别 reCAPTCHA v2
• 用 API 识别 Cloudflare Turnstile
• 用 API 识别 GeeTest v3

请在自有环境中使用 CaptchaAI 验证 CAPTCHA 集成。