Tách biệt hồ sơ trình duyệt cho QA với CaptchaAI

Phạm vi an toàn: Á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 — không áp dụng cho bên thứ ba hoặc luồng không được phép.

Test case A vừa đăng nhập xong, test case B đọc nhầm cookie của A — đây là nguyên nhân phổ biến nhất khiến kết quả kiểm thử CAPTCHA trên staging không tái lập được giữa hai lần chạy CI. Cách xử lý: mỗi kịch bản QA chạy trong một hồ sơ trình duyệt riêng, với cookie, storage và cấu hình xác thực CaptchaAI độc lập.

Vì sao kiểm thử đa tài khoản cần hồ sơ trình duyệt riêng

Khi bộ test có nhiều tài khoản kiểm thử hoặc chạy song song trên nhiều staging, dùng chung một hồ sơ trình duyệt tạo ra rủi ro nhiễm chéo: cookie phiên của kịch bản này rò sang kịch bản khác nên CAPTCHA phản ứng khác nhau giữa hai lần chạy giống hệt nhau, một lỗi ở test A làm hỏng trạng thái của test B chạy sau, và trạng thái trình duyệt trên CI không tái lập vì dữ liệu phiên cũ lẫn vào nhau khi profile không được cô lập.

Dữ liệu nào cần cô lập trong mỗi hồ sơ

Mỗi hồ sơ QA nên tách riêng: cookie, localStorage, sessionStorage, IndexedDB, cache service worker và tiện ích dev đang bật. CAPTCHA cũng chịu ảnh hưởng từ trạng thái phiên — widget có thể phản ứng khác nhau tuỳ lịch sử phiên trước — nên hồ sơ sạch là điều kiện để kết quả kiểm thử nhất quán.

Dựng hồ sơ QA bằng Playwright và gọi CaptchaAI

Đoạn mã dưới đây tạo user_data_dir riêng cho mỗi tài khoản test, mở trang staging và lưu trạng thái phiên sau khi xác thực CAPTCHA:

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')
        # ... xác thực CAPTCHA với CaptchaAI ...
        ctx.storage_state(path=f'state-{qa_user}.json')
        ctx.close()

Truyền profile_dir khác nhau cho mỗi qa_user là đủ để Playwright giữ cookie và storage tách biệt — không cần công cụ quản lý hồ sơ bên ngoài. Bước tiếp theo là gọi CaptchaAI để lấy token cho từng hồ sơ đang chạy:

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()

Gắn luồng CaptchaAI vào từng hồ sơ kiểm thử

Với mỗi hồ sơ, chạy luồng CAPTCHA chuẩn: phát hiện widget, gửi task, polling kết quả, xác thực token qua backend QA. Ghi log kèm profile_id và qa_case — test fail, bạn biết ngay là hồ sơ nào, không cần chạy lại cả suite.

Một đội QA thuê ngoài (phổ biến ở outsourcing tại TP.HCM và Hà Nội) chạy 10-20 hồ sơ song song trong một pipeline CI. Nếu mỗi lần chạy chỉ kích hoạt vài CAPTCHA đồng thời, gói STANDARD ($30/tháng, 15 thread) thường đã đủ; nhiều hồ sơ hơn thì nâng lên ADVANCE ($90/tháng, 50 thread).

Log có cấu trúc giúp bạn biết một lần chạy QA chậm ở đâu, thay vì đoán. Nên thu thập: thời gian lấy token, mã trạng thái HTTP, ID task và độ sâu hàng đợi. Tách development/staging/pre-production thành các kênh log riêng, liên kết các bước bằng correlation id (ví dụ OpenTelemetry).

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

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

Lỗi thường gặp khi test đa hồ sơ

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

Vì sao mỗi kịch bản QA nên chạy trên một hồ sơ trình duyệt riêng?

Cookie và storage của Playwright/Chromium gắn với user_data_dir. Dùng chung profile nghĩa là phiên đăng nhập và trạng thái CAPTCHA đã xác thực của test trước có thể rò sang test sau.

Có thể chạy song song nhiều hồ sơ QA trong cùng một pipeline CI không?

Có, miễn mỗi hồ sơ dùng user_data_dir riêng. Số hồ sơ chạy đồng thời nên khớp số thread trong gói CaptchaAI để tránh nghẽn hàng đợi.

Nên lưu API key CaptchaAI ở đâu trong pipeline?

Trong secret manager của CI hoặc vault — không hard-code trong mã nguồn. Khoá lỡ commit vào kho mã phải xoay vòng ngay.

Retry cho lỗi tạm thời nên cấu hình thế nào?

Idempotent retry kèm exponential backoff (1s, 2s, 4s) và giới hạn số lần thử. Lỗi mạng, mã 5xx và ERROR_NO_SLOT_AVAILABLE phù hợp để retry; lỗi xác thực thì không.

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

• CaptchaAI quickstart
• Kiểm thử QA CAPTCHA được uỷ quyền
• Kiểm thử endpoint CAPTCHA trên biểu mẫu của bạn
• Khi kiểm thử trình duyệt thất bại còn API thành công: gỡ lỗi
• Giải reCAPTCHA v2 qua API
• Giải Cloudflare Turnstile qua API
• Giải GeeTest v3 qua API

Xác thực tích hợp CAPTCHA của bạn trong môi trường nội bộ với CaptchaAI.