Hướng Dẫn Thực Hành

Trạng thái phiên CAPTCHA cho worker QA phân tán

Phạm vi an toàn: Hướng dẫn này chỉ áp dụng cho môi trường QA, staging hoặc pre-production thuộc sở hữu hoặc được uỷ quyền của bạn. Nội dung bao gồm các mẫu chẩn đoán, kiểm thử và quan sát cho tích hợp CAPTCHA của chính bạn — không áp dụng cho bên thứ ba hoặc luồng không được phép.

Chạy 15 worker QA song song trên cùng staging mà không đồng bộ trạng thái phiên sẽ khiến mỗi worker tự lấy cookie, tự gọi CaptchaAI và tự đánh dấu qa_case riêng — log trùng nhau, một số bước bị chạy lại vô ích. Câu trả lời ngắn: đưa cookie, localStorage và trạng thái từng bước vào store dùng chung, khoá theo (qa_case, step_id), rồi tái sử dụng token CaptchaAI trong đúng khoảng hợp lệ.

Một đội QA outsource tại TP.HCM chạy 20 worker mỗi đêm để test checkout trên staging của một app thương mại điện tử kiểu Shopee. Không dùng chung trạng thái, gần nửa worker solve lại CAPTCHA cho cùng tài khoản test, không phát hiện thêm lỗi thật.

Vì sao trạng thái phiên phải dùng chung

Mỗi worker mở một phiên trình duyệt hoặc HTTP session riêng. Nếu không đồng bộ, worker A vừa xác thực xong thì worker B lại mở phiên mới, chồng lấn cookie, có thể gửi CAPTCHA hai lần cho cùng bước. Lưu cookie và localStorage theo qa_case vào store dùng chung (Redis hoặc bảng trạng thái CI) để mọi worker đọc cùng nguồn.

Khoá theo qa_case để tránh xử lý trùng

Khoá bằng cặp (qa_case, step_id) trước khi một worker xử lý một bước. Worker lấy được khoá mới được chạy; các worker khác bỏ qua hoặc chờ kết quả. Cách này ngăn hai worker cùng gửi CAPTCHA cho một bước, giữ log sạch để đối chiếu sau.

Tái sử dụng token CaptchaAI đúng cách

Token CaptchaAI chỉ hợp lệ trong một khoảng ngắn kể từ khi giải xong — dùng lại token hết hạn sẽ bị backend QA từ chối, không phải lỗi của CaptchaAI. Lưu token cùng qa_case và thời điểm tạo, kiểm tra tuổi trước khi tái sử dụng giữa các worker.

Đoạn Python dưới đây là khối xây dựng cho SessionStore và khoá qa_case ở trên.

import os
import requests

API_KEY = os.environ['CAPTCHAAI_KEY']
QA_PAGE_URL = os.environ['QA_PAGE_URL']  # ví dụ 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()

Theo dõi khi worker chạy song song

Ghi log có cấu trúc cho mỗi lần chạy: thời gian lấy token, mã trạng thái HTTP, ID task và độ sâu hàng đợi. Tách log theo môi trường và gắn một correlation id xuyên suốt các bước (ví dụ qua OpenTelemetry) để phát lại cả kịch bản chỉ từ một id.

Danh mục kiểm tra trước khi chạy

  1. Phạm vi kiểm thử giới hạn trong ứng dụng của bạn hoặc tài nguyên đã uỷ quyền.
  2. Khoá CaptchaAI nằm trong CI secret hoặc vault, không trong mã nguồn.
  3. Mỗi lần chạy ghi lại thời gian gọi và mã trạng thái phản hồi.
  4. Có chính sách thử lại idempotent, có giới hạn số lần cho lỗi tạm thời.
  5. Bài kiểm thử tái lập được trên CI, không cần can thiệp thủ công.

Lỗi thường gặp

Vấn đề Nguyên nhân thường gặp Cách xử lý
Test không tìm thấy widget Selector hoặc thời điểm load đã đổi Kiểm tra wait_for_selector trên staging
CaptchaAI trả ERROR_NO_SLOT_AVAILABLE Hàng đợi đầy tạm thời Thử lại với backoff nội bộ
Backend QA từ chối token Sai action/sitekey/secret, hoặc token hết hạn Đối chiếu cấu hình backend, kiểm tra tuổi token

Câu hỏi thường gặp

qa_case nên sinh ra từ đâu?

Từ ID lần chạy CI hoặc test case, không sinh ngẫu nhiên mỗi lần retry — giữ nguyên một qa_case xuyên suốt kịch bản để khoá idempotency hoạt động đúng.

Bao nhiêu worker song song là hợp lý?

Giới hạn thực tế là số thread trong gói CaptchaAI bạn dùng. Theo dõi tỷ lệ ERROR_NO_SLOT_AVAILABLE; nếu tăng, giảm worker hoặc thêm backoff.

Hai worker cùng gửi CAPTCHA cho một qa_case thì sao?

Chỉ worker giữ khoá (qa_case, step_id) mới được phép gửi task. Nếu cả hai vẫn gửi trùng, kiểm tra logic acquire/release lock trước khi đổ lỗi cho CaptchaAI.

Hướng dẫn liên quan an toàn

Đồng bộ trạng thái phiên CAPTCHA cho pipeline QA của bạn với CaptchaAI.

Os comentários estão desativados para este artigo.