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.

TL;DR

Tourner vers le haut Ville d'essai (Docker) pour isoler et évaluer n'importe quel script en toute sécurité.
Exécutez le Liste de contrôle d'acceptation avant qu'un centime ne change de mains.
Utilisez le Score de risque (0–100) décider d'expédier/de retenir/de rejeter.
Vendeurs vétérinaires avec le Rubrique du fournisseur (ne sautez pas ceci).
Si vous achetez, privilégiez les magasins réputés — découvrez nos choix : Meilleurs magasins Tebex.

Partie 1 — « Test City » (Docker) pour une assurance qualité de script sûre et reproductible

Ce que vous obtenez

FXServer conteneurisé + MariaDB (+ Adminer)
Faire le ménage serveur.cfg avec oxmysql et les ressources de base
Monté sur reliure ressources/personnalisé où vous déposez le script en cours de test
Noms/ports de réseau déterministes pour les chaînes de base de données simples

Télécharger test-city.zip (Github)

Comment utiliser Docker (FiveM)

Mode d'emploi :

Décompresser → CD-Test-City
Copie .env.exemple à .env et définissez votre LICENCE_CLE (et les identifiants DB si vous le souhaitez).
Baisse oxmysql dans serveur-données/ressources/[autonome]/oxmysql/.
Mettez le script testé dans serveur-données/ressources/personnalisé/ / et ajouter assurer à serveur.cfg.
docker compose build && docker compose up -d → se connecter via Direct Connect à localhost:30120.

Prérequis : Docker + Docker Compose, une clé de licence cfx et un oxmysql copie de la ressource (déposer dans serveur-données/ressources/[autonome]/oxmysql).

Disposition des dossiers

test-city/
├─ docker-compose.yml
├─ fxserver/
│ ├─ Dockerfile
│ └─ entrypoint.sh
├─ server-data/
│ ├─ server.cfg
│ └─ resources/
│ ├─ [standalone]/oxmysql/ # placez oxmysql ici
│ └─ custom/ # placez le script à tester ici (ex. myscript/)
└─ .env

`.env` (exemple)

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 # Astuce : remplacez par une URL d'artefact spécifique à laquelle vous faites confiance pour la reproductibilité.

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

# Récupérer et extraire l'artefact FXServer (URL fournie 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 # Fournissez la chaîne de base de données pour oxmysql via server.cfg (déjà définie ici), # assurez-vous simplement que la base de données est accessible avant le démarrage pour éviter les erreurs de spam. echo "En attente de la base de données..." until nc -z db 3306; do sleep 1; done echo "DB ready." # Exécutez FXServer avec notre server.cfg # La plupart des artefacts Linux intègrent un run.sh dans la racine de l'artefact. exec bash /opt/fivem/run.sh +exec /opt/fivem/server-data/server.cfg

Si votre artefact utilise un chemin de lancement différent, ajustez la dernière ligne en conséquence (par exemple, /opt/fivem/alpine/opt/cfx-server/run.sh).

`serveur-données/serveur.cfg` (maigre, prêt pour les tests)

# ---------- Identité ----------
sv_licenseKey "%LICENSE_KEY%" # injecté par env dans la commande entrypoint ou à remplacer manuellement
sv_hostname "Test City — Script QA"
sets tags "qa,testing,fivemx"
sv_maxclients 2
onesync on
sv_scriptHookAllowed 0
sv_enforceGameBuild 3095

# ---------- Réseau ----------
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# ---------- Base de données (oxmysql) ----------
set mysql_connection_string "mysql://%MYSQL_USER%:%MYSQL_PASSWORD%@db:3306/%MYSQL_DATABASE%?charset=utf8mb4"

# ---------- Ressources de base ----------
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure hardcap
ensure baseevents

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

# ---------- En test ----------
# Déposez votre dossier de script dans resources/custom/ et activez-le ici :
# ensure myscript

# ---------- Aides QA ----------
# Journalisation verbeuse en développement
setr con_minSeverity info

# Activer le panneau txAdmin (optionnel)
setr txAdminPort 40120

Activez votre script : copiez-le dans serveur-données/ressources/personnalisé/monscript/ et ajouter assurer myscript jusqu'au bloc inférieur.

Exécutez-le

cd test-city docker compose build docker compose up -d # Administrateur à http://localhost:8080 (serveur : db, utilisateur : fivem, mot de passe : fivempw) # Connecter le client FiveM → Connexion directe : your-docker-host:30120

Partie 2 — Liste de contrôle d'acceptation du script (à ne pas ignorer)

Utilisez-le à chaque fois. Copiez-le dans votre suivi et cochez les éléments.

