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.

Kurz zusammengefasst

Drehen Sie auf Teststadt (Docker), um jedes Skript sicher zu isolieren und zu benchmarken.
Führen Sie den Abnahme-Checkliste bevor ein Penny den Besitzer wechselt.
Verwenden Sie die Risikobewertung (0–100) um über das Versenden/Zurückhalten/Ablehnen zu entscheiden.
Tierarztverkäufer mit dem Anbieterrubrik (überspringen Sie dies nicht).
Wenn Sie kaufen, bevorzugen Sie seriöse Geschäfte – sehen Sie sich unsere Empfehlungen an: Beste Tebex-Shops.

Teil 1 – „Test City“ (Docker) für sichere, wiederholbare Skript-QA

Was Sie bekommen

Containerisierter FXServer + MariaDB (+ Adminer)
Sauber server.cfg mit oxmysql und Basisressourcen
Bind-montiert Ressourcen/Benutzerdefiniert wo Sie das zu testende Skript ablegen
Deterministische Netzwerknamen/Ports für einfache DB-Strings

Laden Sie test-city.zip herunter (Github)

So verwenden Sie Docker (FiveM)

Anwendung:

Entpacken → CD Teststadt
Kopie .env.beispiel Zu .env und legen Sie Ihre Lizenzschlüssel (und DB-Anmeldeinformationen, wenn Sie möchten).
Fallen oxmysql hinein Serverdaten/Ressourcen/[Standalone]/oxmysql/.
Setzen Sie das zu testende Skript in Serverdaten/Ressourcen/Benutzerdefiniert/ / und füge hinzu sicherstellen Zu server.cfg.
Docker Compose Build && Docker Compose Up -d → Verbinden Sie sich über Direct Connect mit lokaler Host: 30120.

Voraussetzungen: Docker + Docker Compose, ein cfx-Lizenzschlüssel und ein oxmysql Ressourcenkopie (ablegen in Serverdaten/Ressourcen/[Standalone]/oxmysql).

Ordnerlayout

test-city/
├─ docker-compose.yml
├─ fxserver/
│ ├─ Dockerfile
│ └─ entrypoint.sh
├─ server-data/
│ ├─ server.cfg
│ └─ resources/
│ ├─ [standalone]/oxmysql/ # oxmysql hier platzieren
│ └─ custom/ # das zu testende Skript hier ablegen (z.B. myscript/)
└─ .env

`.env` (Beispiel)

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 # Tipp: Ersetzen Sie es durch eine bestimmte Artefakt-URL, der Sie aus Gründen der Reproduzierbarkeit vertrauen.

