PrestaShop 9.2 RC1 in einer isolierten Staging-Umgebung testen

Eine Umgebung für einen Release Candidate sollte realistisch genug sein, um Inkompatibilitäten aufzudecken, und so weit isoliert, dass ein Fehler nicht zu einer echten Bestellung, Lieferung oder Kampagne werden kann. Das Kopieren einer Produktionsdatenbank unter einen anderen Hostnamen schafft diese Isolation allein nicht.

Die RC1-Ankündigung weist Tester an, eine Neuinstallation zu verwenden, und erklärt, dass Update Assistant keinen Upgrade-Pfad von Beta zu RC1 oder von RC1 zur finalen Version bietet. Mit Stand vom 26. September 2026 ist dies die Bewertung einer Vorabversion, keine Probe eines Produktionsupgrades mit garantiertem Fortsetzungspfad. Offizielle RC1-Testanweisungen.

Das folgende Verfahren erstellt eine entbehrliche Umgebung und eine nachvollziehbare Beweiskette. Es erklärt nicht, wie ein Shop von Version 8 auf Version 9 migriert wird.

Fordern Sie für jede in Staging eingeführte Abhängigkeit Nachweise zur Modulkompatibilität mit PrestaShop 9.2 an, statt sich nur auf eine angegebene Maximalversion zu verlassen.

Nebenwirkungen vor dem Einbringen von Shop-Daten isolieren

Listen Sie jedes System auf, das der Shop kontaktieren kann: E-Mail-Versand, Zahlungsanbieter, Versanddienste, Marketingplattformen, Suchdienste, Analysen, ERP-Verbindungen und geplante Integrationen. Berücksichtigen Sie Rückrufe und Hintergrundprozesse, nicht nur sichtbare Moduleinstellungen.

Erstellen Sie separate Zugangsdaten oder dokumentierte Sandbox-Konfigurationen, wo diese verfügbar sind. Leiten Sie E-Mails an einen Testempfänger um. Verhindern Sie, dass Versand- und Marketingvorgänge echte Empfänger erreichen. Besitzt eine Integration keine sichere Sandbox, deaktivieren Sie ihre externen Auswirkungen und dokumentieren Sie, welches Verhalten nicht erprobt werden kann.

Verwenden Sie Zugriffskontrollen, um die Umgebung privat zu halten. Suchmaschinenanweisungen allein beschränken keinen Zugriff und schützen keine Kundendaten. Begrenzen Sie, wer den Testshop erreichen und wer ihn administrieren kann.

Prüfen Sie auch eingehende Ereignisse. Eine kopierte Rückruf-URL oder ein mit der Produktion geteiltes Anbieterkonto kann dazu führen, dass eine Umgebung Ereignisse für eine andere verarbeitet. Geben Sie jeder Umgebung eine klare Identität und prüfen Sie die Anbieterkonfiguration, bevor Sie eine Integration aktivieren.

Wenn Sie später produktionsbasierte Daten verwenden, minimieren und anonymisieren Sie sie über Ihren genehmigten Prozess. Ein realistischer Katalog erfordert selten echte Kunden-E-Mails, Adressen oder Zugangsdaten. Bewahren Sie die relationale Konsistenz, damit die Anonymisierung keine künstlichen Fehler erzeugt.

Die Nutzbarkeit des Wiederherstellungsmaterials nachweisen

Backups bleiben relevant, obwohl der Kandidat neu installiert wird. Bewahren Sie das Wiederherstellungsmaterial des stabilen Shops über dessen üblichen Betriebsprozess auf und erfassen Sie die Ausgangsbasis des Kandidaten separat, damit Tests zurückgesetzt werden können.

Eine nutzbare Momentaufnahme verbindet die Datenbank mit den zugehörigen Dateien und der Konfiguration. Modulversionen, Medienreferenzen und Datenbankzustand können inkonsistent werden, wenn sie zu unzusammenhängenden Zeitpunkten erfasst werden. Dokumentieren Sie, was die Momentaufnahme enthält und wie sie erstellt wurde.

Stellen Sie die Ausgangsbasis des Kandidaten in einer anderen entbehrlichen Instanz oder an einem Rücksetzpunkt wieder her, bevor Sie sich darauf verlassen. Prüfen Sie, dass sich die Verwaltungsoberfläche öffnet, Testprodukte vorhanden sind und externe Auswirkungen isoliert bleiben. Die Existenz einer Backup-Datei beweist nicht, dass sie korrekt wiederhergestellt werden kann.

Verwenden Sie die Kandidateninstallation nicht, um eine Produktionsdatenbank zu überschreiben und damit „das Schema auszuprobieren“. Halten Sie Datenbankzugangsdaten und Pfade des Experiments ausreichend getrennt, damit gewöhnliche Bedienfehler leichter auffallen.

Schreiben Sie das Rücksetzverfahren vor destruktiven Tests auf. Ein vorhersehbares Zurücksetzen macht spätere Nachweise reproduzierbar und verhindert, dass jeder Test zunehmend durch die Daten des vorherigen verfälscht wird.

