Come valutare, testare e gestire gli script FiveM

Testare uno script gratuito?

Gli script gratuiti vanno bene per controlli rapidi. Per server in produzione, confronta pacchetti server completi o script a pagamento mantenuti, in base al framework e al caso d'uso.

Questa guida semplice e intuitiva su come gestire gli script FiveM è rivolta a proprietari di server, sviluppatori e responsabili del controllo qualità. Otterrete una "Test City" in Docker, simile a quella di produzione, una checklist di accettazione eseguibile end-to-end, un modello di punteggio di rischio quantitativo e una rubrica di verifica dei fornitori che vi eviterà grattacapi.

In breve

• Girare su Città di prova (Docker) to isolate and benchmark any script safely.
• Esegui il Lista di controllo per l'accettazione prima che un centesimo cambi di mano.
• Utilizzare il Punteggio di rischio (0–100) per decidere se spedire/trattenere/respingere.
• Venditori veterinari con il Rubrica del fornitore (non saltare questo passaggio).
• Se decidi di acquistare, preferisci i negozi affidabili: dai un'occhiata alla nostra selezione: I migliori negozi Tebex.

---

Parte 1 — “Test City” (Docker) per un QA degli script sicuro e ripetibile

Cosa ottieni

• FXServer containerizzato + MariaDB (+ amministratore)
• Clean server.cfg con oxmysql e risorse di base
• Montato su legatura risorse/personalizzate dove si rilascia lo script in fase di test
• Nomi/porte di rete deterministici per stringhe DB semplici

Scarica test-city.zip (Github)

Come si usa:

1. Decomprimi → cd test-city
2. Copia .env.esempio A .ambiente e imposta il tuo CHIAVE_DI_LICENZA (e credenziali DB, se preferisci).
3. Gocciolare oxmysql in server-data/resources/[standalone]/oxmysql/.
4. Metti lo script in prova in server-data/resources/custom/ / e aggiungere garantire A server.cfg.
5. docker compose build && docker compose up -d → connettiti tramite Direct Connect a localhost:30120.

Prerequisiti: Docker + Docker Compose, una chiave di licenza cfx e un oxmysql copia della risorsa (rilasciare in server-data/resources/[standalone]/oxmysql).

Disposizione delle cartelle

test-city/ ├─ docker-compose.yml ├─ fxserver/ │ ├─ Dockerfile │ └─ entrypoint.sh ├─ server-data/ │ ├─ server.cfg │ └─ resources/ │ ├─ [standalone]/oxmysql/ # posiziona oxmysql qui │ └─ custom/ # posiziona qui lo script da testare (ad esempio, myscript/) └─ .env

