Como testar e-mails de verificação em Wi-Fi,
sem olhar só o código

Divida o sucesso em três resultados

Testar e-mails de portais de Wi-Fi público não é só confirmar que o código chegou. O e-mail aparecer na caixa de entrada, o portal aceitar o código ou link e o dispositivo original receber acesso à internet são três resultados distintos. Mesmo com a primeira etapa concluída, a validação e a liberação ainda podem falhar por expiração do token, perda da sessão ou regras do gateway.

Antes de começar, combine com as equipes de desenvolvimento e operações os critérios de aprovação: em quanto tempo o e-mail deve aparecer, qual evento do serviço confirma a validação e qual página HTTPS controlada deve abrir após a liberação. Não considere o acesso à internet liberado só porque o portal exibe “sucesso”: a página pode estar em cache, enquanto o gateway ainda não atualizou a autorização.

Isole o endereço e a sessão em cada teste

Faça os testes em um ambiente de teste ou em uma rede para a qual tenha autorização. Use um endereço novo para cada caso independente e registre o ID do caso e a sessão do dispositivo. Reutilize o endereço original apenas em testes de continuidade, como reenvios e cliques repetidos. Não use e-mails, números de quarto, pedidos ou documentos de hóspedes reais nos dados de teste.

Abra o painel de recebimento temporário da Tmpkeye confirme que ele mostra um endereço real e a contagem regressiva, não dois e-mails de demonstração. Mantenha as credenciais de acesso à caixa no mesmo navegador: trocar de navegador não recupera automaticamente a caixa original. Se o portal bloquear o acesso e a página de recebimento não abrir, prepare uma conexão móvel funcional e consulte Como abrir uma caixa de entrada anônima antes de liberar o acesso para diferenciar bloqueio de rede de problemas de entrega.

Comece pela matriz e depois teste combinações

Estabeleça uma referência com um fluxo normal e altere uma variável por vez. Registre o sistema e a versão do dispositivo, o navegador, o estado de liberação da rede e o método de verificação. Se você trocar o endereço, o dispositivo e o navegador ao mesmo tempo após uma falha, não conseguirá identificar o que causou a diferença.

Parta dessa matriz e acrescente as versões de iOS, Android e desktop mais usadas pelo público-alvo. Navegação privada, armazenamento desativado e mudança de idioma podem ser testes adicionais. Defina o escopo de suporte com base no produto; não é necessário testar todas as combinações indiscriminadamente.

Registre três horários para medir a entrega

Registre T0: clique para solicitar o código; T1: serviço do portal aceita a solicitação; T2: e-mail aparece pela primeira vez no painel de recebimento. T1−T0 inclui o processamento do front-end e da solicitação; T2−T1 inclui fila, transmissão e exibição na caixa. Não atribua os dois intervalos genericamente à “lentidão do servidor de e-mail”. Uma resposta de sucesso da API também não comprova a entrega.

Sincronize os fusos horários e os relógios de clientes e servidores; sempre que possível, correlacione os registros usando o ID da solicitação. A consulta periódica do painel pode fazer o e-mail aparecer depois da chegada real. Identifique T2 como “horário observado na interface”. Se tiver autorização, confira o horário de entrada nos registros de entrega; não use o campo Date do e-mail como horário de recebimento.

Repita o teste em várias rodadas e registre a mediana, os casos mais lentos e a proporção de falhas. Defina os limites com base no compromisso do portal e na validade do código, não usando um número fixo de segundos para todas as redes.

Confira o conteúdo, não apenas os seis dígitos

O assunto deve indicar a finalidade, e o endereço do remetente deve pertencer ao domínio esperado. Um nome de exibição igual não comprova a origem. Para avaliar SPF, DKIM e DMARC, você precisa do cabeçalho completo do e-mail ou dos registros de entrega; um ícone ao lado do remetente não basta.

• HTML: Mesmo com as imagens remotas desativadas, o código, a validade e os avisos de segurança continuam legíveis. Em telas estreitas, o conteúdo não deve ultrapassar a largura, e os modos claro e escuro devem oferecer contraste suficiente.
• Texto simples:O código e os links estão completos, sem tags residuais. As quebras de linha não cortam o código, e a cópia não inclui caracteres invisíveis.
• Conteúdo consistente: As duas versões devem ter a mesma finalidade, os mesmos códigos e os mesmos prazos. A versão traduzida não deve incluir instruções em outro idioma.

O painel de recebimento temporário ajuda a conferir a exibição, mas pode não oferecer o MIME original ou a alternância entre as duas versões do corpo. Para confirmar que ambas foram enviadas, confira os registros do seu sistema de envio, o e-mail original ou um cliente de teste controlado. Não conclua que a versão em texto simples existe só porque a página parece correta.

Siga o link de verificação até a sessão original

Confira o destino real, não apenas o texto do botão. O link deve usar o domínio HTTPS esperado, os redirecionamentos não devem levar a sites não autorizados e os parâmetros não devem incluir dados pessoais desnecessários. Use contas de teste fictícias para validar toda a cadeia de redirecionamento e mantenha nos registros apenas caminhos e status sem dados identificáveis.

Teste e aprove separadamente no mesmo dispositivo e em outro

Se a solicitação for iniciada em uma janela de login do sistema e o e-mail for aberto em um navegador completo, o link pode levar a outra sessão de cookies. Abrir no celular um link de verificação solicitado no computador também envolve a vinculação ao dispositivo. Defina primeiro o que o link verifica: o endereço, o navegador atual ou a sessão original do gateway. Recusar a verificação em outro dispositivo pode ser o comportamento correto, mas o usuário deve saber como voltar ao dispositivo original e digitar o código ou solicitar outro.

