Source: https://once-email.com/pt/blog/safe-email-test-evidence Testes e engenharia · 2 de ago. de 2026Atualizado 9 de ago. de 2026 # Como guardar evidências de testes de e-mail sem expor segredos O que manter, o que ocultar e como demonstrar um resultado sem arquivar códigos, links de acesso ou mensagens completas. [Equipe de engenharia do Once Email, Once Email author Equipe de engenharia do Once Email]() Revisado por Revisão editorial do Once Email O que este guia ajuda você a fazer O leitor consegue montar um pacote reproduzível com metadados suficientes e uma lista objetiva de valores que devem ser ocultados. Guia do artigo Por que vale a pena ler este artigo **Análise original** Classificamos evidências pela afirmação demonstrada para minimizar conteúdo e impedir que capturas e logs prolonguem a vida de um segredo. **Contexto de tendências** Equipes compartilham mais artefatos em CI, tickets e chats cuja retenção costuma ser muito maior que a da caixa de teste. **Valor prático** O leitor consegue montar um pacote reproduzível com metadados suficientes e uma lista objetiva de valores que devem ser ocultados. Uma evidência de teste deve provar uma afirmação sem criar um novo incidente. Capturar a tela inteira de um e-mail é fácil, mas pode armazenar por anos um código que deveria durar minutos, um link assinado ou dados de outra pessoa. ## [Comece pela afirmação]() Defina exatamente o que precisa ser demonstrado: entrega dentro do prazo, assunto correto, idioma, existência de um link ou expiração de código. Colete apenas os campos necessários para essa afirmação. Para entrega, horário UTC, identificador redigido e resultado bastam na maioria dos casos. Para layout, use dados sintéticos e recorte apenas o componente relevante. Para um link, registre domínio e formato, não o token funcional. ## [Valores que devem ser removidos]() Redija códigos de uso único, senhas, cookies, cabeçalhos de autorização, links mágicos, parâmetros assinados, endereços pessoais, IPs não necessários e conteúdo privado. Não confie apenas em desfoque visual: o texto pode continuar na camada acessível, nos metadados ou no arquivo original. Use substituições consistentes, como ` [CODIGO_REMOVIDO] ` e ` [TOKEN_REMOVIDO] `, para que o leitor saiba que houve uma ação deliberada. Não substitua tudo por pontos se isso apagar a estrutura que o teste precisava mostrar. ## [Pacote mínimo reproduzível]() Inclua versão da aplicação, ambiente, caso de teste, início e término UTC, tipo de mensagem, resultado esperado e observado. Um identificador de correlação pode ser mantido se não conceder acesso e não revelar uma pessoa. Registre também o limite de espera e o número de consultas. Isso permite distinguir atraso de uma espera arbitrariamente curta. A [checklist de testes]() ajuda a definir essas etapas antes da execução. ## [Capturas, logs e CI]() Capturas devem usar contas sintéticas e ser excluídas segundo uma retenção curta. Logs estruturados precisam aplicar mascaramento antes da gravação, não apenas na interface de consulta. Artefatos de CI devem ter acesso restrito e expiração configurada. Evite imprimir corpo MIME, cabeçalho ` Authorization `, resposta completa da API ou HTML da mensagem. Se um teste falhar, uma exceção não deve despejar automaticamente todos os objetos em memória. ## [Revisão antes de compartilhar]() Abra o artefato final em uma sessão separada e procure padrões de e-mail, tokens, URLs longas e números parecidos com código. Verifique nome de arquivo, miniatura, texto alternativo e histórico do ticket. Compartilhe somente com quem precisa investigar. Ao encerrar o caso, remova caixas e arquivos temporários. A minimização continua válida mesmo quando o dado é “só de teste”, pois ambientes de teste frequentemente recebem cópias ou hábitos da produção. ## [Evidência não é retenção permanente]() Defina uma data de expiração proporcional ao objetivo. Resultado agregado pode permanecer por mais tempo; conteúdo bruto raramente precisa. Um bom registro permite reproduzir a falha sem preservar o segredo que passou pelo sistema. ## Guias relacionados Checklist de testes de e-mail para desenvolvedores: da solicitação à expiração Um plano reproduzível para verificar geração, entrega, conteúdo, links, anexos, acessibilidade e limpeza sem usar dados reais. [Checklist de testes de e-mail para desenvolvedores: da solicitação à expiração]() Como usar uma API de e-mail temporário sem criar testes instáveis Projete testes com caixas isoladas, consultas limitadas, tempo máximo, correlação segura e limpeza determinística. [Como usar uma API de e-mail temporário sem criar testes instáveis]() Postfix vs Dovecot: funções diferentes em um servidor de recebimento Entenda onde Postfix, Dovecot, LMTP, fila e IMAP atuam e use evidências para localizar uma falha de entrega. [Postfix vs Dovecot: funções diferentes em um servidor de recebimento]() ## Ferramentas de e-mail com privacidade em primeiro lugar Gerador hash SHA-256 e SHA-512 Gere hashes de texto localmente com Web Crypto. Gerador hash SHA-256 e SHA-512 [Checklist de testes de e-mail para desenvolvedores: da solicitação à expiração Um plano reproduzível para verificar geração, entrega, conteúdo, links, anexos, acessibilidade e limpeza sem usar dados reais.]() [Alias, caixa temporária ou endereço permanente: qual escolher? Compare três formas de receber e-mail por continuidade, separação, recuperação, exposição e controle.]()