WebDriver e CDP para diagnóstico de CAPTCHA em QA

Antes de automatizar qualquer teste de CAPTCHA, a primeira decisão prática não é qual framework é "melhor" — é como reproduzir o desafio em ambiente próprio, sem gerar tráfego real e sem depender de produção. Este guia mostra como montar esse fluxo de QA usando WebDriver (Selenium) ou CDP (Puppeteer/Playwright) como camada de automação do navegador, da criação da página de teste até o log de auditoria.

O que este teste cobre

O escopo é ambiente próprio, QA, staging ou pré-produção com autorização explícita. Os exemplos usam páginas internas, dados fictícios e endpoints controlados pela sua equipe — nada aqui automatiza login de terceiros, compras reais ou controle de acesso fora do seu ambiente. O foco é diagnosticar rede e renderização com contas de teste, não sistemas de produção.

WebDriver ou CDP: o que muda no teste de CAPTCHA

WebDriver é o protocolo padrão W3C usado pelo Selenium: o script fala HTTP com o ChromeDriver, que por sua vez controla o navegador. CDP é o protocolo nativo do Chrome, usado por Puppeteer e Playwright: o script conversa direto com o navegador por WebSocket, sem camada intermediária. Na prática, isso muda a forma como você escreve o teste — não o resultado do CAPTCHA.

Nenhuma dessas diferenças altera o tempo de resolução: a CaptchaAI resolve o desafio do lado do servidor, então o protocolo de automação só afeta a velocidade de navegação e a forma como você captura a sitekey e injeta o token de volta na página.

Monte o cenário de QA em staging

Crie uma página interna com uma sitekey de QA dedicada, um usuário fictício, um payload previsível e um endpoint de verificação separado de produção. O objetivo é reproduzir o fluxo técnico — carregar o desafio, obter o token, enviar o formulário — sem gerar efeito real para usuários, clientes ou parceiros.

Dados fictícios, sitekey de teste e endpoints internos

Use identificadores como qa_user_001, qa_session_001 e qa_case_001. O backend deve aceitar apenas tokens vinculados à página de staging e gravar os resultados em uma tabela de testes, isolada do banco de produção.

Envie a tarefa à CaptchaAI a partir do runner de QA

Envie a tarefa a partir do runner autorizado — controlado por WebDriver ou por CDP, tanto faz — e registre o ID retornado para rastreabilidade:

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

Valide o token no backend de teste

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 grava nada na tabela de produção.

Registre logs para rastreabilidade e auditoria

Registre sitekey, pageurl, tipo de CAPTCHA, tempo de envio, tempo de resposta, status do backend e o identificador do caso de QA. Esses campos ajudam a depurar regressões sem expor dados sensíveis.

Times de QA no Brasil e em Portugal costumam rodar esse runner em regiões diferentes — por exemplo, sa-east-1 (São Paulo) na AWS. Anote a região junto com o log: comparar uma medição em sa-east-1 com outra em us-east-1 distorce o tempo de resolução e gera falsos alarmes de regressão. Se o log guardar algum dado associável a uma pessoa real, mesmo em teste, trate a coleta considerando a LGPD, no Brasil, ou o RGPD, em Portugal: minimize o que é gravado e defina um prazo de retenção para a tabela de testes.

Solução de problemas comuns

Se o teste falhar, confirme, nesta ordem: a sitekey esperada, o domínio de staging autorizado, a expiração do token, o relógio do runner e diferenças de timing entre navegador e API. Faça retentativas com backoff exponencial apenas dentro da suíte de QA — nunca contra o endpoint de produção.

Checklist antes de publicar a mudança

Antes de publicar a mudança testada, confirme que a documentação aponta para o ambiente próprio, que os exemplos usam dados fictícios, que nenhum endpoint de produção é acionado e que os logs têm correlação suficiente para auditoria. A página de staging deve ter domínio autorizado, sitekey esperada, configuração de backend separada e política clara de expiração. Quando o resultado variar, trate os números como amostra interna: repita a medição e compare apenas cenários equivalentes — mesma região, mesmo protocolo, mesmo plano de threads.

Perguntas frequentes

Preciso escolher entre WebDriver e CDP, ou dá para combinar os dois?

Dá para combinar. O Selenium 4 expõe comandos CDP via BiDi: você navega com WebDriver e usa CDP para eventos de rede na mesma sessão. O que importa para o teste é reproduzir o desafio real, não o protocolo escolhido.

O tempo de resposta da CaptchaAI muda conforme o protocolo do navegador?

Não. A resolução acontece do lado do servidor da CaptchaAI; o protocolo de automação (WebDriver ou CDP) só afeta a velocidade de navegação e a captura da sitekey, não o tempo de resolução do CAPTCHA em si.

Posso reaproveitar a sitekey de produção no ambiente de staging?

Não é recomendado. Use uma sitekey de QA dedicada, associada a um domínio de staging autorizado — isso evita misturar tráfego de teste com métricas reais e simplifica a auditoria dos logs.

Quantas threads da CaptchaAI preciso reservar para os testes de QA?

Depende do volume de execuções paralelas da suíte. Equipes pequenas costumam rodar QA dentro do plano BASIC (US$ 15/mês, 5 threads); se a suíte crescer e passar a rodar em paralelo, o STANDARD (US$ 30/mês, 15 threads) evita fila entre execuções simultâneas.

O que registrar no log para facilitar a auditoria depois?

Os mesmos campos usados na seção de rastreabilidade: sitekey, pageurl, tipo de CAPTCHA, tempo de envio, tempo de resposta, status do backend, identificador do caso de QA e, se o runner rodar em nuvem, a região de execução.

Guias relacionados

• Início rápido da CaptchaAI
• Testes QA autorizados de CAPTCHA
• Testes de endpoint CAPTCHA em formulários próprios
• Depuração quando o navegador falha e a API funciona
• Como resolver reCAPTCHA v2 com a API
• Como resolver Cloudflare Turnstile com a API
• Como resolver GeeTest v3 com a API

Crie sua chave de API e rode o primeiro teste de CAPTCHA em staging com a CaptchaAI.