Engenharia de Prompts para Massa de Dados: Escalando Testes com Cobertura e Sem Duplicidade utilizando LLMs

O uso de LLMs para a geração de dados sintéticos tornou-se uma estratégia atraente para equipes de QA que precisam escalar suas esteiras de testes. A promessa é tentadora: gerar centenas de registros complexos em segundos. No entanto, na prática, a geração automatizada sem direcionamento técnico introduz um risco crítico: a falsa sensação de cobertura.

Quando submetidas a prompts genéricos (como "gere 50 usuários para teste"), as LLMs tendem a operar dentro de padrões estatísticos previsíveis. O resultado é o efeito "João da Silva": um volume massivo de dados que testa repetidamente o "caminho feliz" (happy path), gerando duplicidade de cenários e deixando lacunas profundas em lógica de negócios complexas e cenários de borda (edge cases).

Para mitigar o viés do modelo e garantir a eficácia dos testes, o QA deve transicionar do papel de mero solicitante para o de orquestrador de cenários, aplicando técnicas tradicionais de teste diretamente na engenharia de prompts. A seguir, analisamos três padrões estruturados de prompts para resolver os problemas de cobertura e duplicidade.

1. O Padrão de Particionamento de Equivalência e Valores Limite

Para garantir cobertura sem inflar a base de dados com registros redundantes, o prompt deve forçar a LLM a aplicar técnicas de design de testes antes da geração do dado final. Esse padrão utiliza a abordagem de cadeia de pensamento (Chain-of-Thought), obrigando o modelo a mapear as classes de equivalência estruturalmente.

Exemplo de Prompt Estruturado:

Defina seu papel: Você é um Engenheiro de QA Sênior especializado em testes de API e validação de regras de negócio.

Contexto do Sistema: Estou testando o endpoint de aplicação de cupons de desconto de um e-commerce. As regras de negócio são:
1. Cupons do tipo "FIXO" exigem valor mínimo de compra de R$ 100,00.
2. Cupons do tipo "PERCENTUAL" aplicam-se a qualquer valor, mas têm teto máximo de desconto de R$ 50,00.
3. Cupons com data de validade expirada devem ser rejeitados.

Sua Tarefa:
1. Identifique e liste em uma tabelaMarkdown todas as Classes de Equivalência (Válidas e Inválidas) e os Valores Limite (Boundaries) para as regras acima.
2. Com base nessa tabela, gere exatamente UM payload JSON para cada cenário identificado. Cada cenário deve isolar uma variável de teste para garantir rastreabilidade.

Restrição: Não gere payloads duplicados para a mesma classe de equivalência. Foque na cobertura mínima necessária para testar todas as ramificações do código.

O que essa abordagem resolve:

• Cobertura: Garante que os valores exatos de transição de estado do código (ex: R$ 99,99, R$ 100,00 e R$ 100,01) sejam testados.
• Eficiência: Elimina dados redundantes dentro da mesma classe de equivalência, mantendo a suite de testes enxuta e performática.

2. O Padrão de Matriz de Transição de Estados (Contra a Duplicidade Comportamental)

Em sistemas orientados a eventos ou máquinas de estado (como fluxos de pagamento ou processamento de pedidos), os dados de teste precisam refletir a assincronicidade e o histórico do ciclo de vida da entidade. O erro comum é gerar dados que representam apenas o estado final ou inicial estável.

O prompt a seguir utiliza restrição de grafo para forçar a IA a cobrir caminhos de exceção e transições inválidas.

Exemplo de Prompt Estruturado:

Contexto: Sistema de gerenciamento de pedidos com os seguintes estados: [Criado, Pago, Faturado, Enviado, Entregue, Cancelado].

Diretriz de Geração: Gere uma massa de dados de teste em formato CSV que cubra a Matriz de Transição de Estados do sistema. 

A massa deve conter:
1. Cenários de Fluxo Linear (Transições válidas de ponta a ponta).
2. Cenários de Fluxo de Exceção (Transições válidas de desvio, ex: Criado -> Cancelado).
3. Cenários de Violação de Estado (Transições inválidas que o sistema deve rejeitar, ex: Tentar transicionar de 'Entregue' para 'Cancelado', ou de 'Criado' para 'Enviado' sem passar por 'Pago').

Colunas do CSV necessárias: id_pedido, estado_atual, estado_destino, payload_acao, resultado_esperado (Sucesso/Erro).

Regra estrita: Gere apenas uma linha por combinação única de 'estado_atual' -> 'estado_destino'. Proibido duplicar cenários ideais.

O que essa abordagem resolve:

• Prevenção de Duplicidade: Ao mapear a transição como uma chave única (estado_atual + estado_destino), impede-se que a LLM gere múltiplos registros para fluxos comuns, como pedidos padrão que já foram testados.
• Testes Negativos: Força a criação de dados para validação de resiliência e tratamento de erros do sistema.

---

3. O Padrão de Variabilidade Restrita (Negative Prompting)

A entropia das LLMs pode fazer com que elas gerem dados realistas, porém excessivamente homogêneos em sua distribuição (como utilizar sempre a mesma faixa de CEPs ou a mesma demografia). Para evitar que os testes fiquem tendenciosos, aplicamos restrições explícitas de variância e o conceito de Negative Prompting (o que o modelo está proibido de fazer).

Exemplo de Prompt Estruturado:

Tarefa: Gere um lote de 10 perfis de clientes em formato JSON para homologação de um sistema de análise de crédito.

Requisitos de Variabilidade:
1. Idade: Distribua uniformemente entre as faixas etárias de 18-25, 26-45, 46-60 e acima de 65 anos.
2. Localização: Utilize estados das cinco diferentes regiões do Brasil (Sul, Sudeste, Centro-Oeste, Nordeste, Norte).
3. Renda: Inclua variações de renda formal, informal e desempregados.

PROIBIÇÕES (Negative Prompt):
- NÃO utilize nomes fictícios óbvios ou genéricos (ex: "João da Silva", "Fulano de Tal", "Teste 1").
- NÃO repita a mesma combinação de Região e Faixa Etária em registros diferentes.
- NÃO utilize máscaras de documentos (CPF) idênticas ou sequenciais.

O que essa abordagem resolve:

• Eliminação de Viés Extrinseco: Garante que validações de front-end ou regras de backend baseadas em localização, ou limites numéricos amplos, lidem com dados semanticamente diversos.
• Determinismo Sintático: Reduz a necessidade de sanitização manual posterior dos dados gerados.

Conclusão: A Validação Determinística como Próximo Passo

A engenharia de prompts robusta mitiga a maior parte dos problemas de cobertura e duplicidade na geração de dados sintéticos, mas não elimina a necessidade de validação. Para cenários de larga escala em pipelines de CI/CD, a abordagem ideal combina a geração generativa estruturada (via LLM com os prompts acima) com uma camada de validação determinística.

O ganho de velocidade proporcionado pela IA só se traduz em eficiência real se os dados gerados forem intencionais. O papel do QA, portanto, evolui de escrever dados estáticos para codificar as regras de restrição que governam os modelos gerativos.

No contexto de testes de aplicações baseadas em IA (como testar um LLM, um classificador de machine learning ou um sistema de recomendação), a resposta curta é: depende do tipo de teste, mas na maioria das vezes, a duplicidade estrita (exata) ainda é indesejada. No entanto, a redundância semântica ou a repetição intencional de inputs assume um papel completamente diferente e legítimo do que em softwares tradicionais.

Artigo escrito auxiliado por Google Gemini