A. Pré-vol (avant l'installation)

Type de source : Open source / partiellement ouvert / sous séquestre uniquement.
Dépendances répertoriées : cadre (ESX/QBCore/QBOX), ox_lib, oxmysql, PolyZone, etc.
fxmanifest.lua : lua54 'oui', correct jeu 'gta5', version_fx pas ancien.
Documents : étapes d'installation, exemples de configuration, autorisations, paramètres régionaux, conflits connus.
Licence/Conditions d'utilisation : droits d'utilisation, politique de remboursement, mises à jour, canal d'assistance.

B. Installabilité

Aucune erreur de console sur assurer: aucune trace de pile ni spam d'actifs manquants.
Non natifs dépréciés courrier indésirable.
La configuration se charge proprement : aucune erreur de syntaxe JSON/Lua.
Migrations de bases de données : créer des tables une fois ; les redémarrages ne s'appliquent pas à nouveau et ne s'interrompent pas.

C. Fonctionnel

Cœur les flux fonctionnent : chemin heureux testé (par exemple, achat, flux de travail, artisanat).
Cas limites : entrées erronées, permissions manquantes, quantités hors limites.
Localisation: pas de chaînes codées en dur si les paramètres régionaux le promettent.
Autorisations : commandes du personnel/administrateur bloquées ; pas d'accès gratuit côté client.

D. Performances (client et serveur)

résmon: ralenti ≤ 0,10 ms, actif ≤ 0,50 ms (client).
État de santé du serveur : aucun avertissement de longs problèmes dans des conditions normales d'utilisation.
Requêtes de base de données : pas de boucles serrées ; instructions préparées utilisées ; N+1 minimal.

E. Sécurité

Validation côté serveur : chaque événement du serveur valide source, les permissions et les types d'entrée.
Aucune confiance dans le client : les changements d'argent/d'inventaire dépendent uniquement de la logique du serveur.
Aucune évaluation/chaîne de chargement/code à distance motifs.
Anti-abus : limites de débit/limites sur les points de terminaison spammés.
Intégrité du séquestre : pas de portes dérobées dans les chargeurs de configuration sans séquestre.

Bon modèle d'événement (exemple) :

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) -- adaptateur framework
 if not xPlayer then return end
 -- valider le prix côté serveur, vérifier les limites d'inventaire, faire la DB dans une transaction
end)

F. Compatibilité et propreté

Adaptateurs de framework présents (ESX/QBCore/QBOX) ou clairement déclaré non pris en charge.
Aucune fuite globale, noms d'événements uniques, aucune hypothèse de nom de ressource.
Désinstaller proprement : supprimer la ressource ne brise pas les autres.

Partie 3 — Modèle de notation quantitative des risques (0–100)

Utilisez ceci pour décider « expédier/retenir/rejeter ». Une valeur plus basse est préférable.

Facteur	Poids	Comment noter (0 = bon → 5 = mauvais)
Performance	0.20	résmon inactif : 0 = ≤ 0,10 ms, 1 = ≤ 0,20, 3 = ≤ 0,50, 5 => 0,50 ; les pics ajoutent +1
Sécurité	0.25	0 = tous validés par le serveur + limites de débit ; 3 = quelques écarts ; 5 = fait confiance au client / événements non sécurisés
Stabilité	0.15	0 = aucune erreur ; 3 = avertissements occasionnels ; 5 = erreurs/problèmes fréquents
Compatibilité	0.10	0=adaptateurs/tests ; 3=un seul framework ; 5=interrompt les dépendances communes
Maintenabilité	0.10	0=docs/changelog/versions sémantiques ; 5=pas de docs/abandonné
Chaîne d'approvisionnement/Fournisseur	0.20	0 = réputé, historique, remboursements ; 5 = inconnu, aucune politique

Formule

RiskScore = 100 * Σ(weight_i * (score_i / 5))

Bandes et actions

0–24 (faible) : Expédition vers la plateforme de mise en scène, surveillance.
25–49 (Modéré) : Corrections requises avant la mise en ligne.
50–74 (élevé) : Attendre ; demander des correctifs au fournisseur ou remplacer.
75–100 (critique) : Rejeter.

Exemple

Perf=1, Sec=3, Stabilité=1, Compat=1, Maint=2, Fournisseur=1
Risque = 100*(0,2*0,2 + 0,25*0,6 + 0,15*0,2 + 0,1*0,2 + 0,1*0,4 + 0,2*0,2) = 34 → Modéré

Partie 4 — Grille d'évaluation des fournisseurs (attribuez une note de 0 à 5 à chaque fournisseur, la plus élevée étant mieux)

