Homologação sem dado pessoal real: como testar com dados sintéticos
Existe um atalho tentador em todo projeto de integração: pegar um contrato real, com o CPF e o e-mail de um cliente real, e mandar para o sandbox "só para ver como fica". É rápido, os dados já estão à mão, e ninguém parece prejudicado. O problema é que o ambiente de homologação não é produção em miniatura — ele tem retenção própria, pode ser usado para diagnóstico interno e não carrega os compromissos operacionais do ambiente produtivo. Este guia mostra o que pode e o que não pode ir para lá, quais geradores resolvem cada tipo de dado de teste, e os cinco bugs de roteamento que fazem dado real vazar para homologação sem ninguém perceber.
A regra em uma linha: os seus próprios dados podem ir para o sandbox; os de terceiros não, mesmo com consentimento. Tudo o mais se resolve com dados sintéticos — e eles são mais convenientes do que dados reais, não menos.
Por que o ambiente de testes é diferente
O sandbox parece produção e não é. Quatro diferenças importam na prática:
- Os dados de homologação não são tratados como produção em retenção, segurança operacional ou compromisso de disponibilidade.
- Documentos, transações e biometria de homologação podem ser eliminados a qualquer momento, sem aviso.
- Dados de homologação podem ser usados para diagnóstico técnico interno — logs estendidos, depuração.
- É um ambiente destinado a testes, e não à operação para a qual um titular de dados consentiu.
É esse último ponto que torna o atalho problemático mesmo quando parece inofensivo: quando um cliente concordou que o CPF dele fosse usado para assinar um contrato, ele concordou com uma operação produtiva. Um ambiente de testes não estava no acordo.
Some-se a isso o item 2 — dados podem sumir sem aviso — e o atalho fica ruim até por motivos puramente práticos: você não deveria querer que um dado importante estivesse ali.
O que pode e o que não pode
| Categoria | Pode ir? |
|---|---|
| Seu próprio CPF, e-mail, telefone, biometria — para testar o que você está construindo | Sim |
| CPF, e-mail ou biometria de outras pessoas, mesmo com consentimento | Não |
| Documentos com cláusulas reais e terceiros identificados | Não |
| Selfies ou fotos de documento de identidade de terceiros | Não |
| CPF sintético de gerador de teste | Sim |
| Fotos livres de direito, de bancos de imagem abertos | Sim |
E-mails descartáveis endereçados a você (testes+sd@suaempresa.com.br) |
Sim |
A linha dos e-mails com sufixo merece destaque porque resolve um problema real: testar convite, reenvio e lembrete exige caixas de entrada distintas, e o truque do + gera quantas você quiser, todas chegando na sua.
Geradores por tipo de dado
CPF
Dois casos, conforme o que o fluxo valida:
Vale lembrar o que o dígito verificador significa: ele confirma formato, não identidade. Um CPF sintético com dígito correto é indistinguível de um real para qualquer validação puramente algorítmica — o que é exatamente o que se quer num teste, e é a razão pela qual dígito verificador nunca deve ser tratado como prova de que alguém é quem diz ser.
Rosto e documento de identidade
Para imagem de referência biométrica, rostos gerados por IA — de sites do tipo "esta pessoa não existe" — resolvem o caso: são fotos que não correspondem a pessoa alguma. Para documentos, use modelos fictícios de RG ou CNH feitos para mockup. Nunca a foto do seu documento real, e muito menos a de outra pessoa.
Na maior parte dos testes você nem precisa de imagem. O sandbox simula as verificações biométricas e aceita campos que escolhem o resultado — similaridade, confiança de vivacidade, brilho e nitidez da captura. Dá para exercitar aprovação e reprovação, inclusive nos valores próximos do limiar, sem câmera e sem foto de ninguém. Os campos de simulação aceitam valores entre 0 e 100 e só valem com credenciais de sandbox — eles nunca fazem uma verificação real passar.
Documentos PDF
PDFs com texto genérico e cláusulas de exemplo bastam. Não envie contratos reais de clientes para "ver como fica a interface" — a interface é a mesma com lorem ipsum.
Retenção: o número que quebra teste automatizado
As entidades da API em homologação — transações, envelopes e registros de evidência — expiram em 7 dias.
Isso tem uma consequência prática que aparece como falha intermitente e misteriosa: uma suíte que guarda um transactionId de uma execução anterior e o reaproveita passa a falhar sozinha uma semana depois, sem que nada tenha mudado no código. A correção é criar objetos novos a cada execução, tratada em como testar sua integração do sandbox ao CI.
Se a sua operação precisa de retenção mais longa em homologação — certificação, auditoria de integração —, isso é assunto de contrato, não de configuração.
Se dado real acabou indo parar lá
Acontece, principalmente em integrações com bug de roteamento. O caminho existe justamente por isso: peça a eliminação imediata pelo canal do encarregado de dados, informando
- o
client_idde homologação afetado; - a janela de tempo do envio, em UTC;
- o tipo de dado envolvido (CPF, biometria, documento);
- a identidade do titular, para que a eliminação possa ser confirmada a ele se for o caso.
Reportar cedo é sempre melhor do que esperar para ver se alguém percebe — e a janela de tempo em UTC é o dado que mais acelera a localização.
Os cinco bugs que vazam dado real
Nenhum destes é exótico. Todos já aconteceram com alguém:
| Bug | Correção |
|---|---|
| Variável de ambiente trocada — a URL base aponta para homologação enquanto o cliente acredita estar em produção | Registrar no start-up do serviço um log explícito da URL base resolvida |
| Retry para o ambiente errado — o wrapper de nova tentativa cai num fallback configurado para homologação | Nunca configurar homologação como fallback de produção |
| Cache de token compartilhado — tokens de um ambiente usados em chamadas ao outro | Chavear o cache por (ambiente, client_id) |
| Credenciais embaralhadas no CI/CD — o cofre devolve credencial de homologação para um pipeline de produção | Prefixar os segredos por ambiente: hml/…, prod/… |
| Demonstração ao vivo em homologação com dados reais do prospect | Política interna explícita e um roteiro de demonstração com dados sintéticos |
O último é o mais frequente, e é o único que nenhuma correção técnica resolve. Ele acontece porque a pessoa que faz a demonstração quer que ela pareça real, e o jeito mais fácil de parecer real é usar dados reais. A contramedida que funciona é ter um roteiro pronto com dados sintéticos que já pareça convincente — se o caminho certo for tão fácil quanto o errado, ele é o que será usado.
Uma medida barata que ajuda nos quatro primeiros: as URLs dos dois ambientes diferem por um hífen e três letras (api-hml. e api.). É pouca distância visual para uma diferença tão grande — por isso o log explícito da URL resolvida no start-up vale mais do que parece.
Como fica o dia a dia
Um conjunto de teste bem montado costuma ter isto, e nada além:
- Alguns CPFs sintéticos fixos, versionados junto do código de teste.
- Dois ou três rostos gerados, para os fluxos biométricos que exigem imagem.
- Um PDF genérico de uma página e outro de trinta, para exercitar o caminho de upload por URL pré-assinada.
- E-mails com sufixo apontando para a sua própria caixa.
- Os campos de simulação para os resultados biométricos, em vez de imagens de verdade.
Isso cobre praticamente todo cenário — e tem uma vantagem prática sobre dados reais que costuma decidir a questão: dados sintéticos são determinísticos. O mesmo CPF sintético produz o mesmo resultado hoje e daqui a seis meses, e ninguém pede para ser esquecido no meio da sua suíte de testes.
Quando a integração estiver pronta para sair daqui, o que muda entre os dois ambientes está em o checklist de go-live.
Perguntas Frequentes
Posso usar o meu próprio CPF no sandbox?
Pode. Testar o produto que você está construindo com os seus próprios dados — CPF, e-mail, telefone, até a sua biometria — é aceitável. O que não é aceitável é usar dado de outras pessoas, mesmo com o consentimento delas: o consentimento que elas deram foi para uma operação produtiva, não para entrar num ambiente de testes.
Que CPF sintético eu uso?
Depende do que o fluxo valida. Para fluxos que só conferem o formato, sequências de dígito repetido (00000000000, 11111111111) funcionam e não pertencem a ninguém. Para fluxos que validam dígito verificador, use um gerador de CPF de teste, que produz números com dígito correto e sem titular real.
E rosto, para testar biometria?
Rostos gerados por IA, de sites do tipo "esta pessoa não existe", resolvem o caso de imagem de referência — não correspondem a pessoa alguma. Para documentos de identidade, use modelos fictícios de RG ou CNH feitos para mockup; nunca a foto do seu documento real. E, em boa parte dos cenários, nem é preciso rosto: o sandbox simula os resultados biométricos.
Preciso mesmo de imagem para testar biometria?
Frequentemente não. O sandbox simula as verificações biométricas, e há campos para escolher o resultado — similaridade, confiança de vivacidade, qualidade da captura — o que permite exercitar aprovação e reprovação sem câmera e sem foto de ninguém. É o caminho descrito no guia de ensaio de reprovação.
Por quanto tempo os dados ficam em homologação?
As entidades da API — transações, envelopes e registros de evidência — expiram em 7 dias no ambiente de testes. Isso significa que identificadores de execuções antigas deixam de existir, o que é a causa clássica de testes automatizados que passam a falhar sozinhos por reaproveitarem ids. Crie objetos novos a cada execução.
Mandei dado real sem querer. O que faço?
Peça a eliminação imediata pelo canal do encarregado de dados, informando o client_id de homologação afetado, a janela de tempo do envio em UTC, o tipo de dado envolvido e a identidade do titular. Acontece — sobretudo em integrações com bug de roteamento — e o caminho existe justamente porque acontece.
Qual o bug de roteamento mais comum?
Não é técnico: é a demonstração ao vivo feita em homologação com dados reais do prospect. Depois dele, os campeões são variável de ambiente trocada, retry com fallback apontando para homologação, cache de token compartilhado entre ambientes e o cofre devolvendo credencial de homologação para um pipeline de produção.
Teste com dados que não pertencem a ninguém
CPFs sintéticos, rostos gerados, PDFs genéricos e e-mails descartáveis cobrem praticamente todo cenário de teste. As credenciais de homologação são gratuitas e não pedem cartão.
Criar credenciais de homologação Fale com o time comercial