Dados de Teste para Sistemas Brasileiros: CPF, CNPJ e LGPD
Todo sistema brasileiro que cadastra pessoas ou empresas precisa lidar com documentos nacionais: CPF, CNPJ, RG, PIS, CNH. E todo desenvolvedor desses sistemas enfrenta o mesmo dilema na hora de testar: de onde tirar dados realistas sem violar a lei? Este artigo explica por que dados fictícios são a única resposta correta, o que a LGPD diz sobre isso, e como montar uma estratégia de massa de testes profissional.
O problema: testar exige dados, e dados reais são proibidos
Formulários precisam ser validados. Integrações fiscais precisam ser homologadas. Telas precisam ser demonstradas para clientes. Bancos de homologação precisam de milhares de registros para testes de carga. Em todos esses cenários, usar dados de pessoas reais — mesmo "só internamente" — cria riscos legais e de segurança consideráveis.
A prática antiga de copiar o banco de produção para homologação, comum até poucos anos atrás, tornou-se um passivo jurídico: ambientes de teste têm menos controles de segurança, mais gente com acesso, e vazamentos deles são tão graves quanto de produção perante a lei.
O que a LGPD diz (e as multas que prevê)
A Lei Geral de Proteção de Dados (Lei 13.709/2018) considera CPF, nome, endereço e dados bancários como dados pessoais — e seu tratamento exige base legal, finalidade específica e medidas de segurança. Usar dados reais de clientes em ambiente de teste raramente se enquadra em qualquer base legal legítima.
As sanções: advertência, multa de até 2% do faturamento (limitada a R$ 50 milhões por infração), bloqueio e eliminação dos dados, e — talvez pior — publicização da infração, com dano reputacional. A ANPD já aplicou sanções a empresas de todos os portes, incluindo pequenas.
A solução reconhecida pelo mercado: dados sintéticos — registros gerados artificialmente que parecem reais, passam nas validações, mas não correspondem a nenhuma pessoa.
Anatomia de uma boa massa de testes
Dados de teste profissionais precisam de três propriedades:
Validade estrutural: CPFs com dígitos verificadores corretos, CEPs que existem, e-mails com formato válido. Dados que falham na validação do próprio sistema não testam nada além da validação.
Realismo estatístico: nomes com distribuição parecida com a real (muitos Silvas e Marias, poucos nomes raros), idades plausíveis, coerência entre campos (DDD compatível com o estado do endereço). Sistemas se comportam diferente com dados realistas — problemas de layout com nomes longos, ordenações, buscas.
Marcação clara: todo registro sintético deveria ser identificável como tal (um campo `is_test`, um domínio de e-mail específico como @teste.exemplo). Isso evita o pesadelo clássico: dados de teste vazando para produção e disparando e-mails ou cobranças reais.
Os documentos brasileiros e seus algoritmos
Cada documento nacional tem seu algoritmo de validação, quase todos baseados em dígitos verificadores com pesos:
CPF: 11 dígitos, 2 verificadores, pesos decrescentes com módulo 11.
CNPJ: 14 dígitos, 2 verificadores, sequência de pesos própria. Inclui a estrutura matriz/filial (0001 para matriz).
PIS/PASEP: 11 dígitos, 1 verificador, pesos 3-2-9-8-7-6-5-4-3-2.
CNH: 11 dígitos, 2 verificadores com algoritmo próprio do DENATRAN.
RENAVAM: 11 dígitos, 1 verificador.
Título de eleitor: 12 dígitos, com código de estado embutido e 2 verificadores.
Gerar esses documentos corretamente exige implementar cada algoritmo — ou usar ferramentas prontas que já os implementam.
Estratégias por tipo de teste
Testes unitários: use poucos dados fixos e conhecidos (fixtures), incluindo casos de borda: CPFs válidos, inválidos, sequências repetidas, formatos com e sem máscara.
Testes de integração e E2E: gere dados dinâmicos a cada execução para evitar dependência de estado — mas com seed fixa quando a reprodutibilidade importar.
Testes de carga: gere volumes grandes (10 mil+ registros) previamente em CSV/JSON e alimente a ferramenta de carga (JMeter, k6, Locust). Gerar durante o teste distorce as métricas.
Demonstrações comerciais: use dados realistas e "bonitos" — nomes completos plausíveis, e-mails coerentes. Uma demo com "Teste Teste, teste@teste.com" passa amadorismo.
Homologação com terceiros: ao integrar com APIs fiscais (SEFAZ, prefeituras), use os dados de teste que o próprio órgão publica, quando existirem — muitos ambientes de homologação governamentais têm CNPJs e certificados de teste oficiais.
Ferramentas gratuitas para o dia a dia
Para gerar dados brasileiros válidos sem implementar cada algoritmo, nossas ferramentas gratuitas cobrem o ciclo completo: Gerador de CPF e Gerador de CNPJ para documentos em lote, Gerador de Pessoas para cadastros completos e coerentes (nome, e-mail, endereço, telefone), e os validadores correspondentes para conferir números individuais. Todas com API JSON documentada para integração direta em scripts e pipelines de teste.
Combine com bibliotecas de código aberto (Faker com localização pt_BR, validation-br para Node, pycpfcnpj para Python) quando precisar gerar dentro do próprio código de teste.