`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/*

# FXServer-Artefakt herunterladen & extrahieren (URL via build-arg bereitgestellt)
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

# Nicht-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 # DB-String für oxmysql über server.cfg bereitstellen (dort bereits festgelegt), # nur sicherstellen, dass die DB vor dem Booten erreichbar ist, um Spam-Fehler zu vermeiden. echo "Warten auf Datenbank..." until nc -z db 3306; do sleep 1; done echo "DB bereit." # FXServer mit unserer server.cfg ausführen # Die meisten Linux-Artefakte werden mit einem run.sh im Artefakt-Stammverzeichnis ausgeliefert. exec bash /opt/fivem/run.sh +exec /opt/fivem/server-data/server.cfg

Wenn Ihr Artefakt einen anderen Launcher-Pfad verwendet, passen Sie die letzte Zeile entsprechend an (z. B. /opt/fivem/alpine/opt/cfx-server/run.sh).

`server-data/server.cfg` (schlank, testbereit)

# ---------- Identität ----------
sv_licenseKey "%LICENSE_KEY%" # durch Umgebungsvariable im Entrypoint-Befehl eingefügt oder manuell ersetzen
sv_hostname "Test City — Script QA"
sets tags "qa,testing,fivemx"
sv_maxclients 2
onesync on
sv_scriptHookAllowed 0
sv_enforceGameBuild 3095

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

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

# ---------- Kern- / Basis-Ressourcen ----------
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure hardcap
ensure baseevents

# ---------- Datenspeicher ----------
ensure oxmysql

# ---------- Im Test ----------
# Lege deinen Skript-Ordner in resources/custom/ und aktiviere hier:
# ensure myscript

# ---------- QA-Helfer ----------
# Ausführliche Protokollierung in der Entwicklung
setr con_minSeverity info

# txAdmin-Panel aktivieren (optional)
setr txAdminPort 40120

Aktivieren Sie Ihr Skript: kopiere es in Serverdaten/Ressourcen/Benutzerdefiniert/MeinSkript/ und füge hinzu Stellen Sie sicher, dass MyScript zum unteren Block.

Führen Sie es aus

cd test-city docker compose build docker compose up -d # Adminer unter http://localhost:8080 (Server: db, Benutzer: fivem, Passwort: fivempw) # Verbinden Sie den FiveM-Client → Direktverbindung: Ihr Docker-Host:30120

Teil 2 – Checkliste zur Skriptakzeptanz (nicht überspringen)

Verwenden Sie dies jedes Mal. Kopieren Sie es in Ihren Tracker und haken Sie die Elemente ab.

A. Vor dem Flug (vor der Installation)

Quellentyp: Open Source / teilweise offen / nur Treuhand.
Aufgelistete Abhängigkeiten: Framework (ESX/QBCore/QBOX), ox_lib, oxmysql, PolyZone, usw.
fxmanifest.lua: lua54 'ja', richtig Spiel 'gta5', fx_version nicht uralt.
Dokumente: Installationsschritte, Konfigurationsbeispiele, Berechtigungen, Gebietsschemas, bekannte Konflikte.
Lizenz/Nutzungsbedingungen: Nutzungsrechte, Rückerstattungsrichtlinie, Updates, Support-Kanal.

B. Installierbarkeit

Keine Konsolenfehler auf sicherstellen: Keine Stapelverfolgungen oder Spam wegen fehlender Assets.
NEIN veraltete Natives Spam.
Konfiguration wird sauber geladen: keine JSON/Lua-Syntaxfehler.
DB-Migrationen: Tabellen einmal erstellen; Neustarts führen nicht zu einer erneuten Anwendung oder Unterbrechung.

C. Funktional

Kern Flows funktionieren: Happy Path getestet (z. B. Kauf, Jobablauf, Herstellung).
Randfälle: falsche Eingaben, fehlende Dauerwellen, Mengen außerhalb des zulässigen Bereichs.
Lokalisierung: keine fest codierten Zeichenfolgen, wenn Gebietsschemas versprochen wurden.
Berechtigungen: Mitarbeiter-/Administratorbefehle sind gesperrt; kein freier Zugriff auf der Clientseite.

D. Leistung (Client & Server)

resmon: Leerlauf ≤ 0,10 ms, aktiv ≤ 0,50 ms (Kunde).
Server-Tick-Integrität: Keine langen Hitch-Warnungen bei normalem Gebrauch.
DB-Abfragen: keine engen Schleifen; vorbereitete Anweisungen verwendet; minimal N+1.

E. Sicherheit

Serverseitige Validierung: jedes Serverereignis validiert Quelle, Dauerwellen und Eingabetypen.
Kein Vertrauen in den Kunden: Geld-/Inventaränderungen nur durch Serverlogik.
Keine Bewertung/Laststrang/Remote-Code Muster.
Missbrauchsbekämpfung: Ratenbegrenzungen/Drosselungen an Spam-Endpunkten.
Integrität des Treuhandkontos: keine Hintertüren in Nicht-Escrow-Konfigurationsladern.

Gutes Ereignismuster (Beispiel):

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. Kompatibilität und Sauberkeit

Framework-Adapter vorhanden (ESX/QBCore/QBOX) oder eindeutig als nicht unterstützt deklariert.
Kein globales Leck, eindeutige Ereignisnamen, keine Annahmen zu Ressourcennamen.
Sauber deinstallieren: Das Entfernen der Ressource führt nicht zu Schäden an anderen Ressourcen.

Teil 3 – Quantitatives Risikobewertungsmodell (0–100)

Verwenden Sie dies, um zwischen Versenden/Zurückhalten/Ablehnen zu entscheiden. Niedriger ist besser.

Faktor	Gewicht	So bewerten Sie (0=gut → 5=schlecht)
Leistung	0.20	resmon Leerlauf: 0=≤0,10 ms, 1=≤0,20, 3=≤0,50, 5=>0,50; Spitzen addieren +1
Sicherheit	0.25	0=alles servervalidiert + Ratenbegrenzungen; 3=einige Lücken; 5=vertraut Client / unsichere Ereignisse
Stabilität	0.15	0=keine Fehler; 3=gelegentliche Warnungen; 5=häufige Fehler/Störungen
Kompatibilität	0.10	0=Adapter/Tests; 3=nur ein Framework; 5=unterbricht gemeinsame Abhängigkeiten
Wartbarkeit	0.10	0=Dokumente/Änderungsprotokoll/semantische Versionen; 5=keine Dokumente/aufgegeben
Lieferkette/Lieferant	0.20	0 = seriös, Geschichte, Rückerstattungen; 5 = unbekannt, keine Richtlinien

Formel

RiskScore = 100 * Σ(Gewicht_i * (Score_i / 5))

Bands & Aktionen

0–24 (Niedrig): An Bereitstellung versenden, überwachen.
25–49 (mittelschwer): Vor der Live-Schaltung sind Korrekturen erforderlich.
50–74 (Hoch): Halten; Patches vom Anbieter anfordern oder ersetzen.
75–100 (Kritisch): Ablehnen.

Beispiel

Leistung=1, Sek=3, Stabilität=1, Kompatibilität=1, Wartung=2, Anbieter=1
Risiko = 100*(.2*.2 + .25*.6 + .15*.2 + .1*.2 + .1*.4 + .2*.2) = 34 → Mäßig

Teil 4 – Bewertungskriterien für Lieferanten (Bewertung von 0–5, höher ist besser)

Kriterium	Wie „gut“ aussieht	Hinweise
Identität und Erfolgsbilanz	Klare Marke, jahrelange Aktivität, konsistenter Umgang	Vermeiden Sie Brennerläden
Dokumentation	Installieren + Konfigurieren + Berechtigungen + Fehlerbehebung	Screenshots/Gifs helfen
Aktualisierungsintervall	Änderungsprotokoll, semantische Versionen, aktuelle Commits/Releases	Vierteljährlich+ ist in Ordnung
Support-Qualität	Ticket-/Discord-SLAs, reproduzierbare Fixes, nicht nur „Neustart“	Beispielantworten
Transparenz bei Problemen	Öffentlich bekannte Probleme und Roadmap	Ehrlichkeit > Perfektion
Rückerstattung/Klarheit der Nutzungsbedingungen	Rückerstattungsfrist, Bedingungen, Lizenzbedingungen	Keine dunklen Muster
Testnachweis	Staging-Video, Leistungsmetriken, Framework-Liste	Noch besser: Demo-Server
Sicherheitshygiene	Erwähnt serverseitige Prüfungen, keine sensiblen Schlüssel, keine Auswertung	Fragen Sie nach Audits
Kompatibilitätsrichtlinie	ESX/QBCore/QBOX angegeben, Adapter, Versionsmatrix	Staatlich unterstützte Builds
Preise und Wert	Angemessene Komplexität, keine Paywalls für Abhängigkeiten	Achten Sie auf Upselling-Fallen

Rubrikbewertung (0–50):

40–50: Stark – bevorzugter Anbieter
30–39: Akzeptabel – Monitor
20–29: Schwach – vorsichtig vorgehen
<20: Vermeiden

Profi-Tipp: Vergleichen Sie mit seriösen Marktplätzen. Beginnen Sie hier: Beste Tebex-Shops.

Teil 5 – Wartungshandbuch (nach dem Versand)

Versionsfixierung: Sperrskriptversionen + Abhängigkeitsversionen (z. B. oxmysql, ox_lib).
Zuerst die Inszenierung: alle Updates landen in Teststadt; führen Sie die Abnahme-Checkliste erneut aus.
Backups und Rollbacks: DB-Snapshot + Ressourcendateien vor jedem Update. Behalten Sie eine Rollback.md mit genauen Schritten.
CI-Rauchtest (optional, empfohlen): Headless-Client-Verbindung + Befehlsmakro zum Aufrufen der Hauptflüsse; Serverkonsole auf Fehler analysieren.
Betriebskennzahlen: Führen Sie pro Skript ein einfaches Hauptbuch: durchschnittliche Antwort (Leerlauf/aktiv), Fehleranzahl/Sitzung, Vorfallnotizen.
Änderungsprotokoll Disziplin: Fordern Sie Änderungsprotokolle des Anbieters an und pflegen Sie Ihre eigenen Integrationsnotizen.
Reduzieren Sie das Risiko geplanter Ereignisse: Aktualisieren Sie außerhalb der Spitzenzeiten. Kündigen Sie Wartungsfenster an.

Teil 6 – Vorlagen zum Kopieren

A. Testplan (pro Skript)

# Skript-Testplan —  

## Kontext
Framework(s): ESXQBCoreQBOX
Abhängigkeiten: oxmysql vX, ox_lib vY, PolyZone vZ
DB-Migrationen: janein
Escrow: janein

## Funktionale Fälle
- [ ] Fall 1:
- [ ] Fall 2:
- [ ] Negativfall 1:

## Leistung
resmon im Leerlauf: ____ ms
resmon aktiv: ____ ms (Szenario: ______)

## Sicherheitsprüfungen
- [ ] Alle Server-Ereignisse validieren QuelleBerechtigungEingabe
- [ ] Ratenbegrenzungen vorhanden
- [ ] Keine client-vertrauenswürdigen Geld-Inventar-Mutationen

## Protokolle & Fehler
Auszug einfügen (Server + F8): 

## Ergebnis
BestandenNicht bestanden + Anmerkungen

B. Rollback.md (Skelett)

# Rollback —   

1) Skript deaktivieren: `stop `
2) Ressourcendateien aus Backup wiederherstellen: 
3) DB-Snapshot wiederherstellen: 
4) FXServer neu starten
5) Überprüfen: Konsole sauber, Leistung normal, Abläufe in Ordnung

C. Problemvorlage

**Zusammenfassung** Was passiert ist im Vergleich zu erwartet, mit Zeitstempeln. **Reproduktionsschritte** 1) ... 2) ... **Umgebung** Artefakt-Build: Framework und Versionen: Skriptversion: Andere Abhängigkeiten: **Protokolle** Serverkonsole: F8: **Anhänge** Bildschirme/Videos, wenn möglich.

So nutzen Sie diesen Leitfaden effizient

Bootstrap-Teststadt einmal, halte es sauber.
Für jedes Kandidatenskript:
- Fallen Sie ein in Ressourcen/Benutzerdefiniert/, aktivieren Sie in server.cfg.
- Führen Sie den Abnahme-Checkliste.
- Berechnen Sie die Risikobewertung.
- Überprüfen Sie den Verkäufer mit dem Anbieterrubrik.
Wenn es erfolgreich ist, führen Sie es in die Staging-Phase ein. Wenn nicht, fordern Sie Korrekturen an oder gehen Sie weg.

Benötigen Sie weitere Testanleitungen? Learn how to measure script performance with Resmon in FiveM, fix Server-Thread-Hitch-Warnungen, and build the Part 1 test server with Docker for FiveM.