Przygotowanie modułu komercyjnego do zgodności z PrestaShop 9.2
Deklaracja zgodności modułu komercyjnego jest obietnicą złożoną sprzedawcy dotyczącą kombinacji oprogramowania i zachowania. „Instaluje się na PrestaShop 9.2” to znacznie węższe stwierdzenie niż „obsługuje natywny proces zakupu, zmigrowane strony administracyjne i pracę wielosklepową”.
W przypadku wersji 9.2 RC1 dostępnej 26 września 2026 r. wydawcy powinni precyzyjnie opisywać testy wersji kandydującej. Pomyślna ocena RC nie uzasadnia deklarowania obsługi jeszcze niewydanej wersji stabilnej. Ten artykuł wyjaśnia, jak kwalifikować istniejący produkt modułowy, a nie jak budować jego szkielet.
Jeśli moduł uczestniczy w płatności lub dostawie, uwzględnij plan QA One Page Checkout w macierzy zgodności zamiast testować samą instalację.
Zdefiniuj deklarację obsługi przed zaprojektowaniem macierzy
Zapisz funkcje rzeczywiście oferowane przez moduł i kombinacje, z których mają korzystać klienci. Moduł płatności ma inne ścieżki krytyczne niż moduł wzbogacania katalogu. Rozszerzenie przeznaczone wyłącznie dla Back Office może nie potrzebować pełnej macierzy motywów sklepu, ale rozszerzenie procesu zakupu z pewnością jej potrzebuje.
Oddziel obowiązkową obsługę od opcjonalnej zgodności. Jeśli moduł obsługuje dziś tylko określoną ścieżkę zakupu, podaj to wprost. Jeśli wielosklepowość nie jest obsługiwana, nie pozwól, by instalacja w środowisku wielosklepowym sugerowała coś innego.
Wymień dokładne zależności stojące za deklaracją: rdzeń, środowisko wykonawcze, moduły natywne, motyw tam, gdzie ma znaczenie, i wersję integracji usługi zewnętrznej. Zachowaj widoczność zależności eksperymentalnych zamiast ukrywać je w szerokim zakresie wersji.
Przydatna deklaracja na obecnym etapie brzmi: „przetestowano z 9.2.0-rc.1 przy wskazanych kombinacjach i ograniczeniach”. Informuje pierwszych testerów o istniejących dowodach, nie sugerując gotowości wersji kandydującej do produkcji.
Buduj macierz wokół ryzyka, a nie każdej możliwej permutacji
Zacznij od skutków biznesowych modułu. Która operacja może zmienić pieniądze, stan magazynowy, dane klientów lub zakres sklepu? Które punkty rozszerzeń zmieniły się w wersji kandydującej? Które zależności zewnętrzne mogą powodować opóźnione lub podwójne wyniki?
Użyj macierzy łączącej każde ryzyko z dowodami:
| Obszar modułu | Kwestia związana z wersją kandydującą | Wymagana obserwacja |
|---|---|---|
| Integracja procesu zakupu | Nowy cykl życia interakcji | Prawidłowe końcowe zamówienie i odzyskiwanie |
| Rozszerzenie Back Office | Zmigrowane formularze i siatki | Utrwalone dane i uprawnienia |
| Pole niestandardowe | Eksperymentalny kontrakt rozszerzeń | Typ, zakres i widoczność |
| Zasób lub klient API | Zmieniony schemat lub mapowanie | Kontrakt żądania/odpowiedzi |
| Operacja w tle | Brak kontekstu interaktywnego | Jawny zakres i bezpieczne ponowienie |
| Instalator lub mechanizm aktualizacji | Istniejące dane klientów | Niedestrukcyjny cykl życia |
Następnie wybierz reprezentatywne kombinacje. Przetestuj najniższą i najwyższą wersję środowiska wykonawczego, które deklarujesz jako obsługiwane, wraz z kombinacjami zależności najczęściej ujawniającymi różnice. Dodaj ukierunkowane przypadki, gdy kod rozgałęzia się według wersji platformy.
Nie twierdź, że macierz parami dowodzi poprawności każdej kombinacji. Jest to strategia pokrycia, której ograniczenia należy dokumentować.
Traktuj proces zakupu i zmigrowane strony jako osobne obszary integracji
W przypadku modułu procesu zakupu sprawdź zarówno obsługiwany przebieg zakupu, jak i zależne interakcje płatności lub przewoźnika. Testuj odświeżenie, zmianę adresu, nieudane wysłanie i ponowną inicjalizację. Moduł reagujący tylko na początkowe załadowanie strony może zachowywać się inaczej w natywnym procesie na jednej stronie.
Dla Hummingbird lub motywu potomnego zapisz rewizję motywu i istotne nadpisania. Kontrakt szablonów i DOM procesu zakupu jest konkretną zależnością integracji, a nie jedynie preferencją stylistyczną. Oficjalny kontrakt motywu procesu zakupu.
Dla rozszerzeń administracyjnych ustal zmigrowane strony i aktywne flagi. Testuj zamierzony zapis formularza, filtr siatki i granicę uprawnień pracowników na każdej obsługiwanej ścieżce. Nie używaj podstawowego testu wyłącznie jako SuperAdmin jako dowodu działania procesów zwykłych pracowników.
Sprawdź, czy kod zgodności nie wykonuje się dwukrotnie, gdy zarejestrowane są stare i nowe hooki. Brak błędu krytycznego nie wystarcza, jeśli jedna czynność powoduje podwójne zapisy lub powiadomienia.
Wydawca powinien umieć powiązać każdą zmianę zgodności z przypadkiem powodującym błąd lub udokumentowaną zmianą kontraktu. Unikaj szerokich przeróbek, których korzyści nie można wykazać.
Sprawdź założenia środowiska wykonawczego i usługi właściwe dla wersji
Zgodność środowiska wykonawczego obejmuje kod uruchamiany wyłącznie na nietypowych etapach cyklu życia: instalacji, odinstalowania, zadań harmonogramu, obsługi błędów i wywołań zwrotnych dostawcy. Sprawdź te ścieżki w wersjach środowiska objętych deklarowanym zakresem obsługi.
Prace w wersji 9.2 dodają obsługę definicji usług PHP i plików usług YAML właściwych dla wersji. Umożliwia to dostosowanie powiązań usług przy zachowaniu obsługi starszych wersji, ale wybrane zachowanie ładowania trzeba sprawdzić w odpowiadającej mu implementacji. Zmiana konfiguracji usług właściwej dla wersji.
Jeśli zastosujesz ten mechanizm, przetestuj kontener usług na każdej deklarowanej gałęzi platformy. Potwierdź, który plik jest wybierany i że żadna usługa nie istnieje tylko dlatego, że lokalna pamięć podręczna programisty zachowała starą definicję. Nie zakładaj, że wszystkie alternatywne pliki usług zostaną połączone.
Dla deklaracji obsługi PHP 8.5 sprawdź składnię i wykonaj odpowiednie testy na samym PHP 8.5. Zgodność rdzenia nie potwierdza automatycznie zależności modułu. Informacje o wydaniu RC wymieniają poprawki związane z PHP 8.5, co wzmacnia potrzebę testów właściwych dla wersji zamiast ogólnego wnioskowania. Dziennik zmian wersji kandydującej.
Sprawdź także założenia dotyczące skończonych zbiorów wartości. Zmiana stanu produktu w wersji 9.2 dodaje wartości, które moduł ze sztywno zakodowaną listą dozwolonych wartości może odrzucać lub błędnie oznaczać. Jeśli moduł odczytuje stany, porównaj obsługiwane wartości z rzeczywistym typem wyliczeniowym wersji kandydującej i określ zachowanie dla nieznanej wartości. Zmiana stanu produktu.
Przetestuj ciągłość danych klientów podczas operacji cyklu życia
Zainstaluj wydaną wersję modułu w jednorazowym środowisku bazowym, utwórz reprezentatywne dane, a następnie zastosuj kandydującą aktualizację modułu przez obsługiwany mechanizm. Sprawdź, czy istniejące wartości zachowują znaczenie i czy nowe wartości domyślne nie nadpisują celowych ustawień.
Powtórz próbę aktualizacji, gdy cykl życia na to pozwala. Częściowo wykonana aktualizacja nie powinna tworzyć podwójnych definicji, indeksów ani rekordów biznesowych. Zapisz, jak moduł wykrywa przerwany krok i wznawia pracę.
Testuj wyłączenie i ponowne włączenie osobno od odinstalowania. Sprzedawcy często wyłączają moduł podczas diagnozowania innego problemu; ta czynność powinna być zgodna z udokumentowaną polityką przechowywania danych. Jeśli odinstalowanie może usuwać dane, określ tę politykę jawnie i sprawdź ją na syntetycznych rekordach.
Dla Extra Properties lub własnych tabel uwzględnij warianty sklepu i języka. Migracja zachowująca wyłącznie sklep domyślny może wydawać się udana na prostych danych testowych, jednocześnie tracąc informacje ważne dla klienta wielosklepowego.
Nie używaj destrukcyjnego czyszczenia tylko po to, by pakiet instalował się ponownie bez problemów podczas programowania. Komercyjny cykl życia musi odzwierciedlać oczekiwania klientów i opublikowaną politykę modułu.
Zweryfikuj artefakt dystrybucyjny
Uruchom zestaw testów akceptacyjnych na archiwum, które pobiorą klienci. Kopia deweloperska może zawierać wygenerowane zasoby, zależności dostawców lub pliki konfiguracji nieobecne w spakowanym module.
Sprawdź strukturę archiwum i wymagane pliki. Potwierdź instalację przez obsługiwany Back Office lub proces wdrożenia oraz ładowanie zasobów bez zależności od narzędzi deweloperskich. Zachowuj testy i artefakty kompilacji tylko tam, gdzie proces dystrybucji celowo ich wymaga.
Sprawdź, czy nie dołączono danych uwierzytelniających, lokalnych plików środowiska ani wyciągów z produkcji. To konkretna kontrola pakowania, a nie powód, by dodawać nieistotne treści o zgodności formalnej do interfejsu użytkownika produktu.
Zapisz sumę kontrolną artefaktu lub identyfikator kompilacji razem z wynikami testów. Jeśli po kwalifikacji pakiet zostanie zbudowany ponownie, ustal, czy zmieniła się zawartość, i ponownie wykonaj odpowiednie kontrole. Sama etykieta wersji nie pozwala odróżnić dwóch różnych archiwów z tym samym numerem.
Nadaj ograniczeniu obsługi granicę sprawdzalną testem
Ograniczenie powinno identyfikować wyłączone zachowanie, a nie tylko stwierdzać, że niektóre funkcje nie są obsługiwane. Jeśli rozszerzenie obsługuje dawną ścieżkę administracyjną, ale nie zmigrowaną, zapisz odpowiednią stronę i test wykazujący lukę. Jeśli integracja płatności wyklucza konkretną interakcję na jednej stronie, nazwij tę interakcję i obsługiwaną alternatywę.
Unikaj przedstawiania obejścia za pomocą flagi jako trwałej gwarancji. Może być przydatne podczas oceny wersji kandydującej, ale przyszłe wydanie może wycofać starą ścieżkę. Przypisz osobę odpowiedzialną za adaptację i śledź warunek usunięcia ograniczenia.
Dla zależności zewnętrznych zachowaj deklarację dostawcy właściwą dla wersji razem z własnymi wynikami. Jeśli dostawca później wycofa wsparcie lub zmieni kontrakt, zapis dowodów jasno wskaże kombinacje klientów wymagające przeglądu.
Poprawia to także klasyfikację zgłoszeń wsparcia. Incydent wewnątrz deklarowanej macierzy to potencjalna regresja. Incydent poza nią również warto zbadać, ale nie należy go mylić z wcześniej zakwalifikowaną kombinacją.
Opisz różnicę językiem użytecznym dla sprzedawców: operacja, wersje i praktyczny skutek. Wewnętrzne nazwy zestawów testów są przydatne inżynierom, ale nie powinny być jedynym wyjaśnieniem przekazywanym klientowi.
Publikuj ograniczenia pomagające sprzedawcom podejmować decyzje
Informacje o wydaniu powinny wskazywać nowo obsługiwane zachowania, przetestowane kombinacje i nadal wyłączone elementy. „Różne poprawki zgodności” niewiele mówi sprzedawcy o tym, czy jego proces zakupu lub wielosklepowy przepływ pracy jest objęty obsługą.
Zapewnij pierwszym testerom krótki szablon odtworzenia problemu: wersje rdzenia, modułu i motywu, aktywne flagi, kontekst sklepu i kolejność działań. Ogranicza to wymianę wiadomości poświęconą odtwarzaniu środowiska.
Po oficjalnym wydaniu stabilnego 9.2 porównaj jego końcowe zmiany z zakwalifikowaną wersją kandydującą i ponownie wykonaj odpowiednią część macierzy przed rozszerzeniem deklaracji obsługi. Pomyślne testy wersji kandydującej są cennym przygotowaniem, ale nadal odnoszą się do jej artefaktu.
Silna deklaracja zgodności jest więc pakietem dowodów: ograniczonym kontraktem obsługi, ukierunkowanymi przypadkami regresji, zweryfikowanym archiwum dystrybucyjnym i uczciwymi ograniczeniami. Pomaga to sprzedawcom decydować o wdrożeniu i daje wydawcy możliwą do opanowania granicę wsparcia.
Kontekst platformy bazowej znajdziesz w naszym poradniku tworzenia modułów PrestaShop 9 i zastosuj powyższe kontrole właściwe dla wersji do ocenianej instalacji.
Wybierając rozszerzenie, przejrzyj moduły PrestaShop 9 od PrestaSuite i porównaj udokumentowaną obsługę wersji oraz wymagania integracji z własnymi wynikami testów.