Como testar uma API compatível com OpenAI

Guia de produção: Como testar uma API compatível com OpenAI. Inclui artefato determinístico, limites de falha, controles de rollout e fontes verificadas.

Guia de produção: Como testar uma API compatível com OpenAI. Inclui artefato determinístico, limites de falha, controles de rollout e fontes verificadas.

Decisão primeiro

Como testar uma API compatível com OpenAI é um contrato explícito de produção, não uma mudança isolada. Defina sucesso, falha terminal e rollback antes de mover tráfego; o artefato separa evidência de suposição.

Comece por text, prove stream com um caso determinístico e transforme errors em gate de release.

Artefato reutilizável

Uma linha só passa quando a evidência vem da mesma requisição, janela de teste ou versão de configuração.

Checkpoint Evidência Condição de aprovação
text non-stream_response,finish_state,empty_and_Unicode_input O valor é preservado e comparado exatamente na fronteira do protocolo.
stream SSE_event_order,terminal_marker,usage_placement,disconnect O registro une uma requisição lógica e uma tentativa.
tools single_and_parallel_calls,argument_schema,call_correlation O registro une uma requisição lógica e uma tentativa.
schema valid_object,refusal,truncation,unsupported_keyword O limite é explícito e falha de modo fechado.
usage input,output,cache_read/write,missing_categories Reserva, observação e valor final conciliam no ledger durável.
errors 401,403,429,499,5xx_outer_and_embedded_failures Owner, fonte, data e limitação ficam registrados.

Exemplo resolvido

O exemplo é sintético e determinístico. Use valores revisados do seu workload; nunca inclua segredos ou dados de clientes.

corpus_version: 1
cases:
  - id: text/non_stream_zero_values
    request: { stream: false, temperature: 0 }
    assert: [http_status, response_shape, explicit_zero_preserved]
  - id: stream/disconnect
    action: cancel_after_first_content_delta
    assert: [client_cancelled, upstream_cancelled, terminal_state_recorded]
  - id: tools/two_calls
    assert: [stable_call_ids, arguments_validated, results_correlated]
  - id: errors/rate_limit
    assert: [status_429, retry_after_parsed, attempt_budget_respected]

Procedimento de implementação

  1. Congele requisição, resposta, configuração e baseline observável.
  2. Execute um caso positivo determinístico e preserve o resultado completo.
  3. Execute o caso negativo ou limite correspondente.
  4. Una tentativas por um request ID lógico e registre tempo, estado final e uso sem conteúdo sensível.
  5. Faça rollout em coorte limitada com critérios de parada.
  6. Releia estado durável e comportamento público; reverta se uma invariante falhar.

Modos de falha

Estas falhas invalidam o resultado mesmo quando o HTTP externo parece correto:

  • Uma resposta de texto é tratada como prova de compatibilidade completa.
  • Um 0 ou false explícito some na serialização.
  • Um campo conveniente é lido e outputs tipados, tools, recusas ou resultados parciais são perdidos.
  • Retries sem orçamento amplificam a carga.

Limite do Modelflare

Modelflare centraliza routing compatível com OpenAI, chaves, grupos, uso e falhas, mas uma rota configurada não prova capacidades opcionais. Verifique modelo e canal pelo protocolo nativo, preserve zeros explícitos e use a liquidação durável como verdade de billing.

Use o guia principal para a decisão mais ampla e a documentação para a configuração atual.

Checklist de publicação

  • Responder primeiro à pergunta principal.
  • Definir owner para cada campo, estado, métrica e fórmula.
  • Usar apenas identificadores sintéticos.
  • Preservar estrutura, código, limites e avisos em todos os idiomas.
  • Revalidar contratos, suporte e preços em T-1; mover a data se algo mudar.
  • Antes do horário, excluir de API pública, rotas e sitemap.

Fontes e data de verificação

Fontes verificadas em 2026-08-07; elas não provam uma rota não testada.