État de session pour des workers QA distribués avec CaptchaAI

Quand plusieurs workers QA testent le même flux de staging, les résultats sont souvent incohérents : un worker démarre avec des cookies vides, un autre avec un état enregistré, un troisième avec des données de test différentes. Pour des tests CAPTCHA stables, vous n'avez pas besoin d'un « contexte live partagé » mais d'un état de session clairement documenté par exécution.

Périmètre : ce guide s'applique à vos propres environnements QA ou à des environnements explicitement autorisés. Il décrit comment des workers de test distribués coordonnent un état navigateur et applicatif reproductible. Il ne décrit ni reprise de session sur des sites tiers, ni optimisation pour des accès non autorisés.

Pourquoi un état QA partagé est important

Des workers de test distribués vérifient souvent la même fonctionnalité sous différentes conditions :

• première visite d'un compte de test,
• session active avec un feature flag activé,
• session expirée comme test négatif,
• régression parallèle sur plusieurs rôles.

Sans état coordonné, vous ne comparez pas les mêmes scénarios. Le résultat : des erreurs CAPTCHA difficiles à interpréter, qui viennent en réalité de conditions de départ différentes.

Ce qui peut ou non être partagé entre workers

En QA, seules les données qui contribuent à la reproductibilité d'un cas de test doivent être partagées.

Avec cette séparation, on sait toujours pourquoi un worker utilise un état précis et à quel cas de test appartient un artefact.

Exemple : documenter un état de session dans Redis

from __future__ import annotations

import json
import redis


r = redis.Redis(host="localhost", port=6379, decode_responses=True)


def session_key(test_run_id: str, worker_id: str) -> str:
    return f"qa:session:{test_run_id}:{worker_id}"


def save_session_snapshot(*, test_run_id: str, worker_id: str, cookies: dict, storage: dict) -> None:
    payload = {
        "test_run_id": test_run_id,
        "worker_id": worker_id,
        "cookies": cookies,
        "storage": storage,
    }
    r.set(session_key(test_run_id, worker_id), json.dumps(payload), ex=3600)


def load_session_snapshot(test_run_id: str, worker_id: str) -> dict:
    raw = r.get(session_key(test_run_id, worker_id))
    if not raw:
        return {"cookies": {}, "storage": {}}
    return json.loads(raw)

L'élément clé n'est pas Redis lui-même, mais la structure : chaque worker reçoit des données de session bien définies, attachées à une exécution QA connue.

Utiliser CaptchaAI dans des exécutions QA distribuées

Une fois l'état de départ et l'identifiant d'exécution figés, chaque worker peut suivre le même chemin de vérification et journaliser ses résultats de façon centralisée.

import requests
import time


API_KEY = "YOUR_API_KEY"


def solve_for_worker(page_url: str, sitekey: str) -> str:
    submit = requests.post(
        "https://ocr.captchaai.com/in.php",
        data={
            "key": API_KEY,
            "method": "userrecaptcha",
            "googlekey": sitekey,
            "pageurl": page_url,
            "json": 1,
        },
        timeout=30,
    )
    submit.raise_for_status()
    submit_json = submit.json()
    if submit_json.get("status") != 1:
        raise RuntimeError(submit_json.get("request", "submit failed"))

    task_id = submit_json["request"]
    for _ in range(30):
        time.sleep(5)
        result = requests.get(
            "https://ocr.captchaai.com/res.php",
            params={"key": API_KEY, "action": "get", "id": task_id, "json": 1},
            timeout=30,
        )
        result.raise_for_status()
        result_json = result.json()
        if result_json.get("status") == 1:
            return result_json["request"]

    raise TimeoutError("CaptchaAI result timed out for QA worker")

Là encore, la vérification réelle est une étape QA contre votre propre environnement. Le résultat est corrélé à l'exécution, à l'identifiant de worker et à la réponse attendue.

Vérifier le comportement backend par worker

def verify_worker_run(*, test_run_id: str, worker_id: str, token: str) -> dict:
    response = requests.post(
        "https://staging.example-app.test/qa/captcha/verify",
        json={
            "testRunId": test_run_id,
            "workerId": worker_id,
            "token": token,
            "environment": "staging",
        },
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

Vous pouvez ainsi suivre, par worker :

• quel état de départ était actif,
• quelle réponse votre backend a renvoyée,
• si les écarts entre exécutions parallèles viennent de l'état ou de l'application.

Dépannage

Guides connexes sûrs

• Démarrage rapide CaptchaAI
• Tests QA CAPTCHA dans des environnements autorisés
• Redis pour le diagnostic du TTL des tokens CAPTCHA
• Tester les endpoints CAPTCHA dans vos formulaires web

Coordonnez vos workers QA distribués avec des données d'état claires et des exécutions de vérification reproductibles — CaptchaAI soutient des tests CAPTCHA fiables dans vos propres environnements.