--- title: "Pakiet testów Resolvera GS1: DPP-Linki — rzetelna weryfikacja przed uruchomieniem produkcyjnym — qr3.app Blog" description: "Stabilny pakiet testów GS1 umożliwia weryfikację Resolvera 1.2. Sprawdź przekierowania, zestawy linków, CORS, języki i przypadki błędów przed uruchomieniem produkcyjnym." canonical: "https://qr3.app/pl/blog/gs1-resolver-test-suite-dpp-links/" lang: "pl" robots: "index,follow,max-image-preview:large,max-snippet:-1" --- # Pakiet testów Resolvera GS1: DPP-Linki — rzetelna weryfikacja przed uruchomieniem produkcyjnym — qr3.app Blog > Stabilny pakiet testów GS1 umożliwia weryfikację Resolvera 1.2. Sprawdź przekierowania, zestawy linków, CORS, języki i przypadki błędów przed uruchomieniem produkcyjnym. Canonical: [← Blog](/pl/blog/) [Poradniki](/pl/blog/category/tutorials/) 9 sierpnia 2026 5 min czytania [Poradniki](/pl/blog/category/tutorials/) [gs1-resolver](/pl/blog/tag/gs1-resolver/)[gs1-digital-link](/pl/blog/tag/gs1-digital-link/)[linkset](/pl/blog/tag/linkset/)[konformitaetstests](/pl/blog/tag/konformitaetstests/)[dpp](/pl/blog/tag/dpp/) # Pakiet testów Resolvera GS1: DPP-Linki — rzetelna weryfikacja przed uruchomieniem produkcyjnym Stabilny pakiet testów GS1 umożliwia weryfikację Resolvera 1.2. Sprawdź przekierowania, zestawy linków, CORS, języki i przypadki błędów przed uruchomieniem produkcyjnym. autor: **QR3 Redaktion** ![Pakiet testów Resolvera GS1: DPP-Linki — rzetelna weryfikacja przed uruchomieniem produkcyjnym](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-resolver-test-suite-dpp-links/hero.png) Kod QR, który otwiera stronę w przeglądarce, nie dowodzi jeszcze niezawodności Resolvera. W przypadku Resolvera GS1 dla tego standardu liczy się pełne zachowanie HTTP: Które identyfikatory są akceptowane? Jaki cel jest domyślny? Czy usługa dostarcza czytelny maszynowo zestaw linków? Czy dostęp z przeglądarki z innych domen działa? Czy nieprawidłowe lub niedostępne żądania zgłaszają właściwy błąd? Od **16 stycznia 2026 r.** dostępny jest [GS1-Conformant Resolver Standard 1.2.0](https://ref.gs1.org/standards/resolver/archive). Powiązany z nim [publiczny pakiet testów GS1](https://ref.gs1.org/test-suites/resolver/) jest obecnie uznawany za stabilny; jego kod zaktualizowano ostatnio **29 czerwca 2026 r.** Dzięki temu abstrakcyjną normę można przekształcić w konkretny test odbiorczy. W tym artykule pokazano, co należy sprawdzić przed uruchomieniem produkcyjnym, jakie ograniczenia ma pakiet testów i jakie dowody powinny znaleźć się w technicznej akceptacji. ## Udane skanowanie to dopiero początek Jeden GS1 Digital Link zawiera identyfikator GS1 w identyfikatorze URI HTTPS. Resolver łączy ten identyfikator z jednym lub wieloma zasobami, na przykład stroną produktu, instrukcją, kartą danych lub interfejsem programistycznym. Nasz artykuł podstawowy wyjaśnia działanie [Resolvera GS1 dla tego rozwiązania na żywym przykładzie](https://qr3.app/de/blog/gs1-digital-link-resolver/). Do uruchomienia produkcyjnego nie wystarczy jednak udane standardowe przekierowanie. [Standard Resolvera 1.2.0](https://ref.gs1.org/standards/resolver/) wymaga między innymi protokołu HTTPS, obsługi `GET`, `HEAD` i `OPTIONS`, mechanizmu Cross-Origin Resource Sharing (CORS), rozpoznawalnego linku domyślnego oraz wyjścia w postaci zestawu linków. W przypadku `linkType=linkset` lub nagłówka Accept `application/linkset+json` Resolver nie może przekierowywać. Zamiast tego musi zwrócić dostępne linki typowane jako samodzielną reprezentację. To rozdzielenie jest ważne: ścieżka użytkownika w przeglądarce może działać, podczas gdy dostęp maszynowy, język, typy linków lub przypadki błędów są wadliwe. Dokładnie takie rozbieżności pozostają niewidoczne przy samym teście skanowania. ## Plan odbioru w siedmiu krokach ### 1. Ustalenie reprezentatywnych testowych identyfikatorów URI Nie zaczynaj od jednego przykładowego produktu. Przygotuj niewielki, wersjonowany zestaw testów: - co najmniej jeden prawidłowy identyfikator dla każdego obsługiwanego klucza głównego GS1; - przypadek GTIN bez kwalifikatora; - przypadki z partią lub numerem seryjnym, o ile obsługiwana jest taka szczegółowość; - składniowo nieprawidłowy identyfikator; - prawidłowy, ale nieznany identyfikator; - znany identyfikator bez żądanego typu linku. Standard pozwala Resolverowi obsługiwać tylko podzbiór kluczy głównych GS1. Dla każdego obsługiwanego klucza głównego trzeba jednak w pełni przetwarzać jego kwalifikatory i atrybuty danych. Dlatego zestaw testowy musi odpowiadać rzeczywiście deklarowanym możliwościom, a nie ogólnemu przekazowi marketingowemu. ### 2. Sprawdzenie standardowego przekierowania i metod Najpierw przetestuj zwykłe wywołanie bez specjalnych nagłówków. Oczekiwany jest deterministyczny link domyślny. Następnie sprawdź `HEAD` i `OPTIONS`: `HEAD` nie może stosować innej logiki routingu niż `GET`, a `OPTIONS` musi w zrozumiały sposób przedstawiać oferowane metody. Minimalny test ręczny wygląda tak: ``` curl -sS -D - -o /dev/null \ "https://id.gs1.org/01/09506000134352" curl -sS -I \ "https://id.gs1.org/01/09506000134352" ``` Udokumentuj kod statusu, `Location`, nagłówki pamięci podręcznej oraz liczbę przekierowań. Pętla przekierowań, losowy cel lub ścieżka różniąca się zależnie od metody oznacza błąd dyskwalifikujący, nawet jeśli smartfon ostatecznie wyświetli stronę. ### 3. Żądanie zestawu linków zamiast strony internetowej Najważniejszym testem maszynowym jest zestaw linków: ``` curl -sS \ -H "Accept: application/linkset+json" \ "https://id.gs1.org/01/09506000134352" ``` [RFC 9264](https://datatracker.ietf.org/doc/html/rfc9264) definiuje `application/linkset+json` jako samodzielną reprezentację JSON zbioru typowanych linków internetowych. GS1 zaostrza wymagania: wynik musi przejść walidację względem [normatywnego schematu zestawu linków dla wersji 1.2.0](https://ref.gs1.org/standards/resolver/1.2.0/linkset-schema). Dlatego sprawdzaj nie tylko, czy zwracany jest JSON, lecz także typ multimediów, schemat, bezwzględne identyfikatory URI celów, Anchor i relacje linków. Szczególnie zdradliwe są formalnie prawidłowe, lecz merytorycznie błędne zestawy linków: na przykład podręcznik pod typem linku przeznaczonym dla strony z informacjami o produkcie albo cel dotyczący serii na poziomie GTIN. Dlatego walidacja schematu i fixture'y merytoryczne muszą być stosowane razem. ### 4. Kontrola opisu Resolvera Zgodny z wymaganiami Resolver udostępnia pod adresem `/.well-known/gs1resolver` czytelny maszynowo opis. Zawiera on między innymi podstawę Resolvera i obsługiwane klucze główne. Plik musi przejść walidację względem [schematu GS1 dla plików opisu Resolvera](https://ref.gs1.org/standards/resolver/1.2.0/description-file-schema). Test ten zapobiega częstej niespójności: usługa może obsługiwać więcej lub mniej, niż wynika z jej własnej deklaracji. Dlatego w odbiorze uwzględnij zarówno walidację schematu, jak i porównanie z rzeczywistymi przypadkami testowymi. ### 5. Testowanie CORS i negocjowania treści CORS nie jest funkcją dodatkową. Standard wymaga go, aby aplikacje przeglądarkowe mogły komunikować się z Resolverem między domenami. Przetestuj co najmniej jeden dozwolony Origin przeglądarki oraz ścieżkę preflight. Sprawdź także, czy `Accept: application/linkset+json` i `linkType=linkset` zwracają spójne wyniki. Dodaj test negatywny dla nieobsługiwanego typu multimediów. Usługa, która niezależnie od nagłówka `Accept` zawsze wysyła HTML, jest wprawdzie dostępna dla ludzi, ale nie zapewnia niezawodnego odczytu maszynowego. ### 6. Uwzględnienie języka, kontekstu i szczegółowości Standard przewiduje `Accept-Language` oraz parametr zapytania `context` jako środki rozróżniania kilku pasujących linków. Nie każdy Resolver musi oferować każdą z tych możliwości. Jeśli obsługiwany jest język lub kontekst, reguły wyboru muszą być jednak powtarzalne. Przetestuj więc dostępny język, niedostępny język oraz zdefiniowaną kolejność awaryjną. W przypadku GTIN, partii i numeru seryjnego obowiązuje ta sama zasada: szczegółowy identyfikator może uwzględniać istotne linki z wyższych poziomów, nie zacierając przy tym przyporządkowania merytorycznego. Zapisz oczekiwaną liczbę linków jako fixture; same testy snapshot sprawdzające kolejność są zbyt kruche. ### 7. Semantyczne rozróżnianie błędów Kody błędów są częścią kontraktu. Standard Resolvera przewiduje dla składniowo nieprawidłowych identyfikatorów GS1 komunikat z HTTP 400. Gdy żądany jest konkretny, niedostępny typ linku, przekierowanie do celu domyślnego nie jest właściwą odpowiedzią. Takie przypadki trzeba odróżniać od nieznanego, lecz składniowo prawidłowego identyfikatora. Sprawdź także, czy odpowiedzi błędów nie ujawniają szczegółów wewnętrznych, tokenów ani śladów stosu oraz czy `GET`, `HEAD` i żądania przeglądarkowe zachowują tę samą semantykę. Estetyczny dokument HTML z błędem nie naprawi nieprawidłowego kodu statusu. ## Właściwe wykorzystanie pakietu testów GS1 Publiczny pakiet testów przyjmuje identyfikator URI tego rozwiązania i sprawdza zachowanie względem Resolvera 1.2.0. Dobrze nadaje się jako niezależny test dymny i zgodności. Na potrzeby akceptacji zapisz datę testu, testowany identyfikator URI, wersję standardu, wynik oraz — w razie potrzeby — odtwarzalne przypadki błędów. Pakiet nie zastępuje jednak własnej regresji. GS1 wyraźnie wskazuje, że obecnie nie sprawdza kompresji. Jeśli Twój Resolver przetwarza binarne ciągi EPC lub inne skompresowane formy, potrzebujesz do tego osobnych wektorów testowych. Publiczny pakiet nie zna również Twoich merytorycznych typów linków ani wymagań dotyczących autoryzacji, dzierżawców lub dostępności. Niezawodny proces łączy zatem trzy poziomy: 1. publiczny pakiet GS1 jako zewnętrzny test zgodności; 2. testy schematów zestawu linków i opisu Resolvera w CI; 3. własne testy end-to-end dla rzeczywistych identyfikatorów, ról, języków i awarii. ## Co powinno znaleźć się w dowodzie akceptacji Akceptacja jest powtarzalna dopiero wtedy, gdy wynik jest nie tylko widoczny w przeglądarce, lecz także udokumentowany. Dowód akceptacji powinien zawierać co najmniej wersję standardu i pakietu, czas testu, środowisko docelowe, testowe identyfikatory URI, oczekiwane typy linków, wyniki HTTP, walidację schematu, kontrolę CORS oraz znane wyjątki. Stabilne elementy automatyzuj w CI, ale przed każdą istotną zmianą Resolvera wykonuj ukierunkowany zewnętrzny test względem publicznego pakietu. W ten sposób stwierdzenie „kod QR się otwiera” staje się weryfikowalną informacją o tożsamości, routingu i czytelnych maszynowo informacjach o produkcie. ## Źródła - [GS1-Conformant Resolver Standard 1.2.0](https://ref.gs1.org/standards/resolver/) - [Archiwum standardu GS1 Resolver — publikacja z 16 stycznia 2026 r.](https://ref.gs1.org/standards/resolver/archive) - [GS1 Digital Link Resolver Test Suite — kod zaktualizowany ostatnio 29 czerwca 2026 r.](https://ref.gs1.org/test-suites/resolver/) - [Artefakty GS1 Resolver 1.2.0 i normatywne schematy](https://ref.gs1.org/standards/resolver/artefacts) - [IETF RFC 9264 – Linkset: Media Types and a Link Relation Type for Link Sets](https://datatracker.ietf.org/doc/html/rfc9264) ## Powiązane artykuły - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/dpp-battery-passport-2027-20260715/hero.png) Wiadomości branżowe BatteryPass-Ready uruchamia środowisko testowe dla Cyfrowego Paszportu Baterii Konsorcjum BatteryPass-Ready uruchomiło 24 czerwca 2026 r. publiczne środowisko testowe dla Cyfrowego Paszportu Baterii, z myślą o obowiązku UE od lutego 2027 r.](/pl/blog/dpp-battery-passport-2027-20260715/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/sector-20260713/hero.png) Wiadomości branżowe Cyfrowy paszport baterii 2027: co producenci muszą wiedzieć już teraz Webinary, narzędzia open source i nowe normy: unijny paszport baterii nabiera tempa. Przegląd sytuacji w lipcu 2026 r. i otwartych kwestii do lutego 2027 r.](/pl/blog/sector-20260713/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/sector-20260711/hero.png) Wiadomości branżowe Cyfrowy paszport baterii 2026: środowiska testowe, normy i otwarte pytania Jak przemysł radzi sobie z Cyfrowym Paszportem Baterii? Przegląd środowisk testowych, norm CEN/CENELEC, narzędzi open source i zmian regulacyjnych w lipcu 2026 r.](/pl/blog/sector-20260711/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/regulation-20260708/hero.png) Regulacje Cyfrowy paszport baterii 2027: co naprawdę nakazuje rozporządzenie UE Od lutego 2027 r. Cyfrowy paszport baterii będzie obowiązkowy. Co konkretnie nakazuje (UE) 2023/1542, gdzie branża wciąż zawodzi i jakie standardy obowiązują.](/pl/blog/regulation-20260708/) [← Wszystkie artykuły](/pl/blog/) [Zacznij za darmo](https://app.qr3.app/sign-up)