---
title: "GS1 Resolver tesztcsomag: DPP-hivatkozások megbízható ellenőrzése az élesítés előtt — qr3.app Blog"
description: "A stabil GS1-tesztcsomag ellenőrizhetővé teszi a Resolver 1.2-t. Így tesztelhetők az átirányítások, linkkészletek, a CORS, a nyelvek és a hibás esetek az élesítés előtt."
canonical: "https://qr3.app/hu/blog/gs1-resolver-test-suite-dpp-links/"
lang: "hu"
robots: "index,follow,max-image-preview:large,max-snippet:-1"
---

# GS1 Resolver tesztcsomag: DPP-hivatkozások megbízható ellenőrzése az élesítés előtt — qr3.app Blog

> A stabil GS1-tesztcsomag ellenőrizhetővé teszi a Resolver 1.2-t. Így tesztelhetők az átirányítások, linkkészletek, a CORS, a nyelvek és a hibás esetek az élesítés előtt.

Canonical: <https://qr3.app/hu/blog/gs1-resolver-test-suite-dpp-links/>

[← Blog](/hu/blog/) [Oktatóanyagok](/hu/blog/category/tutorials/)

2026. augusztus 9. 5 perc olvasás [Oktatóanyagok](/hu/blog/category/tutorials/) [gs1-resolver](/hu/blog/tag/gs1-resolver/)[gs1-digital-link](/hu/blog/tag/gs1-digital-link/)[linkset](/hu/blog/tag/linkset/)[konformitaetstests](/hu/blog/tag/konformitaetstests/)[dpp](/hu/blog/tag/dpp/)

# GS1 Resolver tesztcsomag: DPP-hivatkozások megbízható ellenőrzése az élesítés előtt

A stabil GS1-tesztcsomag ellenőrizhetővé teszi a Resolver 1.2-t. Így tesztelhetők az átirányítások, linkkészletek, a CORS, a nyelvek és a hibás esetek az élesítés előtt.

szerző: **QR3 Redaktion**

![GS1 Resolver tesztcsomag: DPP-hivatkozások megbízható ellenőrzése az élesítés előtt](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-resolver-test-suite-dpp-links/hero.png)

Egy QR-kód, amely megnyit egy oldalt a böngészőben, még nem bizonyítja a resolver megbízható működését. Egy GS1 digitális hivatkozás-feloldó esetében a teljes HTTP-viselkedés számít: Mely azonosítókat fogadja el? Mi az alapértelmezett cél? A szolgáltatás géppel olvasható linkkészletet ad vissza? Működik a böngészőből indított hozzáférés más domaineken keresztül? És a hibás vagy nem elérhető kérések a megfelelő hibát jelzik?

