Economize 20% com WELCOMEVer ofertas
Como avaliar, testar e manter scripts FiveM

Como Avaliar e Testar FiveM Scripts Antes de Comprar

Antes de comprar ou instalar um script FiveM, teste-o como um líder de QA: execute-o em um Docker “Test City” isolado, siga a lista de verificação de aceitação, pontue o risco de 0-100 e avalie o fornecedor antes que o dinheiro mude de mãos. Este guia fornece aos proprietários de servidores e desenvolvedores o fluxo de trabalho completo — um stack docker compose FXServer + MariaDB para copiar e colar, limites de desempenho do resmon, verificações de segurança e um playbook de manutenção para depois que você enviar.

Resumo

  • Gire para cima Cidade de Teste (Docker) para isolar e comparar qualquer script com segurança.
  • Execute o Lista de verificação de aceitação antes que um centavo mude de mãos.
  • Use o Pontuação de risco (0–100) para decidir enviar/manter/rejeitar.
  • Vendedores veterinários com o Rubrica do Fornecedor (não pule isso).
  • Se for comprar, prefira lojas de boa reputação — veja nossas escolhas: Melhores Lojas Tebex.

Parte 1 — “Test City” (Docker) para garantia de qualidade de scripts segura e repetível

O que você ganha

  • FXServer em contêiner + MariaDB (+ Administrador)
  • Limpar servidor.cfg com oxmysql e recursos básicos
  • Montado em encadernação recursos/personalizados onde você solta o script em teste
  • Nomes/portas de rede determinísticos para strings de banco de dados simples

Baixe test-city.zip (Github)

Como usar o Docker (FiveM)

Modo de usar:

  1. Descompactar → cd test-city
  2. Cópia .env.exemplo para .env e defina seu CHAVE_DE_LICENÇA (e credenciais de banco de dados, se preferir).
  3. Derrubar oxmysql em dados do servidor/recursos/[autônomo]/oxmysql/.
  4. Coloque o script em teste em dados do servidor/recursos/personalizado/ / e adicione garantir para servidor.cfg.
  5. docker compose build && docker compose up -d → conectar via Direct Connect para host local:30120.

Pré-requisitos: Docker + Docker Compose, uma chave de licença cfx e um oxmysql cópia do recurso (coloque em dados do servidor/recursos/[autônomo]/oxmysql).

Layout de pasta

test-city/
├─ docker-compose.yml
├─ fxserver/
│ ├─ Dockerfile
│ └─ entrypoint.sh
├─ server-data/
│ ├─ server.cfg
│ └─ resources/
│ ├─ [standalone]/oxmysql/ # coloque o oxmysql aqui
│ └─ custom/ # coloque o script em teste aqui (ex.: myscript/)
└─ .env

.env (exemplo)

LICENSE_KEY=changeme_cfx_license_key MYSQL_DATABASE=fivem MYSQL_USER=fivem MYSQL_PASSWORD=fivempw MYSQL_ROOT_PASSWORD=rootpw FX_ARTIFACT_URL=https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/LATEST.tar.xz # Dica: substitua por uma URL de artefato específica em que você confia para reprodutibilidade.

docker-compose.yml

version: "3.9"

networks:
 testcity:

volumes:
 db_data:

services:
 db:
 image: mariadb:10.11
 restart: unless-stopped
 environment:
 MYSQL_DATABASE: ${MYSQL_DATABASE}
 MYSQL_USER: ${MYSQL_USER}
 MYSQL_PASSWORD: ${MYSQL_PASSWORD}
 MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
 command: >
 --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
 --innodb_buffer_pool_size=256M
 volumes:
 - db_data:/var/lib/mysql
 networks: [testcity]

 adminer:
 image: adminer:4
 restart: unless-stopped
 ports:
 - "8080:8080"
 networks: [testcity]
 depends_on: [db]

 fxserver:
 build:
 context: ./fxserver
 args:
 FX_ARTIFACT_URL: ${FX_ARTIFACT_URL}
 restart: unless-stopped
 environment:
 LICENSE_KEY: ${LICENSE_KEY}
 MYSQL_DATABASE: ${MYSQL_DATABASE}
 MYSQL_USER: ${MYSQL_USER}
 MYSQL_PASSWORD: ${MYSQL_PASSWORD}
 depends_on: [db]
 networks: [testcity]
 ports:
 - "30120:30120/udp"
 - "30120:30120/tcp"
 - "40120:40120/tcp" # txAdmin (opcional)
 volumes:
 - ./server-data:/opt/fivem/server-data

