Teste de reenvio de códigos OTP:
associe cada e-mail à solicitação

Por que testes automatizados de regressão ainda confundem duas rodadas em 2026

É comum um script automatizado seguir o fluxo “solicitar código → aguardar e-mail → pegar o mais recente → enviar”. Uma execução bem-sucedida não garante que reenvios consecutivos também funcionem: o primeiro e-mail ainda está na fila quando a segunda solicitação é concluída; duas janelas compartilham a mesma conta, mas o script só salva o horário do último clique.

Nesse caso, o e-mail mais recente na caixa pode pertencer a uma solicitação anterior. Buscar mensagens apenas pelo assunto, pelo status de não lida ou pela ordem de chegada pode fazer um atraso na entrega parecer um erro no código. Também pode fazer com que um código errado funcione por acaso e o defeito passe despercebido. Em testes de e-mail de cadastro, o primeiro passo é estabelecer a correspondência entre solicitações e mensagens, não escrever uma expressão regular para extrair seis dígitos.

Defina primeiro as regras de reenvio; não tente deduzi-las pela caixa de entrada

Antes de executar testes de reenvio de OTP, confirme com as equipes de produto e back-end regras claras e testáveis: o reenvio reutiliza um código ainda válido ou emite um novo? Quando o código antigo é invalidado? A validade começa na primeira emissão ou na emissão mais recente? A regra se aplica à conta, à finalidade ou a uma sessão de verificação específica?

Registre a versão das regras no caso de teste. Se ainda não estiverem definidas, anote o que precisa ser confirmado; não deixe que uma verificação automatizada decida o comportamento do produto pela equipe. O exemplo de reprodução adiante pressupõe que “quando um novo código é emitido com sucesso, o antigo é invalidado imediatamente”.

Um caso por rodada: o endereço é apenas parte do contexto

Na caixa de e-mail temporária copie um endereço exclusivo e atribua um identificador à rodada, como case-r17. Mantenha esse endereço no primeiro envio e nos reenvios da mesma rodada. Registre a versão do ambiente de pré-produção, o identificador da conta, a finalidade da verificação e o identificador da sessão. Não troque de endereço a cada clique em “Reenviar”: isso transforma “reenvio para a mesma conta” em “primeiro envio para uma conta nova”.

Registre para cada solicitação o ID da solicitação no sistema, o resultado da resposta e o ID do evento gerado pelo serviço de envio. Uma resposta de sucesso da API pode indicar apenas que a tarefa entrou na fila. Se o trabalho assíncrono ainda não tiver criado um evento de envio, marque o campo como “pendente de correlação” e preencha-o depois. Em geral, uma solicitação limitada ou rejeitada não deve gerar um novo e-mail, mas siga o contrato da API.

O ID de registro de e-mail da Tempcase pertence ao lado do recebimento e não corresponde automaticamente ao ID da solicitação no sistema. Se os detalhes da mensagem recebida não mostrarem os cabeçalhos ou os campos de correlação, complemente os dados com logs de envio, marcadores de teste controlados ou recursos de observabilidade do ambiente de teste. Não associe mensagens à força só porque os horários são próximos.

Monte uma tabela de correlação em cinco colunas para rastrear cada e-mail

As cinco colunas a seguir formam a estrutura mínima de correlação. Registre no cabeçalho da rodada a conta, o ambiente, a versão das regras e a linha do tempo. Se uma solicitação gerar várias tentativas de entrega, mantenha uma linha por tentativa e anote a relação entre elas; não sobrescreva eventos anteriores.

No campo “evento de entrega”, especifique também a etapa: entrada na fila, envio ao serviço de e-mail, aceitação pelo servidor remoto ou rejeição. Não use o termo genérico “entregue”. O ID do registro do e-mail ajuda a localizar a mensagem, mas não substitui o resultado da API de validação do sistema.

O que testes de reenvio consecutivo, duas janelas e atraso na fila comprovam

Reenvios consecutivos: verifique as regras e o controle de frequência