Teste também a abertura repetida do link. Confirme que a página não autoriza outros dispositivos sem relação com a solicitação e que um token já usado apresenta um status compreensível. Não desative a vinculação nem flexibilize a validação de redirecionamentos só para fazer o teste passar.

Ao reenviar, altere a ordem e teste novamente

Faça duas solicitações consecutivas, identifique-as como A e B pelos números de solicitação e teste os códigos antigo e novo separadamente. Não deduza qual é o mais recente pela ordem da caixa de entrada: atrasos na fila podem fazer A chegar depois de B. Se apenas o código mais recente for válido, o aviso da interface, a validação do serviço e o texto do e-mail devem dizer a mesma coisa. Qualquer outra regra também precisa estar claramente declarada.

Em um ambiente controlado, teste envios duplicados, o limite de frequência e a retomada após o período de espera. A limitação deve ser aplicada no servidor, não apenas desativando o botão. Um tempo de espera da rede também não significa que a solicitação não foi enviada: o sistema pode já tê-la aceitado. Registre o resultado real e evite repetir solicitações sem limite, pois isso pode acionar mecanismos de proteção contra abuso da rede.

Teste separadamente a expiração do e-mail e do token do portal

Por padrão, os e-mails temporários da Tmpkey são válidos por 3 horas; o prazo do código ou link de verificação é definido separadamente pelo portal. O e-mail pode ter mais duas horas de validade, enquanto um token enviado há poucos minutos já expirou. Renovar o e-mail não atualiza o token do portal.

Crie pelo menos dois casos de teste: e-mail válido com token expirado — a verificação deve ser recusada e deve ser possível solicitar outra; e-mail expirado com token do portal ainda dentro do prazo declarado — verifique as regras do próprio portal, sem presumir que a expiração do endereço revoga automaticamente um token já emitido. Teste também os limites antes e depois da expiração, o uso repetido e a validação do horário no servidor.

Use uma configuração de teste com TTL reduzido somente em um ambiente isolado e registre as diferenças em relação à produção. Observe separadamente o momento real em que o e-mail temporário é destruído; não adiante o relógio do celular para simular a expiração no servidor.

Renove para manter o endereço; troque-o para encerrar a caixa antiga

Cada renovação acrescenta 3 horas. Um e-mail pode permanecer ativo por no máximo 24 horas a partir da criação; prevalece o horário de expiração informado pelo serviço. No teste, confira se o endereço permanece igual, se as mensagens antigas continuam disponíveis e se a contagem regressiva é atualizada. Perto do limite máximo, não espere que uma renovação acrescente mais 3 horas completas.

Ao trocar de endereço, você cria um novo e-mail, válido por padrão por 3 horas, e a caixa antiga é destruída. Encerre o caso de teste e salve as evidências necessárias sem dados identificáveis antes de trocar o endereço. Não o altere enquanto aguarda uma mensagem e depois classifique a falta de recebimento no endereço antigo como falha de entrega. O novo endereço também não atualiza automaticamente o destino de recebimento já salvo no portal.

Registre evidências que permitam reproduzir o teste sem possibilitar um login

Cada registro deve incluir: ID do caso, ambiente e versão do build, versões do dispositivo e do navegador, estado da rede, método de verificação, endereço mascarado, ID da solicitação, os três horários e os resultados esperados e reais. Marque separadamente “recebimento”, “verificação” e “liberação”; não registre apenas um resultado geral de aprovado ou reprovado.

Se precisar associar registros ao mesmo endereço, use um identificador do caso ou um hash controlado; não armazene as credenciais completas. Destruir o e-mail de teste não remove capturas de tela anexadas a chamados, arquivos baixados nem cópias em sistemas externos; esses dados precisam ser apagados separadamente.

E-mail temporário não é relatório de taxa de entrega

Um único teste bem-sucedido só confirma o resultado naquele momento, naquele fluxo e para aquele domínio de recebimento. Ele não representa a classificação de spam, as políticas de reputação nem a exibição no Gmail, Outlook ou e-mails corporativos. Antes do lançamento, use amostras de contas reais autorizadas, avalie o comportamento de cada provedor e monitore em produção as entregas, devoluções e conversões de verificação.

O portal pode recusar explicitamente endereços descartáveis; registre isso como uma política de aceitação de endereços, sem contornar a restrição. Não use endereços que serão destruídos para verificações de identidade, avisos de pagamento, alterações de hospedagem, recuperação de contas ou contato de longo prazo. E-mail anônimo não oculta a origem da conexão nem substitui uma auditoria de segurança.

Próxima etapa: receba o e-mail e depois decida se precisa mantê-lo

Para testes de curta duração, use um endereço independente e execute o fluxo completo. Se precisar de um endereço estável para testes de regressão em vários dias, avalie um alias de encaminhamento permanente: as mensagens chegam à sua caixa de entrada, e as configurações e o arquivo dos últimos 30 dias são gerenciados separadamente. O encaminhamento acrescenta etapas ao fluxo; não misture diretamente a latência dele com os resultados do recebimento temporário.

Para instruções de preenchimento do portal voltadas a quem vai se conectar, consulte o Guia de e-mail para acessar a internet em hotéis, aeroportos e cafeterias; para saber quais dados são tratados, consulte a Política de privacidade.