Test FiveM Scripts Before You Buy: QA & Risk Checklist

Before you buy or install a FiveM script, test it like a QA lead: run it in an isolated Docker “Test City”, work through the acceptance checklist, score the risk from 0-100, and vet the vendor before money changes hands. This guide gives server owners and developers the full workflow — a copy-paste FXServer + MariaDB docker compose stack, resmon performance limits, security checks, and a maintenance playbook for after you ship.

In breve

Girare su Città di prova (Docker) per isolare e fare benchmark di qualsiasi script in modo sicuro.
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)
Pulito server.cfg con oxmysql e risorse di base
Montato su legatura resources/custom dove si rilascia lo script in fase di test
Nomi/porte di rete deterministici per stringhe DB semplici

Scarica test-city.zip (Github)

Come Usare Docker (FiveM)

Come si usa:

Decomprimi → cd test-city
Copia .env.example A .env e imposta il tuo LICENSE_KEY (e credenziali DB, se preferisci).
Gocciolare oxmysql in server-data/resources/[standalone]/oxmysql/.
Metti lo script in prova in server-data/resources/custom/<scriptname>/ e aggiungere ensure <scriptname> A server.cfg.
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/ # place oxmysql here
│ └─ custom/ # put the script under test here (e.g., myscript/)
└─ .env

`.env` (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
# Tip: replace with a specific artifact URL you trust for reproducibility.

`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

# Provide DB string for oxmysql via server.cfg (already set there),
# just ensure the DB is reachable before boot to avoid spam errors.
echo "Waiting for database..."
until nc -z db 3306; do sleep 1; done
echo "DB ready."

# Run FXServer with our server.cfg
# Most Linux artifacts ship a run.sh in the artifact root.
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 ensure myscript al blocco inferiore.

Eseguilo

cd test-city
docker compose build
docker compose up -d
# Adminer at http://localhost:8080 (server: db, user: fivem, pass: fivempw)
# Connect FiveM client → Direct Connect: 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 'yes', corretto game 'gta5', fx_version 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 ensure: zero stack trace o spam di risorse mancanti.
NO deprecated natives 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 i flussi funzionano: 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 source, permessi e tipi di input.
Nessuna fiducia nel cliente: le modifiche di denaro/inventario dipendono solo dalla logica del server.
Nessuna valutazione/loadstring/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) -- framework adapter
 if not xPlayer then return end
 -- validate price server-side, check inventory limits, do DB in a transaction
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 inattivo: 0=≤0.10ms, 1=≤0.20, 3=≤0.50, 5=>0.50; i picchi aggiungono +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

RiskScore = 100 * Σ(weight_i * (score_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)

Versione pinning: versioni di script di blocco + versioni di dipendenza (ad esempio, oxmysql, ox_lib).
Prima messa in scena: tutti gli aggiornamenti atterrano in Città di prova; eseguire nuovamente la checklist di accettazione.
Backup e rollback: Snapshot del DB + file di risorse prima di ogni aggiornamento. Conservare un Rollback.md con passaggi esatti.
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.
Metriche operative: tenere un registro semplice per ogni script: resoconto medio (inattivo/attivo), conteggio degli errori/sessione, note sugli incidenti.
Disciplina del registro delle modifiche: richiedere i registri delle modifiche del fornitore; mantenere le proprie note di integrazione.
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

**Summary**
What happened vs expected, with timestamps.

**Repro Steps**
1) ...
2) ...

**Env**
Artifact build:
Framework & versions:
Script version:
Other deps:

**Logs**
Server console:
F8:

**Attachments**
Screens/video if possible.

Come utilizzare questa guida in modo efficiente

Bootstrap Test City una volta, tienilo pulito.
Per ogni copione candidato:
- Lasciati cadere resources/custom/, 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.
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? Learn how to measure script performance with Resmon in FiveM, fix avvisi di problemi di thread del server, and build the Part 1 test server with Docker for FiveM.

After the test workflow is ready, compare the exact framework, dependencies, delivered files and setup notes in the FiveM scripts marketplace.