Quando o app mobile passa a falhar no CAPTCHA só em determinadas redes, a causa raramente está no widget — está na variação de latência e estabilidade entre as conexões que o time testa. Este guia mostra como montar esse diagnóstico dentro do seu próprio ambiente de staging, comparando redes autorizadas, com sitekey de QA, dados fictícios e um endpoint de verificação isolado de produção.
Por que comparar redes antes de liberar para produção
Um app mobile pode se comportar de forma diferente em Wi-Fi corporativo, 4G de laboratório ou VPN interna — não porque o CAPTCHA muda, mas porque timeout, retentativa e latência de rede interagem com o fluxo de forma distinta em cada cenário. Um time de QA em São Paulo validando o checkout de um app antes do lançamento, por exemplo, costuma repetir o mesmo teste em duas ou três redes autorizadas do próprio laboratório, sempre contra a mesma página staging, para isolar se uma falha é do CAPTCHA ou da conexão. Sem essa comparação, é fácil abrir um chamado de bug no lugar errado.
Escopo seguro deste guia
Este guia se limita a ambientes próprios, QA, staging ou pré-produção com autorização explícita. Os exemplos usam páginas internas, dados fictícios e endpoints de validação controlados pela equipe. Não há orientação para automatizar serviços de terceiros, compras reais, filas públicas ou controles de acesso fora do seu ambiente — o foco é comparação de redes autorizadas em cargas próprias, sempre com contas de teste.
Montando o ambiente de QA em staging
Crie uma página interna com sitekey de QA, usuário fictício, payload previsível e um endpoint de verificação separado de produção. O objetivo é reproduzir o fluxo técnico completo — do carregamento do widget ao envio do token — sem gerar efeitos reais para usuários, clientes ou parceiros.
Para os dados de teste, use identificadores previsíveis como qa_user_001, qa_session_001 e qa_case_001. O backend deve aceitar apenas tokens vinculados à página staging e gravar cada resultado em uma tabela dedicada a testes, nunca na mesma tabela de produção. Se o app coletar qualquer dado de usuário durante o teste, trate-o como dado real para efeito da LGPD: nunca use CPF, e-mail ou telefone verdadeiro nos payloads de QA.
Enviando a tarefa CAPTCHA pelo runner autorizado
Envie a tarefa a partir do runner de QA autorizado e registre o ID retornado — é esse identificador que amarra a tarefa CAPTCHA ao caso de teste no seu 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)})
Rode esse mesmo script contra cada rede autorizada que você quer comparar, mudando apenas a conexão de saída do runner — o payload e o sitekey de QA continuam idênticos entre execuções, o que garante que qualquer diferença de tempo venha da rede, não do teste.
Validando o token no backend de testes
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 CAPTCHA e retorna apenas um resultado de teste — sucesso, falha ou expiração — sem acionar nenhuma rotina de produção.
Registrando logs com rastreabilidade completa
Registre sitekey, pageurl, tipo de CAPTCHA, tempo de envio, tempo de resposta, status do backend, rede utilizada e identificador do caso QA. Esses campos são o que permite comparar redes de verdade depois: sem o campo de rede no log, dois testes idênticos em conexões diferentes ficam indistinguíveis no relatório final.
Resolvendo problemas comuns no diagnóstico
Se o teste falhar, confirme nesta ordem: sitekey correta, domínio staging na lista de permissões, expiração do token, relógio do runner sincronizado e diferenças de comportamento entre navegador e chamada direta à API. Faça retentativas com backoff apenas dentro da suíte QA, e nunca contra o endpoint de verificação de produção.
Checklist antes de publicar a mudança testada
Antes de publicar a mudança testada, confirme que a documentação aponta para ambiente próprio, que os exemplos usam dados fictícios, que nenhum endpoint de produção é acionado pelo teste e que os logs têm correlação suficiente para auditoria. A página staging deve 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 — mesma rede, mesmo horário, mesmo payload.
Perguntas frequentes
Preciso testar em rede física real ou uma simulação de latência já resolve?
Depende do objetivo. Simulação de latência (via proxy de desenvolvimento ou throttling do navegador) é suficiente para detectar timeout mal configurado. Para medir o comportamento real do CAPTCHA sob variação de rede, é melhor repetir o teste em conexões físicas distintas do laboratório de QA.
Quantas redes autorizadas devo comparar no mesmo ciclo de teste?
Duas ou três já revelam a maior parte dos problemas: uma rede estável de referência, uma com latência alta e uma terceira intermitente. Comparar mais do que isso raramente agrega dado novo e só aumenta o tempo do ciclo de QA.
A CaptchaAI resolve reCAPTCHA v3 e Cloudflare Turnstile no mesmo runner de teste?
Sim. O mesmo runner autorizado pode enviar tarefas para os dois tipos — basta trocar o parâmetro method da chamada (userrecaptcha para reCAPTCHA, turnstile para Cloudflare Turnstile) e manter o restante do fluxo de validação idêntico.
Como decido se uma falha é da rede ou do CAPTCHA em si?
Repita o mesmo caso de teste na rede de referência estável. Se o CAPTCHA passa lá e falha só na rede sob investigação, o problema é de rede — normalmente timeout curto demais ou expiração do token antes do envio. Se falha nas duas, o problema está no fluxo do CAPTCHA.
Preciso me preocupar com a LGPD nos logs desse diagnóstico?
Sim. Trate os dados de teste como se fossem reais: use identificadores fictícios (qa_user_001 e afins), nunca CPF, e-mail ou telefone verdadeiro, e evite gravar payloads completos — cookies, tokens, cabeçalhos — em logs que não sejam de uso interno da equipe de QA.
Guias relacionados seguros
- 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
- Resolver reCAPTCHA v2 com a API
- Resolver Cloudflare Turnstile com a API
- Resolver GeeTest v3 com a API
Configure o diagnóstico de rede da sua suíte de QA mobile com a CaptchaAI.