.ambiente (esempio)

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 # Suggerimento: sostituisci con un URL di artefatto specifico di cui ti fidi per la riproducibilità.

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 (optional)
    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/*

# Fetch & extract FXServer artifact (URL provided 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

# Non-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/entrypoint.sh

#!/usr/bin/env bash set -euo pipefail # Fornisci la stringa DB per oxmysql tramite server.cfg (già impostata lì), # assicurati solo che il DB sia raggiungibile prima dell'avvio per evitare errori di spam. echo "In attesa del database..." until nc -z db 3306; do sleep 1; done echo "DB pronto." # Esegui FXServer con il nostro server.cfg # La maggior parte degli artefatti Linux include un file run.sh nella radice dell'artefatto. exec bash /opt/fivem/run.sh +exec /opt/fivem/server-data/server.cfg

Se il tuo artefatto utilizza un percorso di avvio diverso, modifica di conseguenza l'ultima riga (ad esempio, /opt/fivem/alpine/opt/cfx-server/run.sh).

server-data/server.cfg (snello, pronto per i test)

# ---------- Identity ----------
sv_licenseKey "%LICENSE_KEY%"            # injected by env in entrypoint command or replace manually
sv_hostname "Test City — Script QA"
sets tags "qa,testing,fivemx"
sv_maxclients 2
onesync on
sv_scriptHookAllowed 0
sv_enforceGameBuild 3095

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

# ---------- Database (oxmysql) ----------
set mysql_connection_string "mysql://%MYSQL_USER%:%MYSQL_PASSWORD%@db:3306/%MYSQL_DATABASE%?charset=utf8mb4"

# ---------- Core / Base resources ----------
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure hardcap
ensure baseevents

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

# ---------- Under test ----------
# Drop your script folder into resources/custom/<scriptname> and enable here:
# ensure myscript

# ---------- QA helpers ----------
# Verbose logging in dev
setr con_minSeverity info

# Enable txAdmin panel (optional)
setr txAdminPort 40120

Abilita il tuo script: copiarlo in server-data/resources/custom/myscript/ e aggiungere assicurati che il mio script al blocco inferiore.

Eseguilo

cd test-city docker compose build docker compose up -d # Adminer su http://localhost:8080 (server: db, utente: fivem, pass: fivempw) # Connetti il client FiveM → Connessione diretta: your-docker-host:30120

---

Parte 2 — Lista di controllo per l'accettazione dello script (da non saltare)

Usalo ogni volta. Copialo nel tuo tracker e spunta gli elementi.

A. Pre-volo (prima dell'installazione)

• Tipo di fonte: Open source / parzialmente aperto / solo deposito a garanzia.
• Dipendenze elencate: framework (ESX/QBCore/QBOX), ox_lib, oxmysql, PolyZone, ecc.
• fxmanifest.lua: lua54 'sì', corretto gioco 'gta5', versione fx non antico.
• Documenti: passaggi di installazione, esempi di configurazione, permessi, impostazioni locali, conflitti noti.
• Licenza/Termini di servizio: diritti di utilizzo, politica di rimborso, aggiornamenti, canale di supporto.

B. Installabilità

• Nessun errore della console attivo garantire: zero stack trace o spam di risorse mancanti.
• NO nativi deprecati spam.
• La configurazione viene caricata pulita: nessun errore di sintassi JSON/Lua.
• Migrazioni DB: crea le tabelle una volta sola; i riavvii non vengono riapplicati né interrotti.

C. Funzionale

• Nucleo flows work: percorso felice testato (ad esempio, acquisto, flusso di lavoro, creazione).
• Casi limite: input errati, permessi mancanti, quantità fuori intervallo.
• Localizzazione: nessuna stringa hard-coded se le impostazioni locali sono state promesse.
• Permessi: comandi staff/admin limitati; nessun accesso libero lato client.

D. Prestazioni (client e server)

• resmon: inattivo ≤ 0,10 ms, attivo ≤ 0,50 ms (cliente).
• Stato di salute del server: nessun avviso di rallentamento prolungato in condizioni di utilizzo normali.
• Query DB: nessun ciclo stretto; vengono utilizzate istruzioni preparate; minimo N+1.

E. Sicurezza

• Convalida lato server: ogni evento del server convalida fonte, permessi e tipi di input.
• Nessuna fiducia nel cliente: le modifiche di denaro/inventario dipendono solo dalla logica del server.
• Nessuna valutazione/stringa di carico/codice remoto modelli.
• Anti-abuso: limiti di velocità/restrizioni sugli endpoint spam.
• Integrità del deposito a garanzia: nessuna backdoor nei caricatori di configurazione non escrow.

Buon modello di evento (esempio):

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) -- adattatore framework if not xPlayer then return end -- convalida il prezzo lato server, controlla i limiti di inventario, esegui DB in una transazione end)

F. Compatibilità e pulizia

• Adattatori Framework presenti (ESX/QBCore/QBOX) o chiaramente dichiarati non supportati.
• Nessuna perdita globale, nomi di eventi univoci, nessuna ipotesi sul nome della risorsa.
• Disinstalla pulito: la rimozione della risorsa non danneggia le altre.

---

Parte 3 — Modello di punteggio del rischio quantitativo (0–100)

Usalo per decidere "spedire/trattenere/rifiutare". Più basso è, meglio è.

Fattore	Peso	Come assegnare un punteggio (0=buono → 5=cattivo)
Prestazione	0.20	resmon idle: 0=≤0.10ms, 1=≤0.20, 3=≤0.50, 5=>0.50; spikes add +1
Sicurezza	0.25	0=tutto convalidato dal server + limiti di velocità; 3=alcune lacune; 5=si fida del client/eventi non sicuri
Stabilità	0.15	0=nessun errore; 3=avvisi occasionali; 5=errori/inconvenienti frequenti
Compatibilità	0.10	0=adattatori/test; 3=solo un framework; 5=interrompe le dipendenze comuni
Manutenibilità	0.10	0=documentazione/registro delle modifiche/versioni semantiche; 5=nessuna documentazione/abbandonato
Catena di fornitura/Fornitore	0.20	0=reputabile, storico, rimborsi; 5=sconosciuto, nessuna politica

Formula

Punteggio di rischio = 100 * Σ(peso_i * (punteggio_i / 5))

Bande e azioni

• 0–24 (Basso): Spedire al punto di raccolta, monitorare.
• 25–49 (moderato): Correzioni necessarie prima della pubblicazione.
• 50–74 (Alto): Sospendi; richiedi patch del fornitore o sostituisci.
• 75–100 (Critico): Rifiutare.

Esempio

• Perf=1, Sec=3, Stabilità=1, Compat=1, Manut=2, Fornitore=1
• Rischio = 100*(.2*.2 + .25*.6 + .15*.2 + .1*.2 + .1*.4 + .2*.2) = 34 → Moderato

---

Parte 4 — Rubrica di verifica del fornitore (punteggio da 0 a 5, più alto è Meglio)

Criterio	Che aspetto ha il “buono”	Note
Identità e precedenti penali	Marchio chiaro, anni di attività, gestione coerente	Evitare i negozi di bruciatori
Documentazione	Installazione + configurazione + permessi + risoluzione dei problemi	Aiuto per screenshot/gif
Aggiorna Cadence	Changelog, versioni semantiche, commit/release recenti	Quarterly+ va bene
Supporto di qualità	SLA per ticket/Discord, correzioni riproducibili, non solo "riavvio"	Esempi di risposte
Trasparenza delle questioni	Problemi noti pubblici e roadmap	Onestà > perfezione
Chiarezza sui rimborsi/Termini di servizio	Finestra di rimborso, condizioni, termini di licenza	Nessun modello oscuro
Prova di prova	Video di staging, metriche di prestazione, elenco framework	Ancora meglio: server demo
Igiene della sicurezza	Menziona controlli lato server, nessuna chiave sensibile, nessuna valutazione	Richiedi informazioni sugli audit
Politica di compatibilità	ESX/QBCore/QBOX dichiarati, adattatori, matrice delle versioni	Build supportate dallo Stato
Prezzi e valore	Giusto per la complessità, nessun paywall di dipendenza	Fai attenzione alle trappole dell'upsell

Punteggio della rubrica (0–50):

• 40–50: Forte — fornitore preferito
• 30–39: Accettabile — monitor
• 20–29: Debole — procedere con cautela
• <20: Evitare

Consiglio da professionista: Fai un confronto con marketplace affidabili. Inizia qui: I migliori negozi Tebex.

---

Parte 5 — Manuale di manutenzione (dopo la spedizione)

1. Versione pinning: versioni di script di blocco + versioni di dipendenza (ad esempio, oxmysql, ox_lib).
2. Prima messa in scena: tutti gli aggiornamenti atterrano in Città di prova; eseguire nuovamente la checklist di accettazione.
3. Backup e rollback: Snapshot del DB + file di risorse prima di ogni aggiornamento. Conservare un Rollback.md con passaggi esatti.
4. Test del fumo CI (facoltativo, consigliato): connessione client headless + macro di comando per raggiungere i flussi principali; analizzare la console del server per individuare eventuali errori.
5. Metriche operative: tenere un registro semplice per ogni script: resoconto medio (inattivo/attivo), conteggio degli errori/sessione, note sugli incidenti.
6. Disciplina del registro delle modifiche: richiedere i registri delle modifiche del fornitore; mantenere le proprie note di integrazione.
7. Ridurre i rischi degli eventi programmati: aggiornamenti al di fuori delle ore di punta; annuncia finestre di manutenzione.

---

Parte 6 — Modelli che puoi copiare

A. Piano di test (per script)

# Script Test Plan — <name> <version>

## Context
Framework(s): ESX/QBCore/QBOX
Dependencies: oxmysql vX, ox_lib vY, PolyZone vZ
DB Migrations: yes/no
Escrow: yes/no

## Functional Cases
- [ ] Case 1:
- [ ] Case 2:
- [ ] Negative 1:

## Performance
resmon idle: ____ ms
resmon active: ____ ms (scenario: ______)

## Security Checks
- [ ] All server events validate source/perm/input
- [ ] Rate limits present
- [ ] No client-trusted money/inventory mutations

## Logs & Errors
Paste snippet (server + F8): 

## Result
Pass/Fail + Notes

B. Rollback.md (scheletro)

# Rollback — <date> <script> <from→to>

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

C. Modello di problema

**Riepilogo** Cosa è successo rispetto a quanto previsto, con timestamp. **Passaggi di riproduzione** 1) ... 2) ... **Ambiente** Build dell'artefatto: Framework e versioni: Versione dello script: Altre dipendenze: **Log** Console del server: F8: **Allegati** Schermate/video se possibile.

---

Come utilizzare questa guida in modo efficiente

1. Bootstrap Test City una volta, tienilo pulito.
2. Per ogni copione candidato:
   • Lasciati cadere risorse/personalizzate/, abilitare in server.cfg.
   • Esegui il Lista di controllo per l'accettazione.
   • Calcola il Punteggio di rischio.
   • Controlla il venditore con il Rubrica del fornitore.
3. Se il problema viene superato, unisciti alla fase di staging; in caso contrario, richiedi delle correzioni o abbandona il progetto.

---

Hai bisogno di altre guide sui test? Dai un'occhiata alla sezione