Estado de sessão CAPTCHA em workers distribuídos de QA

Um teste com vários workers rodando em paralelo só é confiável quando dá para provar, pelos logs, qual execução gerou qual resultado. Sem esse rastro, um caso falha e ninguém sabe se o token expirou, se o sitekey estava errado ou se dois workers pegaram o mesmo caso de teste ao mesmo tempo. É esse o problema que a continuidade de sessão resolve em uma suíte de QA que testa CAPTCHA em vários workers: manter cada execução identificável, rastreável e isolada das demais, do envio da tarefa até o log final.

Este guia mostra como montar esse modelo em um pipeline interno e como estruturar o logging para depurar regressões sem tentativa e erro.

Escopo seguro deste guia

Tudo aqui se limita a ambientes próprios, QA, staging ou pré-produção com autorização explícita da equipe. Os exemplos usam páginas internas, dados fictícios e endpoints de validação controlados pelo time — nenhum deles aponta para produção. Este guia não orienta automatizar serviços de terceiros, compras reais, filas públicas ou qualquer controle de acesso fora do seu próprio ambiente.

Por que a sessão perde continuidade entre workers de QA

Quando cada worker trata a execução como um evento isolado — sem identificador de caso compartilhado, sem correlação nos logs — o comportamento fica difícil de reproduzir. Exemplo comum: um time de QA roda workers em duas regiões (um runner local e outro em sa-east-1, na AWS, simulando latência real de usuários no Brasil), e cada um grava logs em formato distinto. Quando um caso falha, ninguém consegue cruzar os registros a tempo de saber se foi o token QA que expirou ou o worker errado testando o caso errado.

A correção não exige infraestrutura nova: basta um identificador de caso único por execução (qa_case_id), um endpoint de verificação separado de produção e um formato de log consistente entre workers.

Passo 1: monte o modelo de QA em staging

Crie uma página interna com sitekey de QA, usuário fictício e payload previsível, apontando para um endpoint de verificação separado de produção. O objetivo é reproduzir o fluxo técnico do CAPTCHA — envio, espera, validação — sem gerar nenhum efeito real para usuários, clientes ou parceiros.

Passo 2: use dados fictícios e endpoints internos

Use identificadores previsíveis como qa_user_001, qa_session_001 e qa_case_001 — nunca dados de usuários reais. O backend deve aceitar apenas tokens vinculados à página de staging e gravar cada resultado em uma tabela de testes separada da que armazena eventos de produção.

Passo 3: envie a tarefa à CaptchaAI a partir do QA

Envie a tarefa a partir do runner autorizado e registre o ID retornado — é esse ID que amarra a execução ao restante do rastro de log.

import os, time, requests

API_KEY = os.environ['CAPTCHAAI_API_KEY']
SITEKEY = os.environ['QA_CAPTCHA_SITEKEY']

def criar_tarefa_captcha(pageurl):
    resposta = requests.post('https://ocr.captchaai.com/in.php', data={
        'key': API_KEY,
        'method': 'userrecaptcha',
        'googlekey': SITEKEY,
        'pageurl': pageurl,
        'json': 1,
    }).json()
    return resposta['request']

def aguardar_resultado(task_id):
    while True:
        time.sleep(5)
        resposta = requests.get('https://ocr.captchaai.com/res.php', params={
            'key': API_KEY,
            'action': 'get',
            'id': task_id,
            'json': 1,
        }).json()
        if resposta.get('status') == 1:
            return resposta['request']

task_id = criar_tarefa_captcha('https://staging.example.com/captcha-demo')
token_qa = aguardar_resultado(task_id)
print({'token_recebido': bool(token_qa)})

Passo 4: valide a resposta no backend de QA

Depois de receber o token, encaminhe-o para um endpoint interno como https://staging.example.com/qa-captcha/verify. O backend valida a resposta junto ao provedor do CAPTCHA e retorna apenas um resultado de teste — nunca aciona nenhum fluxo de produção.

Passo 5: registre logging e rastreabilidade

Registre sitekey, pageurl, tipo de CAPTCHA, tempo de envio, tempo de resposta, status do backend e o qa_case_id de cada execução. Esses campos são o que permite cruzar um caso que falhou com o worker e o horário exatos, sem precisar reproduzir o teste do zero.

Se a equipe grava esses logs por mais tempo do que dura o ciclo de QA, vale revisar retenção sob a ótica da LGPD: mesmo sendo dados fictícios, o ideal é reter apenas o necessário para auditoria e descartar o resto — o mesmo cuidado que já se aplica a qualquer log operacional.

Solução de problemas mais comuns

Retentativas com backoff exponencial são aceitáveis apenas dentro da suíte de QA.

Perguntas frequentes

Preciso rodar todos os workers de QA na mesma região?

Não. É comum ter um runner local e outro em uma região como sa-east-1 para simular a latência real de usuários no Brasil. O que importa é que todos gravem logs no mesmo formato e usem um qa_case_id compartilhado para correlação.

O que fazer quando o token QA expira no meio do teste?

Reduza o intervalo entre a criação da tarefa e a validação no backend. Se o timeout for recorrente, ajuste a margem de segurança no seu polling em vez de aumentar o tempo limite indefinidamente.

Como evito que dois workers testem o mesmo caso ao mesmo tempo?

Gere um qa_case_id único por execução e nunca reaproveite o mesmo identificador entre workers ou entre rodadas. Isso evita resultados sobrepostos nos logs.

Por quanto tempo devo manter os logs desses testes?

Apenas pelo tempo necessário para auditoria e depuração de regressões. Como os dados são fictícios, o risco é baixo, mas manter uma política de retenção clara — alinhada à LGPD — evita acumular logs sem propósito.

Esse modelo funciona para qualquer tipo de CAPTCHA suportado?

Sim. A mesma estrutura de QA serve para reCAPTCHA v2/v3, Cloudflare Turnstile e GeeTest v3 — basta trocar o method da tarefa e o sitekey de QA correspondente ao tipo testado.

Critérios antes de publicar a mudança testada

Confirme que a documentação aponta para o ambiente próprio, que todos os exemplos usam dados fictícios e que nenhum endpoint de produção é acionado pelo teste. A página de staging precisa ter domínio autorizado, sitekey esperada, configuração de backend separada e política clara de expiração. Quando o resultado variar entre execuções, trate os números como amostra interna: repita a medição, anote a janela de execução e compare apenas cenários equivalentes — nunca amostras de dias ou cargas diferentes.

Guias relacionados

• Guia de início rápido da CaptchaAI
• Testes autorizados de CAPTCHA em QA
• Como testar endpoints CAPTCHA em formulários próprios
• Por que o navegador falha e a API funciona: guia de depuração
• Como resolver reCAPTCHA v2 pela API
• Como resolver Cloudflare Turnstile pela API
• Como resolver GeeTest v3 pela API

Teste a continuidade de sessão CAPTCHA do seu ambiente próprio com a CaptchaAI.