Envie R1 e R2 respeitando o intervalo mínimo permitido e registre as respostas separadamente. Depois, teste os cliques durante o período de espera. Confira se uma solicitação rejeitada realmente não criou uma nova tarefa e se a validade após o reenvio segue o combinado. Não gere carga com solicitações em alta frequência nem contorne os limites.

Duas janelas: verifique o escopo do estado

Use a mesma conta de teste em duas janelas, acione as solicitações em uma ordem definida e registre o identificador da sessão de cada uma. Observe se a regra de invalidação vale nas duas janelas. Uma mensagem antiga ainda aparecer em uma janela não significa que o servidor continua aceitando o código; da mesma forma, a atualização da página não prova que o servidor invalidou o código.

Atraso na fila: verifique o comportamento do sistema quando as mensagens chegam fora de ordem

Somente em um ambiente de teste autorizado, use uma fila controlada ou injeção de falhas para atrasar R1 e permitir que R2 seja entregue primeiro. Registre onde o atraso foi introduzido e sua duração. Esse teste mostra se o sistema respeita as regras de OTP quando as mensagens chegam fora de ordem; não representa os atrasos de uma rede real e não deve alterar filas de produção.

A ordem dos e-mails não indica a ordem das solicitações

A ordem das solicitações, da emissão dos códigos, da execução das tarefas e do recebimento dos e-mails pode ser diferente. O cabeçalho Date também é gerado pelo remetente e não deve ser usado diretamente como horário de recebimento. Para identificar códigos OTP recebidos fora de ordem, priorize a correlação rastreável de eventos em vez de olhar apenas o e-mail mais recente.

Em modelos sob seu controle, você pode incluir um identificador de correlação de teste que não contenha informações secretas ou registrar nos logs a relação entre o ID da solicitação e o Message-ID do e-mail. O código OTP não pode servir como chave de correlação: o sistema pode reutilizar o mesmo código, e solicitações diferentes podem receber códigos iguais. Sem evidências de correlação, registre a conclusão como “não foi possível confirmar a qual solicitação pertence”.

Verifique no sistema se os códigos antigos foram invalidados

Faça verificações separadas para três pontos: se o e-mail chegou à caixa de entrada; se o sistema aceitou o código; e se, após a autenticação, a sessão ou o estado correto foi criado. Receber o e-mail não significa que o código é válido; uma resposta de sucesso da API de verificação também não garante que o login foi concluído.

Para testar o código antigo, depois que R2 for emitido com sucesso, envie o código associado a R1 e registre o tipo de erro retornado pelo sistema e o estado do desafio. Verifique se o código novo funciona e se pode ser reutilizado em uma reprodução independente: validá-lo primeiro pode consumir todo o desafio e fazer com que o código antigo seja rejeitado, ocultando uma falha na invalidação após o reenvio.

Recrie as mesmas condições iniciais para cada ramificação do teste e evite exceder o limite de tentativas. Registre apenas “aceito/rejeitado” e a categoria estável do erro. Não inclua o código OTP completo em relatórios de validação, nomes de capturas de tela ou logs de integração contínua.

Evidências de horário: padronize o formato e registre a origem

Recomendamos usar o formato ISO 8601 com fuso horário e converter os dados para UTC ao consolidá-los, sem deixar de guardar o valor original e sua origem. Identifique separadamente os horários de emissão pelo serviço de negócios, de aceitação pelo serviço de envio, de registro pelo serviço de recebimento e de observação pelo navegador. O mesmo formato de exibição não significa que os relógios dos sistemas estejam sincronizados.

• Para medir a duração dentro de um processo, use um relógio monotônico e registre também um horário de relógio civil para comparação.
• Antes de comparar horários entre serviços, confirme a sincronização dos relógios. Sem uma margem de erro confiável, não subtraia os valores para alegar uma latência precisa.
• O horário em que a consulta periódica detecta o e-mail pela primeira vez é apenas o horário da observação. Verificar a página a cada poucos segundos cria um intervalo de incerteza.
• O horário do cabeçalho do e-mail serve apenas como evidência complementar; não substitui os horários de emissão, entrada na fila ou validação pelo sistema.