fxserver/Dockerfile

FROM debian:bookworm-slim

ARG FX_ARTIFACT_URL
ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y --no-install-recommends 
 xz-utils curl ca-certificates tini bash && 
 rm -rf /var/lib/apt/lists/*

# Baixar e extrair o artefato FXServer (URL fornecida via build-arg)
RUN mkdir -p /opt/fivem && 
 curl -fsSL "${FX_ARTIFACT_URL}" -o /opt/fivem/fx.tar.xz && 
 tar -xJf /opt/fivem/fx.tar.xz -C /opt/fivem && 
 rm -f /opt/fivem/fx.tar.xz

# Não-root
RUN useradd -ms /bin/bash fivem
USER fivem

WORKDIR /opt/fivem
COPY --chown=fivem:fivem ../server-data /opt/fivem/server-data
COPY --chown=fivem:fivem entrypoint.sh /entrypoint.sh

ENTRYPOINT ["/usr/bin/tini","--"]
CMD ["/bin/bash","/entrypoint.sh"]

fxserver/ponto de entrada.sh

#!/usr/bin/env bash set -euo pipefail # Fornece string de BD para oxmysql via server.cfg (já definida lá), # apenas garante que o BD esteja acessível antes da inicialização para evitar erros de spam. echo "Aguardando banco de dados..." until nc -z db 3306; do sleep 1; done echo "BD pronto." # Executa o FXServer com nosso server.cfg # A maioria dos artefatos do Linux envia um run.sh na raiz do artefato. exec bash /opt/fivem/run.sh +exec /opt/fivem/server-data/server.cfg

Se o seu artefato usar um caminho de iniciador diferente, ajuste a última linha de acordo (por exemplo, /opt/fivem/alpine/opt/cfx-server/run.sh).

dados do servidor/servidor.cfg (enxuto, pronto para testes)

# ---------- Identidade ----------
sv_licenseKey "%{LICENSE_KEY}%" # injetado pelo env no comando entrypoint ou substitua manualmente
sv_hostname "Test City — QA de Script"
sets tags "qa,testing,fivemx"
sv_maxclients 2
onesync on
sv_scriptHookAllowed 0
sv_enforceGameBuild 3095

# ---------- Rede ----------
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# ---------- Banco de Dados (oxmysql) ----------
set mysql_connection_string "mysql://%{MYSQL_USER}%:%{MYSQL_PASSWORD}%@db:3306/%{MYSQL_DATABASE}%?charset=utf8mb4"

# ---------- Recursos Principais ----------
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure hardcap
ensure baseevents

# ---------- Datastore ----------
ensure oxmysql

# ---------- Em Teste ----------
# Coloque sua pasta de script em resources/custom/ e habilite aqui:
# ensure myscript

# ---------- Auxiliares de QA ----------
# Logs detalhados em dev
setr con_minSeverity info

# Habilitar painel txAdmin (opcional)
setr txAdminPort 40120

Habilite seu script: copie-o para dados do servidor/recursos/personalizado/myscript/ e adicione garantir meu script para o bloco inferior.

Execute-o

cd test-city docker compose build docker compose up -d # Administrador em http://localhost:8080 (servidor: db, usuário: fivem, senha: fivempw) # Conectar cliente FiveM → Conexão direta: your-docker-host:30120

Parte 2 — Lista de verificação de aceitação do roteiro (não pule)

Use isso sempre. Copie para o seu rastreador e marque os itens.

A. Pré-voo (antes da instalação)

  • Tipo de fonte: Código aberto / parcialmente aberto / somente custódia.
  • Dependências listadas: estrutura (ESX/QBCore/QBOX), boi_lib, oxmysql, PoliZona, etc.
  • fxmanifest.lua: lua54 'sim', correto jogo 'gta5', versão_fx não antigo.
  • Documentação: etapas de instalação, exemplos de configuração, permissões, localidades, conflitos conhecidos.
  • Licença/Termos de Serviço: direitos de uso, política de reembolso, atualizações, canal de suporte.

B. Instalabilidade

  • Nenhum erro de console em garantir: nenhum rastreamento de pilha ou spam de ativos ausentes.
  • Não nativos depreciados spam.
  • Carregamentos de configuração limpos: sem erros de sintaxe JSON/Lua.
  • Migrações de banco de dados: crie tabelas uma vez; reinicializações não reaplicam nem interrompem.

C. Funcional

  • Essencial fluxos de trabalho: caminho feliz testado (por exemplo, compra, fluxo de trabalho, criação).
  • Casos extremos: entradas erradas, permissões ausentes, quantidades fora do intervalo.
  • Localização: nenhuma sequência de caracteres codificada se as localidades forem prometidas.
  • Permissões: comandos de equipe/administrador restritos; sem acesso livre do lado do cliente.

D. Desempenho (cliente e servidor)

E. Segurança

  • Validação do lado do servidor: cada evento do servidor valida fonte, permissões e tipos de entrada.
  • Nenhuma confiança no cliente: mudanças de dinheiro/inventário somente pela lógica do servidor.
  • Nenhuma avaliação/cadeia de carga/código remoto padrões.
  • Antiabuso: limites de taxa/limitações em endpoints de spam.
  • Integridade do depósito em garantia: sem backdoors em carregadores de configuração não-escrow.

Bom padrão de evento (exemplo):

RegisterNetEvent('myscript:buy', function(item, amount)
 local src = source
 if type(item) ~= 'string' or type(amount) ~= 'number' or amount < 1 then return end
 if not HasPermission(src, 'shop.buy') then return end
 local xPlayer = GetPlayer(src) -- adaptador de framework
 if not xPlayer then return end
 -- validar preço no servidor, verificar limites de inventário, fazer DB em uma transação
end)

F. Compatibilidade e Limpeza

  • Adaptadores de estrutura presentes (ESX/QBCore/QBOX) ou claramente declarado sem suporte.
  • Nenhum vazamento global, nomes de eventos exclusivos, sem suposições de nomes de recursos.
  • Desinstalar limpo: remover o recurso não quebra os outros.

Parte 3 — Modelo de pontuação de risco quantitativo (0–100)

Use isso para decidir "enviar/manter/rejeitar". Quanto menor, melhor.

FatorPesoComo pontuar (0=bom → 5=ruim)
Desempenho0.20resmon ocioso: 0=≤0,10ms, 1=≤0,20, 3=≤0,50, 5=>0,50; picos adicionam +1
Segurança0.250=todos os limites de taxa + validados pelo servidor; 3=algumas lacunas; 5=confia no cliente / eventos inseguros
Estabilidade0.150=sem erros; 3=avisos ocasionais; 5=erros/problemas frequentes
Compatibilidade0.100=adaptadores/testes; 3=apenas uma estrutura; 5=quebra dependências comuns
Manutenibilidade0.100=documentação/registro de alterações/versões semânticas; 5=sem documentação/abandonado
Cadeia de suprimentos/Fornecedor0.200=reputável, histórico, reembolsos; 5=desconhecido, sem política

Fórmula

Pontuação de Risco = 100 * Σ(peso_i * (pontuação_i / 5))

Bandas e Ações

  • 0–24 (baixo): Enviar para preparação, monitorar.
  • 25–49 (Moderado): Correções necessárias antes do lançamento.
  • 50–74 (Alto): Esperar; solicitar patches do fornecedor ou substituir.
  • 75–100 (Crítico): Rejeitar.

Exemplo

  • Perf=1, Sec=3, Estabilidade=1, Compat=1, Manutenção=2, Fornecedor=1
  • Risco = 100*(.2*.2 + .25*.6 + .15*.2 + .1*.2 + .1*.4 + .2*.2) = 34 → Moderado

Parte 4 — Rubrica de verificação de fornecedores (pontuação de 0 a 5 para cada um, quanto maior for melhorar)

CritérioComo é o "bom"Notas
Identidade e HistóricoMarca clara, anos de atividade, manuseio consistenteEvite lojas de produtos descartáveis
DocumentaçãoInstalar + configurar + permissões + solução de problemasAjuda com capturas de tela/gifs
Atualizar cadênciaLog de alterações, versões semânticas, confirmações/lançamentos recentesTrimestral+ está bom
Qualidade de suporteSLAs de tickets/Discord, correções reproduzíveis, não apenas “reiniciar”Respostas de exemplo
Transparência de EmissãoProblemas públicos conhecidos e roteiroHonestidade > perfeição
Clareza sobre reembolso/ToSPeríodo de reembolso, condições, termos de licençaSem padrões escuros
Prova de testeVídeo de preparação, métricas de desempenho, lista de estruturasMelhor ainda: servidor de demonstração
Segurança HigieneMenciona verificações do lado do servidor, sem chaves sensíveis, sem avaliaçãoPergunte sobre auditorias
Política de compatibilidadeESX/QBCore/QBOX declarado, adaptadores, matriz de versãoConstruções apoiadas pelo estado
Preço e valorJusto em termos de complexidade, sem paywalls de dependênciaCuidado com as armadilhas de upsell

Pontuação da rubrica (0–50):

  • 40–50: Forte — fornecedor preferencial
  • 30–39: Aceitável — monitor
  • 20–29: Fraco — prossiga com cautela
  • <20: Evitar

Dica profissional: Faça uma referência cruzada com marketplaces confiáveis. Comece aqui: Melhores Lojas Tebex.

Parte 5 — Manual de Manutenção (Após o Envio)

  1. Fixação de versão: lançamentos de script de bloqueio + versões de dependência (por exemplo, oxmysql, boi_lib).
  2. Primeira preparação: todas as atualizações chegam Cidade de Teste; execute a lista de verificação de aceitação novamente.
  3. Backups e reversão: Instantâneo do banco de dados + arquivos de recursos antes de cada atualização. Mantenha um Rollback.md com passos exatos.
  4. Teste de fumaça de CI (opcional, recomendado): conexão de cliente sem interface + macro de comando para atingir os fluxos principais; analisar o console do servidor em busca de erros.
  5. Métricas operacionais: mantenha um registro simples por script: média de respostas (ocioso/ativo), contagem de erros/sessão, notas de incidentes.
  6. Disciplina de registro de alterações: exigir registros de alterações do fornecedor; manter suas próprias notas de integração.
  7. Eventos programados sem risco: atualizar fora dos horários de pico; anunciar janelas de manutenção.

Parte 6 — Modelos que você pode copiar

A. Plano de Teste (por script)

Plano de teste de script # — ## Framework(s) de Contexto: ESX/QBCore/QBOX Dependências: oxmysql vX, ox_lib vY, PolyZone vZ Migrações de Banco de Dados: sim/não Escrow: sim/não ## Casos Funcionais - [ ] Caso 1: - [ ] Caso 2: - [ ] Negativo 1: ## Desempenho resmon ocioso: ____ ms resmon ativo: ____ ms (cenário: ______) ## Verificações de Segurança - [ ] Todos os eventos do servidor validam origem/permissão/entrada - [ ] Limites de taxa presentes - [ ] Nenhuma mutação de dinheiro/estoque confiável para o cliente ## Logs e Erros Cole o trecho (servidor + F8): ## Resultado Aprovado/Reprovado + Observações

B. Rollback.md (esqueleto)

Reversão do # — 

1) Disable script: `stop `
2) Restore resource files from backup: 
3) Restore DB snapshot: 
4) Restart FXServer
5) Verify: console clean, perf normal, flows ok

C. Modelo de Problema

**Resumo** O que aconteceu versus o esperado, com registros de data e hora. **Etapas de reprodução** 1) ... 2) ... **Ambiente** Construção do artefato: Estrutura e versões: Versão do script: Outras dependências: **Logs** Console do servidor: F8: **Anexos** Telas/vídeo, se possível.

Como usar este guia com eficiência

  1. Cidade de teste Bootstrap uma vez, mantenha-o limpo.
  2. Para cada script candidato:
    • Cair em recursos/personalizado/, habilitar em servidor.cfg.
    • Execute o Lista de verificação de aceitação.
    • Calcular o Pontuação de Risco.
    • Verifique o vendedor com o Rubrica do Fornecedor.
  3. Se for aprovado, entre na preparação; caso contrário, solicite correções ou vá embora.

Precisa de mais guias de testes? Aprenda a medir o desempenho do script com Resmon em FiveM, corrigir avisos de engate de thread do servidor, e construir o servidor de teste Parte 1 com Docker para FiveM.

Depois que o fluxo de trabalho de teste estiver pronto, compare o framework exato, dependências, arquivos entregues e notas de configuração no marketplace de scripts FiveM.