GS1 Resolver testu komplekts: DPP-saites rūpīgi pārbaudīt pirms palaišanas

QR kods, kas pārlūkprogrammā atver lapu, vēl nepierāda, ka resolveris darbojas uzticami. Digitālās saites resolverim svarīga ir pilnīga HTTP darbība: kādi identifikatori tiek pieņemti? Kurš mērķis ir noklusējuma mērķis? Vai pakalpojums nodrošina mašīnlasāmu saišu kopu? Vai pārlūkprogrammas pieprasījumi no citām domēnu izcelsmēm darbojas? Vai nederīgi vai nepieejami pieprasījumi atgriež pareizo kļūdu?

Kopš 2026. gada 16. janvāra ir pieejams GS1 Conformant Resolver Standard 1.2.0. Ar to saistītais publiskais GS1 testu komplekts tagad tiek uzskatīts par stabilu; tā kods pēdējo reizi atjaunināts 2026. gada 29. jūnijā. Tādējādi abstraktu standartu var pārvērst konkrētā pieņemšanas testā. Šajā rakstā skaidrots, kas jāpārbauda pirms palaišanas, kādi ir testu komplekta ierobežojumi un kādi pierādījumi jāiekļauj tehniskajā apstiprinājumā.

Veiksmīga skenēšana ir tikai sākums

Viens GS1 Digital Link satur GS1 identifikatoru HTTPS URI. Resolveris sasaista šo identifikatoru ar vienu vai vairākiem resursiem, piemēram, produkta lapu, lietošanas instrukciju, datu lapu vai programmēšanas saskarni. Mūsu pamatrakstā izskaidrots digitālās saites resolveris ar praktisku piemēru. Ražošanas vides apstiprināšanai tomēr nepietiek ar veiksmīgu standarta novirzīšanu.

Resolvera standarts 1.2.0 cita starpā pieprasa HTTPS, atbalstu GET, HEAD un OPTIONS, Cross-Origin Resource Sharing (CORS), identificējamu noklusējuma saiti un saišu kopas izvadi. Izmantojot linkType=linkset vai Accept galveni application/linkset+json, resolveris nedrīkst veikt novirzīšanu. Tā vietā tam jāatgriež pieejamās tipizētās saites kā patstāvīgs attēlojums.

Šis nošķīrums ir svarīgs: cilvēkam paredzētais pārlūkprogrammas ceļš var darboties, kamēr piekļuve no mašīnām, valodas, saišu veidi vai kļūmju scenāriji nedarbojas. Tieši šādas novirzes paliek nepamanītas, veicot tikai skenēšanas testu.

Pieņemšanas plāns septiņos soļos

1. Noteikt reprezentatīvas testa URI

Nesāciet ar vienu paraugproduktu. Izveidojiet nelielu, versiju kontrolētu testu kopumu:

vismaz vienu derīgu identifikatoru katrai atbalstītajai GS1 primārajai atslēgai;
vienu GTIN-gadījumu bez kvalifikatora;
gadījumus ar partijas numuru vai sērijas numuru, ja šāds detalizācijas līmenis tiek atbalstīts;
sintaktiski nederīgu identifikatoru;
derīgu, bet nezināmu identifikatoru;
zināmu identifikatoru bez pieprasītā saišu veida.

Standarts ļauj resolverim atbalstīt tikai daļu GS1 primāro atslēgu. Taču katrai atbalstītajai primārajai atslēgai tā kvalifikatori un datu atribūti jāapstrādā pilnībā. Tāpēc testa kopumam jāatbilst faktiski deklarētajām iespējām, nevis vispārīgam mārketinga apgalvojumam.

2. Pārbaudīt standarta novirzīšanu un metodes

Vispirms pārbaudiet parasto izsaukumu bez īpašām galvenēm. Sagaidāma deterministiska noklusējuma saite. Pēc tam seko HEAD un OPTIONS: HEAD nedrīkst izmantot citu maršrutēšanas loģiku kā GET, un OPTIONS ir skaidri jānorāda pieejamās metodes.

Minimāls manuāls tests izskatās šādi:

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

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

Dokumentējiet statusa kodu, Location, kešatmiņas galvenes un novirzīšanu skaitu. Novirzīšanas cilpa, nejaušs mērķis vai katrai metodei atšķirīgs ceļš ir apstiprināšanas kļūme, pat ja viedtālrunis beigās parāda kādu lapu.

3. Pieprasīt saišu kopu, nevis tīmekļa lapu

Svarīgākā mašīniskā pārbaude ir saišu kopa:

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

RFC 9264 definē application/linkset+json kā patstāvīgu tipizētu tīmekļa saišu kopas JSON attēlojumu. GS1 līguma prasības ir stingrākas: izvadei jāvalidējas pret normatīvo saišu kopas shēmu versijai 1.2.0. Tāpēc pārbaudiet ne tikai to, vai tiek atgriezts JSON, bet arī datu nesēja tipu, shēmu, absolūtās mērķa URI, enkuru un saišu attiecības.

Īpaši maldinošas ir formāli derīgas, bet saturiski nepareizas saišu kopas: piemēram, rokasgrāmata ar produkta informācijas lapai paredzētu saišu tipu vai ar sēriju saistīts mērķis GTIN līmenī. Tāpēc shēmas validācija un funkcionālie testa dati jāizmanto kopā.