**2026. január 16.** óta elérhető a [GS1-Conformant Resolver Standard 1.2.0](https://ref.gs1.org/standards/resolver/archive). A hozzá tartozó [nyilvános GS1-tesztcsomag](https://ref.gs1.org/test-suites/resolver/) időközben stabilnak számít; a kódját legutóbb **2026. június 29-én** frissítették. Így az absztrakt szabványból konkrét átvételi teszt készíthető. Ez a cikk bemutatja, mit érdemes ellenőrizni az élesítés előtt, hol vannak a tesztcsomag korlátai, és milyen bizonyítékoknak kell szerepelniük a műszaki jóváhagyásban.

## A sikeres beolvasás csak a kezdet

Egy GS1 Digital Link HTTPS-URI-ban hordoz GS1-azonosítót. A resolver ezt az azonosítót egy vagy több erőforrással kapcsolja össze, például termékoldallal, útmutatóval, adatlap­pal vagy programozási felülettel. Alapozó cikkünk egy [élő példán keresztül ismerteti a GS1 digitális hivatkozás-feloldót](https://qr3.app/de/blog/gs1-digital-link-resolver/). Éles környezetbe engedéshez azonban nem elegendő a sikeres alapértelmezett átirányítás.

A [Resolver Standard 1.2.0](https://ref.gs1.org/standards/resolver/) többek között HTTPS-t, a `GET`, `HEAD` és `OPTIONS` támogatását, Cross-Origin Resource Sharinget (CORS), felismerhető alapértelmezett hivatkozást és linkkészlet-kimenetet ír elő. `linkType=linkset` vagy a `application/linkset+json` Accept-fejléc esetén a resolver nem irányíthat át. Ehelyett az elérhető, típusozott hivatkozásokat önálló reprezentációként kell visszaadnia.

Ez a különbségtétel fontos: az emberi böngészési útvonal működhet, miközben a gépi hozzáférés, a nyelv, a hivatkozástípusok vagy a hibás esetek hibásak. Az ilyen eltérések egy pusztán beolvasásra épülő teszt során rejtve maradnak.

## Az átvételi terv hét lépésben

### 1. Reprezentatív teszt-URI-k meghatározása

Ne egyetlen mintatermékkel kezdjen. Állítson össze egy kis, verziózott tesztgyűjteményt:

- legalább egy érvényes azonosító minden támogatott GS1-elsődleges kulcshoz;

- egy GTIN-eset minősítő nélkül;

- tétel- vagy sorozatszámot tartalmazó esetek, amennyiben ez a részletességi szint támogatott;

- szintaktikailag érvénytelen azonosító;

- érvényes, de ismeretlen azonosító;

- ismert azonosító a kért hivatkozástípus nélkül.

A szabvány lehetővé teszi, hogy egy resolver a GS1-elsődleges kulcsoknak csak egy részhalmazát támogassa. Minden támogatott elsődleges kulcs esetében azonban annak minősítőit és adatattribútumait teljes körűen fel kell dolgozni. Ezért a tesztkészletnek a ténylegesen deklarált képességekhez, nem pedig általános marketingállításhoz kell igazodnia.

### 2. Az alapértelmezett átirányítás és a metódusok ellenőrzése

Először tesztelje a normál hívást különleges fejlécek nélkül. Determinisztikus alapértelmezett hivatkozás az elvárt eredmény. Ezt követi a `HEAD` és a `OPTIONS`: a `HEAD` nem használhat más útválasztási logikát, mint a `GET`, a `OPTIONS`-nak pedig áttekinthetővé kell tennie a kínált metódusokat.

Egy minimális manuális teszt így néz ki:

```
curl -sS -D - -o /dev/null \
  "https://id.gs1.org/01/09506000134352"

curl -sS -I \
  "https://id.gs1.org/01/09506000134352"
```

Dokumentálja az állapotkódot, a `Location`-t, a gyorsítótár-fejléceket és az átirányítások számát. Az átirányítási hurok, a véletlenszerű cél vagy a metódusonként eltérő útvonal jóváhagyási hiba, még akkor is, ha egy okostelefon végül megjelenít egy oldalt.

### 3. Weboldal helyett linkkészlet kérése

A legfontosabb gépi ellenőrzés a linkkészlet:

```
curl -sS \
  -H "Accept: application/linkset+json" \
  "https://id.gs1.org/01/09506000134352"
```

Az [RFC 9264](https://datatracker.ietf.org/doc/html/rfc9264) a `application/linkset+json`-t típusozott webhivatkozások halmazának önálló JSON-reprezentációjaként definiálja. A GS1 szigorítja a szerződést: a kimenetnek validálnia kell az [1.2.0-s verzió normatív linkkészlet-sémája](https://ref.gs1.org/standards/resolver/1.2.0/linkset-schema) ellen. Ezért ne csak azt ellenőrizze, hogy érkezik-e JSON, hanem a médiatípust, a sémát, az abszolút cél-URI-kat, az Anchor mezőt és a hivatkozásrelációkat is.

Különösen megtévesztők a formailag érvényes, szakmailag azonban hibás linkkészletek: például egy kézikönyv a termékinformációs oldal hivatkozástípusával, vagy sorozathoz kötött cél a GTIN-szinten. Ezért a séma validálását és a szakmai fixture-öket együtt kell alkalmazni.

### 4. A resolver leírásának ellenőrzése

Egy megfelelő resolver a `/.well-known/gs1resolver` alatt géppel olvasható leírást biztosít. Ez többek között megnevezi a resolver gyökerét és a támogatott elsődleges kulcsokat. A fájlnak validálnia kell a [resolverleíró fájlokhoz készült GS1-séma](https://ref.gs1.org/standards/resolver/1.2.0/description-file-schema) ellen.

Ez a teszt egy gyakori ellentmondást előz meg: a szolgáltatás többre vagy kevesebbre képes, mint amit az önleírása állít. Ezért a jóváhagyásba a séma validálását és a valós tesztesetekkel való összevetést is vegye fel.

### 5. A CORS és a tartalom-egyeztetés tesztelése

A CORS nem kényelmi funkció. A szabvány azért írja elő, hogy a böngészőalapú alkalmazások domainközi módon elérhessék a resolvert. Teszteljen legalább egy engedélyezett böngésző-Origint és az előzetes kérést kezelő útvonalat. Ellenőrizze azt is, hogy a `Accept: application/linkset+json` és a `linkType=linkset` következetes eredményeket adnak-e.

Egészítse ki a tesztet egy nem támogatott médiatípusra vonatkozó negatív esettel. Az a szolgáltatás, amely a `Accept`-fejléctől függetlenül mindig HTML-t küld, emberek számára ugyan elérhető, de gépi feldolgozásra nem megbízható.

### 6. A nyelv, a kontextus és a részletesség lefedése

A szabvány a `Accept-Language`-t, valamint a `context` lekérdezési paramétert biztosítja az egymáshoz illeszkedő hivatkozások megkülönböztetésére. Nem minden resolvernek kell minden változatot kínálnia. Ha azonban támogatja a nyelvet vagy a kontextust, a kiválasztási szabályoknak reprodukálhatónak kell lenniük.

Teszteljen egy létező nyelvet, egy nem létező nyelvet és egy meghatározott tartalék-sorrendet. A GTIN, a tétel- és a sorozatszám esetében ugyanez az elv érvényes: a részletesebb azonosító figyelembe veheti a magasabb szintek releváns hivatkozásait anélkül, hogy elhomályosítaná a szakmai hozzárendelést. A várt hivatkozásmennyiséget fixture-ként rögzítse; a sorrendre épülő, tisztán snapshot-alapú tesztek túl törékenyek.

### 7. A hibák szemantikai megkülönböztetése

A hibakódok a szerződés részét képezik. A resolver szabványa a szintaktikailag érvénytelen GS1-azonosítókhoz HTTP 400-as választ ír elő. Ha egy konkrét, nem elérhető hivatkozástípust kérnek, az alapértelmezett célra való átirányítás éppen nem a helyes válasz. Ezeket az eseteket el kell különíteni az ismeretlen, de szintaktikailag érvényes azonosítótól.

Ellenőrizze azt is, hogy a hibaválaszok nem fednek-e fel belső részleteket, tokeneket vagy stack trace-eket, és hogy a `GET`, a `HEAD` és a böngészőalapú kérések ugyanazt a szemantikát őrzik-e. Egy tetszetős HTML-hibaoldal nem ellensúlyozhatja a hibás állapotkódot.

## A GS1-tesztcsomag helyes használata

A nyilvános tesztcsomag egy Digital Link-URI-t fogad, és a viselkedést a Resolver 1.2.0-val veti össze. Független smoke- és megfelelőségi ellenőrzésként jól használható. A jóváhagyáshoz mentse el a teszt dátumát, a tesztelt URI-t, a szabvány verzióját, az eredményt és adott esetben a reprodukálható hibás eseteket.

A csomag azonban nem helyettesíti a saját regressziós teszteket. A GS1 kifejezetten jelzi, hogy jelenleg nem ellenőrzi a tömörítést. Ha a resolver EPC bináris karakterláncokat vagy további tömörített formákat dolgoz fel, ezekhez külön tesztvektorokra van szükség. A nyilvános csomag ugyanígy nem ismeri az Ön szakmai hivatkozástípusait, illetve engedélyezési, bérlői vagy elérhetőségi követelményeit.

Ezért egy megbízható folyamat három szintet kombinál:

1. a nyilvános GS1-csomag külső megfelelőségi ellenőrzésként;

2. a linkkészlet és a resolverleírás séma­tesztjei CI-ban;

3. saját végponttól végpontig tesztek valós azonosítókhoz, szerepkörökhöz, nyelvekhez és kiesésekhez.

## Mi tartozzon a jóváhagyási bizonyítékok közé?

Az átvétel csak akkor ismételhető meg, ha az eredmény nemcsak a böngészőben látható, hanem dokumentált is. A jóváhagyási bizonyítéknak legalább a szabvány és a csomag verzióját, a teszt időpontját, a célkörnyezetet, a teszt-URI-kat, a várt hivatkozástípusokat, a HTTP-eredményeket, a séma validálását, a CORS-ellenőrzést és az ismert kivételeket kell tartalmaznia.

Automatizálja a stabil részeket CI-ban, de minden jelentős resolver-módosítás előtt végezzen célzott külső futtatást a nyilvános csomaggal. Így a „megnyílik a QR-kód” állításból ellenőrizhető kijelentés lesz az azonosítóról, az útválasztásról és a géppel olvasható termékinformációkról.

## Források

- [GS1-Conformant Resolver Standard 1.2.0](https://ref.gs1.org/standards/resolver/)

- [GS1 Resolver Standard Archive – közzétéve 2026. január 16-án](https://ref.gs1.org/standards/resolver/archive)

- [GS1 Digital Link Resolver Test Suite – a kód legutóbbi frissítése: 2026. június 29.](https://ref.gs1.org/test-suites/resolver/)

- [GS1 Resolver 1.2.0 artefaktumok és normatív sémák](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)

## Kapcsolódó cikkek

- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/dpp-battery-passport-2027-20260715/hero.png) Iparági hírek A BatteryPass-Ready elindította a Digitális Akkumulátor-útlevél tesztkörnyezetét A BatteryPass-Ready konzorcium 2026. június 24-én nyilvános tesztkörnyezetet indított a Digitális Akkumulátor-útlevélhez, az EU 2027 februárjától érvényes kötelezettségére tekintettel.](/hu/blog/dpp-battery-passport-2027-20260715/)
- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/sector-20260713/hero.png) Iparági hírek Digitális akkumulátor-útlevél 2027: amit a gyártóknak most tudniuk kell Webináriumok, nyílt forráskódú eszközök és új szabványok: az uniós akkumulátor-útlevél lendületet kapott. Áttekintés a 2026. júliusi helyzetről és a 2027 februárjáig tisztázandó kérdésekről.](/hu/blog/sector-20260713/)
- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/sector-20260711/hero.png) Iparági hírek Digitális akkumulátor-útlevél 2026: tesztkörnyezetek, szabványok és nyitott kérdések Hol tart az iparág a digitális akkumulátor-útlevél bevezetésében? Áttekintés a tesztkörnyezetekről, a CEN/CENELEC szabványairól, a nyílt forráskódú eszközökről és a 2026. júliusi szabályozási döntése.](/hu/blog/sector-20260711/)
- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/regulation-20260708/hero.png) Szabályozás Digitális akkumulátor-útlevél 2027: Mit ír elő valójában az uniós rendelet 2027 februárjától kötelező a digitális akkumulátor-útlevél. Mit követel meg konkrétan a (EU) 2023/1542 rendelet, hol vannak még hiányosságok, és milyen szabványok érvényesek?](/hu/blog/regulation-20260708/)

[← Minden cikk](/hu/blog/) [Kezdés ingyen](https://app.qr3.app/sign-up)