Critère	À quoi ressemble le « bien »	Remarques
Identité et antécédents	Marque claire, années d'activité, poignée cohérente	Évitez les magasins de brûleurs
Documentation	Installation + configuration + autorisations + dépannage	Aide aux captures d'écran/gifs
Cadence de mise à jour	Journal des modifications, versions sémantiques, commits/versions récents	Trimestriel+ c'est bien
Qualité du support	Contrats de niveau de service (SLA) pour les tickets/Discord, correctifs reproductibles, pas seulement « redémarrage »	Exemples de réponses
Transparence des problèmes	Problèmes connus du public et feuille de route	L'honnêteté > la perfection
Clarté des conditions d'utilisation et des remboursements	Fenêtre de remboursement, conditions, termes de licence	Pas de motifs sombres
Preuve de test	Vidéo de mise en scène, mesures de performance, liste des frameworks	Encore mieux : serveur de démonstration
Hygiène de sécurité	Mentionne les vérifications côté serveur, pas de clés sensibles, pas d'évaluation	Renseignez-vous sur les audits
Politique de compatibilité	ESX/QBCore/QBOX déclarés, adaptateurs, matrice de versions	Constructions soutenues par l'État
Prix et valeur	Équitable pour la complexité, pas de barrières de dépendance	Attention aux pièges de la vente incitative

Score de la rubrique (0–50) :

40–50 : Fort — fournisseur privilégié
30–39 : Acceptable — surveiller
20–29 : Faible — procéder avec prudence
<20 : À éviter

Conseil de pro : Comparez les offres avec celles de places de marché réputées. Commencez ici : Meilleurs magasins Tebex.

Partie 5 — Manuel de maintenance (après l'expédition)

Épinglage de version : versions de script de verrouillage + versions de dépendances (par exemple, oxmysql, ox_lib).
Mise en scène d'abord : toutes les mises à jour atterrissent dans Ville d'essai; exécutez à nouveau la liste de contrôle d'acceptation.
Sauvegardes et restaurations : Capture instantanée de la base de données et fichiers de ressources avant chaque mise à jour. Conservez-en un Rollback.md avec des étapes exactes.
Test de fumée CI (facultatif, recommandé) : connexion client sans tête + macro de commande pour atteindre les flux principaux ; analyser la console du serveur pour les erreurs.
Indicateurs opérationnels : tenir un registre simple par script : rappel moyen (inactif/actif), nombre d'erreurs/session, notes d'incident.
Discipline du journal des modifications : exiger des journaux des modifications des fournisseurs ; conserver vos propres notes d'intégration.
Réduire les risques liés aux événements programmés : mettre à jour en dehors des heures de pointe ; annoncer les fenêtres de maintenance.

Partie 6 — Modèles que vous pouvez copier

A. Plan de test (par script)

Plan de test du script # — ## Contexte Framework(s) : ESX/QBCore/QBOX Dépendances : oxmysql vX, ox_lib vY, PolyZone vZ Migrations de base de données : oui/non Séquestre : oui/non ## Cas fonctionnels - [ ] Cas 1 : - [ ] Cas 2 : - [ ] Négatif 1 : ## Performances resmon inactif : ____ ms resmon actif : ____ ms (scénario : ______) ## Contrôles de sécurité - [ ] Tous les événements du serveur valident la source/les permissions/les entrées - [ ] Limites de débit présentes - [ ] Aucune mutation de monnaie/inventaire approuvée par le client ## Journaux et erreurs Coller un extrait (serveur + F8) : ## Résultat Réussite/Échec + Notes

B. Rollback.md (squelette)

Restauration # — 

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. Modèle de problème

**Résumé** Ce qui s'est passé par rapport aux attentes, avec horodatages. **Étapes de reproduction** 1) ... 2) ... **Environnement** Construction de l'artefact : Framework et versions : Version du script : Autres dépendances : **Journaux** Console du serveur : F8 : **Pièces jointes** Écrans/vidéo si possible.

Comment utiliser ce guide efficacement

Ville de test Bootstrap une fois, gardez-le propre.
Pour chaque script candidat :
- Laissez tomber dans ressources/personnalisé/, activer dans serveur.cfg.
- Exécutez le Liste de contrôle d'acceptation.
- Calculer le Score de risque.
- Vérifiez le vendeur avec le Rubrique du fournisseur.
Si le projet est approuvé, fusionnez avec la phase de préparation ; sinon, demandez des correctifs ou éloignez-vous.

Besoin de plus de guides de test ? Learn how to measure script performance with Resmon in FiveM, fix avertissements d'incidents de threads de serveur, and build the Part 1 test server with Docker for FiveM.