Por que gerar dados sintéticos é parte essencial do ciclo de desenvolvimento
Testar um sistema com dados reais é, na maioria dos cenários de engenharia de software, uma prática desaconselhada e, em muitos contextos regulatórios, proibida. Formulários de cadastro, integrações com gateways de pagamento, validadores de documentos e pipelines de importação em massa precisam ser exercitados sob uma variedade de entradas — válidas, malformadas, extremas — sem que isso exponha informação pessoal de clientes ou funcionários reais. O GeradoresOnline existe para preencher essa lacuna: produzir valores que obedecem à mesma estrutura formal e às mesmas regras de dígito verificador dos documentos brasileiros reais (CPF, CNPJ, PIS/PASEP, Título de Eleitor, RENAVAM, chave de acesso de NF-e, entre outros), mas que são gerados de forma aleatória e não correspondem a nenhuma pessoa física ou jurídica existente.
Testes de carga, integração contínua e povoamento de bancos relacionais
Em um pipeline de CI/CD, cada execução de suíte de testes de integração
tipicamente precisa de um conjunto de dados determinístico e reproduzível.
Depender de uma cópia do banco de produção para isso é operacionalmente
caro (volume, tempo de restore, necessidade de mascaramento) e
tecnicamente arriscado, já que dados de produção carregam informação
identificável que não deveria transitar por ambientes de desenvolvimento,
homologação ou execução de testes automatizados em runners de terceiros.
A alternativa é gerar massas de dados sintéticos sob demanda: preencher
tabelas com CPFs, CNPJs, e-mails, telefones e endereços estruturalmente
válidos, exercitar constraints de unicidade e chaves estrangeiras, e
descartar o conjunto ao final da execução. É exatamente esse o propósito
da ferramenta de Dataset em Massa
deste site, que exporta lotes de registros correlacionados (nome, CPF,
endereço, contato) em CSV, JSON ou instruções SQL prontas para um
INSERT em lote — útil tanto para testes de carga (medir
comportamento de índices e planos de execução com volume realista)
quanto para simplesmente povoar um ambiente de desenvolvimento local
logo após rodar as migrations.
O mesmo raciocínio se aplica a testes end-to-end de UI. Suítes escritas em Selenium, Cypress ou Playwright que precisam preencher formulários de cadastro repetidamente — em execuções paralelas, em pipelines que rodam dezenas de vezes por dia — não podem depender de uma lista fixa e curta de CPFs de teste hardcoded no código, porque isso frequentemente colide com regras de unicidade no banco de destino entre execuções concorrentes. Gerar um novo valor válido a cada execução, sob demanda e via API, resolve esse problema de colisão sem exigir lógica adicional de limpeza de estado entre testes.
Dados fictícios como mecanismo de compliance com a LGPD
A Lei Geral de Proteção de Dados (Lei nº 13.709/2018) estabelece que dados pessoais devem ter seu tratamento limitado à finalidade para a qual foram coletados. Ambientes de homologação, staging e desenvolvimento — que frequentemente têm controles de acesso mais permissivos, menos monitoramento e, por vezes, infraestrutura compartilhada com terceiros (serviços de CI, ferramentas de observabilidade, ambientes de demonstração para clientes) — não se enquadram na finalidade original de coleta de um dado de produção. Usar uma cópia de produção nesses ambientes sem anonimização caracteriza tratamento fora de finalidade e amplia desnecessariamente a superfície de exposição de um vazamento.
A prática recomendada, alinhada às diretrizes de anonimização discutidas pela ANPD, é substituir os campos identificáveis por valores sintéticos antes que o dado circule fora do ambiente de produção — nomes, documentos, e-mails, telefones e endereços fictícios que preservam a forma e o formato do dado original (e portanto não quebram validações de front-end nem constraints de banco), mas que são estruturalmente desvinculados de qualquer titular real. É essa a diferença entre pseudonimização (que mantém uma chave de reversibilidade) e anonimização de fato: os documentos gerados aqui não guardam nenhuma correspondência, reversível ou não, com uma pessoa real, porque nunca foram derivados de uma.
A lógica de validação por trás dos geradores
A maior parte dos documentos de identificação brasileiros — CPF, CNPJ,
PIS/PASEP, Título de Eleitor, RENAVAM — usa uma variação do algoritmo de
Módulo 11 para calcular um ou mais dígitos verificadores.
O princípio geral é o mesmo em todos os casos: cada dígito da base do
documento é multiplicado por um peso posicional (uma sequência de
multiplicadores definida pelo órgão emissor), os produtos são somados, o
resultado dessa soma é dividido por 11, e o resto da divisão é transformado
no dígito verificador através de uma regra de mapeamento (frequentemente
11 - resto, com casos especiais para resto 0, 1 ou 10, que
variam de documento para documento). Cartão de crédito segue uma lógica
diferente — o algoritmo de Luhn, que duplica dígitos em
posições alternadas e soma os dígitos dos produtos resultantes — e
IBAN usa checksum ISO 7064 (MOD 97-10), calculado sobre
a conversão de letras para números.
Cada ferramenta deste site implementa o algoritmo específico do documento correspondente no backend, em PHP, e o output já sai com o(s) dígito(s) verificador(es) corretos — o valor gerado passa em qualquer validador que implemente a mesma regra oficial, seja um validador de front-end em JavaScript, uma rotina de backend em uma API de terceiros, ou uma constraint de banco de dados. As páginas de cada gerador têm uma seção própria detalhando a fórmula exata usada naquele documento.