Eine saubere RC1-Ausgangsbasis erstellen

Verwenden Sie das offizielle Release-Artefakt, das zu der zu bewertenden Distribution passt. Dokumentieren Sie das heruntergeladene Artefakt, die Version und jede verfügbare Prüfsummenprüfung. Unterscheiden Sie ein Installationspaket von einem Quellcode-Checkout, der seinen eigenen Build-Prozess benötigt.

Installieren Sie in eine neue Datenbank. Dokumentieren Sie Laufzeit- und Datenbankversionen, ohne die Bewertung zu einer allgemeinen Hosting-Übung zu machen. Ziel ist zu wissen, was getestet wurde, und es mit der vorgesehenen unterstützten Umgebung zu vergleichen.

Führen Sie vor dem Hinzufügen von Anpassungen eine kurze Basisprüfung durch: Back-Office-Anmeldung, Produktansicht, Warenkorberstellung und eine einfache Sandbox-Bestellung, sofern die installierte Zahlungseinrichtung dies erlaubt. Speichern Sie die resultierende Momentaufnahme und das Versionsverzeichnis.

Dokumentieren Sie Feature-Flags ausdrücklich. Der Standardzustand gehört zur Testumgebung. Aktiviert ein späterer Fall eine migrierte Seite oder eine andere experimentelle Funktion, sollte der Bericht dies nennen, statt jedes Verhalten allein der Core-Version zuzuschreiben.

Gehen Sie niemals davon aus, dass die erfolgreiche Installation des Kandidaten einen Upgrade-Pfad zur finalen Version schafft. Behandeln Sie seine Datenbank als entbehrliche Testdaten, sofern spätere offizielle Anweisungen nicht ausdrücklich einen anderen unterstützten Prozess festlegen.

Abhängigkeiten in kontrollierten Gruppen einführen

Fügen Sie Theme und Module entsprechend den betroffenen Abläufen hinzu. Eine hilfreiche Reihenfolge ist die Shop-Darstellung, Checkout-Abhängigkeiten, Back-Office-Erweiterungen und Hintergrundintegrationen. Dadurch lässt sich ein neu eingeführter Fehler leichter zuordnen.

Führen Sie ein Abhängigkeitsregister:

Gibt es für eine Komponente keine Aussage zur Unterstützung von Version 9.2, kennzeichnen Sie diese Unsicherheit. Sie können sie dennoch in Staging untersuchen, doch das Ausbleiben eines Fehlers in einem kurzen Test ist keine Supportzusage ihres Betreuers.

Individuelle Overrides verdienen besondere Aufmerksamkeit. Dokumentieren Sie, was sie ändern und warum. Eine nicht mehr aktivierte Anpassung kann stillschweigend eine Geschäftsregel entfernen, während die Seite funktionsfähig bleibt.

Den Shop-Lebenszyklus über den Checkout hinaus abdecken

Der Checkout ist entscheidend, aber nicht der gesamte Shop. Ein Kandidat kann eine Bestellung annehmen und dennoch bei einem Import, einer administrativen Änderung oder einem geplanten Abgleich scheitern.

Erstellen und bearbeiten Sie bei Katalogvorgängen Produkte, Kombinationen und übersetzte Inhalte, die für den Shop relevant sind. Verwenden Sie repräsentative Einschränkungen sowie ungewöhnliche, aber gültige Werte. Prüfen Sie bei Importen einen kleinen Stapel, einen Validierungsfehler und einen Neustart, statt sofort den gesamten Katalog zu laden.

Bestätigen Sie bei geplanten Aufgaben den vorgesehenen Shop-Kontext und dass Testprozesse keine Produktionsdienste aufrufen können. Führen Sie einen Job zweimal aus, wenn eine doppelte Ausführung ein relevantes Risiko darstellt. Beobachten Sie, ob der zweite Lauf abgeschlossene Arbeit sicher erkennt.

Bewahren Sie bei APIs Schema- und Antwortbeispiele für die Vorgänge auf, die Ihre Clients tatsächlich nutzen. Nehmen Sie nicht an, dass alle Endpunkte installiert sind, nur weil die Core-Version neu ist. Dokumentieren Sie Ressourcenmodulversionen zusammen mit dem Core.

Verwenden Sie bei Multishop unterschiedliche Testwerte in mindestens zwei Shops und prüfen Sie beide nach einem Schreibvorgang. Testen Sie bei übersetzten Routen und Inhalten die Sprachen, die das Unternehmen tatsächlich veröffentlicht. Berücksichtigen Sie eine von der Standardsprache abweichende Mitarbeitersprache, wenn Back-Office-Erweiterungen übersetzte Beschriftungen oder Meldungen verwenden.

