Warte ein FiveM-Skript, indem du eine reproduzierbare Version beibehältst, seine tatsächlichen Gameplay-Abläufe testest und ein funktionierendes Rollback sicherstellst. Eine Ressource, die fehlerfrei startet, ist nur die erste Prüfung; Berechtigungen, Persistenz und Fehlerpfade sind genauso wichtig.
Notiere die funktionierende Basislinie
Liste die Ressourcenversion oder den Commit, den FXServer-Build, das Framework, das Inventar, den Datenbanktreiber und die Konfigurationsänderungen auf. Bewahre bearbeitbaren Quellcode in einem privaten Repository und Anmeldeinformationen außerhalb davon auf. Bewahre das ursprüngliche lizenzierte Paket und die Update-Anweisungen des Autors auf.
Verwende einen isolierten Testserver mit einer separaten Datenbank und eingeschränktem Zugriff. Deaktiviere echte Zahlungsabwicklungen, Produktions-Webhooks und andere externe Aktionen in der Testumgebung.
Überprüfe jedes Update vor der Installation
- Lies die Versionshinweise und vergleiche geänderte Konfigurationen, Abhängigkeiten, Exporte, Ereignisse und SQL. Identifiziere Breaking Changes, bevor du Dateien ersetzt.
- Sichere die aktuelle Datenbank und die passenden Ressourcen-/Konfigurationsdateien. Bestätige, dass das Backup auf der Testinstanz wiederhergestellt werden kann.
- Wende das Update in der vom Autor geforderten Reihenfolge auf die Testinstanz an. Füge die Konfiguration bewusst zusammen; überschreibe die neuen Standardwerte nicht blind mit einer alten Datei.
- Führe normale und Fehlerszenarien aus und vergleiche dann die persistenten Ergebnisse nach Wiederverbindung und Neustart.
Verwende einen Gameplay-Testdatensatz
Notiere für jede wichtige Aktion den Ausgangszustand, die Schritte, das erwartete Ergebnis und das beobachtete Ergebnis. Für einen Shop-Kauf: Der Spieler hat ein bekanntes Guthaben, kauft einen bekannten Gegenstand, erhält genau einen Gegenstand, verliert genau den vom Server definierten Preis und behält dieses Ergebnis nach der Wiederverbindung.
Wiederhole dies mit unzureichenden Mitteln, vollem Inventar, unbefugtem Zugriff, ungültigen Gegenstandsnamen, wiederholten Anfragen und einer Trennung während des Vorgangs. Teste für eine Garage den Besitz, die Verhinderung doppelter Spawns und die Lagerung nach einem Neustart. Teste für Jobs Rang- und Dienstbeschränkungen.
Sicherheit und Leistung separat prüfen
Überprüfe Netzwerkereignisse auf serverseitige Validierung von Berechtigungen, Besitz, Mengen und Aufgabenerfüllung. Ein kritischer Autorisierungsfehler blockiert die Veröffentlichung, unabhängig von guter Leistung an anderer Stelle.
Verwende den Client-Ressourcenmonitor für das Timing von Client-Skripten und den FXServer-Profiler für die Serverarbeit. Notiere die Szene, die Spieleranzahl und die Dauer. Vergleiche identische Arbeitslasten; lege kein universelles Millisekunden-Budget für nicht verwandte Ressourcen fest.
Automatisiere Prüfungen, die echte Fehler aufdecken
Führe Lua-Syntax-/Lint-Prüfungen durch, die für die FiveM-Laufzeit geeignet sind, und gezielte Tests für reine Logik. Mocked Framework-Tests helfen, Argument- und Rückgabe-Fehlpaarungen zu erkennen, aber sie überprüfen nicht die tatsächliche Framework-, Inventar- oder Datenbankintegration. Halte eine Live-Testserver-Checkliste daneben.
Eine umkehrbare Änderung bereitstellen
Wähle ein Wartungsfenster, kündige die erwartete Unterbrechung an und halte die vorherige Version bereit. Aktualisiere nur das überprüfte Paket und die erforderlichen Abhängigkeiten. Starte in der dokumentierten Reihenfolge neu, überprüfe die Protokolle und wiederhole das wichtige Gameplay-Szenario.
Wenn die Überprüfung fehlschlägt, stoppe neue Schreibvorgänge vor der Wiederherstellung. Stelle den passenden Code und alle notwendigen Daten wieder her, unter Berücksichtigung der nach dem Backup vorgenommenen Änderungen. Lösche nicht stillschweigend den Spielerfortschritt, um einen Test zu bestehen.
Einen hilfreichen Fehlerbericht führen
Notiere den ersten relevanten Fehler, die betroffene Ressource/Version, die Reproduktionsschritte und das erwartete Verhalten. Schwärze Anmeldeinformationen und persönliche Identifikatoren aus den Protokollen. Verfolge die Lösung in der Änderungsverlauf der Ressource, damit das nächste Update dieselbe Regressionsprüfung wiederholen kann.