So bewerten, testen und warten Sie FiveM-Skripte

Dieser unkomplizierte Leitfaden zur Wartung von FiveM-Skripten richtet sich an Serverbesitzer, Entwickler und QA-Leiter. Sie erhalten eine produktionsähnliche „Test City“ in Docker, eine durchgängige Abnahme-Checkliste, ein quantitatives Risikobewertungsmodell und eine Bewertungstabelle für Anbieter, die Ihnen Kopfschmerzen erspart.

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)

Anwendung:

1. Entpacken → CD Teststadt
2. Kopie .env.beispiel Zu .env und legen Sie Ihre Lizenzschlüssel (und DB-Anmeldeinformationen, wenn Sie möchten).
3. Fallen oxmysql hinein Serverdaten/Ressourcen/[Standalone]/oxmysql/.
4. Setzen Sie das zu testende Skript in Serverdaten/Ressourcen/Benutzerdefiniert/ / und füge hinzu sicherstellen Zu server.cfg.
5. 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 platzieren (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/*

# 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 # 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)

# ---------- 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

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', Funktion(Artikel, Betrag) lokale Quelle = Quelle, wenn Typ(Artikel) ~= 'Zeichenfolge' oder Typ(Betrag) ~= 'Zahl' oder Betrag < 1, dann Ende zurückgeben, wenn nicht HasPermission(Quelle, 'shop.buy'), dann Ende zurückgeben, lokaler xPlayer = GetPlayer(Quelle) – Framework-Adapter, wenn nicht xPlayer, dann Ende zurückgeben – Preis serverseitig validieren, Lagerbestandsgrenzen prüfen, DB in einer Transaktion ausführen, Ende)

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)

1. Versionsfixierung: Sperrskriptversionen + Abhängigkeitsversionen (z. B. oxmysql, ox_lib).
2. Zuerst die Inszenierung: alle Updates landen in Teststadt; führen Sie die Abnahme-Checkliste erneut aus.
3. Backups und Rollbacks: DB-Snapshot + Ressourcendateien vor jedem Update. Behalten Sie eine Rollback.md mit genauen Schritten.
4. CI-Rauchtest (optional, empfohlen): Headless-Client-Verbindung + Befehlsmakro zum Aufrufen der Hauptflüsse; Serverkonsole auf Fehler analysieren.
5. Betriebskennzahlen: Führen Sie pro Skript ein einfaches Hauptbuch: durchschnittliche Antwort (Leerlauf/aktiv), Fehleranzahl/Sitzung, Vorfallnotizen.
6. Änderungsprotokoll Disziplin: Fordern Sie Änderungsprotokolle des Anbieters an und pflegen Sie Ihre eigenen Integrationsnotizen.
7. 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)

# 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 (Skelett)

# 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. 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

1. Bootstrap-Teststadt einmal, halte es sauber.
2. 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.
3. 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? Schauen Sie sich den Abschnitt an