Schließen Sie mit Vorgängen nach der Bestellung ab: Dokumenterstellung, Statusänderungen, Versandbearbeitung und Übergabe an externe Integrationen. Jeder Fall sollte ein erwartetes Geschäftsergebnis haben, nicht nur einen erwarteten Bildschirm.

Regressionen so melden, dass andere sie reproduzieren können

Ein hilfreicher Bericht enthält einen minimalen Testdatensatz, genaue Versionen, aktive Flags, die Aktionsfolge sowie erwartetes und tatsächliches Ergebnis. Fügen Sie bereinigte Protokolle oder Screenshots nur bei, wenn sie das Problem verdeutlichen.

Versuchen Sie, den Fehler von der sauberen Ausgangsbasis mit dem kleinstmöglichen notwendigen Abhängigkeitssatz zu reproduzieren. Das bedeutet nicht, das betroffene Modul zu entfernen, wenn es für das Problem wesentlich ist. Es bedeutet, unbeteiligte Konfiguration zu entfernen, die den Auslöser verdeckt.

Unterscheiden Sie eine Regression von einer nicht unterstützten Annahme. Beruht eine private Integration auf einem undokumentierten Selektor, sollte der Bericht diese Abhängigkeit nennen. Gibt ein dokumentierter Vorgang auf einer sauberen Installation das falsche Ergebnis zurück, zeigen Sie dies direkt.

Halten Sie sicherheitssensible Informationen aus öffentlichen Fehlerberichten heraus. Ein minimales synthetisches Beispiel ist ohnehin oft hilfreicher als ein Auszug aus einer Produktionsdatenbank. Nutzen Sie bei Sicherheitsproblemen den geeigneten Meldekanal des Projekts, statt Exploit-Details in einem gewöhnlichen Kompatibilitätsbericht zu veröffentlichen.

Einen Nachweis der Testdaten aufbewahren

Dokumentieren Sie für jeden importierten Testdatensatz seine Herkunft, sein Erstellungsdatum und seinen Zweck. Halten Sie fest, welche Daten synthetisch erstellt, welche Beziehungen erhalten und welche externen Kennungen ersetzt wurden. Das hilft, Fehler zu erklären, die durch einen unrealistischen Testdatensatz statt durch den Kandidaten entstehen.

Ein Katalog, in dem alle Produkte vorrätig sind, kann das Verhalten nicht verfügbarer Artikel nicht prüfen. Ein Kundensatz mit nur einem Land kann zielabhängige Lieferregeln nicht aufdecken. Eine Multishop-Kopie, die nur gemeinsame Werte enthält, kann keine Isolation nachweisen. Wählen Sie repräsentative Unterschiede bewusst aus, statt Datenvolumen um seiner selbst willen zu kopieren.

Bewahren Sie den Testdatennachweis neben dem Umgebungsverzeichnis auf. Baut ein späterer Tester die Umgebung neu auf, sollte er die wichtigen Bedingungen ohne eine Produktionsdatenbank wiederherstellen können. Das erleichtert auch, Fehlerberichte an das Projekt auf ein sicheres minimales Beispiel zu reduzieren.

Ändert sich ein Testdatensatz während der Untersuchung, geben Sie dem überarbeiteten Satz eine neue Kennung. Andernfalls können zwei Berichte, die angeblich dieselbe Ausgangsbasis verwenden, unterschiedliche Anfangsbedingungen enthalten und irreführende Vergleiche liefern.

Die Bewertung bewusst abschließen

Das Ergebnis sollte benennen, was bestanden hat, was gescheitert ist, was nicht erprobt wurde und was weiterhin nicht unterstützt ist. Geben Sie jedem blockierenden Problem einen Verantwortlichen und eine Reproduktionsreferenz.

Bewahren Sie vor dem Beenden der Umgebung die für erneute Tests benötigten Nachweise auf. Exportieren Sie Testdatendefinitionen, Versionsverzeichnis und bereinigte Ergebnisse. Widerrufen Sie vorübergehende Integrationszugangsdaten und deaktivieren Sie geplante Aktivitäten, damit eine verlassene Testinstallation nicht weiter externe Dienste kontaktiert.

Erstellen Sie beim Erscheinen eines späteren Kandidaten oder einer stabilen Version gemäß deren offiziellen Anweisungen eine neue Bewertungsbasis und wiederholen Sie die von Änderungen betroffenen Fälle. Übernehmen Sie nicht stillschweigend ein positives Ergebnis aus einer anderen Modul- oder Flag-Konfiguration.

Der Wert von RC-Tests liegt in frühem, reproduzierbarem Wissen. Eine sorgfältig isolierte Installation kann genau zeigen, was Arbeit erfordert, während der Produktionsshop und seine Kunden außerhalb des Experiments bleiben.

Zum Kontext der zugrunde liegenden Plattform sehen Sie sich unseren Leitfaden zum sicheren Upgrade von PrestaShop 8 auf 9 an und wenden Sie die obigen versionsspezifischen Prüfungen auf die Installation an, die Sie bewerten.