Jak testować PrestaShop 9.2 RC1 w odizolowanym środowisku testowym

Środowisko wersji kandydującej powinno być na tyle realistyczne, by ujawniać niezgodności, i na tyle odizolowane, by błąd nie mógł stać się prawdziwym zamówieniem, wysyłką ani kampanią. Samo skopiowanie produkcyjnej bazy danych pod inną nazwę hosta nie zapewnia takiej izolacji.

Zapowiedź RC1 poleca testerom używać nowej instalacji i informuje, że Update Assistant nie oferuje ścieżki aktualizacji z wersji beta do RC1 ani z RC1 do wersji finalnej. Według stanu na 26 września 2026 r. jest to ocena wersji przedpremierowej, a nie próba aktualizacji produkcji z gwarantowaną ścieżką kontynuacji. Oficjalne instrukcje testowania RC1.

Poniższa procedura buduje jednorazowe środowisko i ślad dowodowy. Nie wyjaśnia, jak przenieść sklep z wersji 8 do wersji 9.

Dla każdej zależności wprowadzanej do środowiska testowego żądaj dowodów zgodności modułu z PrestaShop 9.2 zamiast polegać wyłącznie na deklarowanej maksymalnej wersji.

Odizoluj skutki uboczne przed wprowadzeniem danych sklepu

Wymień każdy system, z którym sklep może się kontaktować: wysyłka e-maili, dostawcy płatności, usługi wysyłkowe, platformy marketingowe, usługi wyszukiwania, analityka, połączenia ERP i zaplanowane integracje. Uwzględnij wywołania zwrotne i procesy w tle, nie tylko widoczne ustawienia modułów.

Utwórz oddzielne dane uwierzytelniające lub udokumentowane konfiguracje piaskownicy tam, gdzie są dostępne. Kieruj pocztę do odbiornika testowego. Nie dopuść, by operacje wysyłkowe i marketingowe trafiały do rzeczywistych odbiorców. Jeśli integracja nie ma bezpiecznej piaskownicy, wyłącz jej skutki zewnętrzne i udokumentuj zachowania, których nie da się sprawdzić.

Używaj kontroli dostępu, by zachować prywatność środowiska. Same dyrektywy dla wyszukiwarek nie ograniczają dostępu ani nie chronią danych klientów. Ogranicz, kto może wejść do sklepu testowego i kto może nim zarządzać.

Sprawdź również zdarzenia przychodzące. Skopiowany adres URL wywołania zwrotnego lub konto dostawcy współdzielone z produkcją może sprawić, że jedno środowisko odbierze zdarzenia przeznaczone dla drugiego. Nadaj każdemu środowisku wyraźną tożsamość i sprawdź konfigurację dostawcy przed włączeniem integracji.

Jeśli później użyjesz danych pochodzących z produkcji, ogranicz je i zanonimizuj zgodnie z zatwierdzonym procesem. Realistyczny katalog rzadko wymaga prawdziwych e-maili klientów, adresów czy danych uwierzytelniających. Zachowaj spójność relacyjną, aby anonimizacja nie powodowała sztucznych awarii.

Udowodnij przydatność materiałów do odzyskiwania

Kopie zapasowe nadal są istotne, mimo że wersja kandydująca zaczyna od nowej instalacji. Zachowaj materiały odzyskiwania stabilnego sklepu w ramach jego zwykłego procesu operacyjnego i osobno zapisz bazowy stan wersji kandydującej, aby móc resetować testy.

Przydatna migawka łączy bazę danych z odpowiadającymi jej plikami i konfiguracją. Wersje modułów, odniesienia do multimediów i stan bazy mogą stać się niespójne, jeśli zostaną zapisane w niepowiązanych momentach. Zapisz, co zawiera migawka i jak została utworzona.

Przywróć stan bazowy wersji kandydującej do innej jednorazowej instancji lub punktu resetowania, zanim na nim polegniesz. Sprawdź, czy otwiera się interfejs administracyjny, istnieją produkty testowe, a skutki zewnętrzne nadal są odizolowane. Samo istnienie pliku kopii nie dowodzi, że można go poprawnie odtworzyć.

Nie używaj instalacji kandydującej do nadpisania produkcyjnej bazy danych, aby „wypróbować schemat”. Zachowaj wystarczająco odrębne dane uwierzytelniające i ścieżki bazy eksperymentu, by łatwiej wychwytywać zwykłe błędy operatora.

