安全范围： 本指南仅适用于你自有或经授权的 QA、staging 与预发布环境。内容覆盖针对你自己 CAPTCHA 集成的诊断、测试与可观测性模式 — 不涉及第三方站点或未授权流程。
checkout 的 CAPTCHA 配置错了，大概率是大促当天流量涌进来才被发现——那时再排查已经晚了。
更稳妥的做法是挪到发布之前：在自有 staging 环境里，用虚拟商品和测试支付 token 把 checkout 链路连同 CAPTCHA 校验一起跑一遍。下面用 CaptchaAI 演示做法，全程不接触真实商店或真实支付。
测试范围与边界
- 仅限自有或经授权的 e-commerce QA 场景。
- staging 环境中的 checkout 集成测试。
- 自有 checkout 表单的 CAPTCHA 冒烟测试。
- 虚拟库存、虚拟商品、测试支付 token。
- 内部 endpoint 上的会话连续性测试。
- 不模拟真实购买，不涉及第三方商店。
为什么要在上线前测
国内电商的大促节点（双 11、618）和海外的限时发售，共性是 checkout 峰值流量集中在极短时间。CAPTCHA 响应变慢、token 校验失败率升高，往往只有真实流量打过来才暴露，那时已没有回滚余地。
把 CAPTCHA 集成排进 staging 压测清单，提前揪出 sitekey 配错、token 时效不对这类问题，是不少 QA 团队的标准动作。
搭建 staging checkout 环境
尽量复制生产架构：把 checkout 前端和订单后端一起部署到 https://staging.example.com/checkout-test，配一个带虚拟 SKU 的独立数据库副本，支付网关切到 sandbox 模式。国内网络环境下搭这套环境，装依赖时用国内镜像（比如 pip install -i https://pypi.tuna.tsinghua.edu.cn/simple requests）能省不少等待时间。
构造虚拟商品与测试支付数据
先准备好测试数据，不要用任何真实 SKU 或真实支付信息：
FAKE_PRODUCTS = [
{'sku': 'QA-SKU-001', 'price_cents': 9900, 'stock': 1000},
{'sku': 'QA-SKU-002', 'price_cents': 19900, 'stock': 500},
]
FAKE_PAYMENT_TOKEN = 'qa_pm_token_demo'
STAGING_CHECKOUT = 'https://staging.example.com/checkout-test'
用 CaptchaAI 提交任务
有了测试数据，接下来在自有 staging checkout 上触发 Turnstile 校验，用 CaptchaAI 拿到可提交的 token：
import os, time, requests
API_KEY = os.environ['CAPTCHAAI_API_KEY']
SITEKEY = os.environ['QA_TURNSTILE_SITEKEY']
def solve_turnstile():
r = requests.post('https://ocr.captchaai.com/in.php', data={
'key': API_KEY,
'method': 'turnstile',
'sitekey': SITEKEY,
'pageurl': STAGING_CHECKOUT,
'json': 1,
}).json()
task_id = r['request']
while True:
time.sleep(5)
rr = requests.get('https://ocr.captchaai.com/res.php', params={
'key': API_KEY, 'action': 'get', 'id': task_id, 'json': 1,
}).json()
if rr['status'] == 1:
return rr['request']
在自有 QA endpoint 校验 token
把上一步拿到的 token 以 cf-turnstile-response 字段提交到内部订单 endpoint（https://staging.example.com/qa-checkout）。
QA endpoint 负责校验 token、核对虚拟 SKU，再回一个模拟订单号——这一步验证的是你自己后端的校验逻辑，跟 CaptchaAI 无关。
记录关键指标
给每个 qa_case_id 记下：求解耗时（秒）、后端返回码、端到端时延、重试次数。
汇总中位数、P90、P99 和成功率——这些数字只对你自己的 staging 环境有参考价值，不是生产承诺。
可观测性与链路追踪
给每次 QA 运行打上结构化日志，采集 token 总耗时、HTTP 响应码、任务编号、队列深度。development、staging、pre-production 走独立日志通道，再用 OpenTelemetry 之类的链路追踪串起 correlation id，方便凭一个 id 重放整个场景排查问题。
常见故障与处理
| 问题 | 处理方式 |
|---|---|
| 测试找不到 widget | 检查 staging 环境中的选择器与等待时机 |
CaptchaAI 返回 ERROR_NO_SLOT_AVAILABLE |
在内部 pipeline 中按指数退避重试 |
| 后端 QA 拒绝 token | 对照真实配置核对 action / sitekey / secret |
| 端到端时延偏高 | 在自有环境中重新测量并检查内部网络抖动 |
上线前检查清单
- 测试范围限定在自有或经授权的资源。
- CaptchaAI key 存放在 CI secret 或 vault，不进源代码。
- 记录每次调用耗时与响应状态码。
- 为瞬时错误配置幂等重试与上限。
- 测试能在 CI 中可复现地重复运行。
完整示例：一次 QA 调用
下面这段 Python 示例展示了在自有 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 或你自己的 QA 域名，请在 staging 副本里复现生产配置。
API key 能写在代码里吗？
不能。用 CI secret 管理器或 vault 注入；已提交进仓库的 key 要立即轮换。
瞬时错误怎么重试？
指数退避（1s、2s、4s）加上限。网络错误、5xx、ERROR_NO_SLOT_AVAILABLE 适合重试；鉴权错误重试没用。
只能测 Turnstile 吗？
不是，method 换成 userrecaptcha 或 geetest，配对应 sitekey / gt 参数，同样能测 reCAPTCHA v2、v3 和 GeeTest v3。
相关阅读
- CaptchaAI 快速入门
- 授权 CAPTCHA QA 测试
- 自有表单的 CAPTCHA endpoint 测试
- 浏览器测试失败但 API 测试通过的调试
- 用 API 解决 reCAPTCHA v2
- 用 API 解决 Cloudflare Turnstile
- 用 API 解决 GeeTest v3
把这套流程接进你的 CI，用 CaptchaAI 在每次发布前验证 checkout 的 CAPTCHA 集成。