4. Pārbaudīt resolvera aprakstu

Atbilstošs resolveris nodrošina mašīnlasāmu aprakstu vietnē /.well-known/gs1resolver. Tajā cita starpā norādīta resolvera sakne un atbalstītās primārās atslēgas. Failam jāvalidējas pret GS1 shēmu Resolver Description Files.

Šis tests novērš bieži sastopamu neatbilstību: pakalpojums spēj vairāk vai mazāk, nekā apgalvots tā pašaprakstā. Tāpēc pieņemšanas procesā iekļaujiet gan shēmas validāciju, gan salīdzināšanu ar reāliem testa gadījumiem.

5. Pārbaudīt CORS un satura vienošanos

CORS nav ērtības funkcija. Standarts to pieprasa, lai pārlūkprogrammu lietotnes varētu piekļūt resolverim no dažādiem domēniem. Pārbaudiet vismaz vienu atļautu pārlūkprogrammas izcelsmi un priekšpieprasījuma ceļu. Pārbaudiet arī, vai Accept: application/linkset+json un linkType=linkset sniedz konsekventus rezultātus.

Pievienojiet negatīvu testu neatbalstītam datu nesēja tipam. Pakalpojums, kas neatkarīgi no Accept galvenes vienmēr nosūta HTML, cilvēkiem ir pieejams, taču nav uzticami mašīnlasāms.

6. Aptvert valodu, kontekstu un detalizācijas līmeni

Standarts paredz Accept-Language un vaicājuma parametru context kā līdzekļus, lai nošķirtu vairākas atbilstošas saites. Ne katram resolverim jānodrošina katrs variants. Tomēr, ja tiek atbalstīta valoda vai konteksts, atlases noteikumiem jābūt atkārtojamiem.

Tāpēc pārbaudiet pieejamu valodu, nepieejamu valodu un noteiktu atkāpšanās secību. Uz GTIN, partijas numuru un sērijas numuru attiecas tas pats princips: detalizētāks identifikators drīkst ņemt vērā atbilstošas augstāka līmeņa saites, neizpludinot funkcionālo sasaisti. Sagaidāmo saišu kopumu fiksējiet kā testa datus; tīri momentuzņēmumu testi, kas pārbauda secību, ir pārāk trausli.

7. Semantiski nošķirt kļūdas

Kļūdu kodi ir līguma daļa. Resolvera standarts sintaktiski nederīgiem GS1 identifikatoriem paredz paziņojumu ar HTTP 400. Ja tiek pieprasīts konkrēts, nepieejams saišu tips, novirzīšana uz noklusējuma mērķi nebūt nav pareizā atbilde. Šādi gadījumi jānošķir no nezināma, bet sintaktiski derīga identifikatora.

Pārbaudiet arī, vai kļūdu atbildes neatklāj iekšēju informāciju, pilnvarojuma marķierus vai steka izdrukas un vai GET, HEAD un pārlūkprogrammu pieprasījumi saglabā to pašu semantiku. Glīts HTML kļūdas dokuments nevar kompensēt nepareizu statusa kodu.

Kā pareizi izmantot GS1 testu komplektu

Publiskais testu komplekts pieņem digitālās saites URI un pārbauda darbību atbilstoši Resolver 1.2.0. Tas ir labi piemērots neatkarīgai ātrajai un atbilstības pārbaudei. Apstiprināšanai saglabājiet testa datumu, pārbaudīto URI, standarta versiju, rezultātu un, ja nepieciešams, atkārtojamus kļūmju gadījumus.

Tomēr komplekts neaizstāj paša regresijas testus. GS1 skaidri norāda, ka pašlaik tas nepārbauda saspiešanu. Ja resolveris apstrādā EPC binārās virknes vai citas saspiestas formas, šim nolūkam nepieciešami atsevišķi testa vektori. Tāpat publiskais komplekts nepazīst jūsu funkcionālos saišu tipus, autorizācijas, nomnieku vai pieejamības prasības.

Tāpēc uzticams process apvieno trīs līmeņus:

publiskais GS1 komplekts kā ārēja atbilstības pārbaude;
saišu kopas un resolvera apraksta shēmu testi CI vidē;
paša gala–gala testi reāliem identifikatoriem, lomām, valodām un kļūmēm.

Kas jāiekļauj apstiprināšanas pierādījumā

Pieņemšana ir atkārtojama tikai tad, ja rezultāts ir ne vien redzams pārlūkprogrammā, bet arī dokumentēts. Apstiprināšanas pierādījumā vismaz jāietver standarta un komplekta versija, testa laiks, mērķa vide, testa URI, sagaidāmie saišu tipi, HTTP rezultāti, shēmas validācija, CORS pārbaude un zināmie izņēmumi.

Stabilās daļas automatizējiet CI vidē, taču pirms katrām būtiskām resolvera izmaiņām veiciet arī mērķētu ārēju testu pret publisko komplektu. Tā apgalvojums “QR kods atveras” kļūst par pārbaudāmu apgalvojumu par identitāti, maršrutēšanu un mašīnlasāmu produkta informāciju.