Napisz procedurę resetowania przed testami destrukcyjnymi. Przewidywalny reset zapewnia odtwarzalność późniejszych dowodów i zapobiega stopniowemu zanieczyszczaniu każdego testu danymi poprzedniego.

Ustal czysty stan bazowy RC1

Użyj oficjalnego artefaktu wydania odpowiedniego dla dystrybucji, którą chcesz ocenić. Zapisz pobrany artefakt, wersję i wszelkie dostępne sprawdzenia sumy kontrolnej. Odróżniaj pakiet instalacyjny od pobranych źródeł wymagających własnego procesu budowania.

Zainstaluj w nowej bazie danych. Zapisz wersje środowiska wykonawczego i bazy danych, nie zmieniając oceny w ogólne ćwiczenie hostingowe. Celem jest wiedza o tym, co sprawdzono, i porównanie z docelowym wspieranym środowiskiem.

Przed dodaniem dostosowań przeprowadź krótką kontrolę bazową: logowanie do Back Office, widok produktu, utworzenie koszyka i proste zamówienie w piaskownicy, jeśli pozwala na to zainstalowana konfiguracja płatności. Zapisz wynikową migawkę i wykaz wersji.

Jawnie zapisuj flagi funkcji. Stan domyślny jest częścią środowiska testowego. Jeśli późniejszy przypadek włącza przeniesioną stronę lub inną funkcję eksperymentalną, raport powinien to stwierdzać, zamiast przypisywać całe zachowanie wyłącznie wersji rdzenia.

Nigdy nie zakładaj, że udana instalacja wersji kandydującej tworzy ścieżkę aktualizacji do wydania finalnego. Traktuj jej bazę jako jednorazowe dane testowe, chyba że późniejsze oficjalne instrukcje wyraźnie ustanowią inny wspierany proces.

Wprowadzaj zależności w kontrolowanych grupach

Dodawaj motyw i moduły według procesów, na które wpływają. Przydatna kolejność to prezentacja sklepu, zależności procesu zakupowego, rozszerzenia Back Office i integracje w tle. Ułatwia to przypisanie nowo wprowadzonej awarii.

Prowadź rejestr zależności:

Jeśli komponent nie deklaruje wsparcia wersji 9.2, oznacz tę niepewność. Nadal możesz badać go w środowisku testowym, ale brak awarii w krótkim teście nie stanowi zobowiązania do wsparcia ze strony opiekuna.

Niestandardowe nadpisania wymagają szczególnej uwagi. Zapisz, co zmieniają i dlaczego. Dostosowanie, które przestaje się uruchamiać, może po cichu usunąć regułę biznesową, pozostawiając stronę sprawną.

Obejmij cykl życia sklepu poza procesem zakupowym

Proces zakupowy jest krytyczny, ale nie stanowi całego sklepu. Wersja kandydująca może przyjąć zamówienie, a mimo to zawieść podczas importu, edycji administracyjnej lub zaplanowanego uzgadniania.

W operacjach katalogowych twórz i edytuj produkty, kombinacje i przetłumaczone treści istotne dla sklepu. Używaj reprezentatywnych ograniczeń i nietypowych, lecz prawidłowych wartości. Przy imporcie sprawdź małą partię, błąd walidacji i restart zamiast od razu ładować cały katalog.

Dla zaplanowanych zadań potwierdź zamierzony kontekst sklepu i to, że procesy testowe nie mogą wywoływać usług produkcyjnych. Uruchom zadanie dwukrotnie, jeśli zdublowane wykonanie stanowi istotne ryzyko. Obserwuj, czy drugie uruchomienie bezpiecznie rozpoznaje zakończoną pracę.

Dla API zachowuj próbki schematów i odpowiedzi dla operacji rzeczywiście używanych przez klientów. Nie zakładaj, że wszystkie punkty końcowe są zainstalowane tylko dlatego, że wersja rdzenia jest nowa. Zapisuj wersje modułów zasobów obok wersji rdzenia.

W konfiguracji wielosklepowej używaj odrębnych wartości testowych w co najmniej dwóch sklepach i sprawdź oba po zapisie. Dla tłumaczonych ścieżek i treści testuj języki rzeczywiście publikowane przez firmę. Uwzględnij niedomyślny język pracownika, gdy rozszerzenia Back Office używają przetłumaczonych etykiet lub komunikatów.

