Gerador de CPF: dados sintéticos para automação de testes
Um CPF (Cadastro de Pessoas Físicas) é, do ponto de vista de um sistema de software, uma string de 11 dígitos onde os dois últimos são matematicamente derivados dos nove primeiros por um algoritmo de verificação. Isso significa que qualquer validador — seja uma regex no front-end, uma rotina de backend, ou uma constraint em nível de banco de dados — pode conferir a integridade formal do número sem precisar consultar nenhuma base externa. É justamente essa propriedade que torna o CPF um caso ideal de dado sintético: é possível gerar um número que passa em qualquer validação de formato, sem que ele corresponda a uma pessoa real, porque a validade do dígito verificador não implica existência do CPF na base da Receita Federal.
Casos de uso em automação de QA
Em suítes de teste end-to-end construídas com Selenium, Cypress ou
Playwright, formulários de cadastro que exigem CPF são um ponto de
atrito recorrente: usar um valor fixo hardcoded na suíte (como
111.444.777-35) funciona bem até o sistema sob teste impor
uma constraint de unicidade — nesse momento, execuções paralelas ou
reexecuções da mesma suíte passam a falhar por colisão, não por defeito
real na aplicação. A prática mais robusta é gerar um CPF novo e válido a
cada execução, seja chamando a API deste site
diretamente no beforeEach do teste, seja embutindo a mesma
lógica de geração como um fixture local. Isso elimina a
necessidade de limpar estado entre execuções e permite paralelização
segura de testes que dependem de cadastro de pessoa física.
O mesmo se aplica a testes de carga (k6, JMeter, Gatling): simular centenas de cadastros simultâneos exige centenas de CPFs distintos e válidos, já que a maioria das aplicações rejeita duplicidade antes mesmo de chegar à lógica de negócio — gerar o lote via Dataset em Massa resolve isso em um único export.
A matemática do dígito verificador (Módulo 11)
O CPF tem 11 posições. As primeiras 8 identificam o cidadão dentro da região fiscal de emissão, e a 9ª indica a própria região fiscal (0 para RS, 1 para DF/GO/MS/MT/TO, 8 para SP, e assim por diante). As posições 10 e 11 são os dígitos verificadores, calculados em duas passadas sucessivas do mesmo algoritmo:
Primeiro dígito — cada um dos 9 primeiros dígitos é
multiplicado por um peso decrescente, de 10 até 2 (o dígito na posição 1
é multiplicado por 10, o da posição 2 por 9, e assim sucessivamente até
o da posição 9, multiplicado por 2). Os 9 produtos são somados, e o
resultado é dividido por 11. Se o resto da divisão for 0 ou 1, o dígito
verificador é 0; caso contrário, o dígito é 11 - resto.
Segundo dígito — repete-se exatamente o mesmo processo, mas agora sobre os 10 dígitos já existentes (os 9 originais mais o primeiro dígito verificador recém-calculado), com pesos decrescentes de 11 até 2. A regra de conversão do resto para o dígito final é idêntica.
Formalmente, para uma sequência de dígitos d₁...dₙ, o
cálculo é soma = Σ dᵢ × (n + 2 - i), resto = soma mod 11,
e dv = resto < 2 ? 0 : 11 - resto. É exatamente essa
fórmula, implementada em PHP puro, que este gerador executa: os 9
primeiros dígitos são sorteados aleatoriamente (com a 9ª posição fixada
de acordo com o estado escolhido, quando aplicável), e os dois dígitos
verificadores são derivados deles — nunca o contrário. Por isso não é
possível "escolher" o CPF final: ele é consequência determinística da
base sorteada.
A verificação de CPFs com todos os dígitos iguais (000.000.000-00,
111.111.111-11 etc.) é tratada como um caso inválido à parte
— matematicamente esses números produzem dígitos verificadores
"corretos" pela fórmula acima, mas a Receita Federal nunca os emite, e um
validador correto precisa rejeitá-los explicitamente antes mesmo de
calcular o dígito. A ferramenta de validação
deste site aplica essa mesma checagem.
Por que isso importa para compliance
Usar CPFs de pessoas reais em ambientes de desenvolvimento, staging ou scripts de teste automatizado é um tratamento de dado pessoal fora da finalidade de coleta original, o que a LGPD trata como irregular independentemente de o dado ter sido obtido de forma lícita em algum outro contexto. Gerar CPFs sintéticos — estruturalmente válidos, mas sem vínculo com nenhum titular real — remove esse risco por completo: não há dado pessoal para vazar, porque não há pessoa por trás do número.