安全范围： 本指南仅适用于你自有或经授权的 QA、staging 与预发布环境。内容覆盖针对你自己 CAPTCHA 集成的诊断、测试与可观测性模式 — 不涉及第三方站点或未授权流程。
两个 QA 账号共用一个浏览器配置文件，测试结果很快互相污染：上一个用例的 cookie 会让下一个用例的 CAPTCHA 挑战类型悄悄变样。解法：按账号拆分独立配置文件，再用 CaptchaAI 逐个验证。
哪些状态会在配置文件之间悄悄泄漏
cookies、localStorage、sessionStorage、IndexedDB、service worker 缓存和开发者扩展都可能泄漏状态。同一个 sitekey，在“干净”和“脏”配置文件里触发的挑战类型可能完全不同——这就是 CI 里“昨天能跑，今天就挂”的常见原因。
三种常见的污染场景
- 一个场景的 cookie 泄漏到另一个场景，测试结果互相干扰。
- 多个测试账号共用一套 storage，账号状态串了台。
- CI 里同一个 profile 反复复用，状态越攒越多，失败用例无法复现。
按配置文件拆开，每次 QA 运行都能从已知、干净的状态开始。
用 Playwright 生成 QA 配置文件快照
下面这段代码为每个测试账号启动独立的持久化上下文，用例结束时把状态落盘：
from playwright.sync_api import sync_playwright
def run(profile_dir, qa_user):
with sync_playwright() as p:
ctx = p.chromium.launch_persistent_context(
user_data_dir=profile_dir, headless=True
)
page = ctx.new_page()
page.goto('https://staging.example.com/qa-form')
# ... 在此使用 CaptchaAI 验证 CAPTCHA ...
ctx.storage_state(path=f'state-{qa_user}.json')
ctx.close()
profile_dir 对应磁盘上的一个独立目录，qa_user 用来给落盘的 state 文件命名，两者组合就是一次可追溯的 QA 运行。
把 CaptchaAI 接入内部 QA 流程
每个配置文件跑同一套验证流程：检测 widget，提交给 CaptchaAI（in.php 轮询或 createTask / getTaskResult 均可），再校验 token。结果按 profile_id、qa_case_id 落库，方便回溯。国内团队常在新加坡、香港等多区域并行跑 CI 回归，按 region + qa_user 拼 profile_dir，区域间就不会互相污染。
完整示例：一次 QA 验证请求
下面这段 Python 代码展示在自有 staging 环境中，用 CaptchaAI 完成一次最小 CAPTCHA 验证的流程：
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()
常见故障排查
| 问题 | 处理方式 |
|---|---|
| 测试找不到 widget | 检查 staging 环境中的选择器与等待时机是否匹配当前页面结构 |
CaptchaAI 返回 ERROR_NO_SLOT_AVAILABLE |
在内部 pipeline 中按指数退避重试，而不是立即失败 |
| 后端 QA 拒绝 token | 对照真实配置核对 action / sitekey / secret 是否一致 |
| 端到端时延偏高 | 在自有环境中重新测量，排查内部网络抖动 |
让每次 QA 运行都可观测
给每次运行打结构化日志：token 耗时、HTTP 响应码、任务编号、队列深度。各环境走独立通道，用分布式追踪（如 OpenTelemetry）串到同一个 correlation id，排障时间能砍一半。
上线前检查清单
- 测试范围严格限定在自有或授权资源。
- CaptchaAI key 存放在 CI secret 或 vault，不进源代码。
- 每次运行记录调用耗时与响应状态码。
- 瞬时错误配置幂等重试并设好上限。
- 整套流程能在 CI 中可复现地重复运行。
常见问题
为什么不能让所有 QA 场景共用一个浏览器配置文件？
cookie 和会话状态会在场景间泄漏，CAPTCHA 挑战类型也会跟着变。按场景拆分配置文件才能保证干净起点。
这些示例会不会碰到生产环境？
不会。所有示例均假设 staging.example.com 或自有 QA 域名，不对生产环境跑。
CaptchaAI 的 API key 可以直接写在代码里吗？
不可以。请通过 CI secret 管理器或 vault 注入；已提交到仓库的 key 必须立即轮换。
多套 staging 环境能共用同一个 CaptchaAI 账号吗？
可以。CaptchaAI 按线程数计费而非按次数收费，同一个 API key 的线程配额可被多个 staging 环境共享——多数中小型 QA 矩阵用 STANDARD（$30/月，15 线程）就够用。
相关阅读
- CaptchaAI 快速入门
- 授权 CAPTCHA QA 测试
- 自有表单的 CAPTCHA endpoint 测试
- 浏览器测试失败但 API 测试通过的排查
- 用 API 解决 reCAPTCHA v2
- 用 API 解决 Cloudflare Turnstile
- 用 API 解决 GeeTest v3
在你自己的 staging 环境里，用 CaptchaAI 把配置文件隔离这套流程跑通一遍。