Zakończ operacjami po zamówieniu: generowaniem dokumentów, zmianami statusu, obsługą wysyłki i przekazaniem do integracji zewnętrznej. Każdy przypadek powinien mieć oczekiwany wynik biznesowy, nie tylko oczekiwany ekran.

Zgłaszaj regresje tak, by inni mogli je odtworzyć

Przydatny raport zawiera minimalny zestaw testowy, dokładne wersje, aktywne flagi, sekwencję działań, oczekiwany i rzeczywisty wynik. Dołączaj oczyszczone logi lub zrzuty ekranu tylko wtedy, gdy wyjaśniają problem.

Spróbuj odtworzyć awarię z czystego stanu bazowego z najmniejszym koniecznym zbiorem zależności. Nie oznacza to usuwania dotkniętego modułu, jeśli jest kluczowy dla problemu. Oznacza usunięcie niepowiązanej konfiguracji, która przesłania wyzwalacz.

Odróżniaj regresję od niewspieranego założenia. Jeśli prywatna integracja opiera się na nieudokumentowanym selektorze, raport powinien wskazywać tę zależność. Jeśli udokumentowana operacja zwraca błędny wynik w czystej instalacji, pokaż to bezpośrednio.

Nie umieszczaj informacji wrażliwych dla bezpieczeństwa w publicznych zgłoszeniach. Minimalny przykład syntetyczny często jest bardziej użyteczny niż wyciąg z produkcyjnej bazy danych. Przy problemach bezpieczeństwa korzystaj z właściwego kanału zgłoszeń projektu zamiast publikować szczegóły wykorzystania luki w zwykłym raporcie zgodności.

Zachowuj metrykę danych testowych

Dla każdego importowanego zestawu testowego zapisz pochodzenie, datę przygotowania i cel. Odnotuj, które dane zostały syntetycznie utworzone, które relacje zachowano i które identyfikatory zewnętrzne zastąpiono. Pomaga to wyjaśnić awarie wynikające z nierealistycznego zestawu, a nie wersji kandydującej.

Katalog, w którym każdy produkt jest dostępny, nie sprawdzi zachowania niedostępnych pozycji. Zbiór klientów z jednym krajem nie ujawni reguł dostawy zależnych od celu. Kopia wielosklepowa zawierająca wyłącznie wspólne wartości nie potwierdzi izolacji. Celowo dobieraj reprezentatywne różnice, zamiast kopiować ilość dla niej samej.

Trzymaj metrykę zestawu testowego przy wykazie środowiska. Gdy kolejny tester odbuduje środowisko, powinien móc odtworzyć ważne warunki bez otrzymywania produkcyjnej bazy danych. Ułatwia to również ograniczanie zgłoszeń błędów do projektu do bezpiecznego minimalnego przykładu.

Jeśli zestaw testowy zmieni się podczas badania, nadaj poprawionemu zbiorowi nowy identyfikator. W przeciwnym razie dwa raporty deklarujące tę samą bazę mogą mieć różne warunki początkowe i prowadzić do mylących porównań.

Zakończ ocenę w przemyślany sposób

Wynik powinien wskazywać, co przeszło, co zawiodło, czego nie sprawdzono i co nadal nie jest wspierane. Każdemu problemowi blokującemu przypisz właściciela i odniesienie do reprodukcji.

Przed zakończeniem działania środowiska zachowaj dowody potrzebne do ponownych testów. Wyeksportuj definicje zestawów testowych, wykaz wersji i oczyszczone wyniki. Unieważnij tymczasowe dane uwierzytelniające integracji i wyłącz zaplanowaną aktywność, aby porzucona instalacja testowa nie kontaktowała się nadal z usługami zewnętrznymi.

Gdy pojawi się późniejsza wersja kandydująca lub stabilna, utwórz nową bazę oceny zgodnie z jej oficjalnymi instrukcjami i ponownie wykonaj przypadki objęte zmianami. Nie przenoś po cichu pozytywnego wyniku z innej konfiguracji modułów lub flag.

Wartością testów RC jest wczesna, odtwarzalna wiedza. Starannie odizolowana instalacja może dokładnie ujawnić, co wymaga pracy, pozostawiając sklep produkcyjny i jego klientów poza eksperymentem.

Kontekst platformy bazowej znajdziesz w naszym przewodniku po bezpiecznej aktualizacji PrestaShop z wersji 8 do 9; zastosuj powyższe kontrole właściwe dla wersji do ocenianej instalacji.