Se você só sabe que “não estava lá em uma consulta e apareceu na seguinte”, registre esse intervalo. É mais útil assumir com clareza o que não foi possível medir do que apresentar uma conclusão em milissegundos sem uma origem confiável.

Exemplo de reprodução: o segundo e-mail chega primeiro e o primeiro, depois

O exemplo a seguir é controlado e não indica que esse problema tenha ocorrido na Tempcase nem em algum sistema específico. A regra esperada é: depois que o novo código R2 é emitido com sucesso para o mesmo desafio, o código antigo R1 é invalidado imediatamente.

1. Crie um desafio de teste e envie R1. Anote req-a → evt-a e atrase a entrega na fila de teste.
2. Depois do intervalo permitido para o reenvio, envie R2, confirme a emissão do novo código e anote req-b → evt-b.
3. Observe primeiro mail-b e, depois de liberar o atraso, mail-a. Use o identificador de correlação para confirmar a qual solicitação cada e-mail pertence.
4. Sem ter consumido o desafio com uma autenticação bem-sucedida, envie o código antigo A. Se for aceito, registre a resposta de validação e o estado do desafio e encerre imediatamente essa ramificação.

Se o primeiro e-mail apenas chegou com atraso e o código antigo foi rejeitado corretamente, não classifique automaticamente a entrega fora de ordem como uma falha de autenticação. Talvez seja necessário melhorar a mensagem do e-mail ou as instruções na página, mas isso é diferente de uma falha na regra de segurança.

Compartilhe evidências anonimizadas, não códigos OTP completos

O pacote de informações deve permitir que outra pessoa reproduza o problema passo a passo, sem usar suas credenciais. Use a lista abaixo; identifique a conta por um código e trate endereços reais e IDs de correlação conforme a classificação de dados da equipe.

Não inclua códigos OTP completos, tokens de login, cookies, links de autenticação nem tokens de acesso à caixa temporária em relatórios compartilhados. Oculte informações secretas no corpo das mensagens em capturas de tela e confira a barra de endereço e as ferramentas do desenvolvedor nas gravações. Também não recomendamos guardar códigos OTP curtos usando um hash comum: o conjunto de valores é pequeno e pode ser enumerado. Use identificadores sem relação com o código, como A e B.

Quando trocar de endereço e quando manter a mesma conta

Troque de endereço ao terminar uma rodada ou ao testar um fluxo de cadastro inteiramente novo, para isolar mensagens antigas. Se ainda estiver verificando reenvios, duas janelas, limites de frequência ou invalidação de códigos antigos para a mesma conta, mantenha o endereço e o contexto originais; caso contrário, as premissas do teste mudam.

Os endereços temporários da Tempcase ficam ativos por 3 horas por padrão e podem ser renovados, até o limite de 24 horas por endereço. Cada renovação solicitada na plataforma acrescenta 3 horas, respeitando o limite máximo. Não é possível recuperar e-mails depois que o endereço expira, então não use a caixa de entrada como arquivo de evidências. Para manter um canal de recebimento da conta por mais de um dia, você pode criar um alias em Acesse o encaminhamento contínuo; o alias apenas encaminha mensagens recebidas e não substitui os logs do sistema nem o armazenamento de evidências por tempo indeterminado.

Próxima rodada: comece confirmando a correspondência entre solicitações e e-mails

Na primeira execução, não precisa testar todas as exceções de uma vez. Faça uma rodada de envios normais que possam ser correlacionados, acrescente um reenvio e, por fim, simule a entrega fora de ordem. Se nem sequer for possível confirmar se o e-mail foi enviado, comece por Diagnóstico de recebimento de códigos OTP para conferir as evidências de envio e recebimento. Depois que o e-mail chegar, confira a formatação do corpo e acesse a Ferramenta de prévia de modelos de e-mail.