Starten Sie von einem konkreten Ergebnis#
Definieren Sie die beabsichtigte Änderung: maximaler Rumpf, Preis, Makro, Button oder reales Objekt. XML zu parsen und ein korrekt ausgerüstetes Schiff zu fliegen sind unterschiedliche Ergebnisse.
Eine Einzelspieler-Verifikationssequenz#
Überprüfen Sie die Erweiterungsstruktur, IDs und Abhängigkeiten; XML-Syntax und XX; Import, Patch und Laufzeitprotokolle; den tatsächlichen Spielwert oder Objekt; UI-Klicks, Schließen, Aktualisieren und Wiedereröffnen; dann die gleichen Fakten nach einem vollständigen Neustart. XSD führt keine Skripte aus. Forschung begegnet Konstrukte, die von einem XX angenommen, aber vom MD-Parser abgelehnt wurden.
Die Szenarien trennen#
Überprüfen Sie für eine Eigenschaft den effektiven Wert und die widersprüchlichen Patches. Für ein Schiff, überprüfen Sie Registrierung, Aussehen, Ausrüstungsverbindungen, Flug und Verfügbarkeit. Für eine Einstellung, überprüfen Sie Persistenz und das Fehlen von wiederholten Resets. Neue und gespeicherte Objekte können unterschiedliche Lebenszyklus haben.
Wiederholen Sie teure Tests aus einem Grund#
Eine Änderung der Schaltflächenbeschriftung erfordert die betroffene UI-Prüfung. Änderungen der Ausladung oder Serialisierung benötigen das entsprechende Spielszenario. Sammeln Sie zunächst vollständige Fakten, dann vergleichen Sie alle Unterschiede. Ein Schiff beweist nicht jede Rumpfklasse. Dokumentieren Sie genaue Bedingungen und ungetestete Fälle; verbergen Sie nicht einen Ausfall durch manuelle Reparatur von Testvermögen. Siehe Protokolle, Persistenz in MD und Kompatibilität.